Bug #11976
openFrequencies programmed with chirp have frequency offset in TX
0%
Description
I was programming a Yaesu FT1DR HT with CHIRP. I had just done a “microprocessor reset” on the HT, clearing all memories, so this was “starting from scratch”.
I expected the HT to transmit on the frequencies that I programmed it for.
Instead, several of the frequencies are transmitting on frequencies lower than I had programmed it for, as measured on an SDR waterfall (which has been tested to be accurate with several other sources).
Dial Mhz Measured Mhz Error, kHz¶
146.520 146.519 -1
146.580 146.575 -5
147.480 147.475 -5
147.560 147.556 -4
An error of 5kHz is enough to severely impact readability. It imparts a rough distortion quality to the audio.
If I set the frequency directly on the HT in VFO mode, it transmits accurately on the set frequency. I can also program memories using the HT's own interface, and it transmits accurately on them. It's only when setting frequencies in CHIRP and uploading them to the radio that it transmits off-frequency.
See also issue: https://chirpmyradio.com/issues/1735
Bug #1735 was for the Yaesu VX-8, and it seems to be fixed now. But during troubleshooting, I also checked the frequencies that I had programmed into a VX-8 about 10 years ago with CHIRP (so, before bug #1735 had been fixed), and they had IDENTICAL frequency errors to what the FT1DR is showing. So it may be a similar underlying issue.
Files
Updated by Leigh Marble 8 days ago
- File config.txt config.txt added
- File Yaesu_FT-1D_blank_test_new_entries.img Yaesu_FT-1D_blank_test_new_entries.img added
- File macos_system_info.txt macos_system_info.txt added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20250509]
Updated by Dan Smith 8 days ago
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 :/
Updated by Leigh Marble 6 days ago
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:
- I started with my saved CHIRP file from last time, added a couple memories in CHIRP, and uploaded it to the radio
- I did a radio reset, then uploaded the same CHIRP file to the radio
- 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...
Updated by Leigh Marble 6 days ago
Dan Smith wrote in #note-2:
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.
When creating this CHIRP image, should I have the Test Module loaded?
Updated by Leigh Marble 5 days ago
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
| Stage | Desc |
|---|---|
| 01 | Did a "microprocessor reset" on the radio, and downloaded to CHIRP |
| 02 | Saved memory 1 on the radio (overwrote the default memory 1), and downloaded to CHIRP |
| 03 | Added memory 2 in CHIRP, with identical frequency as memory 1 |
| 04 | Uploaded the two-memory image to radio, and then downloaded back to CHIRP |
Updated by Leigh Marble 5 days ago
PS: And when all that capturing of images was done, I verified again that the radio-programmed memory was transmitting correctly at 146.580, while the CHIRP-programmed memory was transmitting at 146.575, even though the radio display shows 146.580.
Updated by Dan Smith 5 days ago
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.