Bug report and ELRS V4 compatibility

[d51r3verse]

Thank you always for your contributions.

This is a test report and improvement suggestion based on the current master (f751428) with XR4 RX as TX

• I wanted to use ExpressLRS V4 for the Extended PWM range (500–2500) and Arm/CH5 split features, but unfortunately it wasn’t communicate with ELRS V4 TX.
• Is there any way to import a EEPROM V222(used before PR #489) into the current V223 EEPROM?
• ELRS connection status shows at least +30 higher than since f54870f whatever TX rates and baud.

I’m attaching my EEPROM and firmware files for your reference.

2.1.0_EEPROM_VER_222_2025-05-09_f5487f0
2.2.0_EEPROM_VER_222_2025-12-14_0708360a
2.2.0_EEPROM_VER_223_2025-12-14_f751428c

eepromNfirmware.zip

[ajjjjjjjj]

Hi, thanks for your feedback.
What is 0708360a behaviour if you specify it in eeprom copies?

Is there any way to import a EEPROM V222(used before PR #489) into the current V223 EEPROM?

There is no way.
I know it's unconvinient to recreate models, but this is probably the last refactoring needed ever and reason behind it:

• allow for more buttons, - two extra buttons coming!
• regain some free eeprom space after Save RAM: Allocate eeFs only for MAX_MODELS #462,
• regain some RAM by using optimized data structures for modules and trainer data -
  as a bonus this change allowed to increase maximal number of telemetry sensors to mach EdgeTX radios. This may be important since there are new sensors and upcoming changes in INAV.
• adjust data model to match current MPM/EdgeTX implementation requirements, if someone want to work on it,

[d51r3verse]

Thank you for the explanation.

When checking the TX module (XR4 RXasTX) directly on PC using elrsbuddy, the frame rate is correctly reported:
100Hz shows as 100, and 333Hz shows as 333.

However, on all above three builds I tested, the ELRS status consistently reports +30 higher than expected.
Interestingly, after tweaking some of the mixer settings on 2.2.0_EEPROM_VER_222_2025-12-14_0708360a, the abnormal reported value appeared to be normal, but replacing the EEPROM file I previously uploaded again, causes the abnormal count to return. :weird
Could you please check if the EEPROM I uploaded caused same report issue during your testing?

but this is probably the last refactoring needed ever

That's why you #463 remove EEPROM version from status screen?😄
To be honest, I’m a bit concerned about having to manually migrate the EEPROM again if the structure changes.
When ELRS V4 is supported by OpneI6X, I’ll migrate to what should be the final EEPROM version and run my tests then.

Once again, thank you for your continued contributions.

[ajjjjjjjj]

You have mentioned that you use RX as TX mode. Are you using CRSF_FULLDUPLEX self build to connect RX/TX signals separately or not?
If not, can you try this configuration?

[ajjjjjjjj]

Issue confirmed also for CRSF_FULLDUPLEX mode.

[ajjjjjjjj]

@d51r3verse , check on latest master and let me know if this fixes your issues.

[wimalopaan]

I can confirm that this works now with full-duplex

[ajjjjjjjj]

I have tested in on "standard" S.Port module with success.

[d51r3verse]

@ajjjjjjjj , Sorry for dealyed reply.
I upgraded 2.2.0 2d0ca2d.
RM XR4 ELRSv4 rx as tx /w Full-Duplex : All works as I expected.

EXCEPT crazy status bars and lots more disconnection than before firmware.
921kbps I'm use both TX module and i6x itself.
But, any bauds it will add at least 30 packets( even 5x more LoL )

It was no issues with PC lua emulator. Only with openI6X... weird.

What is this craziest sound? maybe telemetry lost/recover? But telemetry log seems to be fine.

IMG_0069.MOV

ELRS and OpenI6x also latest master branch.

openi6x_EEPR223_2.2.0_2d0ca2dd_Os_2026-02-22.bin.zip

I beliebe there is no more EEPROM structure upgrade 🙏

Thank you for your contribution again.

[ajjjjjjjj]

No worries.
This sound is trainer connected/disconnected. Try setting trainer mode to serial, it should go away, but this is not normal.
I don't know what may be the reason, since I don't know how you connected everything together. Maybe your power solution is very noisy step down?
How stable are gimbal readings on "0.0" display mode?