Is this a known bug that I can ignore? Did I configure Serial1 wrong? Could there be some other issue?
I don’t think the RC is faulty as it is new and displays its own axis movements correctly. I have already updated to the newest QGC on Windows v5.0.8
Only thing that comes to mind is the SBUS failsafe bit, but I have checked and unchecked the corresponding setting in RC_OPTIONS (Ignore Receiver Failsafe bit), and the issue has remained.
Hi @jobotics -
You may want to try with QGC version 4.2.8 - Blue Robotics ceased testing versions later than that, so your issue could be connected to something in the new version?
QGC version not the root cause, unfortunately. I had been using the version recommended in the Blueboat software setup guide before: QGC installer from Software setup guide
And I only decided to try a newer version after I had encountered this issue in the older QGC version. The behavior is exactly the same in both QGC versions.
QGC version not the root cause, unfortunately. I had been using the version recommended in the Blueboat software setup guide before: QGC installer from Software setup guide
And I only decided to try a newer version after I had encountered this issue in the older QGC version. The behavior is exactly the same in both QGC versions.
Could you please suggest steps to fix this issue?
Explicitly tried 4.2.8 now, issue remains the same. Could you please assit in fixing this? @tony-white
Update: If I turn the receiver (RF) off and on again via my transmitter (this is possible with my RC model), and sometimes randomly, the issue disappears for a minute or so and all the channels in QGC look normal. After some time the behavior described above reappears, however.
I have solved the issue. I hope someone else will find this useful as well:
The Navigator Documentation mentions a method of switching the RC input to non-inverted UART (IBUS protocol according to table). Luckily, our RC supports IBUS, too.
So, I cut the trace on the back of the board, connected the UART solder pad and – it actually works! No more twitching and the channels are still recognized.
this seems sub optimal. Surely a software tweak can save me from physically damaging my board to fix it? Navigator is supposed to use SBUS, so breaking it to make it use IBUS because the SBUS isn’t implemented properly is not really a good solution.
Hi @flow -
There are two types of SBUS - inverted and non-inverted. The Navigator is setup for the more common inverted signal protocol, but if you need to use it with non-inverted, a hardware change is fundamentally required. You can see how this is accomplished in the schematic, on page 6! I’ve found it to be a common approach on other flight controllers…
I have SBUS, and it twitches. The solution given is to stop using SBUS, switch to univerted by damaging the board.
Whilst this may solve the issue of the twitching, it is fundamentally a call to not use SBUS, which isn’t a good answer. Why is there twitching in the SBUS in the first place?
We are given a hardware answer to a software issue, and the answer is to stop using the default protocol.
Hi @flow -
In my experience, “twitching” of outputs is rarely a software issue!
Can you share what transmitter and receiver you’re trying to use with SBUS? Is this for a BlueBoat or some other custom system? Pictures or an explanation of how you have it currently wired in would also be helpful. What GCS software are you using?
SBUS and inverted SBUS are essentially the same thing, in one the signal has just been inverted! I’m surprised that for both the user that created this thread, and your own situation, that you’re getting things working at all with the protocol not matched correctly. If that were the case, maybe you’d have less hesitation in applying the hardware fix?
A software fix fundamentally isn’t possible here. Applying the hardware one only takes a moment - please share if it doesn’t correct your jitters!
I have a flysky FS-iA6B which puts out SBUS. it is configured to put out SBUS, and the navigator recieves the SBUS and happily responds to it. The protocols are matched.
So my hesitation in hardware modification is due to it not addressing the actual issue.
Which is, a periodic twitch when left at rest, or in the full high position (for my servo outputs 1 and 2, which are mappped from ground steering, and driven by CH3).
the twitch is not regular.
It occurs both when the rover is armed and disarmed, and in auto or in manual mode. it occurs when moving or at rest. It happens before any waypoint behaviour is loaded, and may happen after, I haven’t got that far yet.
if i cut the navigator out of the picture, there is no twitch.
I’ve spent a lot of time researching this, and answers are all over the place. It seems that the BlueOS is doing something, as if I observe the reported RC stick position in QGC then it flicks to all channels low at the same time the servoes twitch, as if it dropping the SBUS. This behaviour stops when I provide a low signal on channel 3 (rc3_min at 1000) , and happens if left in the middle (at 1500), or pushed right (rc3_max at 2000). if i change the rc3_min to be at centre trim (1500) and don’t touch the transmitter, the twitching stops, so it isn’t the raw value coming from the controller that matters, but something within the BlueOS software.
Voltage on the servos is provided by a dedicated 5v5a supply. the blue navigator is driven on its own identical but seperate 5v5a supply. The twitching occurs if i supply the receiver from either source.**
switching to Ibus only inverts the signal. so if it ‘fixes’ anything, then that means there is different software handling of dropped or zeroed frames between the ibus and sbus handlers.
because what we are seeing is a frame arriving with the values set to zero. this causes all channels to flick to RCN_MIN and causes the twitch. Which is why setting RCN_MIN to RCN_TRIM makes the twitch disappear.
The fact that switching to IBUS works, without changing the receiver hardware, means there is either a bug in the flysky SBUS system, or a bug in the BLueOS SBUS handling.
Looking at the code. iBUS drops a bad frame before it touches the channel values. SBUS decodes it, labels it a failsafe, and then applies it.
sbus_decode() says a frame whose first four channels are at or below 875 is logged but not used. The caller still passes those values to add_input(), and add_input() copies them into the live pulse array before it reads the failsafe flag: memcpy(_pwm_values, values, num_values*sizeof(uint16_t));
frontend.set_failsafe_active(in_failsafe);
so this is entirely a software issue and I’m switching to github to propose the fix there.
