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

[Dan Smith]

> When Chirp reads the F6A and completes the download, the resulting table
> doesn't show it's name and the STDERR output from shell where I run the
> Chript Python script doesn't show the names of the memories either.
> Would the memory name not show but actually be getting captured?

Do you mean the column is missing or the values are blank?  If the 
column is missing, add it in the View menu.  However, you should be 
seeing them in the stderr output, as you mentioned.

> Any thoughts on why the cancel doesn't work on the Yaesu radios? Is my
> Python environment missing something?

Oh, right, I meant to mention that.  Apparently you're missing the 
'ctypes' module.  What Python and OS version are you running?

> Great news on the D710 and I'll help test if if you'd like! Curious,
> will you only be capturing memories or will your tool also capturing all
> other user settings for say APRS, etc? It sure would be nice to be able
> to use Chirp for full backups, etc.

CHIRP has mostly focused on just memories in the past, although it does 
support more options for D-STAR.

The Kenwood radios are really a lot easier to do than the other types, 
so I wouldn't be opposed to starting down that road on some of those. 
The only problem is that I have a D700 in my car, but that's my only 
one, so it's not very convenient for development.

> Have you chatted with the author of the VX commander software? It seems
> like he's been busy for a long time and he might be willing to send you
> his source code for that alpha version of the tool.

I haven't, but other people have reportedly solicited some input from 
him and have not been very pleased with the results.

> Regardless, I'd be
> willing to work with you on this one if you want (if that works for how
> you develop things) and, if it came down to it, I could loan you my VX5.

Your call.  I'd be glad to do the work and get it back to you if you 
want to send it.  I'm able to reverse engineer most radios in about 48 
hours (wall clock time) depending on what else I have going on.

> Oh.. interesting and thanks for setting me strait. There has to be a way
> to make a change to the GUI that would maybe give a pop-up about this fact.

Well, I could.  It used to be that the live radios were treated a little 
differently in the UI than the clone types, and it generated confusion 
for a lot of people.  Moving to a more unified approach has made it a 
lot easier to use.  Maybe a "FYI this is live" pop-up with a "don't show 
me this again" checkbox would be appropriate.

> - When a radio's data is downloaded, load it's data into the table but
> have say the first column naming which radio it came from
>
> - When the next radio's data is downloaded, merge that into the table.
> If a given row is identical from both radios, change the 1st row cell's
> name to reflect both radios
> - If a given row (memory slot) are different (conflict), add an
> additional row reflecting the 2nd radio's name, it's data, and maybe put
> it in a different color
> - alternatively, maybe these radios have a unique ID like a serial
> number, user setable name, etc. so use that
>
> - offer a pulldown for this conflict row and ideally REMEMBER this
> decision (maybe this remembering would be more troublesome than what
> it's worth):
> - override the master row
> - move to memory slot: ### (drag and drop would be slick but that might
> be hard in Python)
> - keep unique to this radio
> - delete

Feel free to document the above in a tracker item to (a) remind me and 
(b) preserve it for when we get there.  You can do that here:

   http://trac.chirp.danplanet.com

Thanks!

-- 
Dan Smith
www.danplanet.com
KK7DS