July 2023 - Developers - lists.chirpmyradio.com

[chirp_devel] Developers' wiki page
by Declan Rieb 29 Jul '23

29 Jul '23

Dan, [These thoughts were written to augment the existing page at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersAdd_a_Radio. They may be TMI for many of you experienced folks, but beginners might appreciate lessons-learned. And I’ve not written anything yet about how a Git noob can make your life miserable. Declan Rieb, WD5EQY(a)arrl.net <mailto:WD5EQY@arrl.net> ] Write get_memory(number: int | str) This is called to get your driver to populate the CHIRP memory model with the data for one radio memory. On startup, it’s called once for each memory register you’ve delimited for your radio and once for each special memory. Later it will be called as needed. - get_memory() returns a populated CHIRP memory object that the driver creates as a new instance of the chirp_common.Memory structure. You’ll want to become familiar with the fields in the Memory structure (presently specified in the source tree in the source file chirp/chirp_common.py). - The number of memories is specified in chirp_common.RadioFeatures.memory_bounds, which is a pair of numbers (first memory register number, last memory register number.) get_memory will be called with an integer parameter for regular memory with a value up to the last memory register number. - Special memories are radio-specific registers that can hold special meaning in the radio (such as scan limits, home registers, skip registers, etc.) They are specified in your driver as members of the list that you set at chirp_common.RadioFeatures.valid_special_chans. get_memory() will be called with a string containing the name of the special register, and you must set the Memory.number field of the resulting memory object to an index that is greater than the last memory register number and different than other special memories without holes in the sequence. Subsequent calls to get_memory() may receive either the index or the name. Do read the example driver at chirp/chirp/drivers/template.py. There is a commented stub version of this routine in chirp/chirp.common.py. Your driver is expected to overload it. Write set_memory(memory: chirp_common.Memory) This is called whenever CHIRP wants your driver to set the radio’s memory according to the fields described in the specific chirp_common.Memory parameter. The driver will presumably need to determine the specific radio memory based upon the value of memory.number (e.g. integer less than or greater than last memory number.) The driver should not change the memory structure. There is no special return to CHIRP required. Do read the example driver at chirp/chirp/drivers/template.py. There is a commented stub version of this routine in chirp/chirp.common.py. Your driver is expected to overload it. Radio memory settings that are not included in CHIRP chirp_common.Memory. CHIRP can (optionally) manage and display other settings for each memory. These are stored in a separate subject chirp_common.Memory.extra, and are handled during the get_memory and set_memory by calling _get_mem_extra(mem, _mem) and _set_mem_extra(mem, _mem), respectively. “mem” is the CHIRP memory structure, and “_mem” is the corresponding radio memory structure. You’ll get to write code to handle them similar to “RadioSettings.” Run tests Read the wiki page at https://chirp.danplanet.com/projects/chirp/wiki/DevelopersPython3Environment Tox is a separate application used to run tests for CHIRP. (I got it by “pip install tox” and it installed into my Python instance.) It will check syntax and stylistic features of the python source. It will also run many logic tests on all drivers that have changed in your tree since the last time it was run. Use: $ tox -e style You may then wish to run the driver test only on your driver. It appears that you can do so by executing $ tox -e driver -- -k Vendor_Model Or (to only test drivers with changes:) $ tox -e fast-driver When your new driver gets to the GitHub and a Pull request is made, the CHIRP folks will cause even more extensive tests to be run on it, so try to pass these tests first. Things not said elsewhere: Some of the following are hinted at in the example driver “chirp/chirp/drivers/template.py.” CHIRP has a “directory” structure of all the radios it should know about. Your driver will have one or more “(a)directory.xn--register-kq3d statement, wherein a class is defined for each radio you’re working on. They can inherit from each other (even other models and vendors) once the classes are read by CHIRP. The directory is sorted by text (vendor, model) pairs. That class will have definitions (and some redefinitions) for your radio. It will also implement a function get_features() -> chirp_common.RadioFeatures() You get to return basic information about your radio in the structure that CHIRP defines in chirp/chirp_common.py and you instantiate. Any existing driver should have one for you to copy and modify. CHIRP calls it fairly often when starting, so it’s expected to be lightweight. You probably don’t want this function to be querying the radio each time it’s called. Modes: CHIRP has a predefined set of “modes” available for each memory entry. Whatever your radio defines as modes, they MUST map into the CHIRP model. If the radio’s modes don’t fit into CHIRP’s model, you’ll get to add some translation into your driver. The current list (as of 2023-07-28 from chirp/chirp_common.py) is: MODES = ("WFM", "FM", "NFM", "AM", "NAM", "DV", "USB", "LSB", "CW", "RTTY", "DIG", "PKT", "NCW", "NCWR", "CWR", "P25", "Auto", "RTTYR", "FSK", "FSKR", "DMR", "DN") Live drivers A more-official description can be found at https://chirp.danplanet.com/projects/chirp/wiki/FAQ. Most radios seem to have a mode for which memory can be read or written as a large block, and their drivers reflect that. A few radios can only be accessed on what is effectively memory-by-memory reads/writes. These radios will almost surely need to be written as “live”. An example driver is at chirp/chirp/drivers/kenwood_live.py. Several other Kenwood drivers inherit from that one (at least ts480.py, tmd710.py, ts2000.py.) These drivers do not use the same radio-memory model as most of the others, but can keep a kind of cache. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] Subject: Re: Elecraft KX3?
by Declan Rieb 29 Jul '23

