Inverted UART (for FRsky telemetry) does not work on FMUv5 (CUAV NANO). Is not inverted.

[roman-dvorak]

Describe the bug Inverted UART does not work. Is not inverted. I tried to make FRsky telemetry (S.port) work. And I was unable to get in working. After some time, I looked at it with an oscilloscope. And the data from the autopilot looks like this:

It was tested with CUAV V5 nano (FMU v5 STM32F765). Telemetry was enabled in parameter to some TELEM port. (Several ports have been tested with the same result). FRsky telemetry driver started correctly in the correct mode (single wire, inverted).

https://github.com/PX4/PX4-Autopilot/blob/801ef2d5200a31e8a801a5d6b0faf0aec18be7ef/src/drivers/telemetry/frsky_telemetry/frsky_telemetry.cpp#L384-L387

Level 1 in the time inactivity is forced by autopilot. Although an internal pulldown should be connected.

https://github.com/PX4/PX4-Autopilot/blob/801ef2d5200a31e8a801a5d6b0faf0aec18be7ef/src/drivers/telemetry/frsky_telemetry/frsky_telemetry.cpp#L201-L213

After researching the firmware, I made sure that the IOCTL is written (but i don't know if it's set ). I tried to hardcode it in FRsky driver. It does not help. There are several problems:

• Is hold in a high level (Internal pulldown should be set)
• Data are not inverted (it should)

Data from the FRsky receiver looks correct and inverted. And autopilot responds to them.

Upon further research, I found that this feature is included in NUTTX for this FMU. (I didn't check it in the processor documentation). And on the forum I found a person who also deal with this issue (for another purpose): https://discuss.px4.io/t/dynamixel-servo-on-px4/22995 Therefore, I think it's a problem in some lower-level of the UART driver.

Expected behavior I assume (minimally) that in the inactive state it should be in Log0.

Connection I have connected S.port of FRsky receiver directly to TX pin of autopilot's TELEMx port.

Additional questions

• Has it been tested that FRsky directly connection to RC transceiver works?
• Is FMUv5 a supported platform for that feature (especially CUAV NANO V5)? I can't find exactly this information anywhere. But in NUTTX this property is defined for STM32F765

[elbarto1980]

Hi, I just wanted to add that I am experiencing the same issue with a CUAV V5+ (FMU v5 STM32F765). The receiver I am using is a R9 slim+OTA with FLEX firmware (ACCST). I inspected the signal with a logic analyzer and I can confirm that messages coming from my R9 slim+OTA receiver are correct, as well as its UART settings (57600, 8N1).

But when I set TEL_FRSKY_CONFIG to TELEM/SERIAL 4 and connect the receiver's S.Port wire to the TX pin of Pixhawk's UART4 (/dev/ttyS3), no messages are received by the RC, "frsky_telemetry status" reports 0 packets sent and the logic analyzer detects several "framing errors".

Count me in if you need more tests on the hardware I am using.

[roman-dvorak]

Thank you for the replay and for verifying the malfunction. With different autopilot.

Yes, I have the same observation of the behaviour of the RC receiver itself. I measured it with an oscilloscope. According to your pictures, the signal is really inverted.

This image shows a signal from the RC receiver. Disconnected from autopilot TX.

After connecting RC receiver to the TX pin of autopilot, the signal is most of the time in log1 (If no side is communicating). This can be seen in my picture from the first comment.

the logic analyzer detects several "framing errors"

This cannot be because the logic analyzer assumes an inverted signal. And it is not. From the autopilot. Cant it be that? Are you able to do only a record of your signal (without UART decoding by logic analyser SW; and/or with decoding of non-inverted UART)? With connected autopilot.

"frsky_telemetry status" reports 0 packets sent

Autopilot sends bus packets only after receiving data from the RC receiver. This is the data from your picture. But it's probably not read/detected by autopilot. Are you able to show us the whole output of 'frsky_telemetry status'?

[elbarto1980]

Hi Roman, yes, I think that the most probable cause for the framing errors is that the async signal coming from Pixhawk is not inverted, causing data to be decoded improperly.

I tried to decode UART signal uninverted but the software returns framing errors as well... because the S.Port signal is inverted. I mean, in any case one of the two signals is upside-down.

Regarding the "frsky_telemetry status output", I also tried to stop the process and manually run it again with the correct input arguments (no autodetect), but nothing changes... 0 packet sent.

I will probably be able to do some more tests and post more screenshots tomorrow. Thank you!

[elbarto1980]

@roman-dvorak, here's the raw signal captured with connected autopilot. I acquired 10s data from UART4 TX wire, connected to S.Port. In the zip file attached, you can find a .sal file that you can open using this software and a csv export of the same signal. I suggest you open it with the former because you can use UART decoder offline and many other tools. FrSky_PX4.zip

[roman-dvorak]

I apologize for my late response. Yes, after viewing the record, it looks the same as my observations. Thank you @elbarto1980 for the longer log.

And it's probably a bug on the part of nuttx. I probably can't fix that.

I have found that (@davids5 @bkueng @benjinne) have dealt with this. Can't you help us with that, please? Or who can give us more information?

[benjinne]

So I don't have much to offer here with to getting inverted telem to work, however if you want a quick fix you can always solder to some receivers between the chip and inverter and it will work without needing to invert the UART in PX4. There's some examples on this page https://oscarliang.com/uninverted-sbus-smart-port-frsky-receivers/

[davids5]

Please ensure that the version of Nuttx has the same commits from https://github.com/PX4/NuttX/pull/112

https://github.com/PX4/NuttX/pull/112/commits/38d58a41271063957b4be3de955cbd92536ef7ed#diff-152b63785202e72847dea5ad69537821fcd9632420aa6016289d707be6ce0f75R2441-R2443

The defconfig has both CONFIG_STM32F7_USART_INVERT CONFIG_STM32F7_USART_SINGLEWIRE defined.

Single wire by default is on the TX Pin If CONFIG_STM32F7_USART_SWAP is defined and TIOCSSWAP is called it will be on the RX line

[elbarto1980]

Hi @davids5, thank you for your reply. The nuttx repository that I currently have on my local directory is * (HEAD detached at bf660cba2a). I cannot find the commits you just mentioned, but the code is there.... However, I am not building the firmware, I just downloaded and flashed the last px4 stable release using QGroundControl

[davids5]

@elbarto1980 - The it is in there as all of this was up streamed. I would look at it in a debugger and see if the register values make sense.

[AK7466]

Hi. I am new to FrSky and I am having the same difficulty (i.e. I have failed) in getting telemetry data from the Tx(out) pin of my Pixhawk 4 TELEM2 port via FrSky R9MM Inverted S.Port to the telemetry page of my FrSky Horus X10.

I am not a programmer, but ok with hardware, and have now spent about 20 hours investigating and reached a dead end

I have flashed the Pixhawk 4 with the latest firmware (V13).

Attached are images of the waveform on the S.Port connection, and a schematic of the interconnections.

I hope these are of some help. - They appear to show that after the receiver outputs two bytes (the first of which is always seems to be 0x7E), the Flight Controller (PixHawk 4) responds with 8 bytes

Has anyone made any further progress ?

Many thanks.

Alan K.

[c-devine]

Hi all. I was also having issues with the CUAV Nano FMUv5 frsky telemetry messages(single wire, inverted s.port). In my case, I was getting s.port response packets with the bytes out of order - the byte that is supposed to be first (0x10) was always the last byte in the message.
As a test, I updated sPort_send_data() in sPort_data.cpp to write out bytes 0-7 in order, and again, the first byte was the last byte in the message: Something is going on with the TX when writing only a single byte. Changing sPort_send_data to send out all the response bytes at the same time fixes the issue and now I can see the telemetry in my FrSky Horus X10:

Not sure what is going on, maybe a TX circular buffer issue in nuttx for the FMUv5 uart?