Wiring FrSky Fport receiver to Pixhawk 1 (shared serial 4/5)

Hello!

I am making the switch from FlySky to Taranis X9 Lite and I need to confirm that I am interpreting the wiki correctly.

I want to wire a FrSky ARCHER M+ 2.4GHz Mini ACCESS Receiver to the Pixhawk 1, but I am limited because of the extra sensors I have on board. My current setup is: F450 frame, Pixhawk 1 FC, Raspberry Pi companion, Raceday ESC, LeddarOne range finder and RPi cam.

This leaves me with the SPKT/DSM, USB, ADC3.3, CAN, SPI, ADC6.6 ports available. However, I believe that the reciever’s Fport must be connected to a serial/UART. The LeddarOne is currently on SERIAL 4/5 and does not use the TX#5 nor the RX#5, so I was wondering if that port could be shared with the reciever i.e. use those two pins.

Would this wiring diagram be reasonable?

pxToArc.pdf (978.3 KB)

If so, would these connections be sufficient, or do I need to connect anything else e.g. SBUS.

Also, would I be able to use the Yaapu Telemtry Script eventually?

The inverted S-Port or F-Port can go to your serial5 pin(s), but the receiver SBUS, +5v and 0v should still go to the RCin pins like normal

1 Like

Oh cool. So, I missed the SBUS → RCIn connection. I knew I was missing something… I kept going back and forth through the wiki, but I was only getting more confused lol.

Here is the original (no sbus needed) diagram:

Fport is a one-wire protocol for RC and telemetry. If you use that you don’t need an S-bus connection.

Really? Okay, I guess the original diagram works then… I’ll take down the updated one.

Also, would you recommend a y-wire for ground and power on the shared serial 4/5 port? This way, I can omit the wires to RCIn? Intuitively, it doesnt seem wise, but I thought I’d ask.

I accidentally misspoke earlier, in my initial post… I was mistakenly under the impression that FPort and SPort were the same thing. I said:

Specifically, when I refered to an FPort. The receiver I have, which is in the diagram screenshot, does not have an inverted FPort but a inverted SPort, which is what I should’ve said because it’s the one I need to use.

Therefore, while @dkemxr is correct about the FPort protocol, I believe that @xfacta was right in my case

I guess that this is because SPort (inverted SPort in my case) is a telemetry protocol. For the RC data, the Serial Bus or S.Bus is required. So they are both communications protocols but they each serve different purposes. Let me know if my logic is inaccurate.

So this should be correct:

I make that mistake too since I dont work with S-PORT and F-PORT much anymore.
I was just lucky that I provided somewhat-correct advice :slight_smile:

1 Like

So I’ve been playing around with the configuration, while still trying to fully understand the FPort/SPort spec, which is pretty confusing to a newbie such as myself lol. Luckily, Ive got something working, but it’s not sitting well with me.

I read this neat post about FPort and the like, in which he states that they should’ve named the inverted SPort, FPort. Therefore, I believe that I can simply follow @dkemxr’s logic. I connected the inverted SPort to TX5, then only Vin and GND to RCin and it works i.e. I get rc control. I also had to enable the FPort param in the radio itself.

Then, I uploaded the Yaapu script, which is fire btw (cant wait to tinker with Lua code), and it also works. However, it isnt the most reliable. After a couple minutes, the radio says “sensor lost” and the script stops working. The widget doesnt go away but it no longer updates. I can still control the drone though, so I dont know what “sensor” is lost. Also, while its booting up, I get “CRSFv2: requesting RX device info” and other “CRSF” messages and then one final “CRSFv2: RX device ping failed”. (I’ll attach pics of the messages)

If I restart the radio, the widget then says “no telemetry,” but the voice announces that “Yaapu telemetry is ready.”

If I power cycle the quad and radio, then all sensors come back online and the widget works again, until I leave them idle for a couple of minutes, any thoughts?

Screenshot (56)
Screenshot (57)
Screenshot (58)

I dont know why its sending Crossfire messages, is that normal?

What do you have configured for rc_options ? And are there any Serial Port options set to 10?

I have rc_options set to 32, which I havent touched. But I did set serial5_protocol = 23 (RCIN), serial5_options = 132 (half duplex and pull up). I originally had serial5_options = 4, but then last night I changed it to 132 and it resolved the crossfire messages i.e. I’m not getting any of the CRSF messages, but I still get a “sensor lost” message after letting everything sit idle on the bench for approx 5 minutes.

What about off the bench real world? Frsky can be flaky when the Tx/Rx are too close together.

I only tried real-world prior to the serial5_option = 4 → serial5_option = 132 switch and it was the same.

I will try a real-world hover now and report back.

You probably have provided most of the info required but post a parameter file anyway. I use Fport on a few vehicles. As much as I would like to ditch Frsky altogether I just haven’t gotten around to the process as it’s several craft.

If you go to the telemetry page in Opentx, you can “delete all sensors” and “discover all sensors” and it will show the sensors that are being discovered to you.

Will do…

I did do that and all the sensors did get discovered… the app runs perfect for a couple minutes, but then after that, I get “sensor lost” voice message from the radio. Since I am on the bench, all I do is tilt the craft to get the app’s horizon to tilt as well but it doesnt. None of the sensors get updated after that, unless I power cycle the drone. Weirdly, the app doesnt even reconnect if I reboot from the compass tab. I have to totally unplug.

I suspect that @dkemxr is correct and the connection is flaky because I am too close.

I am pretty new, but I have already noticed that people are trying to stay away from FrSky. I wish I would have researched more before I bought my initial setup, but hey, going through a little pain is always good lol.

What will you switch to, if you dont mind me asking?

I have Crossfire on some newer models and am relatively happy with that. It wasn’t clear what the disposition of TBS was for some months but it looks like Trappy is back in the drivers seat so the future looks brighter. If I was starting from nothing it would be ELRS for sure. I could still convert my Frysky R9 stuff to it but it’s a big undertaking. I might still do it.

So I got something working, but I still get the “sensor lost” every once in a while, which leads to the app freezing. However, it does act a bit more stable and I have attached the params if you still want to take a look. I played around with the params a bit and settled on SERIAL5_OPTIONS = 4, SERIAL5_PROTOCOL = 23, which is still shared with the lidar on SERIAL4. Then, changed RC_OPTIONS = 40 (included the pad byte), and RC_PROTOCOL = 2048 (FPORT). The software picks CRSF if I don’t explicitly set the protocol.

One pretty weird thing I’ve noticed is that the rssi status acts strange in the ardupilot hud display on my laptop. Sometimes it will report but other times it wont, it just reports 0.

As far as the FPort Yaapu app goes, this setup has given me the best results, but I have only flew a handful of times, so I can report back if any issues arise. I’m very tempted to try connecting the SBUS along with GND, RCin just to see how it works, but haven’t yet. In any case, let me know what you think about the setup.

“Sensor lost” happens when the radio is swamped by the telemetry signals as is what happens when the radio and receiver are very close to each other. Telemetry is regained once they are moved apart from each other.

1 Like

Really? Very interesting… it makes a lot more sense why it happens then. It wasnt sitting right with me and I lost a good day trying to figure it out lol.