Bug #1735

Yaesu VX-8DR - Frequencies programmed with chirp have frequency offset in TX/TR

Added by Michael Lustig about 6 years ago. Updated 6 months ago.

Status:Closed Start date:07/04/2014
Priority:High Due date:
Assignee:Bernhard Hailer % Done:

100%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:VX-8DR

Description

All the frequencies I program with chirp result in about 6KHz shift up in the actual TX/TR frequency of the HT, however the screen still shows the original frequency.
Frequencies programmed on the receiver, or VFO mode are correct.

OS: OSX
Chirp vestion 0.4.0

Yaesu from radio good channel 8.img (63.7 kB) David Berten, 10/30/2015 10:04 am

Yaesu from radio good channel 8(test).img (63.7 kB) Jim Unroe, 10/31/2015 10:33 am

yaesu vx8 backup.img - This is the bad file (63.7 kB) David Berten, 11/02/2015 01:30 pm

Yaesu programmed and uploaded.img - This is the good file (63.7 kB) David Berten, 11/02/2015 01:30 pm

Yaesu from radio good channel 8(test2).img (63.7 kB) Jim Unroe, 11/03/2015 03:44 am

chirp-64-wrong-tx-freq.img - Yaesu FT1XDR image, memory #64 transmit oscilator is 5Khz slow. (127.4 kB) ed fardos, 09/11/2017 03:36 pm

yaesu_add_priority.FT1D - Settings written by RT-Systems instead of Chirp (memory 64 works) (584.7 kB) ed fardos, 09/11/2017 03:50 pm

Yaesu_VX-8R_20180220b.img - File with problem (63.7 kB) Paul Mills, 05/13/2019 06:59 pm

Yaesu_VX-8R_20190513c.img - File with problems fixed by manual programming (63.9 kB) Paul Mills, 05/13/2019 06:59 pm

VX-8DR_ch4_Chirp.csv - Imported CSV file, channel 4 only (205 Bytes) Bernhard Hailer, 12/08/2019 08:14 pm

YAESU_VX-8DR_ch4_from_chirp.png - screenshot transmit with Chirp image (618.6 kB) Bernhard Hailer, 12/08/2019 08:14 pm

YAESU_VX-8DR_ch4_from_vfo.png - screenshot transmit with image generated manually from VFO (622.7 kB) Bernhard Hailer, 12/08/2019 08:14 pm

Yaesu_VX-8DR_chirp_redownload.img - Memory image after Chirp upload (63.9 kB) Bernhard Hailer, 12/08/2019 08:14 pm

Yaesu_VX-8DR_stored_from_vfo.img - Memory image after VFO was saved manually (63.9 kB) Bernhard Hailer, 12/08/2019 08:14 pm

Yaesu_VX-8DR_ch4.csv - CSV import file: channel 4 only. (265 Bytes) Bernhard Hailer, 12/09/2019 05:04 pm

Yaesu_VX-8DR_after_factory_reset.img - Image just after a factory reset. (63.9 kB) Bernhard Hailer, 12/09/2019 05:04 pm

Yaesu_VX-8DR_VFO_to_ch4.img - Image after 145.230 - 100.0 TSql was stored in channel 4. Works. (63.9 kB) Bernhard Hailer, 12/09/2019 05:04 pm

Yaesu_VX-8DR_VFO_to_ch4_reload.img - Loaded into chirp, restored in radio. Still works. (63.9 kB) Bernhard Hailer, 12/09/2019 05:04 pm

Yaesu_VX-8DR_after_CSV_import.img - Factory reset, import of CSV file, before sending to radio. (63.9 kB) Bernhard Hailer, 12/09/2019 05:04 pm

Yaesu_VX-8DR_after_CSV_import_reloaded.img - Same, after applied to radio and loaded into Chirp again. Bad. (63.9 kB) Bernhard Hailer, 12/09/2019 05:04 pm

VX-8DR_ch4_Chirp.csv - CSV import file (205 Bytes) Bernhard Hailer, 12/14/2019 10:12 pm

Yaesu_VX-8DR_X01_reset.img - Image fresh after factory reset (63.9 kB) Bernhard Hailer, 12/14/2019 10:12 pm

Yaesu_VX-8DR_X01_chirp.img - Image after CSV imported on factory reset (ch 4) (63.9 kB) Bernhard Hailer, 12/14/2019 10:12 pm

Yaesu_VX-8DR_X01_vfo_over_chirp.img - Image after memory of ch. 4 was overwritten from VFO (63.9 kB) Bernhard Hailer, 12/14/2019 10:12 pm

Yaesu_VX-8DR_X01_reset_again.img - A factory reset on the image of test 3 (63.9 kB) Bernhard Hailer, 12/15/2019 10:30 pm

Yaesu_VX-8DR_X01_chirp_again.img - Chirp import on reset image of test 4 (63.9 kB) Bernhard Hailer, 12/15/2019 10:30 pm


Related issues

