SBE-1/S.Bus/AQ? major issue - confirmed

[Max]

SUMMARY (Sep-19-12): So far there are 2 confirmed cases of radio input signal loss with the Futaba SBE-1 S.Bus adapter (and no reports to the contrary). Do not fly with SBE-1 (at least w/out thorough testing). There are no reports either way of the same issue with direct S.Bus input (from Futaba or other receivers).

From glory to defeat in one quick moment... My AQ Y6 went down hard today.

So I was out flying with the camera/gimbal attached, getting some smooth video. I was in PH mode and just going up/down a bit and yawing around, and using ch 8 to tilt the camera (this is relevant). Everything seemed great. All of a sudden I had no control of the 'copter... but it continued to hold position and altitude. No direction controls, no throttle response. Flipped PH off -- no response. I thought I had set a home position earlier, so I hit AUX2 down. This time I got a reaction, but not a very good one (it started to fall rapidly) so I switched it back to AUX2 middle, which returned the copter to position hold again, with no controls. At this point the Y6 was about 50m in the air and the batteries were running down, and I couldn't figure out how to bring it back safely -- I had no clue what was going on (in retrospect of course I could have saved it). I did consider that somehow the AQ went into failsafe, or I lost radio reception (despite strong RSSI readings on the FrSky telemetry screen), but since I had response on AUX2, that didn't make sense. I tried to bring it back down by flipping to RTH and back, to get it lower at least, but it ended up tumbling out of the air and that's all she wrote. All arms broken, LG bent like pretzels, at least one motor stuffed, gimbal bent up but fixable... and unfortunately the G11 camera has a broken LCD and scratched lens Everything else seems Ok so far. Except my dignity.

Anyway, I did find the problem. It's a bit strange, so bear with me. I'm using an Evo 9 Tx with FrSky conversion and their 8ch Rx going into a Futaba SBE-1 S.bus converter, then through a home-made inverter, to the AQ Spektrum connector. As I described in , there is no way to pass complete signal loss through the SBE-1 (it has it's own failsafe which can't be disabled), so the RSSI/SIGNAL_QUALITY reading from AQ is always "99." I set up failsafe in the Rx instead, which I've successfully tested on the ground.

This all works fine, EXCEPT, apparently, with a particular combination of channel input signals! If my AUX2 switch is in the middle position, AND channel 8 (AUX3) happens to be in a "magic spot" then the RSSI output in AQ GCS drops to zero, and it no longer shows any response on any RC channels! No, really. My AUX3 is on a slider, and if I move it to the right spot, I can get AQ to stop responding to any further control input, until either AUX3 is moved, OR until AUX2 is switched away from middle position (high or low). Somehow it also seems tied to throttle position a bit -- when throttle is all the way down, it's much easier to find the spot on AUX3 which kills the RC input (actually sliding it to middle seems to do it most of the time, if throttle is down).

I dug into it some more, and if I disconnect the SBE-1 channel 8 connector from the Rx entirely, AND AUX2 is in the middle position, then my AQ RSSI reading is zero and there is no response to any control input.

I verified this is not a Rx issue -- while the controls are locked up in AQ, I can get proper output directly from all the Rx channels (using a rc switch and LED to test). I also swapped receivers entirely, trying out a 72Mhz Corona, and got the exact same behavior. I don't know how to test what the SBE-1 is actually putting out on the s.bus.

So basically this whole time I've been flying with a "time bomb" and it took just the right combination of RC signals to set it off. This is the first time I was using AUX3 to carefully tilt the camera, so at some point I triggered the "magic spot" and the AQ went into failsafe mode, from which I couldn't recover (this is when it would have been good to have stage 2 failsafe actually do something).

The log from the flight confirms my findings -- RADIO_QUALITY fades in and out as I'm tilting the gimbal, and then goes away altogether when I stop it in the wrong place, only to return briefly when I flick AUX2 down. In the graph below, Red is RADIO_QUALITY, Blue is Aux2, and Green is Aux3.

The full log file is here: http://max.wdg.us/AQ/AQ-crashlog.zip (12MB).

So far this is all I know on the matter and anything further is speculation. Would love to hear from other SBE-1/S.Bus AQ flyers out there and see if we could narrow down this issue (to me, the SBE-1, S.bus, or AQ). If the problem is not just localized to me, then someone else will be next to discover it the hard way.

Thank you for reading!
-Max

[kinderkram]

Oh sheeet!
Sorry for your loss... that sounds really bad - especially about the camera.

Do you have the chance to test your radio combo against another flight controller? Or at least what each stage of converter, inverter etc. throws out?
Question is: does the FC get no or weird signals or does it "think" it gets a bad signal.

I'm a bit worried since this is the second incident related to a barely tested set of radio combinations. The other case was with PPM but the reaction was similar: the AQ went into failsafe and hovered...
Since your transmitter and receiver seemed ok, I'd also locate the problem somewhere in the line behind the SBE1.

I hope someone with the same combination can bring some light.

