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

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

Closed
chofchop opened this issue May 2, 2024 · 11 comments · Fixed by #2728
Closed

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

chofchop opened this issue May 2, 2024 · 11 comments · Fixed by #2728

Comments

@chofchop
Copy link

chofchop commented May 2, 2024

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

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

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

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

@CapnBry
Copy link
Member

CapnBry commented May 22, 2024

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 CapnBry changed the title [v3.4.0] The first connection takes too long. [v3.4.0] The first connection takes too long DupleTX ESP May 22, 2024
@CapnBry
Copy link
Member

CapnBry commented May 22, 2024

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

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

@pkendall64
Copy link
Collaborator

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

@pkendall64 pkendall64 linked a pull request May 23, 2024 that will close this issue
@chofchop
Copy link
Author

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

schugabe commented May 23, 2024

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

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants