The call sign thing is Fusion. It is kind of like building a node on the Internet. I suspect that like in D-Star the configuration and data are on the cloud somewhere under the callsign identifier. That makes me wonder about data access. Think of the radio as a dedicated terminal on a main frame.
My 2 cents
David KG7ZMX
On Jun 27, 2017 5:49 AM, "Angus Ainslie via chirp_devel" < chirp_devel@intrepid.danplanet.com> wrote:
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@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers