Prevent interference from calling RXdoneISR #3154
Conversation
|
Hello - I was getting intermittent short range failsafes while flying with DJI goggles 3. I made a repeatable test scenario and tested 3.5.3 and the 3.x.x maintenance FW back to back. 3.5.3 had frequent / almost always failsafes by having the G3 next to the Elrs tx and powering the o4 on and off. When the G3 and o4 link or lose link, there is a sudden spike in 2.4 noise, which appears to be generated locally by the G3. The Elrs Tx powers up when there is this increase in noise floor, but the rx was failsafing. 3.x.x had no failsafes, but exhibited the same expected power up behaviour or the tx. Returning to 3.5.3, the failsafe behaviour returned immediately after powering in the goggles 3. cheers for this, it seems as though this will fix the issue for me with short range failsafes. |
Thanks for the feedback. This is very helpful. |
|
Hi! Could someone please write a tutorial how to flash this 3.x.x version and fix this bug? |
In configurator go to Settings, and make sure "Expert mode" is enabled. This kind of question is best asked on discord in the #help-and-support channel. |
* prevent interference from calling RXdoneISR * wording
Under heavy noise/interference there is a chance that a 'fake' packet can be received by the TX module. If this is done during setup for transmitting the next packet it can cause busyTransmitting to be set to false, and the following TXdoneISR() to also be cancelled.
This is bad. Mainly due to HandleFHSS() not being run and the frequency not hopping. This causes the Rx to no longer be in sync and disconnect, or have a very low LQ.
Below is an example of dio going high due to a rxdone, immediately after starting the cmds for transmitting the next packet.
Red highlights tx cmds, yellow rxdone cmds due to interference.