Issue with ELRS Module Display After Updating FrSky X-Lite to EdgeTx Centurion v2.10.5 #5848
Comments
edilsoncorrea
added
bug 🪲
|
Have you checked in with the ELRS guys yet? As if the module is actually
working (i.e. you said the RXs are working flawlessly) and you can use the
Lua script, this may be some weird bug in ELRS. EdgeTX doesn't control the
screen on the module, it only cares about turning the module on or off, and
sending your control inputs to the module (for the most part). If this was
happening in conjunction with changing models (while the handset is on), I
would have suggested it is a hardware compatibility issue, as it seems some
modules have long power off times, so don't properly switch off and on when
changing models, but not sure what else could be happening here since you
state it is also happening when you initially turn on the handset.
…On Tue, 28 Jan 2025, 12:17 am edilsoncorrea, ***@***.***> wrote:
Is there an existing issue for this problem?
- I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
I recently updated my FrSky X-Lite to EdgeTx Centurion v2.10.5 (release
date: 2024-10-13 09:54:55, firmware: edgetx-xlite). I am using an ELRS
2.4TX module, specifically the AION 2.4TX NANO 500mW model, which is
updated to version 3.5.3. My X-Lite is also running the latest Lua script,
elrsV3.lua.
When using OpenTx, the ELRS module’s display would power on normally
whenever CRSF was enabled on the selected model. However, after updating to
EdgeTx, while communication with receivers is working flawlessly, the
module’s display no longer powers on.
The only scenario where the display turns on is when I disable CRSF on the
model and re-enable it. If the X-Lite remains powered on, the display stays
on and correctly shows when the module is connected to the receiver.
However, if I power off the X-Lite and turn it back on, the display stops
working again.
Expected Behavior
The ELRS module’s display should power on automatically whenever CRSF is
enabled on the selected model in EdgeTx, just as it did in OpenTx. The
display should remain on and function normally, showing the connection
status with the receiver, without requiring any additional steps like
toggling CRSF on and off.
Steps To Reproduce
Update the FrSky X-Lite to EdgeTx Centurion v2.10.5 (firmware:
edgetx-xlite).
Use an ELRS 2.4TX module (e.g., AION 2.4TX NANO 500mW) updated to version
3.5.3.
Ensure the Lua script elrsV3.lua is installed and up to date on the X-Lite.
Enable CRSF on a selected model in EdgeTx.
Power on the X-Lite and check if the ELRS module’s display turns on
automatically.
If the display doesn’t turn on, toggle CRSF off and then back on.
Observe that the display works normally while the X-Lite remains powered
on.
Power off the X-Lite and turn it back on, then check if the ELRS display
powers on again.
Version
2.10.5
Transmitter
FrSky X9 Lite / Lite S
Operating System (OS)
Windows
OS Version
Windows 10
Anything else?
*No response*
—
Reply to this email directly, view it on GitHub
<#5848>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KJ5FX4OLVDEHIRBDFD2MY5V7AVCNFSM6AAAAABV6F5NIKVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAYTGMJVGA4TMOA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I still believe there might be something related to EdgeTx, mainly because the issue with the ELRS display started right after I updated to EdgeTx. The only change I made was updating to EdgeTx, as the ELRS module was already running version 3.5.3 prior to the update. |
|
There is no mechanism for EdgeTX to control module display at all, even if we wanted to |
|
I think display not turning on needs to be understood as module is not working at all = not powered. Powering the module is solely under EdgeTX control. @edilsoncorrea please try to reproduce the problem. If the module's display hasn't turned on remove the module from the radio and measure the voltage between the GND and VCC pins if you can. |
Yes, but he says: which strongly suggests module in ON |
|
True, maybe @edilsoncorrea can confirm again that the module is indeed working, ie communicating with the receiver and the lua script is loading even if the display didn't turn on. |
|
Yes, everything works normally except for the display on the module. |
|
@mha1, assuming module work, wouldn't arming toggle display on module? |
|
No, the display should be on as soon as the module is powered and stay on regardless of the arming status. I have two of the same modules and never saw anything like you describe. Have you ever messed with modifying the hardware configuration of the module (hardware.html)? |
|
I will carry out the requested tests, measuring the voltage on VCC. I should note that the module is functioning normally, with the main LED operating correctly and even changing colors. However, the display does not turn on. |
|
Then I hardly see how Etx could be the cause at this point |
|
@edilsoncorrea you don't need to do that. The module is powered if the LED works and it communicates. |
|
@3djc I agree |
|
I was wondering if the module, in addition to receiving voltage on VCC, also requires some sort of command, like an "AT Command," to turn on the display, which might not be sent by EdgeTx. |
|
No, there is nothing Etx does have access to that can control the display at all |
|
@edilsoncorrea please try to get it into the no display problem, then open the ELRS LUA script on the radio. Does it open? Does the display on the module turn on? |
|
No, the display does not turn on when I open the LUA script. The only thing that makes the module's display turn on is when I go into the model configuration, turn off the external "CRSF" module by setting it to OFF, and then turn it back on. |
|
@3djc do you by any chance know what the FrSky X-Lite outputs on the module connector VCC? 5V? |
|
What FrSky calls VMAIN, with is VBAT. As X-Lite are 2S Lion, anywhere between say 6.6 and 8.4. |
|
I can reproduce the problem by just powering the stand alone module via the USB-C connector. No display but after 1min the green LED turns on indicating it wants to go to WiFi mode, ie the module is alive. The label on the module states "Voltage 6-8.4V". I believe 5V is not enough. And I remembered the NV14 outputs 5V. Same behavior as @edilsoncorrea describes with the NV14. I'm sure this is a module specific behavior in conjunction with a low or weak power supply. Specification: Product: 2.4G ELRS TX module jumper |
|
Let me remind you that the module was working normally when Opentx was installed. This bug started happening when I updated to Etx. |
|
And I think we are trying to tell you that we (Etx and ELRS devs) think it is not possible, and are looking for something else that could explain that coincidence. What is current voltage reading on main screen? |
|
And I think I'm trying to explain to you that if it worked with OpenTx and stopped working with Etx, it's not a coincidence. Etx changed the behavior of the power pin, which, if similar to the Taranis X9D+, is controlled by a FET. |
@edilsoncorrea Change in plan, I'd be interested in a voltage measurement directly at the module connector |
|
7.6v |
|
sounds good |
|
As @mha1 requested, I measured the GND and VMain pins. The voltage at this moment is 7.616V. What I believe has changed in Etx compared to OpenTx is that the "Heart Beat" data pin might have changed its initial value when the X-Lite powers on. For example: In OpenTx, it was high, and now in Etx, it’s low, or vice versa. |
|
I'll make a cable with just VCC and GND and connect the module to the X-Lite with only that, isolating the Heart Beat pin, to see if the module powers on in this scenario. |
|
Trying to understand the root cause. Look at my zoomed in screenshot and you'll see SPort is 100us prior to power on of the module low. I can't resolve this in your first picture. Anyhow, I'm trying to get to the root cause. I'm sure the case is clear for you but it really isn't. And for that reason, I'm out. |
|
I redid the test with a Taranis X9D+, and the module powers on normally. I connected both oscilloscope channels to the extension pins and verified that the S. Port pin stays low when the Taranis X9D+ is powered on and remains low until communication starts, right after the boot is completed. I tried capturing with the oscilloscope on the modified X-Lite, adjusting the time for a better "zoom," but it wasn’t enough to determine if the S. Port pin goes back to a low state moments before VCC is powered on. |
|
I was able to capture the states of the VCC and S.Port pins during the boot process of the FrSky X-Lite using a Logic Analyzer. I recorded the data similarly to what @mha1 did. I believe this data might help in understanding what may have changed in EdgeTx compared to the previous behavior in OpenTx.
|
|
Picture 3 shows an idle high data stream which is different to your scope video https://www.youtube.com/watch?v=N1OrlgIignA. Does polarity change after doing the CRSF OFF and ON again? Anyhow. if this is CRSF the module auto detects polarity. |
|
This happens when CRSF is turned off and back on in the module. I noticed that the time until data starts being transmitted is much longer.
|
|
This image is from the boot process of the Taranis X9D+. The time it takes to start transmitting data after the module is powered on is much longer. |
The dT between power on and data stream starting is 4ms (your measurement). The module itself is busy booting for at least 1/2s before it even starts looking at incoming CRSF data packets. Immediately after power power on of the module or 4ms after power on of the module doesn't make doesn't make any difference to the modules ability to auto-detect polarity and baud rate before actually starting to work with the incoming data- |
|
It really doesn’t make a difference in the module’s ability to start processing data. I mentioned in one of my comments above that the module works normally. The problem is not that the module doesn’t work. The issue is that with the changes made in EdgeTx regarding these timings, the DISPLAY no longer turns on during the boot of the X-Lite. And this used to work fine with OpenTx. |
I understand that it's a display only issue and also discussed your issue with the team. Turning on the display is done independent of the incoming serial data. It's turned on regardless of serial data being present or not which by the observed by the "no handset" displayed if the module is just connected to GND and VCC. Do you have other modules, preferably of the same type to try? Please enter WiFi mode of the module and enter 10.0.0.1/hardware.json, click save and attach the file. |
|
I only have this module with a display, but I tested it on the Taranis X9D+, and it works. The high value on the S. Port at the moment the module is powered on is what is preventing the display from turning on. This is easy to test even outside of the X-Lite. I powered it with 8V and used a voltage divider with two 10k resistors to drop 4V on the S. Port pin, and the display didn’t turn on. I’ll save the file later today and attach it here. |
|
Here is the Hardware.json file: |
|
Your hardware.json looks ok. I tried to reproduce the issue using your S.Port high theory on both of my Jumper AION nano TX modules (one on 3.5.2, the other on 3.5.3). A 2s LiFe (6.6V) for VCC and a two 10k resistor voltage divider to provide 3.3V at the S.Port pin. Both modules boot just fine and turn on the OLED display as they should. So far I can only conclude you might have module hw issue and recommend trying another module of the same type. Don't scratch your head about the outgoing colors. Red and GND are swapped to provide SPort, GND, VCC in the right order for the module. Outgoing red = GND, black = VCC (6.6V), yellow = S.Port (3.3V)
|
|
If there is something wrong with my AION, then why did it work fine on OpenTx, and why does it work normally on the Taranis X9D+? I showed the timings on both the X-Lite and the Taranis X9D+. Clearly, they exhibit different behaviors. |
|
I believe it is now clear that the development team will not analyze what has changed in the behavior of the S.Port value for the X-Lite on EdgeTx compared to its behavior on OpenTx. I appreciate the help. In my measurements using a Logic Analyzer, there is clearly not the same interval presented by @mah1 in his measurements. Thank you for all your help, @mah1. I will give up trying to get my module's display to work. I still hope that in future updates, this bug will be fixed and it will work again AS IT DID ON OPENTX. |
|
You presented a scenario to fail your module without any connection to a radio. I spent time and effort to setup the exact scenario and tested two modules identical to yours with no issues. So what do you expect? The test results - two of my modules working, your module not working - hint at a problem with your module. Besides that no one ever reported any similar issues. Get yourself another one of those module, they are cheap. If you can provide a better test scenario to reproduce the problem I'd be happy to try it. Until there is a way to reproduce this issue there can't be a fix. |
|
I forgot to mention a detail in the test with the resistors forming a divider. The goal is to simulate what the X-Lite does: it pulls the S.Port pin high before powering up. If you connect everything at the same time, as in your test, the module powers on. I redid the test here, simulating exactly your scenario with a bench power supply at 6.6V. When I turned on the power supply with all three terminals already connected, the display worked. However, when I connected GND and S.Port with the divider, then powered on the supply, and only afterward connected VCC, the display did not turn on. |
I tried this. Both of my modules still boot and turn on the the display, |
|
This video clearly demonstrates the situation. I included two switches in the circuit. The left switch cuts off the VCC going to the module. The right switch cuts off the voltage (divided by the resistors) going to the S. Port. When I turn on the left switch with the right switch off, the display powers on normally. When I turn on the right switch first and then turn on the left switch, the display does not turn on because the S. Port pin is already in a high state before the module is powered. |
|
If I am understanding the test setup correctly, you are saying when SPort is high at time of power on for the module, the display doesn't work? I can't reproduce that with my module either (running3.5.1) whether at or before power on. I tried both high and low at power on, high before power on (and also low, but not on video) - module and display started up fine each time. |
|
Anyhow, if anything, it would not be an EdgeTX fault, a change yes maybe, a fault no. We are entitled to power the way we want as long as we are within the required spec, and we are since the module is working perfectly control and telemetry wise. The issue is either hardware with this module, or within ELRS. |
|
After a few more repeats, I got another fault scenario, which suggests it is indeed a design fault in the AION... it looks like something is backfeeding via the SPort pin, hence the OLED is not initialising/reset properly (you can see the last frame is displayed instantly if not enough power off time)... and the startup timing is pretty important... if you leave SPort high long enough, it will startup fine. |
Thanks for trying this too. It really looks like there's some backfeeding through the SPort pin keeping some parts zombie alive. This should never happen. Unfortunately I don't have schematics of this rather old module to verify. I also tried with various timings but couldn't reproduce any of this on my two modules so I think there even might even be different revisions. Best advice is probably to scrap the module and get a decent one. |
Quite possible... I'm pretty sure I got this as soon as it was available locally. |
|
There are 2 revisions of this module in the mix as well. The original one, which powers on from USB and the second which does not. |
|
@pfeerick, I'm not sure if you have exactly reproduced one of the tests I did that precisely simulates the behavior of EdgeTx on the X-Lite during boot. When I watched your video, I noticed that. When I set up the scenario, I failed to prepare the circuit to exactly reproduce the X-Lite's behavior. I'll try to describe the sequence as accurately as possible: Could you confirm if you reproduced this scenario? Thank you very much for your willingness to help identify what is happening. |
|
I did exactly this as the last test - sport high via divider, and then VCC
to module. Initially it had no effect, and then after several repeats, with
a short enough high on the SPort pin I was able to get the OLED display to
incorrectly initialise (as shown in the second video), which is another
sign of the module incorrectly allowing for power to backfeed through the
SPort pin. My module is one of the ones that powers the display via USB,
which was changed in a later revision, probably to fix exactly this design
flaw. Basically the OLED will be getting just enough power via the SPort
pin that it does not inatalise properly - a bit longer, it is fine, and
less time it is fine. This is something that *might* be possible to on the
ELRS side, by kicking the display to reset (again?) if it did not properly
respond to init. But to be clear, this is a design flaw of the module,
exposed by a minor timing change that should have no effect as it is still
being controlled well within spec on the EdgeTX side.
…On Mon, 10 Feb 2025, 9:36 am edilsoncorrea, ***@***.***> wrote:
@pfeerick <https://github.com/pfeerick>, I'm not sure if you have exactly
reproduced one of the tests I did that precisely simulates the behavior of
EdgeTx on the X-Lite during boot. When I watched your video, I noticed
that. When I set up the scenario, I failed to prepare the circuit to
exactly reproduce the X-Lite's behavior.
I'll try to describe the sequence as accurately as possible:
The bench power supply needs to be turned on, and the S. Port and GND pins
must be connected. The S. Port pin will receive the voltage reduced by the
voltage divider (resistors). Only after the S. Port pin is at a high level
should the VCC pin receive power from the supply.
Could you confirm if you reproduced this scenario? Thank you very much for
your willingness to help identify what is happening.
—
Reply to this email directly, view it on GitHub
<#5848 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KM3VOUWG76AQ6JUHND2O7Q65AVCNFSM6AAAAABV6F5NIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWGY2TKNBUGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The behavior of your module is different from mine in this aspect. My module always keeps the display off if the S. Port pin is high when the module is powered on. My module is running version 3.5.3, but I have already reverted to version 3.5.1, and the behavior was the same. |
|
That is simply a timing issue / specific to the OLED IC itself... if it inits improperly it will simply show what is still in it's buffer... which could be nothing, random noise, or a full frame. This is why a disconnecting the VCC and then reconnecting while maintaining the parasitic power up via SPort will immediately show "NO HANDSET" on power up, even though the display doesn't actually get set to that until the module has been powered up for several seconds (i.e. it should be showing the ELRS logo and version first, and then after it doesn't see a signal on the SPort for for a couple of seconds it gets set to that - but instead you get "No Handset", ELRS logo, and then "No Handset").
This doesn't change the fact this is a design flaw of the module, exposed by a minor timing change that should have no effect as it is still being controlled well within spec on the EdgeTX side. |
|
Do you think it would be possible to modify EdgeTX to replicate this small timing adjustment that OpenTX applied? If you don't find it convenient to include it in the official version, could you inform me where I can apply it? I can compile a version of EdgeTX with this modification. |
Is there an existing issue for this problem?
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
I recently updated my FrSky X-Lite to EdgeTx Centurion v2.10.5 (release date: 2024-10-13 09:54:55, firmware: edgetx-xlite). I am using an ELRS 2.4TX module, specifically the AION 2.4TX NANO 500mW model, which is updated to version 3.5.3. My X-Lite is also running the latest Lua script, elrsV3.lua.
When using OpenTx, the ELRS module’s display would power on normally whenever CRSF was enabled on the selected model. However, after updating to EdgeTx, while communication with receivers is working flawlessly, the module’s display no longer powers on.
The only scenario where the display turns on is when I disable CRSF on the model and re-enable it. If the X-Lite remains powered on, the display stays on and correctly shows when the module is connected to the receiver. However, if I power off the X-Lite and turn it back on, the display stops working again.
Expected Behavior
The ELRS module’s display should power on automatically whenever CRSF is enabled on the selected model in EdgeTx, just as it did in OpenTx. The display should remain on and function normally, showing the connection status with the receiver, without requiring any additional steps like toggling CRSF on and off.
Steps To Reproduce
Update the FrSky X-Lite to EdgeTx Centurion v2.10.5 (firmware: edgetx-xlite).
Use an ELRS 2.4TX module (e.g., AION 2.4TX NANO 500mW) updated to version 3.5.3.
Ensure the Lua script elrsV3.lua is installed and up to date on the X-Lite.
Enable CRSF on a selected model in EdgeTx.
Power on the X-Lite and check if the ELRS module’s display turns on automatically.
If the display doesn’t turn on, toggle CRSF off and then back on.
Observe that the display works normally while the X-Lite remains powered on.
Power off the X-Lite and turn it back on, then check if the ELRS display powers on again.
Version
2.10.5
Transmitter
FrSky X9 Lite / Lite S
Operating System (OS)
Windows
OS Version
Windows 10
Anything else?
No response
The text was updated successfully, but these errors were encountered: