Model Match forgotten on receiver

[pacaj2am]

Current Behavior

While flying models I noticed, that sometimes the Model Match ID is forgotten on receiver. Happened with 3 different receivers.

Steps to Reproduce

Don't have steps to reproduce. It is just happening as I am flying with models.

Possible Solution (Not obligatory)

n/a

Details

Happened with fixed wing - once with Radiomaster ER4 receiver, other with Mateksys R-24-V (EP1 with CRSF connected decoder).

Suddenly out of the blue after connecting battery to ESC in plane radio announced only telemetry received, without receiver outputting channels. Needed to disable telemetry in Lua (and later on enable Model Match on receiver and add ID as well).

Behaviour is strange - when it happened first time - I thought I might have screwed up something, but it happened again with 2nd receiver.

Never happened on 3.3.

Your Environment

• TX hardware: Radiomaster Boxer internal radio
• RX hardware: RadioMaster ER4, EP1, ...
• Handset model: Radiomaster Boxer
• OpenTX version 2.10.0
• ExpressLRS version (TX & RX MUST MATCH): 3.4.1
• Packet Rate: 333, 8ch
• Telemetry Ratio: 1:128
• user_defines: n/a

[pkendall64]

A transmitter will connect to a receiver when the model number is different (and the RX will do the 3 blink pattern) and you will get telemetry on the radio. The RX will not send any data to the FC or PWM pins in this case.

[pacaj2am]

I know. Yesterday it happened when I:

• disconnected discharged battery (still with 11.V - so receiver was OK)
• connected fresh battery
• I haven't touched any settings on the radio

After connecting the fresh battery radio announced "telemetry recovered" - but I was not able to continue controlling the plane.

When it happened with first RX I thought I might have caused the issue. But now I was sure, that the setting was lost on the RX. I haven't touched the radio/TX while changing the battery. I was alone at the airfield.

[pkendall64]

Did the Lua script script show a model mismatch along the top, and the receiver LED do the 3 blinks to show model match?
Perhaps you should take this to discord in the #help-and-support channel so more people can help you out.

[pacaj2am]

Don't know about LUA. Disabled model match and got output on TX. Later setted up Model Match again - will see how long it will stick.

[mailman451]

I have encountered the same problem on two surface models with two different RadioMaster MT12 (ELRS 3.4.1, EdgeTX 2.10.0), each with it's own binding phrase.

Yesterday on a ER5C-i with ELRS 3.4.0, which I thought was a fluke. Flashed the RX to 3.4.1, configured again and forgot about it. And it happened today on the other MT12 connected to a ER3C-i already at 3.4.1 which then made me look up the issues here.

In both cases, after a power-down of the ESC and when switching on again maybe 30 seconds later, the model match on the RX was reset as was the configuration of the PWM outputs: All outputs back to 50 Hz from 333 Hz and the default failsafe on CH3 back to 988 us instead of my configured 1500 us.

The binding phrase and the WiFi settings were still correct as configured.

The TX Lua script ("Other devices") told me that the model matching on the RX was now "Off", then connecting via WiFi I saw the outputs were reset. When I switched off the model matching on the TX and used "Bind" from the Lua script the receiver connected ("telemetry lost" followed by "telemetry restored") and the model was controllable again.

Configured RX via WiFi and enabled model matching again on the RX and TX, for now it works as it should.

As the RX is inside a closed receiver box I didn't see the RX LED.

[icebalm]

I have seen this multiple times on two of my quads. I think it happens if the receiver goes into binding mode (power on quick three times) but you cancel the bind by just powering off the receiver. The binding UID will stick but the model match data is lost.

[pacaj2am]

this was not happening with 3.3.x

Today it happened again. Lua shows Model Mismatch.

[pacaj2am]

I have seen this multiple times on two of my quads. I think it happens if the receiver goes into binding mode (power on quick three times) but you cancel the bind by just powering off the receiver. The binding UID will stick but the model match data is lost.

It was not in pairing mode.

[pkendall64]

I have been able to reproduce this issue on the bench. It appears to be a power issue causing the config part of the flash (which also contains the power-reset counter) to be reset. This is because as part of the startup we increment the power counter and write to config. The problem is that the ESP erases the flash sector before rewriting it. If the power is removed during that phase (due to a spike etc) then the config is gone and you see the behaviour you are getting.

[mailman451]

I'm aware that power issues/power-off at the wrong time can break flash writes (especially as the ESP32 doesn't seem to have a built-in EEPROM but a flash space called NVS), and that it can happen at least on RX boot (counter write) and 2 seconds later when that counter is reset again.

If that would be the culprit, it seems that pre-3.4.x was a lot less prone to hitting that spot, because I've never experienced it until 3.4.x, where for me it happened twice within two days.

From a very quick glance at a comparison between rx_main.cpp on 3.3.2 and 3.4.2 quite a lot has changed, so I'll try to be more aware when powering on/off my cars to get a better idea of when I trigger this.

[pkendall64]

The problem actually exists on the ESP8285 based receivers, not the ESP32. As it emulates ROM by erasing/writing a whole flash block in one go. I have a fix in the works that moves the power-on/off counter out of the space we use for configuration so it's in it's own space and when that is ready it would be good to get some testing/verification that the problem is fixed.

[pacaj2am]

The problem actually exists on the ESP8285 based receivers, not the ESP32. As it emulates ROM by erasing/writing a whole flash block in one go. I have a fix in the works that moves the power-on/off counter out of the space we use for configuration so it's in it's own space and when that is ready it would be good to get some testing/verification that the problem is fixed.

Indeed both Radiomaster ER4 and EP1 are esp8285.

I can flash from a branch to confirm, usually it happens once a day or two - I can confirm after a weak that problem is gone. Splitting config and bootcount would be mine proposal as well.

I know, I shouldn't be much worried about flash wear, but can we have write counter and offset to write to different parts of flash?

[mailman451]

My bad, haven't used any ESP yet and thought that ESP32 was the architecture, not a specific model.

Anyway, I don't have a build evironment set up outside of the ELRS Configurator, so I'll help testing if I can flash it from the Configurator.

And I've asked myself the same flash wear question. I haven't found anything yet on the flash cycle endurance of the 8285. From my experience you usually get around 10k erase cycles in microcontrollers like STM32 or AVR, which would be quite enough as far as power cycles go.

[pkendall64]

If you would like to test PR #2755 that would be extremely helpful. Please let me know in the comments on the PR. Thanks.

[MayanHawk]

If you would like to test PR #2755 that would be extremely helpful. Please let me know in the comments on the PR. Thanks.

This also may work for my issue #2746

I'll test after this weekend's events

[mama99de]

Had the same issue today twice in a BETAFPV ELRS Micro Receiver 5Ch PWMwith V3.4.2.
Model ID Lost and also Serial Configuration, Pin 2/3 was configured as Serial Output with CRSF. Got back to default 50Hz

[pkendall64]

Had the same issue today twice in a BETAFPV ELRS Micro Receiver 5Ch PWMwith V3.4.2. Model ID Lost and also Serial Configuration, Pin 2/3 was configured as Serial Output with CRSF. Got back to default 50Hz

Could you try with the PR and comment on that if it works or has any failures.

[pacaj2am]

working PR merged