duplicated by Bug #2959: Yaesu VX-8DR off frequency after programming Rejected 10/29/2015

Associated revisions

Revision 2836:38bfa0e7901d
Added by Tom Hayward over 3 years ago

VX8: get_raw_memory() was off by one, making #1735 difficult to troubleshoot.

Revision 3294:4e684d55c1d7
Added by Bernhard Hailer 6 months ago

[vx8] #129, #1735 (same issue): fix for incorrect channel initializations

(resubmission)

Users complained that under certain circumstances 2m repeaters with negative
offsets were not programmed correctly and resulted in a frequency offset or
even an incorrect transmit/receive mode. Both issues #129 and #1735
essentially describe that same problem for the Yaesu VX-8. I ran into the
same issue with a VX-8DR I just got - which made me dig into Chirp

Two bytes were found to be initialized differently when manually programmed,
both were marked "unknown". After a few experiments these bytes could be
(at least partially) identified. (A side product was that I found the bit
responsible for narrowband transmit - that will be used in another patch
fixing issue #1615 to enable this radio for Chirp's "NFM" mode).

Tested with a VX-8DR.

73
Bernhard AE6YN

#129
#1735

History

Updated by Michael Lustig about 6 years ago

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

Updated by Jim Unroe about 6 years ago

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

Updated by David Berten over 4 years ago

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

Updated by Jim Unroe over 4 years ago

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

Updated by David Berten over 4 years ago

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.

Updated by Eugene Mah over 4 years ago

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.

Updated by David Berten over 4 years ago

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.

Updated by Jim Unroe over 4 years ago

David,

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

Jim KC9HI

Updated by David Berten over 4 years ago

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

Updated by Jim Unroe over 4 years ago

David,
I would like to see some more "good" (programmed manually) channels. But in the mean time, upload the attached image to your radio and tell me which ones of channels 2 through 7 are now behaving.
Jim

Updated by David Berten over 4 years ago

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.

Updated by David Berten over 4 years ago

The vx8 backup has the off frequency issues on 2m with negative offsets. Possible on all repeaters too. The programmed and uploaded is the good file it has no distortion.

Updated by Jim Unroe over 4 years ago

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

Updated by David Berten over 4 years ago

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

Updated by Jim Unroe over 4 years ago

David,

Here is an image with channel 8 repeated on channels 2 through 6 but with slight variations based on the data differences I see. Get on the 146.88 repeater with it and try channels 2 through 6 and report back which ones are "fixed".

Jim

Updated by David Berten over 4 years ago

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?

Updated by Jim Unroe over 4 years ago

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

Jim

Updated by David Berten over 4 years ago

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

Updated by Jim Alyanak over 3 years ago

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.

Updated by Bill Moldt almost 3 years ago

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

Updated by Tom Hayward almost 3 years ago

  • Status changed from New to Feedback

Bill Moldt wrote:

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.

Yes, images would really help with this one! If you can provide both images--the original with the issue, and the new one programmed manually--then tell is which channel numbers in each we should compare, it should be pretty easy to spot the issue. Please also specify what details you programmed manually, so that we know what Chirp should be showing for that channel.

Updated by ed fardos almost 3 years ago

I just filed a duplicate (Bug #5145) having experienced this bug first hand on a Yaesu FT1XDR (feel free to delete).

#5145 text:

I was told I was off frequency when transmitting. I put the Yaesu FT1XDR programmed by chirp on the scope and it was slow by 5Khz on that memory location. It was slow by 1-5Khz on roughly eight other memories, and the remaining (30 or so) were on-frequency. I didn't believe it either until I put it on the scope. Chirp data exported into RT-system software via csv, radio flashed, everything worked and was on frequency. I also confirmed the fix with a signal check on the repeater.

Memory #64 in this Chirp image transmits 5Khz slow. Check with qwrx, confirm with other radios, or same radio programmed by front panel, or rt-systems:

http://craiger.org/craiger/chirp-64-wrong-tx-freq.img

Chirp daily-20170714, ubuntu 14.04
Yaesu FT1XDR

Updated by ed fardos almost 3 years ago

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.

Updated by ed fardos almost 3 years ago

channel #64 works in this image (used RT-Systems software). To be compared to the image in #23 above.

Updated by Joel S almost 3 years ago

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 :(

Updated by ed fardos over 2 years ago

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.

Updated by Paul Mills about 1 year ago

It seems to me there are several open bugs that are all similar. Also appears that this also happens on more than one model. Does not seem to bother 70 cm frequencies, but all others are a problem, amount of offset varies.

Once the frequencies are corrected, other data on channel can be changed, and does not seem to cause problems.

Hope this helps to get it resolved.

Does not appear to be OS specific.

Updated by Bernhard Hailer 7 months ago

I got a used VX-8DR and promptly ran into the same problem (CHIRP daily-20191206; Win10 or Linux - same results). Reading through this and other related posts, I started to experiment a little on my own. I programmed only one channel (no. 4) with a 2m repeater which takes negative offset (apparently, that's one of the triggers). For each experiment, I first initiated a factory reset. The programmed parameters were 145.230 MHz, negative offset, 100.0Hz TSQL.

Attached are two images, one taken after manually storing the repeater parameters from the VFO, the other after I downloaded the empty memory from the handheld, imported a CSV file with only channel 4 data in it (attached as well), deleted the first channel, and uploaded it back onto the handheld. That second image was then downloaded from the handheld again. The two images differ quite a bit.

I used an SDRPlay RSP1a with SDRuno software to see what actually happens. I attached two screenshots, they suggest that at transmit, there's more going on than just a frequency shift. At receive, there is a strong audio distortion, which suggests a frequency offset as well; however, the audio is still (barely) legible.

73
Bernhard AE6YN

Updated by Dan Smith 7 months ago

  • Chirp Version changed from 0.4.0 to daily

Bernhard, I just diff'd the memory regions of your two images for channel number 4 and they are identical. There are other changes in the file of course, so it must be related to those and not just the actual contents of the memory. That will make it rather difficult to track down.

Also, Yaesu radios of this vintage (at least) are really bad about clearing memory. When you delete something or even do a factory reset, there are whole swaths of the memory that aren't cleared but rather just ignored, which can make it very difficult to do this sort of issue reproduction.

I haven't yet worked on trying to solve (or even reproduce) this problem yet, but anything anyone can do to get the problem to pop up with as minimal change as possible between a good and bad image will help. Also, since the problem is clearly not stored in the channel part of the memory, it's almost definitely going to be a "here's a good image and here's a bad image" sort of thing, not just "channel 4 is good, channel 5 is not".

Updated by Bernhard Hailer 7 months ago

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

Updated by Bernhard Hailer 7 months ago

I've attached five new images: after a factory reset; after manually setting channel 4 (works); after re-sending that same image to the radio (still works); after manual reset and applying a CSV import for channel 4 - before sending it to the radio; and same after sending it to the radio (and that one has the problem).

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. Not sure whether that's helpful, but this doesn't look like a coincidence to me?

Updated by Bernhard Hailer 7 months ago

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?

Updated by Bernhard Hailer 7 months ago

Some more research.

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. ...

This turned out to be a wild goose chase. That area stores VFO parameters for the current band when you switch bands: here it remembers which parameters you used last time when you selected the same band. This isn't the problem.

I performed three experiments, and I believe they will show the way what's going wrong.

1) I did a factory reset on the radio and collected the image. (As Dan stated, the memory is mostly left unchanged by the reset; a lot of traces of my previous tests were left intact. It turned out to be fortunate.)

2) I imported my usual CSV file which programs 145.230 MHz, negative offset, 100Hz TSQL into channel 4 right into this freshly reset image. Observation: that import changed exactly one byte (0x2C4D, which enables channel 4 and applies a few other flags for it). Because the data from previous experiments was still there, nothing else changed. This image has the problem!

3) I manually programmed my usual 145.230, negative offset, 100Hz TSQL into the VFO, overwrote channel 4 with it, and retrieved the image. That image works normally! When compared with the one from above, it becomes clear that a lot more things were initialized by the radio (most notably within the 32 byte block beginning at 0x32EA, which is the data for channel 4).

Please see the three attached images.

Updated by Bernhard Hailer 7 months ago

To complete the set of experiments started in my previous post, I did two more tests: reset again, and do a chirp import again.

4) Reset again: A factory reset was performed on the image created during test 3. Only one byte was changed (again 0x2C4D; channel 4 is marked invalid and unused). No other changes (besides wiping the VFO area, of course) were applied.

