Hello Dan, Thanks for the reply and see inline..

Unfortunately, I don't have an F6A and had to borrow one to write the
driver.  Can you send me the output that CHIRP generates after trying to
set a memory name so I can see if something obvious is breaking?

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?

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

Yep, neither of these are supported yet, although I have a D710 on loan
right now so support will come for that very soon.  I don't have a VX5,
nor do I know of anyone that has one for me to borrow.  Selecting one of 
the other radio models definitely won't work, as they're all different. 
That's why the "Commander" software programs are all different for 
each model.

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.

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

You can.  The F6A is a "live" radio which makes it behave a little
different (it communicates with the radio in real-time and does not
download an image).  Any changes you make in the editor go back to the
radio immediately.  That's why there is no "upload" option and no "save"
option, because it's manipulating the radio directly.

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.

That's doable, but wouldn't be very high on my list of priorities at the
moment.  I'll be glad to keep it in the back of my mind going forward

Thanks for considering it! I do understand that this can be manually done and that might be the best method. I do have some ideas of how the UI would function though if you do ever get to it:

- 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

The reason for the "keep unique to this radio" would be say on my two D710s, one has an APRS SSID of "KI6ZHD" and another that has "KI6ZHD-9". If I could use this tool to merge data while keeping some settings unique would be ideal.

--David