[chirp_devel] Questions about Elecraft K-series
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
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?
It's just marked blocked because there was nobody to work on it. Back then, one could count the number of radios we might support and so we would mark a request as blocked until someone had access to one to work on. Nowadays, ten new radios get released every time I brew coffee, so we do that less :)
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.)
Labeled as public doesn't matter, it's the license that matters. However, that code is GPLv3 which is compatible with CHIRP (obviously). Anything you actually copy needs to maintain attribution, but that looks like a good place to start. It'd be great if Elecraft wanted to help, but it sounds like maybe they don't. I definitely don't understand why smaller manufacturers would ever shy away from someone that wants to freely increase their user base in exchange for a little data on the internals which is easy enough to discover as it is.
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?
Yes, almost all the HF radios are live and it sounds like this would be no exception. If the radio doesn't do a full memory dump, it will fit the live radio model better.
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?
Sure, but for a live driver there's no file format so we'd have to do something special. I'd prefer we just work on talking to the radio and not parsing their not-likely-widely-distributed file format.
I have a KX3 so I can help test. I don't put memories into my HF radios, so I don't really care to work on it, but if you do, you're welcome to unblock that issue and have at it :)
--Dan
participants (2)
-
Dan Smith
-
Declan Rieb