FWIW, if you do go down the route of a file based method, I suspect that you would be better off with an open/export option rather than trying to pretend that a file is a serial port in the upload/download functions (I would just have those function spit out a warning).

This would be a useful template for other radios as well. E.g. the KU-UV8D plus has an encrypted serial protocol that I have not yet been able to crack, but the data file itself is not encrypted.

________________________________ From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com on behalf of NNN Wx via chirp_devel chirp_devel@intrepid.danplanet.com Sent: Sunday, May 28, 2017 7:26:43 PM To: Angus Ainslie Cc: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] FT2D

Thanks for the prompt reply.

*sigh* OK. I’ll try to start. I’ve been reading the instructions. I’ve already dumped the microSD-based file (“BACKUP.DAT”) and have some inkling of at least the gross features of memory format.

The Yaesu-supplied ADMS-8 software can build files, so I don’t need to have the radio in the loop all the time. I suspect it possible to get a basic memory map within a shortish time. I’ll try to compare and contrast the FT1 based upon the template in the source code. I’m so new to the VHF world that I don’t understand most of the options that are accessible to the programmable capability, so it’ll probably only be a beginning.

Unfortunately for me, the FT2D data connection has been impossible to use. I believe that the FT2D uses a straight USB cable with an internal UART-to-USB connection, and no driver I’ve tried allows serial ports to connect to the radio. I conjecture that multiple serial ports* are multiplexed over the same USB) I am able to move the BACKUP.dat file between radio and computer by using the microSD card. So a sine qua non for me to use chirp for now is to be able to send the erstwhile serial data to and from a file. Having scanned the template, I’m guessing that do_upload(radio) and do_download(radio) will need to support file-based rather than serial I/O based. That may be A Big Deal for chirp.

* microphone/speaker/camera, memory programming, and software update all seem to be included. The FT2D has a separate microphone/speaker connector, but the USB connector takes priority: completing a USB connection stops the audio to internal or external speaker.

On May 28, 2017, at 18:20, Angus Ainslie <angus@akkea.camailto:angus@akkea.ca> wrote: <snip>

I'm pretty sure no one has done significant work on the FT2D.

I did do a lot of work on the FT1D and I'm assuming it's not that different. Unfortunately I don't have a FT2D to work with.

With the origiinal FT1D driver it was hundreds ( it not thousands ) of memory dumps to get the correct offsets for the settings.

Angus

Adding to my fun, I’ve skimmed the FT1D user manual, and the FT1D has the same feature as the FT2D: The radio can put “preset frequencies” into memory banks. See p 52 “Registering Your Favorite Preset Receiver Memory Channels in Memory Bank”. If somebody with an FT1D could follow those directions and enter a preset into a memory bank, I’ll bet that chirp misbehaves in the same way after reading in the image from the radio, and one should be able to use chirp’s Browser to see the following values in “channel” (clearly, taken from my FT2D):

0x0000 is memory Location 1 0x0001 is memory Location 2 … [no surprises here]

0x1800 is channel 1 of the "WX Channel Frequency List” 0x1801 is channel 2 of the "WX Channel Frequency List” ... 0x2800 is channel 1 of the “International VHF Marine frequencies” 0x4000 is channel 1 of the “Worldwide short wave broadcast”

Such high values of “channel" cause chirp to emit an error when assigning memory locations to banks in the Banks tab of the UI, and those values will be encountered if they have been manually entered into the FT2D and then read into chirp (and, I presume from the FT-1D as well.) If the values occur, the bank with an offending location cannot be further set (or unset); the error always happens. Unaffected banks can still be manipulated correctly.

It looks to me as if a “channel” (one of 100) in the FT1D (and FT2D) memory map* for “bank_menbers” array should be interpreted as a structure of its own: 1 bit unknown (0xFFFF is designates an unused channel in FT2D; I’d guess 1=unused, 0=used may suffice) 1 bit for SW presets 1 bit for Int VHF presets 1 bit for WX presets 1 bit unknown (perhaps 1=FM, 0=AM?) 11 bits of channel number (allows up to 2047 memory locations; FT2D uses only 999 so there might be yet another bit of flags and one fewer for number.)

Heaven only knows if or how the radio would handle having multiple “presets" bits set in one channel. If chirp were to handle these bits, it’d probably be polite to include logic that prevents that from being saved (“toggle bits” as it were.)

So, I ask in decreasing order of importance: What’s the “correct” way to restructure the FT1D (and thus FT2D) memory model* to include 100 channels per bank as an array of u16 (present situation) but with an internal flag structure in each one? I’m not quite sure how chirp handles “channels” in its own virtual model; I presume it just use the u16 as two bytes without any modifications and it’d be up to the driver to interpret them. I have temporarily prevented the error from occurring by changing the FT1D.py to use “channel & 0x7FF” wherever “channel” is used in most places (but not while checking for 0xFFFF.) I’ve added no functionality for interpreting the flag bits, and I’ve not changed the memory model.

