Question: this radio’s memories contain data for TWO VFOs in each memory. I’m confident I can display the second VFO as mem.extra fields (frequency and mode) but is there any workaround way to get CHIRP to display both sets of fields in the normal display? Or possibly to preset the “display extras” menu item for the radio at startup?
You could put the second VFO in the offset field and support only simplex and split for the duplex column. That's kinda how commercial radios (and copies of them) do it. But no, there's no other way and I think exposing it in mem.extra would be less than ideal.
Question: The driver's routine “get_features” shows up as being called 24 times(!) I’ve put a LOG.debug inside to show that valid_modes has the appropriate values. I expected it to be called once. It’s not a problem to me, but it is a surprise. Is this normal?
Yes, get_features() is called all over the place and is assumed to be very lightweight. If you need to ask the radio stuff to generate the features, do it once and cache it. Ideally, you wouldn't talk to the radio at all during get_features() because it'll hang whatever part of the UI hits it first while you do.
Problem: Having set ‘valid_modes’ to be appropriate for the radio, when I try to use one of the more esoteric ones (“AM-S/LSB”) CHIRP complains that the value is not in a (default? canonical?) list of modes… that list is NOT the one that is shown as having been set in “get_features”! It looks to be one set in chirp_common.py. What have I done wrong?
You don't get to just arbitrarily define modes as a driver. This is so that we have consistent importing between radios. I dunno what "AM-S/LSB" is supposed to be, but you'll need to coerce that into one of the standard modes. Optionally you could expose part of that through mem.extra potentially, but the better thing to do is just coerce it to something standard. CHIRP is an abstraction, which means we can't support absolutely every non-standard detail of every radio.
--Dan