Devo RX led flashing.

Hello
I am using a devo 12s with a banggood 4 in one module. I use a devo rx 8 channel

I have some difficulties configuring a model and as I was trying to do that I noticed that in a position of the right stick (up and left) the red light of the Rx flashes.
when the sticks is in a different position the light is fix.
I changed the alim of my RX twice same result.
I changed the rx for another brand new : same result.
The led flashes but the Rx works
Any idea of other test or of what can makes this led flashes ?

Hello

I have tried the following
Format the USB drive.
Re load the firmware
I have the same problem RX flashing on a position of the right stick.
The flashing is not regular as when binding is lost.
The binding is not lost as the servo on channel 1 works but not the one on channel 4

Any help is welcome

Hello
After testing more I found that the loss of binding depends on a value in channel setting.
This model file is for a glider with ailerons, flaps, V tail and motor.
The problem occured when I tried to have the maximum throw for my flap servos.
The binding loss appears in crow function ( mix2).When the right stick is in upper position.

In the included file the scale+ for channel 7 ( a flap) is 167 and all works. No binding loss, no flashing.
If increased to 168 or more, binding is lost when the stick is up, Rx flashes. If the stick is slighly moved down the binding comes back.
Binding is not completely lost but erratic. I think that this is due to the fact that I have a fixed ID. So I have some response for some servos but very irregular when the binding is reset.

How is this possible ?

EDIT : I have tried my model file on my Devo 8s and finally I got the same problem. Loss of binding

FDR,
Thanks a lot for your reply, But it is hard for me to understand.
I am not specialist in programming.
Do you mean that the combination of the mixers of my model file makes that in certain position of the stick of my Tx, the values sent by the Tx makes the Rx loses binding.

If this is true, would it not be good to prevent this by putting max and min values for these values ?

FDR,
Thanks for the explanation.
I have effectively changed the limits and scales which has stopped the phenomenon. But it remains that this can be dangerous if somebody does not see that in extrème positions, the binding is lost .
Should I post an issue in the Bug report ?

Done
Thank you for your help
Morlacus

I was able to duplicate the flashing led behavior with Devo10 nightly build and RX1002 receiver. The receiver is not losing binding and the packets are fine. The PWM outputs are stable and correct even when the LED flashes.

The behavior is triggered by short PWM outputs - less than about 920 microseconds. It only happens if a couple of channels have short output pulses. This makes me think the receiver is mis-interpreting the short output pulses as indicating some type of error condition, and blinking the LED as an indicator.

The PWM output is stable down to at least 900 microseconds on the RX1002. I'm hesitant to change the signal limit in the code, which is mentioned in the doc/Devo.txt file: "The sticks return '0' when centered and seem to max out at 0x640 at either end the upper-nibble of byte 9 indicates whether the channel value is positive/or negative I.e at the end of stick travel the value is 0x640 and bit 9.x indicates which end the stick is at".

I propose addressing the github issue by adding a note to the manual about this behavior. Comments invited!

I am pleased that you could find the same behavior or the devo Tx than I

I want just add that even if the binding is not lost the result is the same as servos stop working and recover a normal comportment just when the Rx light stops flashing.

As this behavior is difficult to detect (need to look at the led while testing sticks, pots, etc in all possible configs) my opinion is that it should be made impossible.

In fact the Rx led flashes also when no servo is plugged if the sticks are in the position where the flashing is triggered. So for me this does not depends on the servo.

Thanks for the explanation
On the other hand, the servo era is not totallly out of date....

Morlacus wrote: On the other hand, the servo era is not totallly out of date....

I mostly fly fixed wing aircraft and even if you use a SBUS/IBUS/SRXL receiver connected to your flight controller the FC will most probably put out a PWM signal. I guess Walkera will not be the company to put all the pieces together: A transmitter, receivers and servos that can be flashed with free software, a nice error corrected RX output protocol that isn´t reengineered (unlike SBUS) and all the data and power distribution cables/brackets/connectors. I think instead of a JR connector we could use something like XT30 + a data pin. 3 pins and 30 A should be plenty if there are servos for aileron/flap/main landing gear on a detachable wing. While PWM servos are totally out of date we still can´t get anything better for our money if we don´t want to be trapped into SBUS2 only stuff. BTW I like the way the devs try to keep the devo protocol module clean. If even needed this pwm travel issue could be addressed by a protocol option but not in general.

I'll do some more testing to make sure "servo stops working" is due to the low PWM pulse width and not because the receiver is going into failsafe. If it is going into failsafe that would be a reason for making a change, but I don't think it's the case.

Any protocol change to limit PWM output has the potential to change the behaviour of users existing models. I'd rather avoid it if not necessary.

I understand the concern. On the other hand some users models could have hidden defect which could be dangerous in some case.

If you consider not the best to add limits to pwm pulse, would it be possible

-either add a feature in the devo protocol to add or not the limiting of the pulse range
-or trigger a warning screen if the conditions of the "flashing light" were reached based on the computation of the model.ini settings.