Bug #129: Radio shows NFM for rx mode, but behaves as though it is in AM mode - CHIRP

Actions

Copy link

Bug #129

closed

Radio shows NFM for rx mode, but behaves as though it is in AM mode

Added by Eric Macauley over 12 years ago. Updated almost 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Dan Smith

Category:

Target version:

Start date:

04/17/2012

Due date:

% Done:

100%

Estimated time:

Chirp Version:

daily

Model affected:

Yaesu VX-8R

Platform:

MacOS

Debug Log:

I read the instructions above:

Description

I created a new memory entry in chirp for a 2m repeater, freq 145.230, PL tone 100.0, standard negative offest and FM mode. When I transmit this image to my Yaesu VX-8R and select the new memory entry, everything appears correct on the radio display, it shows NFM receive mode, but received audio suggests it is operating in AM. If I go into the set menu on the radio and change the RX MODE to AM for that memory location, received audio then works correctly. It seems as though some how the definitions of NFM and AM for this memory location got swapped.

I have attached two images to this bug. The first vx_8r_mem3_good.img is an image I cloned from my radio after programming this repeater in manually to location MR 3 on the radio where RX MODE is NFM and behaves correctly. The second, vx_8r_mem3_bad.img is an image I created in chirp by entering the same repeater info, it is this image when loaded on my radio that exhibits the swapped NFM and AM behavior for MR 3.

Files

Download all files

vx_8r_mem3_good.img (63.7 KB) vx_8r_mem3_good.img	MR 3 programmed via radio set to NFM RX MODE behaves correctly	Eric Macauley, 04/17/2012 10:41 PM
vx_8r_mem3_bad.img (63.7 KB) vx_8r_mem3_bad.img	MR 3 programmed via chirp set to NFM RX MODE seems to behave as though it is AM mode	Eric Macauley, 04/17/2012 10:41 PM

Actions

Copy link

Updated by Dan Smith over 12 years ago

Assignee set to Dan Smith

Hmm, this is strange indeed, but I'm not sure how what you're describing is possible.

There are just two bits in the memory field that chirp gets to set that control what mode the memory uses. There's no way for me to change what gets displayed on the screen of the radio, and thus no way for chirp to have set it to AM but have NFM displayed. The radio displays (and uses) the mode indicated by those two bits.

Was memory 3 used before you edited it with CHIRP? If so, you might try doing a delete of the memory in chirp and then re-creating it, which should do a wipe of the whole channel to start fresh. If that helps, then it's likely something left in the memory previously that chirp didn't touch. In that case, I could take a look at your images and try to determine what that might be. If deleting/wiping the memory doesn't, then I'm not quite sure what to recommend, as a lot of people (myself included) seem to have pretty good success with it. Do any of the other memories exhibit this behavior?

Actions

Copy link

Updated by Eric Macauley over 12 years ago

Hi Dan,

Did a little more digging on this issue. I found that the problem pops up when I program a memory using chirp that was never used before. To prove this, I did a factory reset of my radio, the factory reset makes memory location 1 have a set of defaults stored in it, and all other memory entries are empty. I loaded this factory default image into chirp, then used chirp to program the same repeater info into Mem 1 (overwriting the factory default) and Mem 2 (never used). Here's what I programmed into both locations:

Frequency: 145.230
Name: N6NFI
Tone Mode: Tone
Tone: 100.0
Duplex: -
Offset: 0.600
Mode: FM

I loaded this modified image onto my radio and observed that Mem 1 operated as expected, and Mem 2 had an almost static like or over-modulated quality to it on the receive audio. I then manually programmed the same repeater info on the radio itself into Mem 3 and it operated as expected. I downloaded this image back from the radio, did some poking around in the chirp code, found the v8x.py mem map information, and pulled the following memory data from the chirp image using a hex editor at the appropriate offsets to compare Mem 2 (programmed via chirp with rx issues) to that of Mem 3 (programmed on radio and operating as expected). Here's what I saw:

Mem2 (NFM): 05 10 14 52 30 C1 00 00 17 06 17 0F 12 FF FF FF FF FF FF FF FF FF FF FF 00 06 00 0C 00 00 00 00
Mem3 (NFM): 80 10 14 52 30 C1 00 00 17 06 17 0F 12 FF FF FF FF FF FF FF FF FF FF FF 00 06 00 0C 00 0D 00 10

The two memory locations differ in the values for "unknown1" and "unknown7". I hacked the Mem 2 location of the radio image with a hex text editor to change only its "unknown1" value from 0x05 to 0x80 (to match that of Mem 3), left "unknown7" untouched, reloaded onto the radio, and it then worked correctly. This appears to rule out the difference of "unknown7" from being the cause, and I can only surmise that it is the 0x05 value that gets loaded into "unknown1" during a _wipe_memory operation that is causing the strange receive audio issues. It would seem based on what I have observed at least that the mem.unknown1 value should be 0x80. Incidentally, it seems that the value 0x00 for unknown1 makes the location a "Priority Channel" for scanning, as that is what Mem 1 factory default starts off with.

The _wipe_memory operation setting mem.unknown1 to 0x05 would also explain why a memory location previously programmed on the radio, and then redefined using chirp does not show a problem, as I believe in that scenario _wipe_memory is not executed, chirp simply overwrites the known bytes and leaves the unknown* entrie untouched.

Hope that helps, let me know if you need any other data or images to look at.

Actions

Copy link