Hi everyone,
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.
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> | | 17 | 4E | 00 | 099.955 | <23><78><0> | <00010111><01001110><00000000> | | 18 | 4E | 00 | 099.960 | <24><78><0> | <00011000><01001110><00000000> | | 19 | 4E | 00 | 099.965 | <25><78><0> | <00011001><01001110><00000000> | | 1A | 4E | 00 | 099.970 | <26><78><0> | <00011010><01001110><00000000> | | 1B | 4E | 00 | 099.975 | <27><78><0> | <00011011><01001110><00000000> | | 1C | 4E | 00 | 099.980 | <28><78><0> | <00011100><01001110><00000000> | | 1D | 4E | 00 | 099.985 | <29><78><0> | <00011101><01001110><00000000> | | 66 | 2B | F0 | 099.990 | <102><43><240> | <00011110><00101011><11110000> | | 1F | 4E | 00 | 099.995 | <31><78><0> | <00011111><01001110><00000000> | | 20 | 4E | 00 | 100.000 | <32><78><0> | <00100000><01001110><00000000> | | 21 | 4E | 00 | 100.005 | <33><78><0> | <00100001><01001110><00000000> | | 22 | 4E | 00 | 100.010 | <34><78><0> | <00100010><01001110><00000000> | | 23 | 4E | 00 | 100.015 | <35><78><0> | <00100011><01001110><00000000> | | 24 | 4E | 00 | 100.020 | <36><78><0> | <00100100><01001110><00000000> | | 25 | 4E | 00 | 100.025 | <37><78><0> | <00100101><01001110><00000000> | | 26 | 4E | 00 | 100.030 | <38><78><0> | <00100110><01001110><00000000> | | 6B | 2B | F0 | 100.035 | <107><43><240> | <01101011><00101011><11110000> | | 28 | 4E | 00 | 100.040 | <40><78><0> | <00101000><01001110><00000000> | | 29 | 4E | 00 | 100.045 | <41><78><0> | <00101001><01001110><00000000> | | 2A | 4E | 00 | 100.050 | <42><78><0> | <00101010><01001110><00000000> | | 2B | 4E | 00 | 100.055 | <43><78><0> | <00101011><01001110><00000000> | | 2C | 4E | 00 | 100.060 | <44><78><0> | <00101100><01001110><00000000> | | 2D | 4E | 00 | 100.065 | <45><78><0> | <00101101><01001110><00000000> | | 2E | 4E | 00 | 100.070 | <46><78><0> | <00101110><01001110><00000000> | | 2F | 4E | 00 | 100.075 | <47><78><0> | <00101111><01001110><00000000> | | 70 | 2B | F0 | 100.080 | <112><43><240> | <01110000><00101011><11110000> | | 31 | 4E | 00 | 100.085 | <49><78><0> | <00110001><01001110><00000000> | | 32 | 4E | 00 | 100.090 | <50><78><0> | <00110010><01001110><00000000> | | 33 | 4E | 00 | 100.095 | <51><78><0> | <00110011><01001110><00000000> | | 34 | 4E | 00 | 100.100 | <52><78><0> | <00110100><01001110><00000000> | | 35 | 4E | 00 | 100.105 | <53><78><0> | <00110101><01001110><00000000> | | 36 | 4E | 00 | 100.110 | <54><78><0> | <00110110><01001110><00000000> | | 37 | 4E | 00 | 100.115 | <55><78><0> | <00110111><01001110><00000000> | | 38 | 4E | 00 | 100.120 | <56><78><0> | <00111000><01001110><00000000> | | 75 | 2B | F0 | 100.125 | <117><43><240> | <01110101><00101011><11110000> | | 3A | 4E | 00 | 100.130 | <58><78><0> | <00111010><01001110><00000000> | | 3B | 4E | 00 | 100.135 | <59><78><0> | <00111011><01001110><00000000> | | 3C | 4E | 00 | 100.140 | <60><78><0> | <00111100><01001110><00000000> | | 3D | 4E | 00 | 100.145 | <61><78><0> | <00111101><01001110><00000000> | | 3E | 4E | 00 | 100.150 | <62><78><0> | <00111110><01001110><00000000> | | 3F | 4E | 00 | 100.155 | <63><78><0> | <00111111><01001110><00000000> | | 40 | 4E | 00 | 100.160 | <64><78><0> | <01000000><01001110><00000000> | | 41 | 4E | 00 | 100.165 | <65><78><0> | <01000001><01001110><00000000> | | 7A | 2B | F0 | 100.170 | <122><43><240> | <01111010><00101011><11110000> | | 43 | 4E | 00 | 100.175 | <67><78><0> | <01000011><01001110><00000000> | | 44 | 4E | 00 | 100.180 | <68><78><0> | <01000100><01001110><00000000> | | 45 | 4E | 00 | 100.185 | <69><78><0> | <01000101><01001110><00000000> | | 46 | 4E | 00 | 100.190 | <70><78><0> | <01000110><01001110><00000000> | | 47 | 4E | 00 | 100.195 | <71><78><0> | <01000111><01001110><00000000> | | 48 | 4E | 00 | 100.200 | <72><78><0> | <01001000><01001110><00000000> |
Thanks,
John.
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
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?
Sorry, I totally skipped over this question, but kinda gave you a hint:
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.
Looks to me like those are using a 9000 multiplier, possibly signaled by the high bits in the "F2" byte. Perhaps some of those were configured as airband?
--Dan
Long ago, in June of 2000, I wrote a standalone program to upload/download an ascii text channel list to/from the Icom IC-R2, an ancestor to the R6, which nevertheless looks very similar.
I remember the frequency encoding was strange, with lots of special cases, including different encoding if the spacing was .625 kHz, and handling of the MW band in a totally different format depending on whether 9kHz or 10Khz spacing was being used, and perhaps some other gotchas that have escaped me over the past two and a half decades. But I believe I got the R2 frequency handling solid. I distributed that software for free to a large mailing list of R2 users, and after a few initial bug reports were fixed (that had to do with things other than the frequency), it was very stable.
I dug up my source code, and have just now posted it on the web, at
https://ag6qr.net/priv/VmhNvUR7k8k92fQs7PfN/r2pepperSource.zip
It's written in C++. The meat of the frequency handling code is in the class CFrequency, which is declared in r2radio.h, with the member function definitions in r2radio.cpp.
The C++ class stores frequencies in an internal format consisting as an integer number of kHz, plus flags saying whether it's spaced in 62.5 kHz intervals, and whether it's a 9kHz spaced MW frequency.
The key member functions are
CFrequency::setFromData, converts the raw data bytes from the radio's internal format into an integer number of kHz,
CFrequency::putToData, converts a frequency in integer kHz to the radio's internal data storage format
CFrequency::setFromAscii converts an Ascii buffer into the integer number internal representation
CFrequency::putToAscii converts the internal representation into an Ascii buffer.
I don't know if the R6 uses the same strange internal representation as the R2 did, but it sounds like there may be some common ground here. I don't have access to an R6.
It has been literally decades since I've touched this code, but I remember writing it, and I just glanced over it, and it looks reasonably familiar. I'll try my best to answer questions.
You're welcome to contact me privately off this list, because the details of the internal representation of frequencies on these old scanners may not be of general interest to the entire list. I apologize, I haven't been actively participating in this list recently, and I've missed many posts.
--Rich Cochran/AG6QR
ag6qr@sonic.net
On 6/5/24 15:22, John Bradshaw via Developers wrote:
Hi everyone,
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.
Would appreciate some fresh eyes on the frequency encoding.
Thanks Dan and Rich.
Rich - Downloaded your code and will get a proper look at it over the next few weeks.
Dan - will get the frequency coded and then do a pull request. Will do the settings part of the GUI as an increment (they're easily changed on the radio anyway).
Regards,
John, Mi0SYN.
On 06/06/2024 02:21, Richard Cochran via Developers wrote:
Long ago, in June of 2000, I wrote a standalone program to upload/download an ascii text channel list to/from the Icom IC-R2, an ancestor to the R6, which nevertheless looks very similar.
I remember the frequency encoding was strange, with lots of special cases, including different encoding if the spacing was .625 kHz, and handling of the MW band in a totally different format depending on whether 9kHz or 10Khz spacing was being used, and perhaps some other gotchas that have escaped me over the past two and a half decades. But I believe I got the R2 frequency handling solid. I distributed that software for free to a large mailing list of R2 users, and after a few initial bug reports were fixed (that had to do with things other than the frequency), it was very stable.
I dug up my source code, and have just now posted it on the web, at
https://ag6qr.net/priv/VmhNvUR7k8k92fQs7PfN/r2pepperSource.zip
It's written in C++. The meat of the frequency handling code is in the class CFrequency, which is declared in r2radio.h, with the member function definitions in r2radio.cpp.
The C++ class stores frequencies in an internal format consisting as an integer number of kHz, plus flags saying whether it's spaced in 62.5 kHz intervals, and whether it's a 9kHz spaced MW frequency.
The key member functions are
CFrequency::setFromData, converts the raw data bytes from the radio's internal format into an integer number of kHz,
CFrequency::putToData, converts a frequency in integer kHz to the radio's internal data storage format
CFrequency::setFromAscii converts an Ascii buffer into the integer number internal representation
CFrequency::putToAscii converts the internal representation into an Ascii buffer.
I don't know if the R6 uses the same strange internal representation as the R2 did, but it sounds like there may be some common ground here. I don't have access to an R6.
It has been literally decades since I've touched this code, but I remember writing it, and I just glanced over it, and it looks reasonably familiar. I'll try my best to answer questions.
You're welcome to contact me privately off this list, because the details of the internal representation of frequencies on these old scanners may not be of general interest to the entire list. I apologize, I haven't been actively participating in this list recently, and I've missed many posts.
--Rich Cochran/AG6QR
ag6qr@sonic.net
On 6/5/24 15:22, John Bradshaw via Developers wrote:
Hi everyone,
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.
Would appreciate some fresh eyes on the frequency encoding.
Developers mailing list --developers@lists.chirpmyradio.com To unsubscribe send an email todevelopers-leave@lists.chirpmyradio.com
participants (3)
-
Dan Smith -
John Bradshaw -
Richard Cochran