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!