<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">(Questions marked with ***)</div><div class=""><br class=""></div><div class=""><div class="">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 <a href="http://USB.org" class="">USB.org</a>. 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. </div><div class="">*** 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.</div><div class="">*** 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”?</div><div class=""><br class=""></div><div class="">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.</div><div class="">*** Has anybody already looked at or roughed in a radio-format Import/export capability for chirp?</div><div class=""><br class=""></div><div class="">One other USB “weirdness” is that plugging in <u class="">any</u> 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.</div><div class=""><br class=""></div><div class="">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.</div><div class="">*** Is Another Yaesu product using a similar memory definition (perhaps the 400?)</div><div class=""><br class=""></div><div class="">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”!</div></div></body></html>