Frsky S8R receiver - serious bug when using SBUS

[tinkerguy]

Hi fellow hobbyists, I'm posting a message in the hope that Aloft Hobbies or somebody who may have connections with Frsky can report a problem with the S8R receiver in the hope that it can be fixed in a future firmware update. I've checked out this on a number of S8R receivers from different manufacturing dates and the problem is the same.

It seems like the S8R receiver encodes wrong SBUS channel value when the equivalent output sent falls below 880 microseconds. This happens on all firmware versions including the latest v2.1.2 and is easily reproducible. All you need to do is to connect the S8R receiver using the SBUS connection to either an RB-10, SBUS-to-PWM decoder and observe the deflection on the servo.
Expand the end-points in OpenTX in the output screen so so that you get 121% or more. Now if you move the sticks and follow the servo movement, once the actual output on a channel drops below 880 microseconds, the servo will suddenly deflect to the other side and stay there. This can be very dangerous situation either from a control standpoint or if the channel is assigned to a throttle. The PWM output from the normal servo channel pins seems ok. The non-stabilized ACCST receivers do not seem to have this bug.

Please try this out for yourself and I hope Frsky can have this fixed.

 

[HENNY]

Well firstly the latest OTX firmware is version v2.3.15. OTX version v2.1.2 dates back to 2015. Update your radio first.
Secondly you should not be operating the PWM ideally below 1000 usec. 880 is at the bottom end of the scale. You will find at 880 usec the addition deflection you achieve is almost zero anyway. If you need additional deflection just move your control horn take off point out to the next hole. A number of the older servos cannot travel to 880 usec and will hit the internal feedback pot causing the sort of results as you describe.

 

[tinkerguy]

You just assumed I used an old release. I keep all my radios, receivers and sensors updated to the latest firmware release. The Taranis radio is already running OpenTX 2.3.15.

The radio OS version is not part of the problem. The same problem happens with newest EdgeTX release on a Radiomaster with the S8R. Extended range is a feature of the Open-Sourced firmware that allows you to get more throws - it is a supported feature. Most of my new brushless digital servos can operate way beyond the normal limits. All work fine when connected to the PWM output of the S8R - its only the SBUS that gets wonky. Again the SBUS output works fine with the X8R, RX8R Pro at values below 880us.

The behavior of the S8R in misencoding a high SBUS value at the low range is a dangerous bug.
At the very least - if the low end limit is reached it should hold that position ( ie stay at 880us ) - not swing to some large value.

 

[Konrad]

The PWM at that low a value is undefined. So there is no Sbus code to correspond. If you need more movement program the servo to respond to the defined RX output (increase the motion at the cost of lowering the resolution).

I think most RX only output valid values as a way to filter the output with a band pass filter.

Agree the output should stay fixed. I fear that the low value results in the loss of the pulse resulting in the residual value being added to the next pulse. Hence the jump.

Don’t know the memory limitations on the gyroed RX. The correct solution is to have the TX output valid values. Not cut into the RX filtering of noise on the line.

If using Humper hardware I'd strongly recommend staying with Jumper TX and RX combo.

P.S.
I think today’s servo pulse is defined as 1000µs to 2000µs. Most standard servo motion is defined as 1100µs to 1900µs plus trim. There is enough safety in the separation pulse to allow most PWM signals to be expanded 20%. So that would be a width of 900µs to 2100µs. I wonder how the servo "pulse" is defined in S-Bus.

 

[tinkerguy]

Update:

Thanks guys for the input.
Took out my digital oscilloscope to help troubleshoot what's going as it is able to read and measure the PWM width directly.
Here are the readings in microseconds with the radio set to maximum output ( +- 150% )

	Min Pulse Width	Center Pulse Width	Max Pulse Width
Displayed on Taranis Radio Screen	732	1500	2268
Measured at S8R PWM Channel PIN	894	1498	2074
Measured at S8R SBUS to PWM decoder	898	1502	2074

So realistically the maximum useful range from SBUS is probably around 900 to 2070 on my tested receiver.

So what happened to my initial observation of the sudden deflection? I think it has something to do with failsafes.

I realized that I have never ever set a "custom" value to the failsafe, using instead the "hold" setting. So I tried setting on the radio and then tested it again.
To my pleasant surprise, the wild deflection stopped happening at the low end - even when I move the stick all the way down to the lowest (displayed) value of 732.
I then set the failsafe back to other possible values : "hold", "no pulse". Again, the wild deflection stopped happening - so something has been changed inside the receiver.

So I think this is what's happening: Apparently on a new S8R receiver, you need to at least program the failsafe once either from the radio or by pushing the F/S button on the receiver.
If you fail to do that, there is some weird uninitialized variable within the firmware that causes it to output a random value from SBUS once the low limit has been reached.

Fortunately it remembers the last value set, so now this random value no longer is sent once you reach the low limit, and actually keeps the low value ( measured at 898 microseconds ).

I normally do not use the custom failsafe setting as I prefer the receiver to hold the last value until it gets a good frame again. In my more than a decade of flying on 2.4 GHz I have never encountered a failsafe.

All I need to remember to do now is to set the custom failsafe settings at least once on all my receivers, whether I intend to use them or not.

 

[jseyfert3]

Secondly you should not be operating the PWM ideally below 1000 usec. 880 is at the bottom end of the scale. You will find at 880 usec the addition deflection you achieve is almost zero anyway. If you need additional deflection just move your control horn take off point out to the next hole. A number of the older servos cannot travel to 880 usec and will hit the internal feedback pot causing the sort of results as you describe.

