FrSky Telemetry on Pixhawk - a one transistor interface

I just upgraded to a Pixhawk controller from and APM 2.6, previously to the APM 2.6 I flew using MultiWii firmware ported to the 32bit Naze32 flight controller, and I flew with that for some time.
One nice feature of the Naze32 was support for FrSky telemetry with minimal additional hardware between its ARM STM32 and the FrSky D series receiver, just a single transistor used as an inverter worked fine. So a full RS232 chip interface was not needed on that flight board.

The FrSky D series will actually read the telemetry stream fine with an inverted 3.3V signal on the RX-data pin in my experience (however my inverter had a 5V logic output anyway).

When I moved to APM land over a year ago I had to add an Arduino board to convert Mavlink serial data to a FrSky telemetry format so I could get telemetry on my radio again. I used the jD-IO board firmware and an Arduino Mini to do that, and it worked (but never very well IMHO).

Now with the Pixhawk the Arduino converter can be eliminated and just a simple logic inverter be used in-line again (I suspect that if the serial logic can be inverted before being sent from the Pixhawk that we’d need nothing at all in between a Pixhawk and a FrSky D series receiver !).

Back with the Naze32 board and now with the Pixhawk I used a slightly hacked $2.50 Hobbyking item to do the inverting. It’s actually made as a signal level booster for servos, but by removing one transistor (it has two) and shifting a resistor it’s a tiny convenient inverter (and level booster if powered from 5V).
hobbyking.com/hobbyking/sto … v_5v_.html

The pictures show the modification I did, remove the second transistor, remove the 10K, shift fit the 1K in it’s place, strap across the vacant transistor position.

The input wire goes to Pixhawk Telem-2 TX pin 2, 5V is from Telem-2 pin 1, Ground from Telem2 pin 6. On the D series RX side the ground and RX-data are connected, the 5V out fro the inverter is not. I use a FrSky D8R-XP receiver. To connect to the Pixhawk I used a DF13 six pin plug and three wires salvaged from a damaged 3DR Power Module cable, the receiver side is the servo lead supplied with the servo signal booster (but swapped to the output side of it).

I’ve only just got this going on the Pixhawk, but so far the telemetry sent by the Pixhawk is very good and stable, none of the sometimes random values that plagued my more complex APM setup with the Arduino Mavlink-Frsky converter, and more of the values actually work like expected. So far so very good…

[attachment=4]1.JPG[/attachment]

[attachment=3]2.JPG[/attachment]

[attachment=2]3.JPG[/attachment]

[attachment=1]4.JPG[/attachment]

[attachment=0]5.JPG[/attachment]

[quote=“sneezy”]I just upgraded to a Pixhawk controller from and APM 2.6, previously to the APM 2.6 I flew using MultiWii firmware ported to the 32bit Naze32 flight controller, and I flew with that for some time.
One nice feature of the Naze32 was support for FrSky telemetry with minimal additional hardware between its ARM STM32 and the FrSky D series receiver, just a single transistor used as an inverter worked fine. So a full RS232 chip interface was not needed on that flight board.

The FrSky D series will actually read the telemetry stream fine with an inverted 3.3V signal on the RX-data pin in my experience (however my inverter had a 5V logic output anyway).

When I moved to APM land over a year ago I had to add an Arduino board to convert Mavlink serial data to a FrSky telemetry format so I could get telemetry on my radio again. I used the jD-IO board firmware and an Arduino Mini to do that, and it worked (but never very well IMHO).

Now with the Pixhawk the Arduino converter can be eliminated and just a simple logic inverter be used in-line again (I suspect that if the serial logic can be inverted before being sent from the Pixhawk that we’d need nothing at all in between a Pixhawk and a FrSky D series receiver !).

Back with the Naze32 board and now with the Pixhawk I used a slightly hacked $2.50 Hobbyking item to do the inverting. It’s actually made as a signal level booster for servos, but by removing one transistor (it has two) and shifting a resistor it’s a tiny convenient inverter (and level booster if powered from 5V).
hobbyking.com/hobbyking/sto … v_5v_.html

The pictures show the modification I did, remove the second transistor, remove the 10K, shift fit the 1K in it’s place, strap across the vacant transistor position.

The input wire goes to Pixhawk Telem-2 TX pin 2, 5V is from Telem-2 pin 1, Ground from Telem2 pin 6. On the D series RX side the ground and RX-data are connected, the 5V out fro the inverter is not. I use a FrSky D8R-XP receiver. To connect to the Pixhawk I used a DF13 six pin plug and three wires salvaged from a damaged 3DR Power Module cable, the receiver side is the servo lead supplied with the servo signal booster (but swapped to the output side of it).

I’ve only just got this going on the Pixhawk, but so far the telemetry sent by the Pixhawk is very good and stable, none of the sometimes random values that plagued my more complex APM setup with the Arduino Mavlink-Frsky converter, and more of the values actually work like expected. So far so very good…

[attachment=4]1.JPG[/attachment]

[attachment=3]2.JPG[/attachment]

[attachment=2]3.JPG[/attachment]

[attachment=1]4.JPG[/attachment]

[attachment=0]5.JPG[/attachment][/quote]
Nice 8)
I am working on s port as well. Your cable would need an extra diode then.

S.Port support will be well received for sure. I’m liking the serial support, it’s much better than what I had on the APM.

The cable might be this simple, or do you think it needs buffering as well ?
eflightwiki.com/eflightwiki/ … dified.png

Regards,
Martin

PS. So are you the code contributor for the Pixhawk Frsky telemetry ?

[quote=“sneezy”]S.Port support will be well received for sure. I’m liking the serial support, it’s much better than what I had on the APM.

The cable might be this simple, or do you think it needs buffering as well ?
eflightwiki.com/eflightwiki/ … dified.png

Regards,
Martin

PS. So are you the code contributor for the Pixhawk Frsky telemetry ?[/quote]
Yep that’s the cable I use for my development: SPC cable from frsky after the FUL cable.
I did the integration in APM code indeed but with the help of what was done in px4 lib and tridge.

Ah ok. Where can I post some discussion to you about what is sent from the Pixhawk to the Taranis ?

I have an idea that sending HDOP on T2 instead of Sats count and 3D lock might be better, as Pixhawk needs HDOP <2.0 to arm, and Sats value does not always reflect that.
Also I have a question about failsafe message values being sent instead of flight modes on T1 ?
Regards,
Martin

I know bumping old threads is frowned upon, but I felt it’s worth it this time.

Was a bit skeptical about this but decided to give it a try, soooo glad I did.

I now have 2 of these leads made up, one for my quad (Pixhawk AC3.3) and one for my plane (Pixhawk AP3.4), did a bit of googling to find some scripts and tweaked them a little bit to suit but I now have RSSI, flight battery, distance, altitude, GPS status and number of sats, flight timer, current, and total mah consumption all on one screen on my Taranis. Battery and RSSI are in a nice picture style too. I then have a 2nd page showing all the values as a diagnostic aid and a 3rd page for a lost model locator based on RSSI strength.

And it’s a LOT smaller and easier to do then a Teensy.

Glad the info is still of use, maybe it just looked too simple to be taken seriously :slight_smile:

As of a few weeks ago I’ve now been trying out a similar two transistor interface for X series S.Port receivers that need bidirectional inversion. The credit for that one goes to this thread below though not me, I just tweaked the values they used to adjust the logic levels at the S.port and Pixhawk a bit better.
github.com/diydrones/ardupilot/issues/1587

I agree, I like the KISS approach to the telemetry interfacing now that Pixhawk integrates the right protocol itself with no need to buy and program yet another MCU board.
Martin

The idea is simple enough, de-soldering that rather tiny board not so much lol
Well worth it though!