[chirp_devel] Candidate Yaesu FT2D driver

[Angus Ainslie]

Hi Declan,

The patch looks reasonable to me but I have no way to test it. You 
should submit a patch according to these guidelines.

http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess

Hopefully there is another user with and FT2D that can do some testing 
for you.

Angus

On 2017-06-25 19:39, NNN Wx via chirp_devel wrote:
> I’d love a second set of eyes on this. It turns out the FT2DR is
> almost identical to the FT1D except for for character coding. Thanks
> to Angus Ainslie (FT1D) and Wade Simmons (FTM3200D) for their work and
> help.
> 
> I’m not a python expert, but there wasn’t much to do in the end,
> so there’s probably no damage from my processing.
> 
> I’m not a mercurial anything. I tried to build a patch, but it
> doesn’t seem to handle a de-novo file at all (EVERYTHING on the
> chirp-developers site seems to describe changing an existing file.
> Ain’t none, ’til now.) So I built a candidate patch description,
> and am attaching the actual new files. Somebody may need to walk me
> through building a correct hg patch for a new file; I know I’ll need
> to attach the image to a formal-submission email anyway, so this may
> just be an OK format for a first file.
> 
> I’m not a Yaesu expert:
> - I’ve reset my radio several times and it always leaves some APRS
> detritus behind. So the test image has Albuqerque-centric APRS logs in
> it.
> - The radio insists that the user enter a callsign before it can CLONE
> or read or write a microSD card. So the image has my callsign.
> - Furthermore, I don’t know much about the useful settings of the
> radio, so I don’t know what interesting parameters might be bogus in
> the FT1D format. My spot checks make ‘em look quite OK in chirp!
> 
> The chirp tests that I ran work for all other systems (well, I only
> ADDED one file into the drivers directory, so nothing else SHOULD have
> broken.) Of course the tests work with mine (since mine is the
> prototype image for now.)
> 
> I’ve looked enough at the microSD card “BACKUP.dat” and the
> chirp .img file to believe that they’re almost exactly the same
> format: mostly just memory map. chirp may be adding a sixteen-byte
> header that includes the chirp model number and other data. chirp
> doesn’t seem to have any obvious file-format conversion capability
> that one can automagically call to prepend or remove such headers. My
> guess is that adding microSD card support will be straightforward but
> will require modifying the underlying chirp code, and not just
> fiddling with the driver. I might be able to rig up a unix script or
> code to do that. (actually I thought I’d HAVE to do that, since it
> took forever for me to get the correct cable and get my Macintosh to
> work with it.) I suppose an external script could handle it. But first
> things first: here’s a
> 
> CANDIDATE FT2D DRIVER PATCH: Add the attached ft2d.py file to
> chirp/drivers.
> 
> # HG changeset patch
> # User Declan Rieb <nthreewx at gmail.com>
> # Date 1498434406 21600
> #      Sun Jun 25 17:46:46 2017 -0600
> # Node ID 781f31ea27002a2e473d4f5783891e6c939aab4c
> # Parent  c845633cb641f05ac4323d36c913bc1f20d47bf6
> [ft2d] New driver for Yaesu FT2DR. #3257 #3325 #3887
> Same model as FT1D (and thus a clone of FT1D) except for character
> handling as in FTM3200D.
> 
> 
> Declan Rieb WD5EQY
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: 
> http://chirp.danplanet.com/projects/chirp/wiki/Developers