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