ExpressLRS icon indicating copy to clipboard operation
ExpressLRS copied to clipboard

Dangerous behaviour with mismatched Tx/Rx versions

Open NameOfTheDragon opened this issue 2 years ago • 3 comments

Current Behavior

I have the following equipment:

  • RadioMaster TX16S with HappyModel ES24TX Pro module
  • Diatone Roma F5 quadcopter running Betaflight 4.3, with HappyModel EP1 Rx
  • Custom build tinywhoop running Betaflight 4.3, with HappyModel EP1 Rx

I use Model Match on my quads so they will only respond to the correct Tx models.

I had upgraded my Tx to 3.0.0-RC1 (Radiomaster TX16S with Happymodel ES24TX Pro) I had also upgraded my Roma F5 to ELRS 3.0.0-RC1 and made sure it was bound and responding. I then powered down the Roma F5 and powered up my tinywhoop to update it, I had not yet selected the tinywhoop model on the radio. I powered the radio off and received the "Rx still connected" alert. This was my first warning, there ahoulr NOT have been any Rx connected at this point. I didn't recognize it for what it was, so I pressed on and forced the radio to power off.

I powered the radio back on, selected the correct model for the tinywhoop and started to build the firmware. Without warning, the motors started spinning sporadically with random duration and the quad tried to take off.

My TX has several safety interlocks to prevent accidental arming.

  1. Throttle must be at zero
  2. Toggle switch must be held while the arm switch is flipped
  3. Model match should prevent a mismatched model from even fully connecting

There is absolutely no way this model should have been able to arm itself. The radio arming interlocks were completely bypassed, model match was completely bypassed. This will result in people getting injured.

Steps to Reproduce

  1. Update TX module
  2. Update first quad to 3.0.0-RC1
  3. Power off first quad
  4. Power on second quad
  5. Power off radio, it may say "Rx still connected" - first red flag. Force the power off.
  6. Power radio on (dismiss any switch warnings etc)
  7. Wait a while. Make sure your props are off!!!!

Your Environment

  • TX hardware: HappyModel ES24TX Pro module
  • RX hardware: HappyModel EP1
  • Handset model: RadioMaster TX16S
  • EdgeTX 2.6.0
  • ExpressLRS version (TX & RX MUST MATCH): Mismatched versions - 3.0.0-RC1 on TX, RX still on 2.2.0 waiting to be updated
  • Packet Rate: 250Hz
  • Telemetry Ratio: 1:32
  • user_defines:

NameOfTheDragon avatar Jul 03 '22 17:07 NameOfTheDragon

Hmm I'm still not sure how this can happen since v3 has moved the sync packet to another frequency. The only thing I can think of is that BF is processing RC packets while not being in the Connected state. Something to look at later.

If this is repeatable can you please test https://github.com/ExpressLRS/ExpressLRS/pull/1673 flashed to the TX.

JyeSmith avatar Jul 04 '22 23:07 JyeSmith

Yeah it is because we try to break the connection API by moving the sync channel but users can really be dumb and get their TXes to syncspam while their different-version RX models are powered with props on and try to force a connection. The #1673 method will be much more reliable in the face of this sort of behavior.

CapnBry avatar Jul 05 '22 13:07 CapnBry

Hmm I'm still not sure how this can happen since v3 has moved the sync packet to another frequency. The only thing I can think of is that BF is processing RC packets while not being in the Connected state. Something to look at later.

If this is repeatable can you please test #1673 flashed to the TX.

I fully accept that this happened as the result of a perfect storm of stupidity on my part, but unfortunately we are all stupid several times a day. My 5-inch powers the receiver from USB, whereas my tinywhoop doesn't and requires a battery plugged in. The 5-inch has made me lazy about taking the props off because the motors can't start on USB power.

I'll try to repro it in a video. I would have to downgrade my tinywhoop to V2

NameOfTheDragon avatar Jul 18 '22 02:07 NameOfTheDragon