Namimno OLED TX module inconsistent binding #1260
Comments
|
Check out my thread, to me it sounds like the same issue: |
|
@Xedos9er I've been watching your issue with great interest. I hope this is something that can be resolved with software because, at least in my case, there's clearly a way to establish a bind. I have a hot air station and I can remove caps to test, but I think even that's a bit much to ask with these component sizes. |
|
Maybe related to #1229? |
|
JHEMCU EP24S and Flywoo EL24P behave the same. I don't have anything else besides a Happy Model 2G4 AIO and that's working fine. I have a Happy Model EP1 on the way and will update if that's any better. |
|
From the image searched from internet, JHEMCU EP24S and Flywoo EL24P have just rebranded the same board apparently. |
|
Well, as a follow up to this. I installed the Happy Model EP1 and I was able to upgrade it via WIFI flash from v1 to v2.01 without issue. I can also bind instantly every time the quad or TX is power cycled. If there is no planned or possible fix for the JHEMCU or Flywoo RX issues, I would suggest putting up an advisory of some sort to let people know not to waste their money. Especially since the Flywoo and JHEMCU variants seem to be more readily available at the moment. I have never had a problem with any other Flywoo or JHEMCU product, but I would've gladly steered away if there was an official statement about their potential problems. |
|
We are working on a ExpressLRS Configurator & HW Errata List |
|
Can we close this as this is not a Namimno issue and there is an issue for JHEMCU RX. |
|
Agreed |
Current Behavior
Namimno OLED TX module does not bind consistently with JHEMCU EP24S or Flywoo EL24P. I am able to get it to bind by messing with the LUA script but I don't feel that's intended behavior. TX module seems to work fine with HM 2G4 AIO.
Steps to Reproduce
I made a video showing the issue. See timestamps for context.
https://youtu.be/sxolYfHlH8M
:12 - Model was previously bound at 500 hz 1:8. Turning on TX shows module in 500 hz 1:8 25mw.
:20 - Plug in quad. Immediate "telemetry lost". Module goes into full power 500 hz 1:2 1000mw. RX light blinking (it will not bind if left in this state)
:27 - Bumped arm switch (yikes), curiously the quad beeps here despite appearing to have no bind and no telemetry. (Rxbt is 0.
RX still flashing.)
1:05 - Enter LUA script. LUA displaying 500 hz 1:8 but the module says 500 hz 1:2 1000mw. Change telemetry ratio to 1:2 via LUA script and exit.
1:32 - "Telemetry lost. Telemetry recovered." repeatedly. Rxbt is being returned. Module screen displaying 500 hz 1:2 25 mw.
1:44 - Re-enter LUA script. Change back to 1:8 telemetry ratio.
1:59 - TX module now says 500 hz 1:8 25 mw. No more telemetry lost messages. Solid blue light on RX.
Possible Solution (Not obligatory)
I don't know why this is happening but there seems to be a janky workaround as seen above. I have to do this process every time the transmitter is turned off and on again. Sometimes if the TX is left on and only the quad is power cycled, the bind will happen automatically.
Details
The behavior is nearly the same for both JHEMCU and Flywoo receivers. I detailed my experience with the JHEMCU in #1229. I tried both the DIY target and JHEMCU EP24S target with the same symptoms. For the Flywoo, I bricked it via WIFI flash using the EL24P target and had to revive it with bootloader + passthrough using the DIY 2400 RX ESP8285 SX1280 target. You are seeing the Flywoo with DIY target in the video.
Flywoo RX flash output. There is a warning about the crystal in there. Not sure if relevant. I also saw "Cannot detect RX target, blindly flashing!" on the initial WIFI flash and the subsequent passthrough flashes.
Your Environment
The text was updated successfully, but these errors were encountered: