[chirp_devel] Subject: Re: Elecraft KX3?

[Declan Rieb]

> 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.

OK. I understand. Is there a way to expose the labels of the columns from the UI so that a driver could change “offset” to “VFOB” for example? I don’t much like the mem.extra idea, either.


> 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.

Thanks. That’s “a good thing” for driver authors to know. I’ve started a compendium of what I consider useful hints that I’ve encountered in working a driver that I wish I’d known earlier. It’s probably not ready for real publication, but I an email the rtf or text it to others if desired.


> 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.

OK. I understand that, too.  That, is also a “a good thing” to know ahead of time.

______
Declan Rieb WD5EQY
wd5eqy at arrl.net






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20230728/875c0cc6/attachment-0001.html