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

[David Ranch]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20110205/0c2ca01c/attachment.html