I’m able to get the FT-1D, FT2D and I think FT-3D to read Yaesu’s SD-card format. [Only the FT2D is for sure tested.) I’m not really confident in the ability to correctly write such a file, so I’ve marked it as readonly=True in the directory. Since the Yaesu manual gives directions for writing an SD-card but not for the Adms programmer, it makes sense to me to be able to at least read such a card. A new user can save original state and memories without having to resort to a serial cable (that does NOT come with the radio by default.) The Yaesu Adms formats (.ft1d, .ft2d, .ft3d) are already handled by CHIRP.
My “difficulty” is twofold: Yaesu by default writes a file on the SD-card called BACKUP.DAT (at least for FT2D) The file does not have (AFAICT) any explicit identifier indicating which type of radio was used.
So, I’ve set the drivers to use filetypes .sdc1, .sdc2 and .sdc3. To make that work, the user will need to rename the file or copy it to a file with an appropriate filetype to use it with CHIRP. These new filetypes are described as “[radio] sdcard” in the open dialog
Is there any reasonable way to give help to users by describing the process inside CHIRP? I’m thinking pop-up context-sensitive box. Or even to apprise them of the new capability?
______ Declan Rieb WD5EQY wd5eqy@arrl.net
My “difficulty” is twofold: Yaesu by default writes a file on the SD-card called BACKUP.DAT (at least for FT2D) The file does not have (AFAICT) any explicit identifier indicating which type of radio was used.
So, I’ve set the drivers to use filetypes .sdc1, .sdc2 and .sdc3. To make that work, the user will need to rename the file or copy it to a file with an appropriate filetype to use it with CHIRP. These new filetypes are described as “[radio] sdcard” in the open dialog
Where are the .sdcX names coming from? Is that some convention you made up or is that used elsewhere?
Either way, I think it's likely to be confusing to the users. Why not just register a format of "Yaesu FT-1 SD card backup (*.dat)" (etc) and just have each of your drivers be able to handle those?
Is there any reasonable way to give help to users by describing the process inside CHIRP? I’m thinking pop-up context-sensitive box. Or even to apprise them of the new capability?
I can't think of how this could possibly work. I open a vanilla CHIRP, go to file->open and go looking for my file. CHIRP has no idea what radio you have on your mind, so it can't really do anything like this in a radio-specific manner.
--Dan
participants (2)
-
Dan Smith -
Declan Rieb