Momentary loss of RF link when changing flight mode

[AJHAJHAJH]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

When selecting different flight modes, the RF link appears to drop maybe 1 time in 10. the green LED on the Rx goes out, the red LED briefly illuminates, the servos go to failsafe positions and after a fraction of a second the RF link resumes, the red LED goes out and the green LED comes on.

This behaviour only affects my RMTX16s Mk1 and brand new Mk2 when using the internal MPM.

Expected Behavior

The RF link should be constant through flight mode changes.

Steps To Reproduce

1. Use a RadioMaster TX16s with an internal MPM to control a model with multiple flight modes.
2. Use switch E to change flight modes repeatedly
3. Observe intermittent fail safes

Version

2.10.0

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

No response

OS Version

No response

Anything else?

I have tried several different models using different FrSky receivers. I have also tried a TX16sMk1 and a TX16sMk2. The bug also shows if no servos are connected the the Rx.
All MPM's are V1.3.4.0 AETR FrSkyX2Cloned and LBT.

The bug goes away if:

1. Use the same model setups on a Horus X10
2. Use an external IRangex MPM rather than the internal MPM of the TX16s
3. Flash the TX16s with OTX 2.3.14
   RM_MPM.zip

[ParkerEde]

I cannot reproduce the problem described with my TX16S MK II and 2.10.0. I also switch the flightmodes with SE and as RX I use frsky ArcherPlus R6, SR6, X8R etc
Do you have any LUAs running?
Can you try a fresh default etx sdcard content and create a new default model and rebind the RX and try again?

[AJHAJHAJH]

"Do you have any LUAs running?"
Yes, and also widgets - disabling them makes no difference.

"Can you try a fresh default etx sdcard content and create a new default model and rebind the RX and try again?"

1. This worked correctly.

2. I then copied one of my troublesome models (Stigra) to the fresh SD card. This also worked correctly.

3. I then copied the associated sound files to SOUNDS\en\Stigra - the problem reappeared
   StigraSounds.zip

4. I selected external MPM rather than internal - the problem disappeared.

As an aside, prior to V2.8 I would always populate the model's sounds directory with .wav files for all modes, switches and logical switches. V2.8 would take about a minute to select a model. I'm not clever enough to understand the code in detail but it seemed that 2.7 looked for the file as needed whereas 2.8 checked each file found and generated a catalogue on model selection - which was what took all the time. I have no idea if this is relevant.

[AJHAJHAJH]

After a sleepless night I have discovered:

1. This page https://github.com/EdgeTX/edgetx-sdcard-sounds says:
   "Note: EdgeTX supports up to 32khz"

2. If I resample my sounds down to 16kHz, the problem goes away.

I don't understand why this problem exists for the internal MPM but not the external one, but I have a solution.

Thank you for your time and effort, my apologies for wasting both.

[ParkerEde]

I think that the development should actually check why the RF link is temporarily lost only when working with unsuitable sound files. Something like this should be intercepted in any case, as it represents a potential risk. I would not say that this ticket should be closed, but that a developer should take a closer look at it.

[pfeerick]

Indeed... I think now that we have a possible lead as to the a specific reproducible cause, now need to see how to prevent/mitigate it.

@AJHAJHAJH Thanks for narrowing that down, and uploading the files in #5011 (comment) ... that should help to reproduce it.

[3djc]

Out of curiosity, how where those generated ? The format seems to be WaveFormatEx where we use PcmWaveformat

[AJHAJHAJH]

"Out of curiosity, how where those generated ?"

The ones I uploaded were generated by an Android version of a voice from https://www.cereproc.com. I wrote (badly) an App to generate files in whatever format Android wants and then convert them using https://www.nch.com.au/switch/index.html

[AJHAJHAJH]

I've messed with this some more:

I used FFMPEG to convert the files so that they are PcmWaveformat rather than WaveFormatEx - no change.

I discovered that other files from SD\SOUNDS\en<ModelName> (L60-on, SB down etc.) also cause the RF link to glitch, the problem is not confined to flight mode changes.

I renamed (three characters) the SD\SOUNDS\en<ModelName><FlightMode> files and moved them to SD\SOUNDS\en\ and played them using a special function triggered by flight mode - no change.

I then renamed and moved all the files from SD\SOUNDS\en<ModelName> to SD\SOUNDS\en\ and played them all using an appropriate special function and the problem went away.

Again, this problem only occurs for me when using an internal MPM in a TX16S.

I hope this information will help someone cleverer than me to locate and fix the problem.

[AJHAJHAJH]

Still experiencing this issue on 2.11.3, but have just discovered it does not affect my models which use only two servos (elevon equipped gliders).

[AJHAJHAJH]

Release 2.11.5 seems have made this issue better and worse at the same time.

It is better in that the loss of RF happens much less frequently. Sometimes it can take many minutes to induce the fault.

It is worse in that the loss of RF is no longer momentary and now lasts for several seconds. Compare the attached video with the one in the original post.

EdgeTxRFLoss.mp4