I think today’s servo pulse is defined as 1000µs to 2000µs. Most standard servo motion is defined as 1100µs to 1900µs plus trim. There is enough safety in the separation pulse to allow most PWM signals to be expanded 20%. So that would be a width of 900µs to 2100µs. I wonder how the servo "pulse" is defined in S-Bus.

Well this made me curious. I was looking at my HS-5056MG digital servos getting them ready to put into my plane. I needed to center them so I took out my new battery cell voltage tester with built in servo tester and plugged the servo in. The tester goes from 500-2500 uS. The servo, albeit digital, moved from roughly 750-2250 uS (+/- a few uS). If you continued moving outside this range, it just didn’t move, and more importantly, you don’t hear the motor trying to move it either. It just stops moving cleanly. I suspect being digital it just ignores values outside a pre-defined limit and doesn’t try to move further.

Nope. Actually I know that’s what they do now. Before I posted I played around more. With the servo centered, I flicked the pot on the servo tester super fast to the minimum range. The servo never budged off center. So anything outside a set pre-defined range and the digital servo just stops moving and ignores the input.

So then I was curious and repeated the same test on my HS-82MG analog servos. The results where that at approximately 805 on the low end and 2330 on the high end, the servo hit a mechanical limit and you could hear the motor trying to continue moving. Going further did cause a slight amount of additional movement but of course it was straining the entire time, and any movement in this this range should really be avoided. I did not perform the flick the pot on the servo tester to minimum test, since the servo motor straining confirmed the servo doesn’t ignore out of range commands but tries to follow them even though it’s pushing against its mechanical limits.

What was most interesting was the digital servo seemed to have exactly 250 uS above and below the “standard” range of 1000-2000 (or 350 if you call it 1100-1900), whereas the analog servo didn’t go as low but went even higher. I have 3 more of these analog servos and one digital. I am curious if the other digital will show the very defined range of 750-2250, while the analog ones will show variation in the range.

Now, is this extra range practical? Probably only in very edge cases. If you have the arm centered at 90°, it’s probably at like 10° at the end stops. Assuming a regular pushrod setup, trigonometry means any movement here gives almost nothing at the control. If you were directly rotating something then perhaps, though they make rotary servos that may be better suited to this.

 

[Wayne]

Oddly some others recently spotted something similar that we might be able to fix with our UNI-RX firmware. They were suggesting changes to Sbus for a redundant receiver setup where everything is being passed via sbus. Basically they were seeing servo values shifted when the system falls back to the secondary receiver. They finally tracked this down to the ability of OpenTX (and Edge (Edge is just a port of OpenTX)) to use the extended PWM outputs. Sbus does not support these extended limits, and nor do some servos, etc. So why allow the transmitter to do this? It just causes issues down the road.

@MikeB says it much better than I can:

I still think the mistake is in openTx in allowing more than +/-125% pulses to be transmitted. This is something that was changed at some point as the original open9x had a limit of +/-125% (and er9x/erskyTx still keeps to these limits). If some part of the system as a whole (in this case SBUS) cannot support a wider limit range, then the Tx should NOT allow such pulses to be transmitted.

Even if the SBUS scaling is changed for the redundancy use, SBUS servos still need a standard SBUS output, and are still limited to +/- 125%.

Turn off the extended limits and you should be good to go. Adjust your servo arms and control horns if you need more throw.

 

[MikeB]

Even -125% is a problem!
I've just tested a S8R running V2.1.0 EU-LBT and I can see the problem existing, even with failsafe set.
Using erskyTx, extended limits are set to a maximum of +/- 125%. I've enabled these, and configured a channel to use them with the channel source set to a pot.
I'm monitoring the SBUS output with a logic analyser.
On the SxR receivers, you must run the self check and calibrate the servo outputs after enabling and using extended limits or the Rx won't actually use them!
At a Tx channel output of 879uS (-121%), the SBUS output for the channel is 0, as you go below 879uS, the channel output jumps to 2047 (2160uS) (note these SBUS values are not in uS).

Mike

 

[tinkerguy]

Confirmed what Mike has observed in his test. The problem has nothing to do with failsafes. Once I re-calibrated the S8R to use the extended limits - the SBUS output wrapped around on both high and low extremes. If this cannot be fixed on firmware, Frsky should at least document the limitation. Imagine the SBUS output is driving a throttle, when it gets too low - it wraps around and outputs max - a potentially dangerous situation.

 

[HENNY]

Confirmed what Mike has observed in his test. The problem has nothing to do with failsafes. Once I re-calibrated the S8R to use the extended limits - the SBUS output wrapped around on both high and low extremes. If this cannot be fixed on firmware, Frsky should at least document the limitation. Imagine the SBUS output is driving a throttle, when it gets too low - it wraps around and outputs max - a potentially dangerous situation.

you are missing the point and that is don,t use extended trims.

 

[MikeB]

It is still a problem that should be fixed. FrSky are now investigating it.

Mike

 

[DirkW]

We had this issue a few years ago. I am not sure but I believe it was an XSR receiver...

 

[jseyfert3]

Okay, this is a bit off topic, but related to that previous test I did. This $4 HobbyKing servo has a 180° range of motion and operates from 500-2500 uS. I shit you not. It was just barely hitting a mechanical stop at 500 but not at 2500.