-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Add TX module debug capability to hardware screen #5648
Comments
Just a little history for you... Until I proposed that the ELRS Lua
actually told you to enable the ELRS module in model setup, the Lua would
do what I think you described as "locking up the whole radio" - when in
point of fact it simply sat there saying loading, and could be exited with
a long press of the RTN key, like any other standalone Lua script.
Does the debug screen not correctly state that the int/ext modules are OFF,
when they are off? Thus correctly giving you the current status of the
module? And then when you go and turn it on, report the status?
I have no problem with making the debug screen more "useful", but this
sounds like exactly the _wrong_ way to go about it, and is actually more
dangerous, as it *could* interrupt transmission (which is currently
doesn't) and could mislead as to status of internal and external RF modules
(which it currently doesn't).
A better solution would be to become more familiar with the methoduly of
making and configuring model settings in EdgeTX, and perhaps options in the
wizard to enable the internal/external RF. However, for the latter,
consider this now. For internal ELRS, it could be as simple as on/off...
There can be more to that, but I'll leave that for ELRS getting started
guide to explain things like bind options, model match and model profiles.
But for internal MPM, you then need to configure protocol and sub protocol,
potentially tweak protocol specific settings and then sometimes bind. And
then there are all the external RF module types (and options).
So is perhaps a realistic/achievable solution there to prompt/remind the
user to go configure the RF setup for their model (at the end of the
wizard)? As to me this entire problem stems from "I didn't know I needed to
turn on/configure the RF".
…On Tue, 5 Nov 2024, 6:22 am jmole, ***@***.***> wrote:
Is there an existing issue for this feature request?
- I have searched the existing issues
Is your feature request related to a problem?
I recently got a Radiomaster TX16S II, and started playing around with it
by first going through the model wizard. I made a new quadcopter model, and
then moved on to explore other parts of the touchscreen GUI.
When I later tried to launch the ELRS lua script, the radio stopped
responding. So, I upgraded the radio firmware, and then ELRS firmware via
serial passthrough. After this, the ELRS lua script said there was no
module connected, but I was able to escape from it and try other things.
I later discovered that the new model that the wizard had created had no
modules enabled, but it took a lot of fooling around (including me
disassembling the radio) to discover this.
So it was surprising to me that I was able to flash the module with a new
ELRS version, but I was not able to query basic parameters about the
module, either on the Hardware page, or the Version page, simply because
the model I was using didn't have the module enabled.
Describe the solution you'd like
A button on the hardware tab, that when pressed:
- warns that packet transmission may be stopped
- queries module busses and reports their status
- describes the findings
Describe alternatives you've considered
1. a more emphatic warning on the ELRS lua script about going to the
model page
2. have the wizard lua script include the radio's default module by
default in new models
While these would both have solved my immediate problem, I think having a
model-free ability to debug module communication would be a great addition
to EdgeTX.
Additional context
*No response*
—
Reply to this email directly, view it on GitHub
<#5648>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KLOOSEBM32IAGVTS7TZ67CPDAVCNFSM6AAAAABRFBLR42VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTGNZWGE4DQNA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
The modules are not "off" though, it's just that the serial link on the edgeTX side is disabled. I also think it's unlikely that someone will be diving into the hardware menu to debug an RF module and interrupt transmission while actively piloting a vehicle. You can just as easily crash by switching to a new model or attempting to change model settings on the fly. The idea here is to allow for model-agnostic hardware validation on the bench, just like we do today with switches, analogs, etc. |
The power to the modules is switched off, when they are off.in the model config. |
No, the modules are really off. EdgeTX cuts power to the internal/external modules if Internal/External RF settings are set to "Off" as can be easily observed with an external OLED screen module. |
I am at a loss then, how did I manage to flash the internal ELRS module via edgeTX serial pass through if it was off? |
Because when you use the ELRS Configurator to update the module, it has control of the radio, not you. It can turn stuff on and off as it needs to get it's job done. i.e. I've not checked the programming flow on the ELRS configurator when it's flashing via passthrough, but it probably turns the module off, holding a GPIO down to configure the ELRS module's MCU to go into programming mode, and then powering the module back up again (but now it is sat in programming mode, waiting for the firmware update to come in). And something similar happens when you do passthrough flashing to the backpack module. |
You mean, it's possible to turn on the radio module and communicate with it without interfering with other functionality in EdgeTX? It seems like this is exactly the sort of thing I'm asking for here (except that perhaps a lua debug script could "take control of the radio and turn things on and off to get it's job done"). I'm happy to take a stab at this myself if this sounds feasible. |
Not entirely, no. Sure, you could use a Lua script (instead of the USB
passthrough - this has nothing to do with the ELRS Lua) to turn the
internal module on or off - but note that this is impractical to do for the
external module, because you then need to know *which* module types it is -
but then if using some external or internal configurations, this can wipe
out the control link.
It is for this reason, as well as for consistency of behaviour - i.e.
status display should simply display current status, not alter settings -
that I think the current behaviour is entirely correct.
…On Wed, 6 Nov 2024, 4:06 am jmole, ***@***.***> wrote:
You mean, it's possible to turn on the radio module and communicate with
it without interfering with other functionality in EdgeTX? It seems like
this is exactly the sort of thing I'm asking for here (except that perhaps
a lua debug script could "take control of the radio and turn things on and
off to get it's job done").
I'm happy to take a stab at this myself if this sounds feasible.
—
Reply to this email directly, view it on GitHub
<#5648 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KPRX7L3O5B3RO5AGKTZ7ECL3AVCNFSM6AAAAABRFBLR42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJXHA2DQNJWG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
You also need to consider if this makes things even more confusing... i.e.
you go into radio -> version -> module info and it says the internal module
is ELRS XYZ packet rate... so it must be on, right? Then why doesn't it
connect to RX, or Lua talk to it... Oh, it isn't on, need to turn it on in
model settings. Er... but why did module info not reflect current state,
that it is OFF ?!
…On Wed, 6 Nov 2024, 7:14 am Peter Feerick, ***@***.***> wrote:
Not entirely, no. Sure, you could use a Lua script (instead of the USB
passthrough - this has nothing to do with the ELRS Lua) to turn the
internal module on or off - but note that this is impractical to do for the
external module, because you then need to know *which* module types it is -
but then if using some external or internal configurations, this can wipe
out the control link.
It is for this reason, as well as for consistency of behaviour - i.e.
status display should simply display current status, not alter settings -
that I think the current behaviour is entirely correct.
On Wed, 6 Nov 2024, 4:06 am jmole, ***@***.***> wrote:
> You mean, it's possible to turn on the radio module and communicate with
> it without interfering with other functionality in EdgeTX? It seems like
> this is exactly the sort of thing I'm asking for here (except that perhaps
> a lua debug script could "take control of the radio and turn things on and
> off to get it's job done").
>
> I'm happy to take a stab at this myself if this sounds feasible.
>
> —
> Reply to this email directly, view it on GitHub
> <#5648 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABJ66KPRX7L3O5B3RO5AGKTZ7ECL3AVCNFSM6AAAAABRFBLR42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJXHA2DQNJWG4>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Also, things like XYZ aren't available unless you are running the script, where the lua act as a dumb terminal. In other words, you have no realistic way (ie API) to get and store information displayed by the lua script |
Is there an existing issue for this feature request?
Is your feature request related to a problem?
I recently got a Radiomaster TX16S II, and started playing around with it by first going through the model wizard. I made a new quadcopter model, and then moved on to explore other parts of the touchscreen GUI.
When I later tried to launch the ELRS lua script, the radio stopped responding. So, I upgraded the radio firmware, and then ELRS firmware via serial passthrough. After this, the ELRS lua script said there was no module connected, but I was able to escape from it and try other things.
I later discovered that the new model that the wizard had created had no modules enabled, but it took a lot of fooling around (including me disassembling the radio) to discover this.
So it was surprising to me that I was able to flash the module with a new ELRS version, but I was not able to query basic parameters about the module, either on the Hardware page, or the Version page, simply because the model I was using didn't have the module enabled.
Describe the solution you'd like
A button on the hardware tab, that when pressed:
Describe alternatives you've considered
While these would both have solved my immediate problem, I think having a model-free ability to debug module communication would be a great addition to EdgeTX.
Additional context
No response
The text was updated successfully, but these errors were encountered: