Cant get telemetry working

I have a bunch of APM controllers. They all work flawlessly. Then I figured I needed to move up to a PixHawk. I got TWO version 2.4.8 boards. They seem to work , but no matter what I do, the telemetry will NOT work.

The RFD900+ radios are all set up properly, since when two of them are each connected using USB->RS-232(TTL) adapters, they talk to each other using two instances of PuTTy at 576700 baud.

I use RFD900+ radios, and connected them up.
“Outside” pin to RFD900 +5 (pin closest to the outside of the controller).
Next pin to RFD900 RxD
Next pin to RFD900 TxD
Inside pin to GND (pin closest to the center of the controller).
I’m connected to Telemetry Channel #1

I left the handshaking lines off for the moment, thinking that might complicate matters.
The radio GREEN LED is on steady, indicating that it is connected with the “base”.

In Mission Planner OPTIONAL SETUP (Sik radio), my only option is to LOAD PARAMETERS. When I choose that option, it tells me that it cannot get a response.

So I connected the PIxHawk telemetry channel directly to the USB -> TTL converter (set for 3.3V logic levels) and connected the USB converter to my computer. I brought up Mission Planner and tried to connect. But I get “no heartbeat received”.

Thinking that the problem just might be a bad controller, I connected a SECOND PixHawk to the radio. But that doesn’t work either.

Is there something on a PixHawk that I need to do? Or a setting that I need to change? On an APM it “just works”.

Have you set SERIAL 1_BAUD to 57600
Using Mission Planner connected on USB?

Everything is set up for 57600. Just like my APM controllers.

I don’t have a pinout infront of me, but from this, it sounds like you made your own connector. A common mistake is to connect the PixHawk TX to the Radio TX, and the PixHawk RX to the Radio RX (as we would normally do for electrical connectors). Instead the correct setup is PixHawk TX to Radio RX, and Pixhawk RX to Radio TX. Did you perhaps get caught by this?

I’m generally very aware of the Tx/Rx issues, but since I look out for it, I don’t generally get those wrong. I have a BSEE and have designed hardware all my life. The usual problem is that the “instructions” found on the web are wrong, and that is why I would like someone to check my pinout. Yes, I made my own cable.

The problem is there are those “helpful” engineers that try to fix the problem by relabeling the RX and TX ports so TX goes to TX. So it does not hurt to swap the transmit and receive lines around and see if it starts working. It is also possible that not hooking up the handshaking is causing the serial line to be paused.

I made my own cable(s) too, with the help from some research assistants, and I’ve gotten RFD900+ to work with a Pixhawk (which I think is like your 2.4.8) and with a Pixhawk 2.1.

In summary (details below), try #1 connecting the CTS/RTS pins (aka “handshake” lines, as suggested by @mike ) and #2 powering from the Servo Rail rather than the Telem1 port.

Here’s a document specifying the RFD900+ pinout on page 9:

Here is a website specifying the Telem1 pinout:

So… using these, I’ll work though your description above:

  1. Outside pin (Telem1 pin 1) to RFD900 +5 (pin 4 in the RFD900 manual)
    I did NOT do this. I used the +5V provided off the SERVO RAIL rather than the telem1 port. Try this yourself?
  2. Next pin (Telem1 pin 2) to RFD900 RxD (pin 7 in the RFD900 manual)
  3. Next pin (Telem1 pin 3) to RFD900 TxD (pin 9 in the RFD900 manual)
  4. Inside pin (Telem1 pin 6) to GND (pin 2 in the RFD900 manual)
    I used the SERVO RAIL ground, not the telem1 port.

Just to complete my cable description, I ALSO have:
5. CTS (Telem1 pin 4) connected to RFD900 CTS (pin 3 in the RFD manual)
6. RTS (Telem1 pin 5) connected to RFD900 RTS (pin 11 in the RFD manual)

Let me know if any of this helps?

1 Like

Thanks to all who answered. I got it working. It was bad information on the net.

So that we know for the future, what was the issue? Did you need the Handshake pins? Or was it the power? Or did you find some bad pinout somewhere?

I agree, resolution needs to be confirmed and detailled in order to use threads as references.
Any cause is a good cause , bad reference, bad connection, etc.

I found a website from TECHNO SYS. An Indian gentlemen explained the pinout. If you can follow it correctly, you are a better engineer than I am.

So basically you have been unfortunately mislead by an external source and the information presented by @mike and @hunt0r -based on original documents- helped you resolve the issue.

So please hit the ‘‘resolved’’ button and enjoy :wink: