Inav: R9Slim S.BUS faulty readings

[ondrascz]

I have receiver FrSky R9 Slim, flashed to the newest available EU/LBT firmware, also the module R9M si flashed to newest available EU/LBT firmware. The receiver is connected via dedicated S.BUS port (UART 2 RX). In EU/LBT mode the receiver support only 8 channels via S.BUS.

If the receiver is bound without a telemetry, everything works OK, all the 8 channels are read correctly.

If the receiver is bound with telemetry (25mW mode), the channel reading is faulty. The channels reading becames random from time to time, sometimes even channels 9-16 have random values, the failsafe is triggered randomly.

In a case there is anything being transmitted on channels 7 and/or 8, the problem disappears, so there is a workaround. But I've tested it also in 1.8.0 and there everything is correct even without channels 7 and/or 8 transmitted, so it seems that something related to S.BUS reading changed from 1.8.0 to 1.9.0. I've tried to reproduce the issue also with R-XSR, but in this case, everything is OK. Probably due to fact, that R-XSR uses all 16 S.BUS channels.

All the settings are default, except the channel map ( map TAER5678 ).

TL/DR summary:

1.9.0-RC1:
No-telemetry bind: OK
Telemetry bind + something mixed to CH7 or CH8: OK
Telemetry bind + nothing mixed to CH7 or CH8: NOT OK

1.8.0:
No-telemetry bind: OK
Telemetry bind + something mixed to CH7 or CH8: OK
Telemetry bind + nothing mixed to CH7 or CH8: OK

Board and Version

Board: Matek F405-CTR
iNAV: INAV/MATEKF405 1.9.0 Feb 18 2018 / 15:03:23 (f8dcc1a47)

[shellixyz]

Very little has changed in the S.Bus code between 1.8 and 1.9. Please try this build to see if it fixes your issue:
inav_1.9.0_MATEKF405.hex.zip

[ondrascz]

Flashed the test build provided and it seems to be fixed. R9Slim is bound as EU/LBT 25mW with telemetry, Transmitting only four channels and no glitches in channels 9-16. What has been changed, if I'm not too curious? ;)

[shellixyz]

Great! Never too curious ! I reverted #2718.

[shellixyz]

@digitalentity Looks like #2718 is causing issues with some setups.

[fiam]

@shellixyz Nice catch! I'd vote for dropping workarounds for faulty RXs. If eLeReS wants to speak SBUS, it should do so properly.

[digitalentity]

@shellixyz @fiam interesting find.

[rodizio1]

This issue is caused by limitations of SBUS.

SBUS issues are:

• No CRC, thus there is no way for inav code to make sure that what it has received/decoded is actually valid channel data
• The packet start marker is a single byte that also can occur in the payload
• There is no sure way to surely detect packet end for inav code, some SBUS receivers send different fixed bytes, some send whatever other stuff (telemetry or something). SBUS is just reverse-engineered, there is no clear knowledge about what the end byte does

What causes the above behaviour is that when timing goes wrong and the payload happens to contain a byte that is the same as the startbyte, inav code will basically start reading "in the middle of a packet" and interpret everything wrong which causes channel values to go completely nuts.

Because of the above SBUS limitations, this is very hard to fix for all cases. To make sure this cannot happen, the timing of the SBUS stream the RX sends must be known and timing in inav must be implemented very carefully. Even if that is implemented 100% right (which I think is next to impossible considering that there is no official SBUS specifications and a lot of different receivers), there is still the risk, that either the flightcontroller or receiver goes "out of timing" because of some CPU load issue etc.

