• Hello Rolf and Andrew,

    I have the same issue with an incorrect longitude value as I am further West in Vancouver Canada.

    Both the APM (3.1.2) and Taranis have the latest stable software version installed. I will try the suggestions in the thread (reload the Taranis firmware) and try your test code you just posted.



    • I found the problem, it was in my code . I have updated the file for the Teensy on the main page or you can get it here. Thank's for pointing this out for me
      • Rolf, thank you very much for fixing the code. The coordinates now work for me! (Toronto, Canada). The speed still displays 0 (SPD 0), but the coordinates were far more important for me (for quad recovery in case of a fly away).

  • Rolf, I flashed my Taranis with your FW (opentx-x9d-v1.1.02) and it still has the same bugs. Are you using the newest APM firmware? I am running the quadcopter 3.1.2 firmware, which is the newest

    • I was running fw 3.1, updated it to  3.1.2 and it still works for me...

      I have made a new file with simulated lat/long try to install this on the Teensy

      and see if you get 43'23,8644N, 79'16.3368E
           ap_rc_ch3 = mavlink_msg_rc_channels_scaled_get_chan3_scaled (& msg);

    works. Thank you.


  • Rolf,

    I was just looking at the information you provided about the conversion FrSky does to the incoming GPS Lat and Long data. It answered my questions about how it determined N-S and E-W. Now I'm wondering what the AP does to the raw GPS data. It has to be coming from the GPS in raw NMEA format.  What does the AP do with the raw data? I'd be happy to find it myself, if you can point me to the location of the GPS code.

    I still haven't figured out why the data is being zeroed out as it goes from MavLink_FrSkySPort.ino to FrSkySPort.ino.  I guess my lack of experience with C++ really shows.

    I really appreciate your help, patience, and all the hard work you put into this. Without your work to start from, I would never have attempted this in the first place.


    • See above...

      • I just now found the Mavlink RAW GPS code and saw that it deals in decimal degrees, not degrees and decimal minutes. Now it makes sense.

        I understand your program only sends data on a 3D fix. I turn on he LED when I have a 3D fix, so I have some visual confirmation of the fix. Like I said only the gps_status value is being passed to FrSkySPort.ino. All of the others are zero. I'll keep slogging away at it. It's the best way to learn I guess.

        Thanks again.


        • Is the Mavlink data coming from an APM with an GPS connected? or do you use something else as the mavlink source?

This reply was deleted.