Decoding FrSKY telemetry data with an Arduino – Part four

Now let’s look at the necessary code to transmit telemetry data from our aircraft. We have an Arduino on board the plane, connected to the telemetry port of our FrSky receiver. I used a D4R-II. The harness that plugs into the side of the receiver (at least the one supplied with mine) has red wire for the serial data coming out of the receiver – this I connected to Pin A2 of my Arduino, and a green wire for serial data into the receiver – this I connected to Pin A1.

I made the Arduino mimic the way the standard FrSky telemetry options send their data – so there’s no need for a FrSky hub on the plane – all the sensors for GPS, magnetometer, accelerometer, etc. are connected to the Arduino – the Arduino reads those sensors and then sends data to the FrSky receiver in the standard form. So if you have a transmitter such as a Taranis that understands FrSky telemetry and displays it on its screen that will work. For the extra data types that are not standard FrSky telemetry, I used the additional coding system described in part three. A Taranis doesn’t understand that data, of course, and just ignores it, – but it is still detects the standard GPS, variometer, and other data and displays that without a problem. To detect and display the additional data requires a custom Arduino decoder, as described in part three. I suppose it might be possible to create custom firmware for a Taranis to do the same, but I’ve not looked at that.

I was going to produce a cut-down version of my original code to post here, but I’m running short on time, so for those of you who wish to study it and extract the relevant parts to use in your own projects, I’m going to post my original ‘Piagma’ sketch. You can download the sketch using this link.

Piagma is a model plane autopilot I wrote that uses a Raspberry Pi for the higher-level functions of waypoint selection, steering, etc. An Arduino is used as an interface to read all the sensors, and as an interface for the Raspberry Pi. But you don’t need the Raspberry Pi for it to be useful – even without the Raspberry Pi, the Arduino reads all the sensors and sends the data back to the base station through the FrSky telemetry system. If a Raspberry Pi is present, the Arduino works as an SPI slave and the Raspberry Pi is the SPI master.

The sensors I used were a MPU6050 gyro/accelerometer, a BMP085 barometer/altimeter, a HMC5883L magnetometer, and a ‘standard’ serial data at 9600 baud GPS unit. The Arduino also decodes the CCPM data available from the FrSky receiver and drives the decoded data out to the individual servos and motor controls. One channel of CCPM data is used as an Auto/Manual switch – in the manual position the received channels from the base station are sent direct to the servos – in the auto position, the Raspberry Pi controls the servos. This means that when testing, if the autopilot goes crazy, or the Raspberry Pi crashes or stops communicating with the Arduino, then by flicking a switch on your transmitter you can take manual control.

When I get a bit more free time, I may produce a cut-down version of the Piagma Arduino sketch removing the Raspberry Pi parts to make it clearer. but maybe this post will help those of you who are keen to make progress.

I also wrote my own telemetry receiver / display / data logger for attaching to the ground station – that allows you to monitor all the telemetry data with an ordinary ‘dumb’ transmitter rather than a Taranis – that’s also Arduino based with a colour LCD screen and an SD card for data logging. If I ever get around to it, I guess I can cover that in part six or seven or whatever!






11 responses to “Decoding FrSKY telemetry data with an Arduino – Part four”

  1. Carl Davey avatar
    Carl Davey

    Really Cool! so can the transmitter receive a 20 byte user packet? the Frsky document mentions 6.
    I’d really like to send LTM telemetry over the Frsky downlink so that the newer android apps work.

    I’m currently modifying your sketches so that this can be sent:

    Thanks again

    1. ceptimus avatar

      The trick is to split larger packets of data into smaller chunks each chunk having an identifier byte that enables the chunks to be reassembled into the large packet. So for a twenty-byte packet you could send it in four quarters of six bytes each (within each quarter you’d have a one-byte ‘address’ plus five bytes of data).

  2. Dan avatar

    Thanks for the great information.

    Do you have any information on the protocol for configuration of RSSI and RxBat alarms? I’m not sure if they are available on the DHT/DJT modules. I had a DHT module a while back and developed something similar to what you have created here. I’ve since replaced the DHT with an XJT but would like to set its alarm levels now.

    Thanks in advance for any info.

  3. halim avatar

    Your work is great.
    I try to take the data from the s.port output on the r9m transmitter and connect it to the mission planner program from the computer via bluetooth. But it doesn’t work. Does this work work?

    1. ceptimus avatar

      Hi halim,
      Sorry, I don’t have an r9m module so I don’t know if it uses a different protocol or different connection.

  4. Maurits avatar

    Great to read all this. I’ve done exactly the same 2 years ago. A lot of fun to combine my electronics hobby with RC. I have made a display on my old Futaba FC16 (with DHT) and can also send custom data from the receiver to the display 🙂

  5. Albert Farguell avatar
    Albert Farguell

    Dear Ceptimus, It’s great to have the knowledge to do what you do. But it’s even greater to have the will to share it with all of us. Thank you. I dare to ask you for some advice.
    As a hobbyist, I spend some time refurbishing antique rc transmitters (Kraft, Pro Line, etc) with new technology components, and to do so, I’ve been using Frsky DHT module together with suitable receivers. Some of these receivers had port A1 and A2, which I used to get telemetry from a Pitot tube and a LiPo on board. And this was possible because the telemetry protocol used by Frsky was publicly available.
    But they have stopped producing DHT modules and receivers with A1 and A2 ports, and now they sell a new rf module named XHT that works with two new protocols (to me) such are PXX and S.PORT, and they sell it without any information about them. I’ve tried to contact Frsky to get some insight, but they have not answered to me. I wonder what kind of costumer is this product targeted to.
    And now the question: do you think there are better alternatives, other than XHT, enough documented, to substitute the DHT modules and get the telemetry from a RadioMaster receiver?
    Thank you in advance.

  6. Roberto avatar

    Amazing code, very very usefull. I will use it with my D8R-XP to read voltage and level of fuel on my TREX700n using A1 and A2 analog ports. Please I would ask you if I can integrate arduino inside my TX radio connecting it with DHT RS232 port. Reading your first part, you told that I can connect DHT-TX to 100k resistor and than directly to PIN11. I can connect DHT-GND to arduino GND. Can I also connect DHT+5V to arduino VCC as supply power? Or it is better to gain supply power directly from battery using other method? Thanks Bye Roberto

    1. ceptimus avatar

      Thanks Roberto. Yes, in my modified transmitter, I used the 5V from the DHT module connected to the Arduino VCC to power the Arduino, and a small display.

      I think the only reason to connect the Arduino to the transmitter battery instead would be if you were connecting lots of power-drawing extras to the Arduino (displays with bright backlights and such). In this case you’d connect the switched battery positive to the Arduino’s Vin (sometimes labelled ‘raw’) pin. You wouldn’t then connect the 5V from the DHT to the Arduino’s VCC pin, but you should still link the two GNDs.

      The Arduino’s Vin pin can handle anything from about 6V up to 12V, and most transmitter batteries fall inside that range.

  7. Richard avatar

    Hi, ceptimus, You did a hell of a job! Thank you for sharing it with the public. I am trying to extract FrSky telemetry from the new Tandem series transmitters via the S.Port or the wireless embedded in them. It seems that they did some changes to the S.Port (telemetry) protocol. Do you know if that is a true statement?

    1. ceptimus avatar

      I think it’s true that the S.Port telemetry is different to the old ‘D’ series. I have some S.Port receivers, and how the telemetry works for those is on my list of things to investigate. I don’t have any of the ‘Tandem’ things though.

Leave a Reply

Your email address will not be published. Required fields are marked *