Hi John,
Made progress with the Icom IC-R6, most things now coded, except for one rather important field (frequency). One that's sorted just the device settings GUI to code before the first pull request, hopefully get some user feedback and test images at that stage.
Just FYI, I'd much prefer to get a base driver as the first submission. It's much less to review and we can just focus on the core bits, especially if there's anything controversial. Once that's working and ready, more patches to add functionality are then easier as incremental changes.
Would appreciate some fresh eyes on the frequency encoding. Can still code this but would like to understand why they've done this and how it relates to the hardware.
Columns below:
- F0-F2 are the 3 coded bytes in memory (F0 is the least significant, below is "radio order" per the ICF)
- Freq in MHz (each row increments by 5kHz in this example - the smallest CS-R6 allows)
- Dec and Hex are the decodes of F0 to F2.
Every 9th row breaks the expected pattern (i.e. 99.990 MHz isn't 1E 4E 00 but 66 2B F0). I see the lower 6 bits of F0 increment by 1 but why set the 2nd highest bit? Why toggle bits in F1 as well as setting 4 bits high in F2? Why every 9 rows?
| F0 | F1 | F2 | Freq MHz | Dec | Hex | | -- | -- | -- | -------- | -------------- | ------------------------------ | | 16 | 4E | 00 | 099.950 | <22><78><0> | <00010110><01001110><00000000> |
I think this is just stored assuming a 5kHz tuning step, which is pretty common for an Icom:
99950000 / 5000 = 19990 which is 0x004E16
So use a ul24 type in chirp (i.e. unsigned little-endian 24-bit) and multiply by 5000 to get the frequency.
Be careful, some radios will use a variable tuning step stored in the channel such that you might use a multiplier of 6250 if some flag is set.
--Dan