All, my first post here. Correct me I am in the wrong section I am not new to electronics, but new building my first hexacopter. Reading all I could for the last two months, and things start to materialize in my shack.
This not a question, which should lead to the well documented and over discussed “inverted, non inverted” issue.
My rough setup:
Pixhawk 4, Frsky RXSR (ACCESS, EU), Arducopter 3.6.11, QGC and Mission Planner.
Before I start my permanent wiring, I want everything to work on my desk and thoroughly tested. I cannot get any output from any of the Serial Ports when configured as FRSKY Telemetry passthrough. Forget the inverted/uninverted discussion, when not connected to the S.port of my RXSR, the Tx lead shows no activity. Configuring as MavLink2 gives me the regular databursts as output on my Tx pin. So my UARTS are OK. Juggled around with faking the RTS/CTS, waited, tried other serial ports, but no output whatsoever.
It makes me think there is some kind of prerequisite for this telemetry to kick in. A status of some kind (armed ? Which would be weird) before this data is sent out. Attached a snapshot of my poor mens’scope of Tx on Telem1 port, Tx. When configured as Frsky passtrhough, signal is clean, at 3.3V, with no data activity visible.
Any thoughts or hints ?
IIRC the receiver polls the “sensors” in passthru mode. No polling, no data being sent by FC.
If you don’t have a MAX2323 handy, try beta AC 4.0 and use serial_options.7 on the port and straigth wire connection to SPort. Pixhawk 4 runs OK with it.
Thanks Cornel for superfast response. The MAX chips are in flight from China. And I now understand the pulses I see on S.port is actually the polling. But inverted. I will give it a shot with 4.0 and connect straight. Not flying yet, so a crash on the desk is acceptable…
To give you some background, the FrSky Telemetry Passthrough protocol was written by the folks at Craft & Theory as part of their Flight Deck LUA product. In the early days before the protocol was added to ArudPilot, you had to use a version of ArduCopter that had been modified by C&T. I have been a Flight Deck user since those early days.
In recent history another system that uses this protocol has been added to the Open Source ecology, namely Yappu.
Both systems use a hardware device that connects a Pixhawk telemetry port to the SPORT of a compatible FrSky receiver. I have been using X8R and X6R receivers.
I have R-XSR receivers in my racers, but I am using BetaFlight with those aircraft… I can tell you that it should not be all that difficult to add a wire to the R-XSR cable at the SPORT position and then connect the other end to a Pixhawk telemetry port. Then to verify every thing is working just Discover Sensors in the radio.
Caveat: I have no idea weather or not this will work with ACCESS…
Tnx for your coment O´Gazer. I figured out all the inverted/uninverted aspects, appreciate the historic background and where we stand today. I will follow Cornels advice on stepping forward with 4.0, if I read the release notes correctly, some of my missing pieces are covered there. And your caveat warning (“I have no idea weather or not this will work with ACCESS…”), we´ll see about that. I can flash back to ACCST quite easily to verify. Will keep U posted.
Just to let you know, my FRSKY passthrough telemetry is up and running on Pixhawk4.
3.6.11 with the famous MAX3232, solder wires on top, TTL side is UART, diode on the RS232 = Sport side. Too many pictures of wrong wiring floating around…
4.0.0 worked as well with SerialOption set to 7 and single Sport wired to UART TX.
And I can also confirm that this runs over Frsky ACCESS to RXSR EU LBT.