I'm currently working on mapping out the special channels (vfos, calls, u/l scan limits) as well as the some of the global settings. I'm not sure exactly how those special channels are dealt with, as I didnt see a sample implementation in template, just an actual implementation like ft-857, etc.
Yeah, that's unfortunately pretty ugly right now. Looking at one of the other implementations will get you there.
How can I solve the issues with importing from floats that dont match (i.e., 6.25)? do I need to bracket them into my list at get_memory or set_memory time?
What do you mean? If you don't declare that you support 6.25kHz splits then CHIRP won't ask your driver to attempt to set one.
On the ToneSql type, how do I preserve a channel setting for Bell or Auto, if chirp doesnt support it. Do I have to be destructive and box all channels into one of the supported types? It's totally possible to have set Bell or Auto in memory on the radio. What happens when I import this now? How should I deal with this, if I cant tell chirp what are possible/legal values for my radio?
Right now, we just coerce those to supported values, which ends up losing the bell setting if the user attempts to write to that memory channel. You could, I suppose, detect and preserve that bit prior to setting it if you want, but then the user would have to disable an errant bell bit on the radio itself. You could expose that in the extra settings...
I commented out the ARS code, but now if I can do custom fields (i'll see how it's done with uv-5r) then I may be able to make this a bool field, and deal with the logic of ignoring/setting duplex field in get/set memory members.
Cool.
I understand it is semantics and style, but since these allowed tone values for this particular radio will NEVER change, I don't want to be dependent upon chirp_common tones never changing.
I understand it's a bit icky, but we've done okay for five years on this model.
It would be a long shot that they ever do change, but if they do, it would be more difficult to determine which tones are now supported/unsupported, since the "source of truth" gets altered.
I understand. The reason we started with this pattern pre-dates CHIRP supporting anything but Icom radios, and a few other things. It's all in git history and the subtractive model makes it easier to eye-parse the differences.
Thanks!