(I am talking from experience, I wrote an SBUS implementation for EZ-Wifibroadcast on the Pi and had exactly that behaviour with inav and cleanflight when the timing wasn't right. This is BTW why I refuse to implement SBUS within EZ-Wifibroadcast, that protocol is broken by design)

[digitalentity]

Yep. Since most S.Bus implementations follow the timings used by FrSky/Futaba, it's best to keep things compatible.

[krzysztofmatula]

As #2718 is reverted I talked again with eLeReS devs. They claim it's hard to achieve Futaba timings on Atmega with soft-serial they have to use for SBUS.
What about adding a CLI option to set this timeout? Is it acceptable?

[fiam]

Sorry, closed by mistake. Reopening

[fiam]

@krzysztofmatula I'd say the best solution would be eLeReS speaking proper SBUS or using something else. If that's not possible, we might be able to find a suitable workaround. However, I don't see how much good an eLeReS specific workaround does overall, since everyone has to special case SBUS from eLeReS for this to work.

I do know for a fact that SBUS decoding using soft serial on atmega328 produces a lot of corrupted data (found it the hard way), so I guess encoding is kinda the same. I guess they don't have an inverter for the HW serial, so they have no choice but to use soft serial. Could you ask if they'd be able to output non-inverted SBUS at normal SBUS speeds using the HW serial? That way it would work with both INAV and BF without any additional changes, since the sbus_inversion setting would take care of that. Also, there are already other RX out there using this method (like OpenLRS).

[krzysztofmatula]

@fiam There is one HW UART available on eleres-mini RX that could be potentially used to output SBUS, but the same UART is used to get telemetry from the FC (e.g. LTM). To use it and not to compromise functionality the LTM would need to be output from inav at exactly 100kbps. So... this would be another thing to do...

The SBUS output from eleres has been used since a couple of months (using the patched delay) by a number of people, so I guess there are no issues. I haven't flown it much by myself yet.

Previously I was always using PPM from eleres and it worked just fine. Lately I changed FC from SPF3 to genuine OmnibusF4V5 and PPM is highly affected by the telemetry (transmitted at 430MHz). I was investigating this for quite a while and it must be some PCB layout that is just sensitive for such signal being transmitted nearby. Switching to SBUS apparently helps. My explanation is that UART is just more resistant to single spikes or something.

Anyway, I don't want to spoil the SBUS code in inav. For me alone it's perfectly fine to live with a local change. But I'd like to explore all possibilities.

[rodizio1]

As #2718 is reverted I talked again with eLeReS devs. They claim it's hard to achieve Futaba timings on Atmega with soft-serial they have to use for SBUS.
What about adding a CLI option to set this timeout? Is it acceptable?

As explained above, there is no other way for inav code than relying on timing to safely extract the correct channel data from the SBUS frames. The other problem is, that a wrong timing setting wouldn't be directly apparent, these issues can (and do, as we've just seen) only occur under certain conditions. This is dangerous.

Again, if timing doesn't match and parsing goes wrong, you'll get completely random channel values, that is, it's jumping around wildly between 1000 and 2000. If this happens on a plane while in some mode where the flight control does not limit the servo endpoints, the servos will try to go to positions far beyond configured endpoints (and mess-up servo-linkage, gears inside the servo, pull too high currents and burn-out, or whatever might give first.)

If their hardware doesn't allow them to use the same timing as genuine Futuba receivers do, they simply shouldn't use it, this is dangerous.

Graupner/JR SUMD, Flysky IBUS, Multiplex SRXL / XBUS would be three protocols for example that are properly designed, i.e. there is no way that channel data gets interpreted wrong, it will either read correct channel values or ignore the data.

[digitalentity]

I believe we can close this. S.Bus timing change for eLeReS was reverted, it's plain old FrSky's/Futaba's S.Bus again. Lack of CRC in S.Bus frames are a pain, but we can probably add sanity checks to the S.Bus RX code to discard data that's obviously incorrect.

[SmartTommy]

@shellixyz,@ondrascz
hi, did the new firmware fixed the “BUG”?

[shellixyz]

@SmartTommy Yes it is fixed. Back to the old 3ms per frame.

[SmartTommy]

@shellixyz
so nice！which version should we use? the 1.9.0 or 1.8.0?

[shellixyz]

Higher versions should always be better otherwise we wouldn't bother releasing them so 1.9.0 ;)

[abyz28]

Hi, i also having the same issue with this. But I'm using R9 receiver. Im on furious fpv F35 inav 1.9.0. I did follow this youtube video https://www.youtube.com/watch?v=kJpvvCzoId0 but still same. Any help would be nice.

[Basti77]

I found this vid:
https://www.youtube.com/watch?v=Gh6i1kyxY6s
from the release date I installed the last FW available at that time.
tata of the failsafe INAFS now corresponds to the one of the recipient.
but now there are the bugs that were fixed in the following versions.

The model is in the basement, the transmitter is in the range check outside the house and I have an RSSI of 48.

In the tumble dryer there is also no failsafe at INAV.

another bug in the Frsky FW?