NV14 - module settings not displaying/updating correctly

[pfeerick]

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

When opening the Internal RF module settings on NV14, with a configured module, it says AFHDS3 instead of AFHDS2A in the choice field on inital page load

but allows selecting AFHDS2A in the popup list, but even then it needs to be selected twice to show all AFHDS2A options (the RF power field is missing on the initial selection)

Expected Behavior

That AFHDS2A be selected correctly, and not require muitple selections to show all options.

Steps To Reproduce

1. With 2.10-RC3, go into Model Settings -> Internal RF
2. Witness it showing AFHDS3 on a AFHDS2A-only handset
3. Press on the Mode option, and see it now offer OFF and AFHDS2A as only choices
4. Press on the AFHDS2A, and see it load almost correctly.
5. Repeat 3, and see the RF Power option now appear.

1-4 are repeatable in simulator, the 5th entry depends on hardware check.

Version

Other (Please specify below)

Transmitter

Flysky NV14

Operating System (OS)

No response

OS Version

No response

Anything else?

#4942 fixes an unrelated error in afhds2a_settings.cpp
Looks like AFHDS3 layout could do a smaller receiver id field as the range button is going off screen.

[philmoz]

I'm not seeing this in Companion/simulator downloaded from the 2.10 RC3 release, or in a self build.

Can you share the etx file.

[pfeerick]

Interesting... so Companion Simulator is obviously pre-loading something that simu and radio don't ... which is one of the reasons I never using the Companion simulator to ab test stuff as it doesn't simulate the radio as well as simu does. The screenshots were from simu, which is behaving exacly the same as hardware with a nearly 'at defaults' config.

NV14-simu.zip

[pfeerick]

Something is seems to be happening further back in the load process... as it isn't initialising the RF ... so the module page "bug" may be limited to simply the RF power settings not loading/updating correctly... it seems like it is actually mis-interpreting AFHDS2A as AFHDS3 somewhere on read-back (even though it is correctly saved as TYPE_FLYSKY_AFHDS2A), and the GUI is then acting accordingly.

[philmoz]

It's the presences of the 'subType' property which is not being written correctly I think.
Companion does not write this; but your model file has it.

In r_modSubType function the module type gets overwritten because subType == 0 (AFHDS3).

[philmoz]

Can you try #4953 on the actual radio.

[pfeerick]

Yes, that fixes the major issue on radio... it now boots up knowing it has AFHDS2A as the active RF, and is settings/reading it back correctly on reboot - not incorrect reference to AFHDS3 anymore.

Can you think of a simple way to trigger/refresh showAFHDS2Options correctly after having selected AFHDS2A as the active module type (i.e. New Model => OFF => AFHDS2A would be the workflow).

[philmoz]

Do you mean the 'RF Power' option? That appears to rely on the firmware version being received from telemetry data, so needs the receiver to be bound and sending telemetry.

If you leave and re-enter the Internal RF setup page does it show up?

[pfeerick]

Do you mean the 'RF Power' option?

Yes

That appears to rely on the firmware version being received from telemetry data, so needs the receiver to be bound and sending telemetry.

getNV14RfFwVersion() does not require a receiver to be connected - it is querying the internal RF version which is available once the module has booted. i.e. it needs a refresh after a delay if the version is high enough.

If you leave and re-enter the Internal RF setup page does it show up?

Yes. You can simply turn the RF on, exit the page and re-enter the page.

[philmoz]

Try the updated version of PR 4953

[pfeerick]

Yup, that got it... can even see the option being added in as the module reports it's version just after enabling it.