[v3.4.0] The first connection takes too long DupleTX ESP

[chofchop]

Current Behavior

When using Generic ESP8285 Full-duplex 2.4GHz RX as TX as the transmitter module, It takes about 1 minute to connect to the receiver for the first time after turning on the transmitter.

Steps to Reproduce

Please refer to the video.

1.Turn on the transmitter

2.Turn on the receiver at any time (even before the transmitter)

3.Connection will be established after about 1 minute

Possible Solution (Not obligatory)

This phenomenon does not occur with the external module (BetaFPV NanoTX), so it seems to only occur with the internal module or DupleTX esp.

Details

The same symptoms occur with v3.4.0-RC1 and v3.4.0-RC2.
Furthermore, in v3.4.0-RC2, connection lost and connection recovery are repeated.

Your Environment

• TX hardware: EP1tcxo(Generic ESP8285 Full-duplex 2.4GHz RX as TX)
• RX hardware: EPW6
• Handset model: MT12
• OpenTX version (including nightly number) : EdgeTX 2.10.0-RC1
• ExpressLRS version (TX & RX MUST MATCH): v3.4.0-RC3
• Packet Rate: F1000
• Telemetry Ratio: 1/32
• user_defines: PWM Freq. : ch1-333Hz, ch2-333Hz, ch3-160Hz, other-50Hz

[chofchop]

I tested it using another device (such as EP2tcxo), but it still takes about 1 minute to connect for the first time.
A newly discovered fact is that ExpressLRS lua often does not recognize devices.
Additionally, the device will become much hotter than normal.

[CepinCepin]

Yesterday I flashed 3.4.0 to Frsky R9 (2019) TX - 868MHz in RM TX16s and 2 R9MX receivers.
The reconnect (turn off either Tx or Rx) time raised from ~1-2sec (few months old elrs version) to ~10secs (using 3.4.0).

[chofchop]

This is probably a problem with DupleTX ESP.
CapnBry, could you please check this issue?

[CapnBry]

EDIT: I just watched the video and I'll have to look into that. I do not have the same behavior on any of my devices. They all connect incredibly fast.

I don't really want to pull out a DupleTX to test with, but it could be that your initial rate on the RX is wrong? That would only make it take 20 seconds to connect though. Also make sure to verify your TX up and running before starting the RX, because cycling around takes forever if the RX missed the initial connect.

The initial rate can be set by one of two methods (both set the same thing):
1 - Use the ExpressLRS Lua to change the packet rate away from what you're using, and then switch it back. This stores the new rate on the receiver for faster starting.
2 - Connect to the RX (normal operation) and the turn off the TX, so the receiver disconnects. This stores the last used rate on the receiver

[CapnBry]

It definitely does seem to take a long time for the ESP8285 DupleTX to start actually transmitting. I have no clue why and this is something that's insanely difficult to debug because there's no other wires to get debug information out. I can tell that it takes like 50 seconds to start transmitting based on the power draw of the TX though. The time is also isn't "from boot", it has some other timeout, because if I stop sending channels, then start again, it takes the 20-30 seconds again to start (shorter but still very long).

I'm not sure when I'll have time to look deeper, there's been a lot of bugs to look into since 3.4 release, but I can at least confirm on superficial inspection that DupleTX ESP targets may have something weird happening.

EDIT again! I know what is happening, will be fixed in an future release (not 3.4.1 which is already out)

@CepinCepin your issue is not related to this Issue. Maybe check my suggestions in the the comment above, but beyond that I have nothing for you and it is off topic for this thread.

[chofchop]

Thank you for investigating.
I look forward to future releases. I will use v3.3 until then.

[pkendall64]

@chofchop could you check this PR#2728, and let us know if it fixes it for you, thanks.

[chofchop]

@chofchop could you check this PR#2728, and let us know if it fixes it for you, thanks.

Sorry, I don't know how to build and flash PR#2728.
I usually build and update using VS Code's PlatformIO.

[schugabe]

@chofchop could you check this PR#2728, and let us know if it fixes it for you, thanks.

Sorry, I don't know how to build and flash PR#2728. I usually build and update using VS Code's PlatformIO.

https://github.com/pkendall64/ExpressLRS/tree/fix-8285-as-TX you can clone that repo/branch and use vs code to build+flash it

or download the patch https://patch-diff.githubusercontent.com/raw/ExpressLRS/ExpressLRS/pull/2728.patch and apply it to your local repository

[chofchop]

Thank you, I was able to build and flash PR#2728(34203ad).
As a result, RX is now instantly connected to TX.

It seems like the device is generating more heat than before, but maybe I'm wrong.

[pkendall64]

Thanks for confirming that the PR fixes the issue.

As a TX it will always generate more heat, but it should not be generating more heat with 3.4 vs 3.3 as it is using the same radio parameters and power output.