CHIRP

Frequencies originally programmed on the receiver, then downloaded to chirp, modified on chirp and uploaded back work fine!

Michael,
Why don't you make a .img file with two memories. Both the same except 1 created in CHIRP and 1 created in the radio. Then add it to this issue so someone can take a look at it to see what might be different between the two.

Also double check them in the radio to make sure one is right and one is wrong. And finally, let us know which is which.
Jim KC9HI

I can confirm this, and it still occurs with the latest update. I found it happening on frequencies with a - (negative) offset. When transmitting it is off frequency, I think around 6hz. I thought it was a radio problem and sent it back to Yaesu twice. They eventually figured out it was the memory channel(s).

Chirp daily-20151023 on MacOS

As requested over a year ago, please provide a CHIRP Radio Image file with a minimum of 2 channels, both of the same intended frequency.

Channel 1: a CHIRP programmed channel that is off frequency
Channel 2: a manually programmed channel that is on frequency

Attach this image to the issue along with a note to explain which is which.

Hopefully, then, a CHIRP developer can look at the image to see what is different between the two channels and come up with a solution to correct it. Without this assistance by the radio owners, there isn't much chance of this being corrected (the CHIRP developers don't have free access to every radio that CHIRP supports).

Jim KC9HI

David Berten wrote:

I've attached a file from my CHIRP. Channel 8 is good, Channel 48 has the issue.

It has a lot of other channels in that file. Let me know if you need a file with only two channels.

I can't get this image file to load onto my radio. Chirp fails with a "Failed to communicate with the radio: Radio did not ack block 1" error when I try to send it to my radio.

I did some testing with my VX-8DR on all four bands and all the frequencies I tested (memory and VFO) were pretty much bang on with what was displayed on my HT.

That's the problem, it is bang on, it shows up correctly on the Chirp software and on the VX-8DR itself. Somehow behind the scenes, the radio when it transmits, is off frequency. This was verified at Yaesu using a frequency counter. I am using MacOS. I was able to open the .img file again to verify that it opens and is working.

David,

Is channel 8 the only channel that is working? Or are all of them except 48 working?

Jim KC9HI

Hi Jim, Channel 8 is the only channel that was programmed from the VX-8DR keypad. Channel 8 works with no distortion. All other channels were programmed using Chrip, including 48. I added 48 so you could compare it to 8. They are both the same frequency, tone, etc. 48 distorts my audio, 8 doesn't. As for all the other channels they may only serve as confusion. However, I have experienced issues with other channels on 2m with a negative offset.
David

I was able to load that file, but testing it will be difficult. I've been dealing with this for many months. People have been very nice helping me out, but I feel like I am pushing my luck. I think if your file works it only determines if it's my cable. I know for certain that if I program the radio with the keypad there is not distortion. Since you've been helping me I've switched over to Chirp on a PC. So far so good, but have not done extensive testing. I'm going to include a file in the next post that was programmed with the Chrip on Mac OS and I know for certain has issues. I'll also include a file from the PC, that was programmed with the radio keypad then uploaded to Chrip which is a good file.

David,

There is a difference in the way CHIRP programs a VX-8DR radio channel and the way it is programmed using the keypad. I think I narrowed it down to 3 bytes.

I changed the first few channels so that you could help me determine which differences are the ones that really affect the TX frequency. Since I don't have a radio here that I can test with, I must depend on someone that has one to do the testing. Without the cooperation of someone with a VX-8DR to do the testing, there isn't much that can be done.

I could program a simplex channel multiple times with the different variations. Surly you can find someone that can listen to 7 or 8 transmissions and tell you which sound OK and which ones don't. Or maybe you can borrow a frequency counter.

Jim KC9HI

Hi Jim, I can only reach repeaters on channels 2,5,7 & 8. Which ones do you want me to test?

Jim, I loaded the image from my Mac and tested 2-6. All of the channels seemed okay except 5. We spent a bit of time on 6 it was said it seemed a bit noisy, but it did seem okay. Does that shed any light on the matter?

I would have expected 3, 4 and 5 to still have issues and 2 and 6 would be OK. Hmmm.

Jim

Jim, I had someone new to radio helping me test. So, I'm not sure I got the best feedback. I could try again.

Hi. I can confirm that I am having the same problem with Windows 10, Chirp (version: Sunday, ‎January ‎15, ‎2017, ‏‎3:10:30 AM) on a Yaesu VX-8DR. On multiple repeaters I am told that I am off frequency. I enter the value in the VFO and I am fine. I enter it in Chirp and sync and I am off. Thanks for an otherwise amazing piece of software.

Hello,

I encountered this bug on my Yaesu VX8-DR after using the MacOS version of Chirp (daily-20170714) to program my new radio. Veteran operators local repeaters reported me as sounding like I was "off frequency". The solution was for me to factory reset my radio and program manually.

I'd like to assist the developers in tracking this down, so feel free to reach out for image files or other information.

Regards,
Bill Moldt

BTW, it's easy to observe the slow frequency using "gqrx" with a $20 software defined radio. You can see the spectrum, put a line on the desired frequency, then transmit with the broken Yaesu. The peak is well to the left of the line by 5Khz. Using RT-Systems software to program the repeater, or using the radio front panel puts the peak right on the line as expected. It's truly bizarre that the "displayed" frequency on the radio is not the actual transmitted frequency.

Wow, just seeing this bug as well. Filed basically a duplicate. The issue has been around 3 years? That is depressing, as a fix is unlikely :(

I just observed the same problem with RT Systems software, so its not just chirp. factory reset, load older backup, hope its okay. If you use any software to program your ft1d, verify frequencies afterwards. a $20 sdr radio for your pc and gqrx app will show you which frequencies are off by as much as 5Khz. test your radio before you need it for safety.

Dan, thanks very much for your quick response! I'm willing to carry out any test which would help the cause. I will do some further digging on my side. I can also loan out my radio if that helps.

The one thing I can add right now is that the problem is reproduceable. I can factory-reset the radio and then program the VFO and transfer it to memory, and things work fine. I can then factory-reset the radio, download the (seemingly) empty channel list, import the one-liner for channel 4, send that back to the radio, and things don't work. So it looks like we will have to concentrate on what else besides the channels is uploaded from and downloaded to the radio, and when these things change.

Next test should probably be to simply retrieve a stored-from-VFO memory and program it back into the radio as it was.

73
Bernhard AE6YN

Ok, I took this puzzle as an incentive to finally dig into Chirp's code (something I wanted to start for a long time).

When I diff the memory, there's one thing which jumps into my eye. In bad images (e.g. "after_CSV_import"), the memory positions 0x0664, 0x068C, 0x06E4, 0x070C, and 0x174C each contain three peculiar bytes (hexadecimal!) "14 40 00". In good images (e.g. "VFO_to_ch4"), they are "14 52 30". Looks like the (decimal) frequency which is supposed to be for my channel (145.230 MHz). 144.000 is the default in this radio. ...

The first few memory locations are just VFO frequencies in BCD, so, no surprise here: these are correctly mapped in the code for the VX-8. However, the one in 0x174C falls into a region which isn't mapped out (unless I missed something). This region contains 24 groups of 32 bytes each, beginning at 0x150A and ending on 0x1809. At first glance, the order of the bytes seems to be:

4 bytes BCD (a frequency)
2 bytes (possibly always 0, but need investigation)
16 bytes (possibly always 0xFF, need investigation)
10 bytes (variable values, need investigation)

Does anyone have input on this?

Fix applied, available in today's build.