Adding to my fun, I’ve skimmed the FT1D user manual, and the FT1D has the same feature as the FT2D: The radio can put “preset frequencies” into memory banks. See p 52 “Registering Your Favorite Preset Receiver Memory Channels in Memory Bank”. If somebody with an FT1D could follow those directions and enter a preset into a memory bank, I’ll bet that chirp misbehaves in the same way after reading in the image from the radio, and one should be able to use chirp’s Browser to see the following values in “channel” (clearly, taken from my FT2D):
0x0000 is memory Location 1 0x0001 is memory Location 2 … [no surprises here]
0x1800 is channel 1 of the "WX Channel Frequency List” 0x1801 is channel 2 of the "WX Channel Frequency List” ... 0x2800 is channel 1 of the “International VHF Marine frequencies” 0x4000 is channel 1 of the “Worldwide short wave broadcast”
Such high values of “channel" cause chirp to emit an error when assigning memory locations to banks in the Banks tab of the UI, and those values will be encountered if they have been manually entered into the FT2D and then read into chirp (and, I presume from the FT-1D as well.) If the values occur, the bank with an offending location cannot be further set (or unset); the error always happens. Unaffected banks can still be manipulated correctly.
It looks to me as if a “channel” (one of 100) in the FT1D (and FT2D) memory map* for “bank_menbers” array should be interpreted as a structure of its own: 1 bit unknown (0xFFFF is designates an unused channel in FT2D; I’d guess 1=unused, 0=used may suffice) 1 bit for SW presets 1 bit for Int VHF presets 1 bit for WX presets 1 bit unknown (perhaps 1=FM, 0=AM?) 11 bits of channel number (allows up to 2047 memory locations; FT2D uses only 999 so there might be yet another bit of flags and one fewer for number.)
Heaven only knows if or how the radio would handle having multiple “presets" bits set in one channel. If chirp were to handle these bits, it’d probably be polite to include logic that prevents that from being saved (“toggle bits” as it were.)
So, I ask in decreasing order of importance: What’s the “correct” way to restructure the FT1D (and thus FT2D) memory model* to include 100 channels per bank as an array of u16 (present situation) but with an internal flag structure in each one? I’m not quite sure how chirp handles “channels” in its own virtual model; I presume it just use the u16 as two bytes without any modifications and it’d be up to the driver to interpret them. I have temporarily prevented the error from occurring by changing the FT1D.py to use “channel & 0x7FF” wherever “channel” is used in most places (but not while checking for 0xFFFF.) I’ve added no functionality for interpreting the flag bits, and I’ve not changed the memory model.
What’s the “correct” way to display such a structure in the Banks tab of the UI? At present, one cannot even use chirp to see that these fields are set. It might be useful to postpend lines to the columnar display when presets exist (e.g. "WX #1…. checkmark:, "int VHF #5… checkmarks”, “SW #25…. checkmarks”) I don’t think we have access to the actual frequencies involved so they cannot be displayed. ATM, FT2D and chirp always cause these high-flagged channels to exist at the END of the Banks listing.
What’s a “correct” way to SET or UNSET such a structure using the Banks UI? If they were displayed as above, the checkboxes would presumably be active just as they are in the rest of the UI. That’d make them easy to UNSET: just uncheck the corresponding box. I don’t have a good suggestion for SET; it’d be unwieldy to add ALL the possible presets as “high locations”, but more interactive options would require UI changes. Is this a place for “Special Channels” in the Memories tab?
* I have no Idea what the FTM-3200D or other radios subordinate to FT1D does with banks and preset frequencies; a change to the FT1D memory model might break the FTM-3200D. But if the FTM-3200D is working fine with the u16 channel and doesn’t have more than 2047 memories, it should be just fine.
Declan Rieb WD5EQY