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

[X12s] MPM module connectivity issue #4357

Open
1 task done
Unb0rn opened this issue Nov 23, 2023 · 9 comments
Open
1 task done

[X12s] MPM module connectivity issue #4357

Unb0rn opened this issue Nov 23, 2023 · 9 comments
Labels
bug 🪲 Something isn't working triage Bug report awaiting review / sorting

Comments

@Unb0rn
Copy link

Unb0rn commented Nov 23, 2023

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

I have a modded X12s device (ISRM, externalaccessmod and so on), I've had some problems with my multiprotocol module where I got only NO_TELEMETRY message. (Described it here)
After upgrading to 2.9.2 the issue has been kinda resolved - I can now make MPM work but it involves some strange actions. By default I still get this no telemetry message but then if I change external module in model settings to something else and back, the module gets detected, I can run spectrum scan on external module without any stutters and even flash it successfully. The module's fw version is displayed correctly in system info. This workaround works until reboot.

One more thing - this switching back and forth works with some options and doesn't work with others - like selecting Flysky and then back Multi module works fine, but selecting R9M and back Multi still produces no telemetry.
I have no idea how to debug it further...

Expected Behavior

MPM module gets discovered every time when it's selected in model settings.

Steps To Reproduce

  1. Select MULTI in external RF
  2. Reboot
  3. Get No telemetry
  4. Select Flysky
  5. Select MULTI back
  6. IT WORKS! (Not anymore, 2.10 broke it completely, read the last comment)

Version

2.10.3

Transmitter

FrSky X12

Operating System (OS)

No response

OS Version

No response

Anything else?

No response

@Unb0rn Unb0rn added bug 🪲 Something isn't working triage Bug report awaiting review / sorting labels Nov 23, 2023
@pfeerick
Copy link
Member

Can you backup your RADIO and MODEL folders, and try with a nightly build? There were some changes around use of the SPort lines which could be relevant to you.

@Unb0rn
Copy link
Author

Unb0rn commented Nov 24, 2023

Can you backup your RADIO and MODEL folders, and try with a nightly build? There were some changes around use of the SPort lines which could be relevant to you.

Actually it got worse!) Looks like it's somehow tied to this FLYSKY external module mode. This newer nightly build - cdfe7b5 has no FLYSKY option.
By default MULTI has this "NO TELEMETRY" message and then selecting any other option first and then back to MULTI results in "no serial data" message.

Flashing back 2.9.2 and running through the steps I described previously returns MPM back to normal.

One more thing - in m X12s unit I have inverter replaced with the faster one (CRSF/ELRS work fine and R9M/ACCESS too), maybe it has something to do with it?

@ParkerEde
Copy link
Contributor

Today I have ETX2.9.2 and my Horus X10S Express with an IRange IRX+ (MPM) connected to a Blade130S and suddenly lost all control. This has happened twice in a short space of time. Luckily nothing happened to the Blade 130S, it happily fell out of the air. The red control LED then flashed on the Irange IRX+ module. Normally it lights up permanently. I then flashed back to ETX 2.9.1 and the problem did not occur again. What happened with 2.9.2 that the serial connection to the MPM can no longer be kept stable?

@pfeerick
Copy link
Member

pfeerick commented Dec 3, 2023

Actually it got worse!) Looks like it's somehow tied to this FLYSKY external module mode. This newer nightly build - cdfe7b5 has no FLYSKY option.

Try AFHDS3 - that is its proper name.

I guess for your external access mod you have AUX1 set to "External module" in the hardware settings?

@ParkerEde
Copy link
Contributor

today I got the same problem again. There is definitely still a problem in the serial control of the MPM.

@Unb0rn
Copy link
Author

Unb0rn commented Dec 15, 2023

@pfeerick Regarding the config - exactly, aux1 is dedicated to ACCESS (External module in settings), Sample mode is set to "Normal" (as I said, the inverter is replaced and I have no problems with any ELRS modules on any rate, just for example)

I tried again on the latest nightly (42e245b) - the result is the same. Setting the module to AFHDS3 and back to MULTI still proucest the old "no serial input", rolling back to 2.9.2 and doing the same thing - setting external module to FLYSKY and back to MULTI results in the correct version detected, external spectrum scan working without any hiccups and so on.
And of course, Multi module still doesn't work for me without these manipulations mentioned above - neither for 2.9.2, nor for nightly.

Feels like we need to add some reset or something.

@richardclli
Copy link
Collaborator

richardclli commented Dec 18, 2023

