If I restart the chirp program, the memory name is missing in UI after the radio memory load as well as STDERR: -- D7->PC: N PC->D7: MR 0,055 D7->PC: MR 0,055,00224040000,0,0,0,0,0,0,08,08,000,000600000,0,0 PC->D7: MNA MNA 0,055 D7->PC: N
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.
- I cannot save the download memories. The File --> Save and "Save As"
are greyed out. Maybe these options aren't used as there is Radio --> "Export to" ?
Correct. "Save" means "Save an image". There is no image for a live radio, so you can't do that.
I've already added the aforementioned notice dialog, which explains this. You should see that in the next round.
- By default, when downloading the memories on a THF6A, it downloads
memories 0-399 but displays 0-25. If I change the "Memories Memory range" to say 0-399 and click on go, it re-downloads all 400 memories which takes a long time. This re-download should be suppressed.
It's cached on some of the other live radios, and I can do the same for the kenwood ones. You are, I believe, the first person to attempt using the kenwood driver(s) other than myself and a small circle of friends :)
- If I try to edit an entry, say memory slot 55, and I type in a
repeater name and then hit enter, I get a dialog box saying "Error setting memory: Frequency 0.000000 is out of range." It then proceeds to re-read the entire radio's memory which take a while (this re-download should be suppressed. The UI should either require the user to enter in the frequency FIRST or it should let the user enter in the memory's name but not upload the name it until a frequency is also entered in.
That has been fixed in the repository already, since the beta you are using was posted.
- I'm also curious, I imagine that these LIVE radios are using NVRAM
which has limited writes before the memory will begin to fail. Is it wise to send lots of little writes like this vs. suppress all updates until the data set is complete?
I guess I can't really speak to that. However, I can say that all of the radios I've ever looked at do a lot of "scratch pad" type operations on the same memory that stores all of this data. Even powering on the radio generates a write. Every click of the dial in VFO mode generates a write. I think that if the NVRAM was likely to wear out (like flash does), the radios would be more frugal.
- 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?
- 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.
- Erasing say memory #55 grey's out the entry in the UI and the status
field gets stuck on "[1] Erasing memory 55". Nothing happens to the radio's memory.
Yeah, this is related to #5.
I sure am glad someone is finally giving the kenwood driver(s) a workout, thanks! :)