[Max]

Thanks Norbert. The worst part is that I didn't even get any video because the camera didn't save it. Oh well, it took crap video anyway... nice pics though. Everything else can be/is getting fixed. Even the stuffed motor seems OK after some cleaning (will keep it around as a backup). Those things are pretty tough. One of the arms survived, and even one prop left intact!

Well yea I don't think it's the Rx since it does the same thing with an entirely different RC system (the Corona, with stock Evo 72Mhz synth module). I have also flown the FrSky Rx with another controller in the same Y6, although I couldn't swear I ever hit that exact same combo of channel positions. I guess I could plug it in and try, but seems futile.

Unfortunately I have no way to test what exactly the SBE-1 is putting out (with or w/out my inverter). Nor do I have any other S.Bus Rx to plug into the AQ, obviously. If S.bus is just s serial protocol, what would I need to read/analyze it? I don't have a real scope, but if it's something that can be read with a simple sound card or parallel port analyzer, I can manage that.

If anyone flying an actual Futaba S.bus Rx could check this on their setup, it might help narrow things down further.

For kicks, I was going to try compiling a firmware version with the PPM changes and see what happens. Can't fly 'till I figure this out anyway.

Speaking of compiling, I was using version r21 from the repo which I compiled, but I also verified the same behavior with the r19 .hex file posted for download, just to make sure.

-Max

[joebar.rc]

[epyonxero]

Im also using the SBE-1 converter. Its connected to an Optima 7 Rx and Aurora 9 Tx. I looked at the Radio Quality log from a flight I did last night and I had 100% signal except for one point where it dropped to 32% for maybe 100 data points and returned to 100%, the drop didnt coincide with any of my channel outputs. Ill keep an eye on this.

[Max]

Hi Menno, thanks for chiming in. The channels aren't anywhere near 100% deflection when this happens (and it doesn't happen when they are). Also it's not a FrSky issue at all, still happens with good ol' 72Mhz too. But yes, obviously something is causing an output which can't be interpreted correctly by the FC (not saying that's an AQ problem necessarily). I guess I could try to hook some kind of analyzer to the output and see what happens (?).

Is there no-one on the dev team who is using S.Bus?? How do you guys test it to claim it works? One guy flying s.bus doesn't prove this isn't an issue (maybe his ch. 8 is on a switch or he's never used it-- who knows). I realize sbe-1 was untested and if it's faulty then so be it (but people should be warned). But if it's an s.bus problem, that seems like a bigger deal.

Epyonxero -- this sounds very similar. Under normal circumstances there should be no way to get a true "rssi" reading from the SBE-1. Could you please test on the ground and see if you can get the RSSI output to zero? To watch it using QGCS, open the Engineer tab, then in the MAVLink Message Inspector sidebar expand the RC_CHANNELS_RAW tree -- "rssi" should be at the bottom. Then try moving ch. 7/AUX2 to the middle and then either moving AUX3 slowly through the full range (if you have it on a POT), leaving it in the middle (if you have a switch), or maybe unplugging ch.8 from the SBE-1 altogether. With mine, ch.7 in the middle and ch. 8 unplugged I get the 0 rssi reading consistently.

Thanks
-Max

[epyonxero]

[Max]

Ah yeah that would be a bit different. I'll try it with a 7ch Rx. and see what happens on my setup. But yea, Rx 5 into SBE-1 ch. 8 could be a good test also. Thanks.

-Max

[Max]

I did manage to view the SBE-1 output in a serial terminal. But it's a bit hard to analyze by hand! Would appreciate any ideas about what to do with the output. I used this as a reference:

http://mbed.org/users/Digixx/notebook/f ... d-by-mbed/

BTW noticed that the protocol is supposed to include data about dropped packets as well as when failsafe mode is engaged. Seems kinda useful.

-Max

[epyonxero]

Well I went for a tuning flight today and accidentally confirmed Max's issue. I took off, hovered in manual then switched to Alt Hold, I then flew around some in Alt Hold with no issues. Next I set home position then flew away from the home point and engaged RTH. When the copter got back to home I put the RTH switch back to normal and no longer had control. I looked at the GCS on my Android phone and there was no response to inputs and I got a message saying radio loss. Luckily the copter was hovering just low enough that I was able to reach up and grab it to disconnect the battery.

After that I tried to repeat the problem on the ground and I narrowed it down to channel 7 (Aux 2), just like Max said, but only when returning to the middle position from either up or down. Throttle position didnt make a difference, channel 6 (Aux 1) didnt seem to make a difference, I tried it in the start position and the Alt Hold position. I only got the radio loss message when the board was armed and when returning the Aux 2 switch back to middle, never when switching away. Toggling the switch again after the Stage 1 loss message would re-establish the signal. Attached are the RSSI and Channel 7 graphs from the first flight and then when I was trying to induce the signal loss. The green line is RSSI.

EDIT: Just tried to induce the problem with the board disarmed and while I didnt get the radio loss message it did freeze the radio input display.