Bug #559
closedChirp does not correctly decode some ID-880H frequencies
100%
Description
In some Icom radios (including the ID-880H), a frequency multiplier "index" is stored along with a frequency "sub-value", in order to save space in the memory list.
For the ID-880H, the 3-bit index value (separate indicies for xmit and receive) should index into the following multiplier table:
static uint32_t const resolutions[ 8 ] = { 5000, 6250, 6250, 8333, 9000, 10, 10, 10 };
If the wrong table values are used, the wrong frequency is displayed. Eg, on the ID-880H, 121.5 MHz (the international distress/MayDay frequency) from the radio is displayed by Chirp as 67.5MHz, probably because 5000 (index 0) was used rather than 9000 (index 4). Perhaps you are assuming the multiplier is only a 2-bit value?
The ID-880H is a big-endian processor, and the first 24 bits of a memory location are (high-to-low bit order):
- 3-bits, rx multiplier index
- 3-bits, tx multiplier index
- 18-bits, receive frequency "sub-value".
I marked this as "Urgent", because potentially it could cause corruption of a user's frequencies. It is NOT urgent for me personally (I use Icom's software for the ID-880H).
Updated by Dean Gibson over 11 years ago
I looked at id880h.py (my first ever look at any Python code), and while the "get" part of the code looks easy to change, the "set" part references "chirp_common.is_fractional_step(...)", so unless that reference is removed, the change looks a bit more complicated. Presumably the radio's logic in selecting a multiplier is to try them in descending order, picking the first one that doesn't give a fractional result. I presume this only because 121.5 could have used the "5000" multiplier, but instead the radio picked "9000".
I'm hesitant to change the architecture by suggesting a change that removes "chirp_common.is_fractional_step(...)".
Updated by Dan Smith over 11 years ago
- Assignee set to Dan Smith
- Target version set to 0.4.0
Updated by Dan Smith almost 11 years ago
- Status changed from New to Feedback
- Priority changed from Urgent to Normal
Sorry I'm just getting around to looking at this.
On my radio, I don't have a 9000Hz step accessible through the front panel, nor does the manual list that as a valid step. I can tune to 121.500MHz via 8333Hz step, and confirm that it's stored with the proper index into your table in the memory. However, the math doesn't get me back to the right frequency, so I must be missing something.
The whole value in the field is 0x6038F4. If I take 0x38F4 (14580 in decimal) and multiply by 8333, I get 121495140 which is not 121500000 that I'm expecting. Can you point out my error?
Thanks!
Updated by Dean Gibson over 10 years ago
I think you are confusing the "step" (which the user can set), with the internal "multiplier" that the radio chooses when storing a frequency.
You don't have to use the same algorithm that the radio uses (my statement in my 1st update as to what the radio does, is only a guess), you (again, my guess, but it works in my code in DStarCom) just have to use a multiplier that gives the correct (exact) frequency (and of course store the corresponding multiplier index).
Eg, for 121.5, I think you could pick 5000, 6250, or 9000 as the divisor (since all divide evenly into 121.5x106), and store "0", "1", or "4" for the corresponding multiplier, and I think it would work. 8333 won't work, as you point out.
In the example, the radio picked a multiplier of 9000, and stored 13500 (decimal) and a multiplier index of 4. Your code just looked at the low-order bit of the 3-bit field, interpreted that as "0" (not "4"), multiplied by 5000 (not 9000), and arrived at 67.5MHz.
Updated by Tom Hayward almost 8 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Dan Smith to Tom Hayward
- % Done changed from 0 to 100
Updated by Tom Hayward almost 8 years ago
- Status changed from Resolved to Closed