Hello CHIRP experts. Thanks for reading, and especially for responding to my questions in bold.

1. I’ve just found that CHIRP-next and CHIRP-source both break when I try to look at the settings data for a radio that’s new (ahem… not quite: when I use a default .ft1d file written by Yaesu’s ADMS software.) The root cause is that no data have (ever yet) been placed into the APRS section, and CHIRP effectively burps on a Null link. I’ve fixed that, I think. I also simplified some of the inheritance “differences”… The FT1, FT2 and FT3 all have 900 memories, and 99 Skip-memories and 100 PMS-memories, so changing the ft1d.py to at least define them (even if not quite handled!) seemed like a no-brainer. Question 1: How to put this branch into the regular tree? Will I need to submit an error report (issue) so I can get a case number and email you the diff file with an appropriately-referenced datum? Or, since things are still being wholesale-changed, should I just push it on up? (I’m loath to do that because y’all are very good at spotting stupid programmer errors and I’m no Python expert.) All of my other changes below will be sequential branches from this one.

2. The GM/WWIRES-X support from the ft70.py is almost drop-in compatible, so I’ve a (separate) ft1d.py that at least displays those data in a settings tab. (I’ve not tried setting them yet; most are pull-down menus.) There is more work desired to enter to support the digital rooms and categories (Yaesu’s ADMS handles those, so I think CHIRP should as well.) This work supports Feature #6151

3. I’ve yet another ft1d.py branch that handles the 99 skip-memories, 100 PMS-memories and 11 Home memories as ‘specials’. So far, they seem to be displaying correctly (yay!) This looks like the same issue as Bug #3951 but for Yaesu FT-1D, FT2D, FT-3D. - One downside for now is that there are ~1200 lines in the CHIRP output page. At least for testing purposes, most are empty, and so a LOT of scrolling is required. Is there any way to have CHIRP [optionally] display only one blank line in a row (skipping others) or to go back to the toggles for “show blanks” and “show specials”?? I can imagine having the UI become sensitive to a radio-specific parameter (e.g. rf.display_blank_lines and rf.display_specials, both set True by default but selectable by the driver and/or in the UI) I can imagine having memory output look like the following for an FT1 (Home frequencies are always set; Specials show at least first and maybe last line, even if blank) 1 freq … 2 freq … 3 (blank line) 10 freq … 11 (blank line) 900 (blank line) S1 freq … S2 (blank line) S99 (blank line) L1 (blank line) U50 (blank line) H1 0.65 H2 … H11 …

Question 3a: Can I (optionally) have CHIRP hide some blank lines?

- It seems that specials have an execution path that I didn’t expect. When I try to SET a regular memory, my present debug shows ‘set_memory’ is called and works fine. I’ve modified it to handle the special memories, similar to changes in ‘get_memory.’ But when I try to change a special memory, my driver's ‘set_memory’ routine isn’t called at all. Instead, I run into an error (I was able to get debug file from CHIRP_next after loading my driver module; that is attached. I had loaded an ADMS file and touched the settings button, then tried to change Skip901 special memory.) Traceback (most recent call last): File "/Users/declan/chirp/chirp/wxui/common.py", line 452, in run_safe return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/wxui/memedit.py", line 1038, in _memory_edited self._radio.validate_memory(mem)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/chirp_common.py", line 1227, in validate_memory return rf.validate_memory(mem) ^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/declan/chirp/chirp/chirp_common.py", line 976, in validate_memory (mem.number < lo or mem.number > hi) and \ ^^^^^^^^^^^^^^^ TypeError: '<' not supported between instances of 'str' and ‘int'

Now AFAICT, the ‘mem.number' that my driver gets can be either an integer (1-900 in FT1D case) or an appropriate string for the specials (e.g.’Home1’). Those names came from my specials list used to set ‘rf.valid_special_chans’ … I don’t think I ever set mem.number, but it seems as if CHIRP is using the names from my specials list (I can’t quite tell… I never put debugs into the memedit.py or chirp_common.py.) I don’t explicitly use ‘extd_number’ anywhere in my drivers.

Question 3b: HOW do I correctly allow CHIRP to modify a special memory?

______ Declan Rieb WD5EQY wd5eqy@arrl.net