search

EdgeTX / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio
https://edgetx.org
GNU General Public License v2.0
1.59k stars 337 forks source link

No Multi Telemetry Detected #5402

Open tonims1 opened 2 months ago

tonims1 commented 2 months ago

Is there an existing issue for this problem?

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

In the latest nightlys I have noticed that the status module stays at no telemetry detected. It does it to me by continually changing models. Sometimes it takes a lot for it to appear. but there is something that causes this. Going back to 2.10 I don't have this problem. I have 2 tx16 and it does it to both of them

Expected Behavior

that when changing models the multi module is not blocked

Steps To Reproduce

Constantly changing models causes it. Sometimes it appears right away but other times it doesn't.

Version

Nightly (Please give date/commit below)

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

No response

OS Version

No response

Anything else?

No response

pfeerick commented 2 months ago

Most times it seems to only take a second, which is probably just the delay between the MPM being enabled and starting to send data. But I was able to reproduce this switching between several models with internal MPM enabled... - it is not stuck at "No MULTI_TELEMETRY detected" ... and no changing of protocol settings, nor exiting or re-entering the Internal RF is changing things (i.e. it doesn't appear to be a cosmetic/refresh issue)... but I don't have a RX bound atm so don't know if it is entirely cosmetic or if there are issues communicating with the MPM.

tonims1 commented 2 months ago

When this happens the receiver continues to work but without telemetry

3djc commented 2 months ago

I have not been able to replicate :(

tonims1 commented 2 months ago

Sometimes he does it right away, but sometimes it takes a long time to do it.

tonims1 commented 2 months ago

but when it does, the only way to make it work again is to turn off the radio. Changing the model does not work again.

tonims1 commented 2 months ago

When it happens to me the most is changing between models that have the Frsky protocol. With others it costs more to do it.

pfeerick commented 2 months ago

JC: set up at least two models with MPM configured, perhaps different protocols for each (although funnily enough like the op commented I had frsky x and X2 configured when I repeated it), and simple switch from one model to the next, after a pause in each to allow the MPM to start up properly. After several switches the UI for the module status should give up.

Thanks for confirming the RF continues to work.

On Fri, 9 Aug 2024, 1:45 am tonims1, @.***> wrote:

When it happens to me the most is changing between models that have the Frsky protocol. With others it costs more to do it.

— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/issues/5402#issuecomment-2276143190, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KMAMG4AN2R552TLOE3ZQOHCRAVCNFSM6AAAAABMEGS6DKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZWGE2DGMJZGA . You are receiving this because you commented.Message ID: @.***>

philmoz commented 2 months ago

I can't reproduce this on my TX16S either. I created 2 models one as FrSky X, the other FrSky X2. Failsafe set to hold on both, all other properties as default. Neither model is bound to a receiver. MPM ver is 1.3.4.0 TAER. No matter how many times I switch the Module Status always shows the MPM version in the Internal RF page.

3djc commented 2 months ago

I have done that, I'm actually bound to an x6r for both models, and I switch from one to the other. I use the rssi bars to confirm I have telemetry , but neither on t15 or tx16s can I break it

pfeerick commented 2 months ago

This is going to be a frustrating one to pin down... I just tried with the latest nightly, and was about to get it to fail after 6-8 model switches... I then tried turning the internal RF on and off, and that made no difference. That TX16S is running MPM 1.3.3.33 FWIW...

I then restarted the radio, set the failsafe on both models to "hold" (as I had only changed one before, which I found handy as if the failsafe warning didn't appear, no need to check the module settings... it was already unresponsive ;)) ... and have not been able to get it to do it again now... setting the same one as before back to none... makes no difference... ... 20 cycles later and another restart and it is still behaving... :confounded: :face_with_head_bandage:

After it just did it to me again after a power up and switching into a blank model to setup another test model, I just sat at the Internal RF setup screen, and kept turning the internal RF on and off... (literally just that... no protocol change or anything) and after 20 or so cycles it gave up again... but after another reboot it seems fine...

btw @philmoz this is the fullscreen alert I was referring to before with no background ... I think the alert poped up between model select and having just touched a blank section of the main view to bring up the carousel menu... (which was onscreen once the alert cleared): IMG_20240809_180858

tonims1 commented 2 months ago

I have found a pattern that always tends to fail three models. the first Frsky x2 D16 the second Frsky X2 LBT (EU) the third Frsky D D8. If I restart after the failure in the latter it does not start well. always without telemetry. I have to change model and restart. I have V1.3.4.0 AETR

tonims1 commented 2 months ago

I have found the model that always blocks my module. I've had this model for a long time and I've never had this done before. I started doing it in the last nightlys model1.zip

tonims1 commented 2 months ago

I have closed it by mistake.

tonims1 commented 2 months ago

It keeps failing with other models too. but I see that the protocol that makes it fail the most is FrskyD D8

tonims1 commented 2 months ago

fix: apply customizable switching rules in configure ( #4994 ) It is the cause of this problem. I compiled this commit from June 1 (9A7E1DB) and it causes this error. (the previous one 65799050 from the same day works fine

3djc commented 2 months ago

Interesting theory, but it doesn't contain any colorlcd code, and all other code is only for radio with custom switches, so your tx16s would not be affected if there was issue with it

tonims1 commented 2 months ago

I don't know why but it is what causes me to run out of telemetry when changing models. I have tried it several times.

tonims1 commented 2 months ago

Sorry the previous one who insisted also did it to me. I'm still looking

tonims1 commented 2 months ago

After going around a lot, I see that the protocol that always makes it fail is FRSKY X D16, exactly the model that happens. but it has failed since June 1 (6579905) in the previous ones after trying a lot it failed once in many attempts, but since the pr5023 was merged it fails every time the model with this protocol is selected.