[chirp_users] Thoughts on TH-F6A support and looking for D710 support
dsmith at danplanet.com
Sat Feb 5 14:58:58 PST 2011
> 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.
> 1) 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.
> 2) 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 :)
> 3) 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.
> 4) 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.
> 5) 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
> 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?
> 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.
> 6) Erasing say memory #55 grey's out the entry in the UI and the status
> field gets stuck on " 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! :)
More information about the chirp_users