[chirp_users] Thoughts on TH-F6A support and looking for D710 support

[Dan Smith]

> 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
> 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?

> 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 "[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! :)

-- 
Dan Smith
www.danplanet.com
KK7DS