Bug #6457
closedIC-2730 driver does not properly support tuning steps other than 5kHz
100%
Description
Hi,
I discovered that the "oddsteps" test was non-functional for every driver, which means that bit of verification was not getting run. After I fixed it, the ic2730 driver now fails the test because it always assumes a 5000Hz step in storing the memory. Thus, this test is now failing for this driver in the main branch.
Rhett, if you're still around could you take a look and see if you can fix the test? If not, I don't really have any option other than to just disable 6.25kHz steps for this driver, which wouldn't be great.
dan@eagle:~/dev/chirp/tests$ ./run_tests -t Edges -d Icom_IC-2730A
Icom IC-2730A Edges FAILED: Field `freq' is `145855000', expected `145856250'
Thanks!
Updated by Dan Smith almost 6 years ago
Also, if you don't have time to look at this but could just post an image with two channels that are identical aside from one being on a 6.25khz step frequency that would be helpful.
Updated by Rhett Robinson almost 6 years ago
- Status changed from New to In Progress
I have a patch pending. I have something which works for at least some, but not all frequencies. I believe it improves the coverage of the driver, but I know it leaves some still missing, though I'm not sure I have time to fully figure everything out, so I'll leave my notes here:
Details:
It turns out the first three bytes of each memory location includes some flags. I believe the first 6 bits are flags, and here are what the masks seem to mean:
0x08 = frequency multiplier is 6250 (default is 5000)
0x10 = frequency multiplier is 25000/3 (~8333) (not entirely sure)
0x01 = offset multiplier is 6250
The remaining 16 bits are the steps on that multiplier.
For example, if the first five bytes are 0x205a010079, this breaks down to flags of 0x08, for a frequency multiplier of 6250 and default offset multiplier of 5000. The remaining frequency bytes are 0x05a01. 0x05a01 * 6250 = 144006250 for a frequency of 144.00625 (note this requires a TS of 6.25). The offset is 0x0079, with a multiplier of 5000 = 0.605 (non-standard, I was testing).
Another example: 0x245a010061. The frequency flags are now 0x09 = 0x08 | 0x01, implying a frequency and offset multiplier both of 6250. Remaining frequency = 0x05a01 * 6250 = 144.00625 still, but now offset . 0x0061 * 6250 = 0.60625.
The flag of 0x10 for a frequency multiplier of 25000/3 is a bit tricky, though, because not all bytes correspond to the exact multiple, in terms of displayed frequency, so I haven't fully figured out what's going on there. For example, I notice it seems to use that representation for a lot of the really low frequencies the radio can handle (e.g. 118.000 MHz).
For example: 0x483750. Flags are: 0x12. The remaining frequency is 0x3750, and 0x3750 * 25000/3 = 118000000 = 118.000 MHz. But, go up to 118.005, and the frequency bits stay the same: 0x483750. But, the TS and mode bits change. Go up past that, and it seems to regularly increment the frequency flags: 118.010 = 0x483751, 118.015 = 0x483752, etc. The frequencies are not exact multiples of 25000/3, though, but are close. So, this needs more research to figure out how this is being encoded.
I've also discovered while doing this that the modes the memory supports includes at least AM and narrow AM, so I'm adding that in my patch too. I just don't have time right now to figure out exactly how the TS, mode and frequency bits all work together to encode these lower frequencies.
If you play around and find other frequency/TS/mode combinations the radio doesn't support in the ham bands, though, let me know (new bug, I guess) and I can try to figure those specifically out, at least.
Updated by Rhett Robinson almost 6 years ago
I should add: the tuning step seems to be more or less stored correctly; what is actually failing is the representation of the memory, which is independent of the tuning step. For example: I can step TS=6.25, and then select a memory of 144.00625, and then set TS back to 5. The memory will show TS=5, but frequency of 144.00625 per the flags I've described.
Updated by Dan Smith almost 6 years ago
Rhett,
Yeah, other icom radios store the tuning step completely independently of the multiplier used to store the frequency. Take a look at the id880 driver and see if it gives you any clues. I think that one is probably the most right.
Thanks for looking into this..
Updated by Rhett Robinson almost 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Applied in changeset commit:a57feb274e43.
Updated by Rhett Robinson almost 6 years ago
Thanks for the reference to id880, that does look like a lot better. I realize that this issue, as written, is not properly closed. The driver now supports 6.25 kHz, but not any other tuning steps. I marked the bug fixed in my patch thinking first that the issue was primarily about the failing test. Would you prefer a new bug for full support of all tuning steps? Reopen this one? A new bug for each step not fully supported? My preference would be to rename this one to reflect the failed test and 6.25 kHz (and so leave it closed), and open a new bug for each tuning step not fully supported as we discover them, as I'm a fan of minimal changes/more fine-grained bugs, but it's up to you.
Updated by Dan Smith almost 6 years ago
Up to you. I mostly just want discussion/logs correlated to the commits. Fine-grained bugs are fine for that, as are lumpy ones. You or I can re-open this and let the next one close it, or just tag it against this one again, it won't hurt anything :)
Thanks a lot for following through!