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@arrl.net