[chirp_devel] Yaesu FT2D questions and comments

[NNN Wx]

(Questions marked with ***)

I’ve had absolutely no luck communicating with FT2D via the USB, not even while running Windoze on my Macintosh. The 0x26aa/0001 VID/PID are not registered with USB.org. I conclude that that Yaesu are either encrypting the communications, or that the “special drivers” needed for the FT2D are jiggered to match the VID/PID. I tried doing that jiggering by hand to drivers and failed to get any serial access. I cannot find a Prolific-supplied chip that might support the microphone/speaker/camera as well as firmware update and memory access . That functionality would presumably need a Quad UART (or I2S and UART) to be multiplexed onto the USB. 
*** Has anybody looked inside an FT2D to identify the chip that is being used to connect to USB? FTDI and SiLabs market chips that would fill the bill.
*** I don’t think the “clone” function is required to read or write, since the ADMS-8 software doesn’t mention it. Anybody successfully connected to FT2D without “clone”?

Since serial communications won’t work (yet?) I’ve proven that I can get the microSD card to carry information betwixt FT2D and my computer. And I can use the Yaesu-supplied ADMS-8 software to “program” the file on the card. So I don’t need memory dumps from the radio directly, at least while doing mapping. But it’s been suggested that chirp could use an import/export capability, using data in the actual radio format, rather than a chirp-interpreted memory.
*** Has anybody already looked at or roughed in a radio-format Import/export capability for chirp?

One other USB “weirdness” is that plugging in any active USB disconnects both the builtin speaker/mike and any plugin speaker/mike. The FT2D doesn’t even check to see if there’s a microphone/speaker connected to the USB port before disabling the others.

I have started trying to reverse engineer the FT2D BACKUP.DAT file, which I presume is a memory dump. At the moment I'm concentrating on just the repeater-memory fields, rather than the APRS or other general settings. From reading the FT1D source code, I’m not confident that there’s really all that much similarity to the FT2D, except perhaps for Yaesu’s penchant for 0xFF-filling text fields.
*** Is Another Yaesu product using a similar memory definition (perhaps the 400?)

It’s disconcerting that a full-reset FT2D (power-on-BACK-DISP-BAND) seems to keep all of its memories intact except for the memory map and maybe the first memory slot. At least that’s the case as evidenced by a reformatted microSD card being written from a reset FT2D: It contained almost all of my hand-inserted memory locations AND APRS data, although ADMS-8 honors that memory map and only displays the first memory slot. It’s fortunate for Yaesu that nobody keeps truly private information on the FT2D; reading a backup microSD card provides almost all the information even after a “full reset”!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20170603/e153b8df/attachment-0001.html