CHIRP

[Uploaded from CHIRP next-20250509]

So, I was not able to reproduce this with an FT3DR (which is the exact same driver and memory map, but obviously some internal differences in the radio itself).

That said, I did find one "unknown" bit that changed when I programmed a channel with chirp vs. the radio itself. This doesn't seem to have any effect on my FT3DR, but it's similar to the one from the vx8 example you dug up. Please try the attached module using LoadingTestModules. You need write a new memory with chirp for this to take effect (or edit a current one in some meaningful way). Just using this to upload won't be enough.

If it doesn't work, please attach an image with two identical memories, one written with chirp and one from the radio itself so I can see if the FT1D is setting other unknown bits.

Also, note that most Yaesu radios (very unfortunately) including this one don't really wipe much when you do a "reset". All your old channels are still in the memory of the radio, just marked as deleted. It makes it very difficult to ever get a clean slate with these. One of the many reasons I avoid them when possible :/

OK, I got to try the uploading process again, with the test module running. Unfortunately seems to be the same results as before. I tried 3 uploads in a row:

1. I started with my saved CHIRP file from last time, added a couple memories in CHIRP, and uploaded it to the radio
2. I did a radio reset, then uploaded the same CHIRP file to the radio
3. I added a couple more memories in CHIRP, and uploaded the file to radio

I will upload the image with the two identical memories as requested soon...

OK, I ran a series of radio downloads and uploads, and captured an image at 4 different stages. (Image files are named numerically to keep them in order.)

Yaesu_FT-1D_01_reset.img
Yaesu_FT-1D_02_radio_programmed_mem1.img
Yaesu_FT-1D_03_CHIRP_programmed_mem2.img
Yaesu_FT-1D_04_CHIRP_programmed_round_trip.img

Please, if we need to do this again, don't zip up the images. It makes a lot of work for me to grab them out compared to bare attachments. I know the log was too big and had to be zipped, but no need to do that for images.

Also, image 4 is not necessary and image 1 is not important either. As I mentioned, the radio doesn't actually reset anything so the image isn't actually clean like you might think. Yaesus are terrible at that.

There are a number of differences between your radio-saved channel and the chirp one. Attached is a new module to try which makes one of those changes that looks more obvious. Please try and report back. Same rules apply, it only affects newly created or edited memories - an upload is not enough.

Our of curiosity, could you try the attached image?

I looked at Yaesu_FT-1D_03_CHIRP_programmed_mem2.img, and there are some unknown settings being set in memory 2 (CHIRP config) that aren't set in memory 1 (radio config).

Specifically, the first byte contains things such as clock_shift. It looks like a good target to experiment with.

  u8 unknown0:2,
     mode_alt:1,  // mode for FTM-3200D
     clock_shift:1,
     unknown1:4;

I've manually set that byte to 00 in Yaesu_FT-1D_03_CHIRP_programmed_mem2.img:

Could you try memory 2, to see if it makes a difference?

Hi Dan,

I don't have this exact radio to test my change, no. I did try to be as thorough as possible, however, before suggesting this.

Here was my process:

• I compared the two files provided by Leigh (Yaesu_FT-1D_02_radio_programmed_mem1.img vs Yaesu_FT-1D_02_radio_programmed_mem2.img)

There are two differences:

• Memory 2 goes from used=0;valid=0 (byte==00h) to used=1;valid=1 (byte==03h) at address 0x280B in struct flagslot flag[]
• Memory configuration 2 is changed at addresses starting at 0x2D6A (32 bytes per memory configuration)

In Yaesu_FT-1D_02_radio_programmed_mem2.img, I compared memory configurations 1 (programmed via radio) and 2 (programmed via CHIRP):

Radio (memory 1) - 0000 1465 80c0 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0006 000c 000d 0018
CHIRP (memory 2) - 0500 1465 80c0 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0000 0008 0000 0000
                   ^                                                             ^    ^    ^    ^

I then decompiled FT1D_ADMS-6_EXP.zip from Yaesu's web site, and analyzed the code pertaining to the memory configuration set by CHIRP. The values set by CHIRP that differ from what the radio sets are:

- Byte 0 (00h vs 05h): bit 0-1 are for RecvRefFreq, bits 2-3 are for SendRefFreq, bit 4 is for ClkSeft, bit 5 is HalfDev
- Byte 25 (06h vs 00h): middle byte of BCD SeftSendFreq
- Byte 27 (0Dh vs 00h): ToneFreq
- Byte 29 (0Dh vs 00h): bits 0-4 are for PRFreq and bit 5-7 are for DcsCodeRev
- Byte 31 (18h vs 00h): bits 0-2 are for Bell, bit 5 is for Att, bit 7 is for RadioRecv

Since Byte 0 is set to 0 by the radio (in memory configuration 1), and to whatever was in the memory by CHIRP (in memory configuration 2), it seemed like trying to set it to 0 (setting SendRefFreq and RecvRefFreq to 0 like the radio does) would be reasonable.

Since you have way more experience then I do when it comes to these radios, I will follow your advice and take down the test file. Maybe somebody down the line can do something with this analysis.