5) Chirp again: the same CSV file as used in test 2 was imported again. Remember, previously there was a working channel programmed from a manually set VFO, and this import overwrote it: several changes were caused. The changes are comparable to the ones seen in Test 3. The resulting image had the problem again.

From these five tests it can be derived that there are four bytes in particular which are of interest. These bytes are in the memory region for the channels.

0x32ea: good 0x00, bad 0x05 - unknown1 = 0x00 -> unknown1 = 0x05
0x32eb: good 0x10, bad 0x15 - tune step index 0 -> index 5 (this one is probably without any ill effect)
0x3307: good 0x0d, bad 0x00 - unknown7, first byte
0x3309: good 0x18, bad 0x00 - unknown7, third byte

The first, third, and last byte in this list are suspicious. They are also marked "unknown" in Chirp's VX-8 code... I currently don't have a working Python environment and therefore can't test changes myself. Hopefully I'll find some time during the holidays.

Updated by Bernhard Hailer 6 months ago

Fix applied, available in today's build.

Updated by Bernhard Hailer 6 months ago

  • Assignee set to Bernhard Hailer
  • % Done changed from 0 to 100

Updated by Bernhard Hailer 6 months ago

  • Status changed from Feedback to Closed
  • Target version set to chirp-daily
  • Platform changed from MacOS to All

Also available in: Atom PDF