JR Failsafe behaviour
05-23-2007 | 02:00 PM
#1
Thread Starter
Senior Member
My Feedback: (11)
JR Failsafe behaviour
Hi Danny,
Hope you can explain this one, since I like to understand as much as possible about the way in which my chosen brand of radio works.
Per http://www.rcuniverse.com/forum/fb.asp?m=5887092 :
This behaviour seems inexplicable to me ; here's what my understanding of the failsafe behviour would be expected to be:
TX builds up a digital frame containing required servo positions, plus some housekeeping bits (including info about what the failsafe positions are). A CRC (or checksum etc., but let's call it a CRC for the purposes of this discussion) is calculated based on the frame content and added to the frame that is transmitted.
RX receives the frame, separates it into CRC and base frame info, calculates the CRC from the base frame using the same algorithm as the TX does. RX compares the calculated CRC to the received one. If they match, RX resets its 'bad_frame" counter to zero, stores a copy of the positional info and then uses the positional info to drive the servos. If the CRCs do NOT match, the RX increments the bad_frame count and checks whether this count has passed a designated threshold. If the threshold HAS been passed, servos are driven to their pre-set failsafe positions or held in last position depending on the failsafe settings. If the threshold has NOT been passed, then ALL servos hold their prior position.
This means that if e.g. you set throttle to kill as your failsafe, then when a "bad frame" is detected, the throttle will in fact "hold" for a set period (Something around 1/4 second with the 10X, used to be selectable with older JR radios) before going to the kill position.
The exact behaviour of any manufacturer's system can diverge from the above, but it should be pretty close in general.
For invalid data to be passed to the servos, it would seem that either the RX must malfunction, or the bad frame must be corrupted in such a way that the CRC still checks out - an occurence which is typically designed to be statistically very rare.
So, I understand that based on the limitations of the PCM checks, it is possible in rare circumstances that a bad frame may still be acceptable to the RX due to the 'chance' occurrence that e.g. a corrupted frame gets corrupted in such a perfect way that its CRC corruption matches the main data's corruption. Seems to me though, that this would by its very nature be a "random chance" issue, and not something that is reproducable.
David says his experience was reproducable - why is this ? I would like to understand whether this is some fluke occurence of one bad RX, or a design bug or even a feature, whether I am misunderstanding how JR implements failsafe, etc.
Thanks in advance for any education you can provide.
Gordon
Hope you can explain this one, since I like to understand as much as possible about the way in which my chosen brand of radio works.
Per http://www.rcuniverse.com/forum/fb.asp?m=5887092 :
ORIGINAL: DaveShulman
We duplicated the exact scenario.
When you have a radio (JR10X) on and working, and add another radio on the same channel, at a reasonable distance away (to where it won't immediately swamp the original) and slowly bring the 2nd radio closer, once within range, the 1st radio goes into about 1/2 stick of down elevator before going into hold/failsafe. It's probably less than a second of input in the down elevator before holding.
If you do this and the 2nd radio is close by and swamps the signal, it goes into hold/failsafe immediately (without the down elevator).
We duplicated the exact scenario.
When you have a radio (JR10X) on and working, and add another radio on the same channel, at a reasonable distance away (to where it won't immediately swamp the original) and slowly bring the 2nd radio closer, once within range, the 1st radio goes into about 1/2 stick of down elevator before going into hold/failsafe. It's probably less than a second of input in the down elevator before holding.
If you do this and the 2nd radio is close by and swamps the signal, it goes into hold/failsafe immediately (without the down elevator).
TX builds up a digital frame containing required servo positions, plus some housekeeping bits (including info about what the failsafe positions are). A CRC (or checksum etc., but let's call it a CRC for the purposes of this discussion) is calculated based on the frame content and added to the frame that is transmitted.
RX receives the frame, separates it into CRC and base frame info, calculates the CRC from the base frame using the same algorithm as the TX does. RX compares the calculated CRC to the received one. If they match, RX resets its 'bad_frame" counter to zero, stores a copy of the positional info and then uses the positional info to drive the servos. If the CRCs do NOT match, the RX increments the bad_frame count and checks whether this count has passed a designated threshold. If the threshold HAS been passed, servos are driven to their pre-set failsafe positions or held in last position depending on the failsafe settings. If the threshold has NOT been passed, then ALL servos hold their prior position.
This means that if e.g. you set throttle to kill as your failsafe, then when a "bad frame" is detected, the throttle will in fact "hold" for a set period (Something around 1/4 second with the 10X, used to be selectable with older JR radios) before going to the kill position.
The exact behaviour of any manufacturer's system can diverge from the above, but it should be pretty close in general.
For invalid data to be passed to the servos, it would seem that either the RX must malfunction, or the bad frame must be corrupted in such a way that the CRC still checks out - an occurence which is typically designed to be statistically very rare.
So, I understand that based on the limitations of the PCM checks, it is possible in rare circumstances that a bad frame may still be acceptable to the RX due to the 'chance' occurrence that e.g. a corrupted frame gets corrupted in such a perfect way that its CRC corruption matches the main data's corruption. Seems to me though, that this would by its very nature be a "random chance" issue, and not something that is reproducable.
David says his experience was reproducable - why is this ? I would like to understand whether this is some fluke occurence of one bad RX, or a design bug or even a feature, whether I am misunderstanding how JR implements failsafe, etc.
Thanks in advance for any education you can provide.
Gordon
05-30-2007 | 12:58 PM
#3
Thread Starter
Senior Member
My Feedback: (11)
RE: JR Failsafe behaviour
In this thread that cropped up in the aftermath of Dave's problem: http://www.rcuniverse.com/forum/fb.asp?m=5893894 ... it seems that several other people also reproduced the problem.
Gordon
Gordon
