[chirp_devel] Candidate Yaesu FT2D driver

[NNN Wx]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170625/0c897b95/attachment-0003.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft2d.py
Type: text/x-python-script
Size: 2981 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170625/0c897b95/attachment-0001.bin 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170625/0c897b95/attachment-0004.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Yaesu_FT2D_R.img
Type: application/octet-stream
Size: 130507 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170625/0c897b95/attachment-0001.img 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170625/0c897b95/attachment-0005.html