Flysky external module is FRM303, and it works only with AUX1 and radio settings set AUX1 to external modules in X10 based radios, so it may related to "ACCESS MOD".

I am not sure what you have modded in your X12S, if you can give me more details, I will see if I can help.

Can you backup your RADIO and MODEL folders, and try with a nightly build? There were some changes around use of the SPort lines which could be relevant to you.

Actually it got worse!) Looks like it's somehow tied to this FLYSKY external module mode. This newer nightly build - cdfe7b5 has no FLYSKY option. By default MULTI has this "NO TELEMETRY" message and then selecting any other option first and then back to MULTI results in "no serial data" message.

Flashing back 2.9.2 and running through the steps I described previously returns MPM back to normal.

One more thing - in m X12s unit I have inverter replaced with the faster one (CRSF/ELRS work fine and R9M/ACCESS too), maybe it has something to do with it?

@Unb0rn
Copy link
Author

Unb0rn commented Dec 18, 2023

@richardclli Thanks! I'm ready to answer any questions.
Regarding the radio itself - it is an ordinary X12s(not the factory ISRM version), everything I replaced/modded myself.
List of X12s mods I use:

  1. XJT radio module replaced with ISRM (the same upgrade FrSky sells for X10s)
  2. Bluetooth module replaced to a new version from the same upgrade bundle (the new PARA thing - I think this is the only mod I don't actually use.
  3. Stock "slow" inverter has been replaced to a faster one like described here
  4. External ACCESS mod applied to handle my R9M 2019
  5. Replaced the stock screen with an I2C touchscreen

The MPM (IRX4+) I use has been modded too as the author suggests here

Everything (except for MPM) seems to work fine - I train from time to time using XSR-SIM, so ISRM works fine, never had any problems with it. I've also tried flying with ELRS (but for now it's only my DIY 433 version, waiting for hi-speed 2.4 receivers to arrive, so actually not a good test for inverter; however ELRS app works fine with any baudrate, it doesn't hang and doesn't show signs of high communications error rate), even the MPM seems to work fine (tried indoors with a whoop, not for long obviously, as well as Lua Spectrum Scan EXT) but it still requires this switching to FLYSKY back and forth on every reboot on 2.9.2 and doesn't work at all in nightlies.

I haven't tried long-range with R9M in ACCESS for a long time, almost lost my interest in it, but I can say the module is identified and reports the correct version info.

@Unb0rn
Copy link
Author

Unb0rn commented Aug 4, 2024

After updating to the latest 2.10.3 I can confirm that the problem still exists.
The behavior now is:

  1. Internal ISRM + External CRSF - Doesn't work at all
  2. External CRSF Only - Works!
    Switching between port speeds has issues:
  • Setting baud rate to 400k results in Status: 1000 Hz and nothing works, even elrsv3 lua script is unable to communicate with the module, but this problem can be "fixed" by switching the internal ISRM on and back off (it really feels like this action resets the bus or something). After that 400k produces the correct Status: 500 Hz and elrsv3 lua is back to normal
  • Setting baud rate to 115k produces Status: 150 Hz and everything is alright
  • Setting baud rate to 921k is exactly the same as 400k, but it cannot be "fixed" the same way as 400k - flicking ISRM on and off still results in Status 1000 Hz
  • Setting baud rate to 1.87M resolves all the issues - Axis Thor 2400 runs at full 1000Hz, no errors in elrsv3 lua
  1. R9M ACCESS - seems to work fine with both ISRM on and off (probably due to using a separate aux1 UART)
  2. Internal ISRM + MSM - Doesn't work at all (No MULTI_TELEMETRY no matter what I switch)
  3. MPM Only - Doesn't work
    After reboot it produces No MULTI_TELEMETRY, but switching ISRM on and off OR switching to some other mode - AFHDS3, for example turns the status to "No serial input" and cycling the protocols inside MPM (for example Flysky -> FrSky D) occasionally shows the correct MPM version and then back to "No serial input"

Additional note: this internal ISRM flicking seems to be more "powerful" than reboot - if the system boots with CRSF 400k it still produces this incorrect status and module connectivity loss, but flicking ISRM on and off "resolves" the problem
Maybe the system selects incorrect communication speed? Like 400kbaud port is unable to communicate full 1000Hz, but it still tries for some reason.

It feels like either something is being incorrectly reset or wrong port speed is chosen.
Can we try to limit the port speed? Is there any way to do it for MPM, maybe through the console?

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