Cool. Curious, can I download directly from your repository (CVS, SVN, GIT, etc.)? I haven't seen any URLs, instructions, etc. to do so. Probably intentional.Ah, I see the problem. That second-to-last line should be "MNA 0,055". It has an extra "MNA" in there and the radio NAKs it with 'N'. I should be able to fix that here and shoot you an update to verify.
Done: TRAC #785) When I was doing some testing (I think I accidentally tried to write to an empty memory slot: -- Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54 ------Ah, good one, thanks. Can you file a tracker item for that?
Btw.. if the vrious Kenwood radios are a little different, shouldn't the STDERR show something like PC->F6 instead of PC->D7? Little misleading if that's supposed to represent the radio.6) I've also seen error like the following where chirp is working fine and then it breaks. Notice that the radio's name in STDERR goes from D7 to E7 which might be expected but I'm not sure.Hmm, yeah, that's interesting for sure. That might be one I have to reproduce locally.. That's pretty strange.
I'm glad I can help out as I've been looking for something like this for some time now! I'm going to add your tool to my HamPacket documentation which is a Step-by-Step guide forYeah, this is related to #5. I sure am glad someone is finally giving the kenwood driver(s) a workout, thanks! :)