However, I cannot understand what I’ve done to the driver to cause the following problem. I KNOW the problem is my fault, because CHIRP_next does the change correctly, while it behaves incorrectly as described below when CHIRP_next is loaded with my modified driver. As a non-Python-er, I’ve even tried to interact with the driver while running, but haven’t a clue where to look or what to modify to get the output that’ll point to the problem.

[I include a debug file from that CHIRP_next test.]

Bottom line request for help: How can I have affected the UI without having messed up my driver's structures? Or CHIRP’s mem structure either, AFAICT. Any guesses, please? 

This UI silliness occurs in spite of the driver passing all tox tests for it:

tox shows no syntax errors in the pep8 section, and 

tox -e driver -- -k Yaesu_FT-1D_R

Indicates that my changed driver passes all tests (well, 31 passed and two skipped.)

When I load a bare FT1D file (presumably factory-fresh; actually a default file from Yaesu’s ADMS software for the FT-1D), the expected shows in the CHIRP UI:

- Memory 1 (first slot, python index 0) has an entry of 145 MHz, FM

- Eleven “Home" memories are defined as described in the manual.

- The other 1100 memories show as empty

[Although the files won’t show in the email summary, I attach two screenshots of that situation, both file labels showing “Bare FT1D”, but have removed them from this reprise.]

AFTER attempting to change the second memory slot (python index 1) to show 146 MHz, I expected the UI to auto-populate the rest of the line similar to what showed on the first memory (FM…). BUT:

- Memory 2 UI now shows a label with an asterisk (almost surely indicating a change to that line) with the 146 I typed still in the frequency location; the rest of the line is blank

- Home3 (!) UI now shows the correct Memory 2 line, along with label “2”, as if it were memory 2

[Two more screenshots labeled with “after mem 1 change” are no longer included but available.]

- Looking at the browser, memory index 1 and Home1, Home2 and Home 3 all show the correct register information.

[Two more screenshots after the changed include “browser” in the filename are no longer included.]]

- This type of problem occurs for every memory line up through 100, although it starts to populate the PMS specials memory lines.

BUT: If I save the file, exit and restart CHIRP, everything is in the ‘correct’ place. That’s in keeping with the browser having shown the correct data in the correct place!

Debug file, shows information from unmodified FT-1D module, and then the modified one after “load module”: