Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Momentary loss of RF link when changing flight mode #5011

Open
1 task done
AJHAJHAJH opened this issue May 15, 2024 · 7 comments
Open
1 task done

Momentary loss of RF link when changing flight mode #5011

AJHAJHAJH opened this issue May 15, 2024 · 7 comments
Labels
bug 🪲 Something isn't working triage Bug report awaiting review / sorting

Comments

@AJHAJHAJH
Copy link

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
@AJHAJHAJH AJHAJHAJH added bug 🪲 Something isn't working triage Bug report awaiting review / sorting labels May 15, 2024
@ParkerEde
Copy link
Contributor

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
Copy link
Author

"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
Copy link
Author

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
Copy link
Contributor

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 pfeerick reopened this May 16, 2024
@pfeerick
Copy link
Member

pfeerick commented May 16, 2024

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
Copy link
Collaborator

3djc commented May 16, 2024

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

@AJHAJHAJH
Copy link
Author

"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

NCHSwitch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🪲 Something isn't working triage Bug report awaiting review / sorting
Projects
None yet
Development

No branches or pull requests

4 participants