R224 + frsky s.bus 16ch bug?

[SuperSharpShooter]

I've just come across a new issue on my AQ running the stable release r224.

I'm using a Taranis radio with X8R receiver in 16ch mode connected via s.bus with an inverter, and it works fine (shows radio quality 100%), until any parameter is written to rom, then the radio quality goes to 0%, and the radio doesn't work again until the AQ is power cycled. This could be dangerous if any parameters are changed during flight. This issue happens whether the params are changed via QGC, or via the android app.

Previously I have been running this same AQ board with a D8R-II receiver connected via PPM for a few months without issues.

I also have another AQ board running R224 with an X8R receiver connected via s.bus, but it's only in 8ch mode, and is bound to a FRSKY DJT module on a Turnigy 9x. This setup uses the same inverter, and doesn't lose the radio link when parameters are written. Next step will be to try binding this receiver to the Taranis in 16ch mode and see if the issue also appears.

I've just done some more testing on this first AQ which is having issues, and sometimes writing to rom will just cause a drop in radio quality to 90%, and then it will come back and keep working, and other times it will drop it to 0. Also if I keep writing parameters to rom when the radio quality shows as 0, it will sometimes come back to 100%.

I have of this last test if anyone is interested. Is anyone running an X8R via s.bus in 16ch mode with R224 who is able to replicate this?

[Max]

Hi Glenn,

I believe this relates to a bug (or, really, an sbus protocol design issue IMHO) which was fixed in a later AQ fw. http://code.google.com/p/autoquad/source/detail?r=314 Basically what can happen is that AQ can start reading the SBus data in the middle of a frame (set of channel values) and gets out of sync with the Rx. It then gets confused about which value belongs to which channel, with unpredictable results like you're seeing. This should NOT happen during a normal startup if the Rx turns on at the same time as the AQ. But if the Rx is already on and the AQ gets reset or has a pause in the main loop (like when saving params to ROM), then it can happen.

The good news is that AQ will never write params to ROM while armed/flying. The bad news is that it can still happen "in the field" if you don't check the radio values after saving new params or restarting the AQ. Safest bet is probably to power cycle the whole system or at least the AQ and Rx together.

We should probably consider porting the fix to 6.7 branch... Meanwhile one can also simply merge the changes from the above link into futaba.h/c from r224 and it will work.

EDIT: errr, actually you'd also need the changes from http://code.google.com/p/autoquad/source/detail?r=314 . Or simply remove lines #103 and #104 from the updated futaba.c, they're not strictly necessary.

-Max

[bluuu]

Maybe it's a problem when there is more then 12 channels ?
I use Futaba S.Bus but I have 12 channels.
I wrote setting many times (on the field) and problem never happend.
Maybe Frsky S.Bus is little different ?

[SuperSharpShooter]

Alright, thanks Max, I'll get my build environment back together so that I can compile this fix into r224.

[Max]

It most likely has to do with how long the gap is between frames, which changes depending on the actual Rx (and maybe what mode it's in). With a longer frame gap it's just less likely that the AQ starts reading the serial stream in the middle of a frame. The frame itself is only 3ms long, while the gap can be anything from 4 to 11 ms (IIRC). FrSky seems to prefer a shorter gap, so the problem is more likely to manifest itself there. But it can still happen with Futaba Rxs.

-Max