Bug #4121

QYT KT-8900R: Extra-Settings are reset on every change in the "regular" memory settings

Added by Michael Wagner over 3 years ago. Updated over 3 years ago.

Status:New Start date:10/10/2016
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Chirp Version:daily Platform:Windows
Model affected:KT-8900R


Every time a channel is edited, all its extra-settings are reset.

Steps to reproduce:
1. - load a KT-8900R-image
2. - select an arbitrary memory-channel, click on "Properties", select tab "Other"
3. - configure different values for "Scramble", "Busy channel lockout", "PTT-ID", "PTT ID Signal Code", "Optional signalling", "Speaker mute" and save them by clicking "OK"
(3.a - optional: verify again in "Properties/Other" that the values have been stored)
4. - in the "Memory"-Window, change an arbitrary value of the previously configured memory (e.g. set a different name). Note: the remaining settings of that memory did not change
5. - Again open "Properties/Other" of that memory.
=> expected behavior: settings set in steo 3 are still there
=> actual behavior: the settings have been reset to False/False/OFF/1/OFF/"ToneDTCS"

Associated revisions

Revision 2794:2b56eb3d6651
Added by Michael Wagner over 3 years ago

[btech] Resetting mem-extra-settings only when editing previously empty memory. Part of fix for #4121
Attempt to fix #4121 for the driver btech.py following Dan's proposal in http://intrepid.danplanet.com/pipermail/chirp_devel/2016-October/004298.html .

Michael Wagner, OE4AMW

Revision 2804:a91c9641e0e8
Added by Michael Wagner over 3 years ago

[uv5r] Memorize extra-settings before erasing memory. Fix for UV-5R of issue #4121
Try two, with consistent naming of variables.


Updated by Michael Wagner over 3 years ago

As I just noticed, this issue is not limited to the KT-8900R, it also occurs at least on the UV-5R as well.
However, with the Yaesu FT-857D the issue does not occur (so, it is not a general error that affects all radios).

Unfortunately I do not have more different radios to test.

Updated by Michael Wagner over 3 years ago

Another finding: This only happens if the memory is edited in the table itselves.
If it is edited in the "General"-Panel of the "Properties"-Window, the issue does not occur.

Also available in: Atom PDF