29 Jul '23

> 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(a)arrl.net

2 1

[chirp_devel] Elecraft KX3?
by Declan Rieb 27 Jul '23

27 Jul '23

The new driver is almost-working to read (only) the Elecraft KX3 (and only basic memories.) But I’ve a few questions, and a problem: 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? 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? 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? This problem is stumping me. The debug is from an execution aborted after the errors. Memories 8 and 10 have mode ‘AM-S/LSB’! Source is in the new “elecraft” branch on darieb/darchirp hub. It won’t pass any of your standard tests, yet. Thanks in advance. ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1

[chirp_devel] TYT TH-8600
by Andy Knitt 20 Jul '23

20 Jul '23

I recently purchased a TYT TH-8600 and am starting working through mapping out the memory so that I can hopefully eventually put together a PR to add support for this radio, as it's been requested quite a few times. This will be my first attempt to do this and I have a couple newbie questions: 1 - Does anyone have any recommendations for a similar TYT radio that I should look to use as a 'closest' starting point? I've been looking at a few different TYT models and while the themes are similar there are some reasonably big differences among them. I'm not familiar enough with their product line to know which ones might be the closest to the TH-8600. If no one knows, I'll just suffer though figuring it out. 2- This radio supports a few features ( 2Tone & 5Tone signalling, etc.) that aren't typically used in amateur radio. Is it normal practice to fully tease out the entire memory map and add support for these types of things to CHIRP, or just skip them? Thanks, Andy KN1TT

5 7

[chirp_devel] Questions about Elecraft K-series
by Declan Rieb 10 Jul '23

10 Jul '23

I emailed with Elecraft within the last year and volunteered to work with them to get CHIRP to access K-line memories (the radios have at least 199, AFAICT.) Elecraft does have software to handle the memories, but it only runs under Windoze and with an old library. Elecraft were only interested in working with a proven professional developer, and were not willing to discuss much further. A very old CHIRP request (#248) has been “Blocked." It asked to get CHIRP to work with a Elecraft K3. I wonder if anybody has revisited that decision or if (possibly?) Elecraft has asked that CHIRP not support it? And, if they’ve asked, what are the reasons? Programming for the K3, KX2, KX3 are very similar. It looks as if the new K4 is compatible with the “old” methods, too. The commands for accessing memory are documented as “Internal use only" in the available literature. Tracing communications via the Elecraft software indicates that there’s a lot more going on than just the two commands to read and write, although it seems to display the full contents of the two commands. There exists some old (2011) deciphering of the communications available at https://github.com/ik5pvx/k3mem/blob/master/docs/k3-er.html, which at first glance jibes well with my KX3 traces. (That repository is labeled public by GitHub.) Elecraft’s software has the ability to read or write a single, selected memory. If one selects the whole radio’s memory, it appears to access each memory sequentially. Does this mean that CHIRP should use a live radio model? Is there a recommended driver version to model for the K-series? Elecraft’s software writes (and presumably reads) an XML file, which should not be terribly difficult to reproduce in CHIRP. Has XML been done in a driver before? ______ Declan Rieb WD5EQY wd5eqy(a)arrl.net

2 1