ELRS Model switching no connection to module

[nmare99]

Describe the bug

After switching model in EdgeTX, lua script connection fails to TX module. It's necessary to turn off and turn on the radio to make the module work again
TX hardware: Happymodel ES24 TX 2.4g
Handset model: Taranis QX7 (with cross mod)
Edge TX 2.6.0
TX ExpressLRS version: 2.0.1

Steps to Reproduce

1. Turn radio on .
2. Radio connects to module
3. Change to another model with ELRS Rx and no connection to module
4. Power radio off and on and it connects to module

Model match in settings is turned off.

The same problem with Radiomaster TX16S (Edge TX 2.5.0)

pkendall64 wrote here https://github.com/ExpressLRS/ExpressLRS/issues/1259#issuecomment-1017846503 that "It is expected that EdgeTX/OpenTX reboots the module when switching models.
If the module is not restarting properly when doing that then I'd say that EdgeTX/OpenTX may need a longer off time for the module when switching." And "... when you switch models in OpenTX/EdgeTX the handset power cycles the module. If the power off is not long enough it looks like it's causing the module to crash which is why the LUA is failing and you have to power cycle the radio. I have an ES24TX Pro Series and this problem does not happen on that module."

[raphaelcoeffic]

Yeah, we do reset the module, indeed. The question would be: how long should the reset be? And, is that dependent on the module itself?

[pfeerick]

I seem to have been suffering from this also, as I noticed my HM ES24TX was playing up when switching between models when testing the MPM wireless trainer PR... and it seemed like a manual on and off of the module setting cleared it. So some sort of increased delay looks to be needed, as the module is probably not cleanly restarting.

[raphaelcoeffic]

At the moment, the delay should be 200ms minimum on external modules:

edgetx/radio/src/storage/storage_common.cpp

Lines 63 to 69 in 50aeb50

	#if defined(HARDWARE_INTERNAL_MODULE)
	stopPulsesInternalModule();
	#endif
	#if defined(HARDWARE_EXTERNAL_MODULE)
	stopPulsesExternalModule();
	RTOS_WAIT_MS(200);
	#endif

If the module is not really power-reset within 200ms, then frankly, there is an issue with the module... 200ms is a looonnng time!

[nmare99]

Now I have tried such an operation:
When I switch models and one of the switches is in the wrong position, a warning is displayed on the handset screen.

At this point, the TX module remains powered off. Moving indicated switch(es) to correct position will remove the warning and power on TX module.
Connection with the module works fine.
So increasing the module shutdown delay fixes this problem.

[raphaelcoeffic]

Ok, but how long? As I said, 200ms should be pref toy sufficient to drain power out of the module.

[pfeerick]

Ideally, yes, 200ms should be enough, but perhaps there is enough capacitance to keep the MCUs partially so they don't fully shut down. That would still imply something would need to be done on the ELRS side... i.e. why isn't brownout detection kicking in? Maybe some mechanism to tell it it must reset? Otherwise it is going to be a game of wackamole...

[raphaelcoeffic]

why isn't brownout detection kicking in?

Indeed! @pkendall64 Any comments on this?

[pkendall64]

why isn't brownout detection kicking in?

Indeed! @pkendall64 Any comments on this?

That I do not know? The brownout detection is put in place by the underlying arduino framework code. I too think it must be some large capacitor holding power., and playing wackamole is no fun (especially for the mole 😄 )!

As an aside, is there a reason that EdgeTX power cycles the module when switching models and both models use the external module bay?

[pfeerick]

Probably because it is dumb, and doesn't look at what module type the next model uses? 😁 In doing so, it's a clean slate each time.

Yeah, I would have though the espressif brownout detector code was active... but this could be skating right on the edge... mole and thwacker will be needed. 😆

[raphaelcoeffic]

As an aside, is there a reason that EdgeTX power cycles the module when switching models and both models use the external module bay?

Apart from "it's always been this way?" you mean? 😅

[nmare99]

I tried to increase the delay time from 200 ms. 250 ms, 300 ms, 400 ms, 500 ms did not bring a positive result. Only at 1000 ms switching from model to model worked fine.

[raphaelcoeffic]

I tried to increase the delay time from 200 ms. 250 ms, 300 ms, 400 ms, 500 ms did not bring a positive result. Only at 1000 ms switching from model to model worked fine.

This is crazy!!! One complete second! 😳

[nmare99]

I tried to increase the delay time from 200 ms. 250 ms, 300 ms, 400 ms, 500 ms did not bring a positive result. Only at 1000 ms switching from model to model worked fine.

This is crazy!!! One complete second! 😳

That's right :) But I have nowhere to hurry :))

[pkendall64]

I tried to increase the delay time from 200 ms. 250 ms, 300 ms, 400 ms, 500 ms did not bring a positive result. Only at 1000 ms switching from model to model worked fine.

There must one ginormous capacitor in that module! 1s is an eternity without power!

[pkendall64]

So maybe the best "solution" would be not to power cycle the module if it's the same bay and the same configuration for the case of the multi-protocol module.
I think CRSF should be fine not to power-cycle because when you switch model you'll send the MSP command to set the modelId and it should be good with that.