Telemetry to Turnigy 9X (with FrSky FLD-02 Telemetry Display Screen)

Hi all,

My setup is this:

Transmitter: Turnigy 9X running er9x

TX/RX: FrSky DJT 2.4Ghz Combo Pack for JR w/ Telemetry Module & V8FR-I...

Flying thingy: 3RD Arducopter running APM1

I already have telemetry over Xbee to my laptop but I would like to have data to my hands as well.

There are mods/hacks on google how to get transmitter to show FrSky telemetry but I'm planning on taking the easy route and buy a separate FLD-02 screen. 

My questions:

1. Do you have experience using APM and the FLD-02?

2. Any reason why this is stupid? :-) I have no problems soldering tricky stuff but if there is a cheap and easy way (the FLD-02) then I'll take it!

Views: 13875

Reply to This

Replies to This Discussion



Thank you very much Vito for the pictures.

Hello all,

  First of all a very big thank you for you help in getting my IOBoard working with the FrSky and APM 2.5.

Good news...the data is flowing and I have information showing on the FLD-02 :)

A few things I have noticed:

Voltage: I am using a 4S battery however the voltage screen shows I am using a 3S battery and the cell voltages are incorrect. The screen will also briefly flick over to a second voltage screen which shows 1S before going back to the 3S screen.

RPM is not working off the throttle at all and remains on 0 constantly.

Ampere is not reading anything other than 0.

GPS and RSSI are working great.

I am using the firmware posted on Sunday by Vito following Mike's video post regarding the voltage issues. I have uploaded a video showing what is happening with my setup at the moment.

Thanks again for all your help. I am happy to test any firmwares and help in anyway I can.



I have been testing mine on the ground, so I havent tested ampere or RPM yet. I will test those when I fly this weekend. As for 4S, I forgot, I did make one very minor change to the code to support > 3S. You can grab my version from my forked repo:

I sent a pull request to Vito, so hopefully he can merge that in soon.

And my voltage screen is still a little jumpy, i think thats just the nature of the way the cells are reported across the telemetry protocol. Even with the slight flicker, the voltage screen is very useful!

Thanks Mike :)

I don't suppose you happen to have the file as a hex or could give me some quick instructions on how to upload the .ino. I have tried in Arduino 1.0.3 but it errors on the Title line of the code. I am probably doing something wrong :)

Give the attached hex a try. Ive never distributed a build like this, so hopefully I found the right .hex file.

As for building, the technique is similar to building ArduPilot. Basically the trick is to checkout the github code, and then open arduino, then into the preferences and change the sketchbook directory to the directory you checked out from github. After you restart arduino, from the File -> Sketchbook menu, you will see the jD_IOBoard -> jD_IOBoard_FrSkyMAVlink project. When you click on that, it will open the arduino code, along with several other files in tabs. Simply select your FTDI serial port and set the board type to Arduino Pro or Pro Mini (5V, 16Mhz) w/ ATMega328, then click the upload button.

Updated hex file


Thanks Mike.

I just tested the firmware, 4S is now reading correctly however the voltages are not correct. The display is showing the 4S battery as being around 15.5v however it it is almost nearly fully charged. I put it the battery on the charger to check and it is showing 16.7v. Any idea on the big difference in voltage reading?

Also with the previous firmware in the GPS section displayed N,S,E,W beside the lat/long. Is it possible to incorporate those into your battery fix firmware? I know it's a small visual thing but it does look good and may help.

Voltage comes directly from the mavlink feed. In fact, we dont even have the individual cell voltages, we fake it by dividing based on number of calculated cells. So that means if the voltage is off, APM is giving it the wrong value. Most likely this is a divider setup in the mission planner config on the power module page. I would expect the reported voltage in the mission planner to also be off - can you check and make sure its incorrect (and matches the telemetry voltage) there too for sanity sake?

As for N,S,E,W, I didn't change any of that code. They should be coming along just as they were before. I will need to double check mine tomorrow when I am at my workshop, but I was pretty sure they were showing up last night. 

I had a look Mike and you are exactly right, it is mission planner reading the voltage incorrectly. I think they may be a bit of a bug in mission planner though. I have a 3DR power module, I have set mission planner to "sensor: 3dr power module" and "APM Ver: APM2.5 - 3DR Power Module" and it is reading the measured battery voltage at 15.643v which is giving the calculated battery voltage around 15.7v.

In have then tried a number of option to try to correct it by changing the type of sensor and the voltage divider, at first it seems to work and has the voltage reading correctly around 16.6-16.8v. As soon as I then click back into the current sensor configuration screen it resets everything back to the default 3DR options and hence back to 15.7v. No matter what I do it won't save the changes I make. I have tried changing the divider in the advanced parameters list to, and then write it to the apm, I click back into the configuration screen and it resets again. Silly mission planner. Either that or my sensor of damaged.

Like many of you, I've been struggling to get the GPS data displaying correctly and hoped that Mike's code would provide the answer. Not in my case it didn't, though others have reported that 'it's working well'.

The problem I found was that the co-ords were still a factor of 100 out and Lat & Lon were displayed in the wrong order.

I changed the Mavlink GPS message divisor in Mavlink.ino back to 1E7 - this corrected the *100 error. Then I went through the FrSky_Funcs.ino file and discovered that the lat & lon items were being placed in the telemetry packet in the wrong order. The issue here was that the program correctly identifies e.g the longitude case as 0x12 & 0x12+8 but then codes it as 0x13 & 0x13+8 (and vise versa for the latitude). Correcting these parameters put everything right with the Tx display.

Here's a picture -

I thought I'd blank out the last two digits of the co-ords in case somebody sends in the drones !

Hope you find this useful.

if you use 1E7 you reduce the precision of localization.
I have an FLD-02 and not the turnigy telemetry modding, I believe that in FLD-02 the lat and lon are showed in correct order.

To get the correct values ​​I have inverted the 0x12 and 0x13 codes .
Can anyone confirm that the FrSky protocol manual use erroneously the codes?

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service