mLRS icon indicating copy to clipboard operation
mLRS copied to clipboard

Configure wireless bridge for betafpv-micro-1w-2400

Open brad112358 opened this issue 7 months ago • 8 comments

This depends on PR #331

Untested.

brad112358 avatar May 24 '25 19:05 brad112358

Seem to be missing something:

Flash bridge with #331 branch, uncomment ESP82XX, GPIO0_IO Flash BetaFPV with with this branch

See settings but they don't apply. Tried to change the WiFi Channel to 13, the Lua reports 13 after a power cycle but Win says the AP is still on channel 6.

jlpoltrack avatar May 27 '25 21:05 jlpoltrack

@jlpoltrack Thanks for testing! The timing must still be too tight somewhere. I don't have one to test, but I'll try to simulate not having the reset and gpio0 connected with something else. Can you confirm that the BetaFPV esp32 has no direct control of the reset or gpio0 lines on the esp8266?

brad112358 avatar May 28 '25 19:05 brad112358

I said before that I had spend quite some time on getting the timing and stuff right ... you made some changes and it might be related to that ... I'll make some comments in the other PR

olliw42 avatar May 29 '25 08:05 olliw42

Can you confirm that the BetaFPV esp32 has no direct control of the reset or gpio0 lines on the esp8266?

This is correct, only Tx / Rx are hooked up to the ESP32 (there's dipswitch block for those lines).

jlpoltrack avatar May 29 '25 14:05 jlpoltrack

@jlpoltrack I was able to reproduce the problem you observed on my RM pocket by commenting out the first part of AtMode::Do() which watches for changes on GPIO0_IO. In this test, the problem was that we don't wait long enough at startup for the first AT command because the esp8266 gets going faster than the esp32 and times out. The STM in the R9M must startup a little faster than the esp32. Please try changing the initialization of startup_tmo_ms in AtMode::Init() to "startup_tmo_ms = 1750 + millis();" and let me know if that solves the problem.

Thanks!

brad112358 avatar May 29 '25 20:05 brad112358

Please try changing the initialization of startup_tmo_ms in AtMode::Init() to "startup_tmo_ms = 1750 + millis();" and let me know if that solves the problem.

Yes, that seems to have done it - now WiFi channel changes are applied.

jlpoltrack avatar May 29 '25 21:05 jlpoltrack

Yes, that seems to have done it - now WiFi channel changes are applied.

Thanks! It would be nice to have some idea where the cutoff is. In my tests, 950 worked, and 850 didn't, but I expect your case might require more time than my test since reset is not under control of the esp32. Can you try a couple more tests, perhaps 950 and 1100 or 1200 and see about where it starts working?

Thanks!

brad112358 avatar May 29 '25 21:05 brad112358

1250 worked for me - if maybe 900 is the threshold for you then I would think that is enough buffer...

jlpoltrack avatar May 31 '25 02:05 jlpoltrack