What’s the “correct” way to display such a structure in the Banks tab of the UI? At present, one cannot even use chirp to see that these fields are set. It might be useful to postpend lines to the columnar display when presets exist (e.g. "WX #1…. checkmark:, "int VHF #5… checkmarks”, “SW #25…. checkmarks”) I don’t think we have access to the actual frequencies involved so they cannot be displayed. ATM, FT2D and chirp always cause these high-flagged channels to exist at the END of the Banks listing.

What’s a “correct” way to SET or UNSET such a structure using the Banks UI? If they were displayed as above, the checkboxes would presumably be active just as they are in the rest of the UI. That’d make them easy to UNSET: just uncheck the corresponding box. I don’t have a good suggestion for SET; it’d be unwieldy to add ALL the possible presets as “high locations”, but more interactive options would require UI changes. Is this a place for “Special Channels” in the Memories tab?

* I have no Idea what the FTM-3200D or other radios subordinate to FT1D does with banks and preset frequencies; a change to the FT1D memory model might break the FTM-3200D. But if the FTM-3200D is working fine with the u16 channel and doesn’t have more than 2047 memories, it should be just fine.

Declan Rieb WD5EQY

[Was just cleaning out some old list mail and came across this.]

Thanks for working on this.   FWIW, This feature of preset channels goes back to at least the VX-8 and probably earlier.   A long, long time ago, The initial banks implementation in chirp crashed when loading my VX-8's image because it contained preset channels in one of the banks.

I did a little reverse engineering and what you discovered looks familiar.  I have to see if I can find my notes.  I eventually gave up because I realized it would need a decent bit of work to make chirp handle this especially in the UI for working on the banks.

(I was only scanning a handful of the Marine special/preset changes, so I just added those to the 900 regular memories and problem solved.  I also eventually got Uniden scanner which pretty much ended any scanning/monitoring I was doing with the VX-8.)

--Rob

On 9/20/2017 7:02 AM, NNN Wx via chirp_devel wrote:

Adding to my fun, I’ve skimmed the FT1D user manual, and the FT1D has the same feature as the FT2D: The radio can put “preset frequencies” into memory banks. See p 52 “Registering Your Favorite Preset Receiver Memory Channels in Memory Bank”. If somebody with an FT1D could follow those directions and enter a preset into a memory bank, I’ll bet that chirp misbehaves in the same way after reading in the image from the radio, and one should be able to use chirp’s Browser to see the following values in “channel” (clearly, taken from my FT2D):

0x0000 is memory Location 1 0x0001 is memory Location 2 … [no surprises here]

0x1800 is channel 1 of the "WX Channel Frequency List” 0x1801 is channel 2 of the "WX Channel Frequency List” ... 0x2800 is channel 1 of the “International VHF Marine frequencies” 0x4000 is channel 1 of the “Worldwide short wave broadcast”

Such high values of “channel" cause chirp to emit an error when assigning memory locations to banks in the Banks tab of the UI, and those values _will_ be encountered if they have been manually entered into the FT2D and then read into chirp (and, I presume from the FT-1D as well.) If the values occur, the bank with an offending location cannot be further set (or unset); the error always happens. Unaffected banks can still be manipulated correctly.

It looks to me as if a “channel” (one of 100) in the FT1D (and FT2D) memory map* for “bank_menbers” array should be interpreted as a structure of its own: 1 bit unknown (0xFFFF is designates an unused channel in FT2D; I’d guess 1=unused, 0=used may suffice) 1 bit for SW presets 1 bit for Int VHF presets 1 bit for WX presets 1 bit unknown (perhaps 1=FM, 0=AM?) 11 bits of channel number (allows up to 2047 memory locations; FT2D uses only 999 so there might be yet another bit of flags and one fewer for number.)

Heaven only knows if or how the radio would handle having multiple “presets" bits set in one channel. If chirp were to handle these bits, it’d probably be polite to include logic that prevents that from being saved (“toggle bits” as it were.)

So, I ask in decreasing order of importance: What’s the “correct” way to restructure the FT1D (and thus FT2D) memory model* to include 100 channels per bank as an array of u16 (present situation) but with an internal flag structure in each one? I’m not quite sure how chirp handles “channels” in its own virtual model; I presume it just use the u16 as two bytes without any modifications and it’d be up to the driver to interpret them. I have _temporarily_ prevented the error from occurring by changing the FT1D.py to use “channel & 0x7FF” wherever “channel” is used in most places (but not while checking for 0xFFFF.) I’ve added no functionality for interpreting the flag bits, and I’ve not changed the memory model.

What’s the “correct” way to display such a structure in the Banks tab of the UI? At present, one cannot even use chirp to see that these fields are set. It might be useful to postpend lines to the columnar display when presets exist (e.g. "WX #1…. checkmark:, "int VHF #5… checkmarks”, “SW #25…. checkmarks”) I don’t think we have access to the actual frequencies involved so they cannot be displayed. ATM, FT2D and chirp always cause these high-flagged channels to exist at the END of the Banks listing.

What’s a “correct” way to SET or UNSET such a structure using the Banks UI? If they were displayed as above, the checkboxes would presumably be active just as they are in the rest of the UI. That’d make them easy to UNSET: just uncheck the corresponding box. I don’t have a good suggestion for SET; it’d be unwieldy to add ALL the possible presets as “high locations”, but more interactive options would require UI changes. Is this a place for “Special Channels” in the Memories tab?

• I have no Idea what the FTM-3200D or other radios subordinate to FT1D does with banks and preset frequencies; a change to the FT1D memory model might break the FTM-3200D. But if the FTM-3200D is working fine with the u16 channel and doesn’t have more than 2047 memories, it should be just fine.

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