New Model #2795
openIcom IC-R6
0%
Description
Icom IC-R6
Related issues
Updated by Eric Dropps over 8 years ago
Do you have a copy of the CS-R6 software? This would likely be needed (or a loaner receiver) to add support.
Updated by Johan Nilsson over 8 years ago
Eric Dropps wrote:
Do you have a copy of the CS-R6 software? This would likely be needed (or a loaner receiver) to add support.
Sorry i don't have , but i think it uses the CI-V protocol. Like some models you already support for example Icom 746.
Updated by Kristian Sørensen over 7 years ago
Any chance of the Icom IC-R6 being supported by Chirp?
In the paper manual for the IC-R6 it says it uses the CI-V "communication interface".
Just for a laugh I tried downloading from the IC-R6 telling Chirp it is an Icon 746 (because that one apparently also also uses CI-V(, and Chirp did do some downloading from the IC-R6 but with errors, and Chirp could not upload to the IC-R6.
Would it help matters if I offered to let you borrow my IC-R6 for some months?
Updated by Mark Schaffer over 1 year ago
I can loan my IC-R6 to a developer to get this added to CHIRP. Just let me know.
Updated by Steef Pieters 3 months ago
Johan Nilsson wrote:
Icom IC-R6
Hi guys, I own a R6, also CS-R6. I would reallyreally like support of Chirp with programming. CS6 sucks (sorry). Csv Importing and exporting is impossible. Exporting and directly importing = “illegal data”. Which shows exporting already corrupts.
How are things with support of Icom IC-R6 8 years later? Can I help with CS eg ?
Greetz Steef
Updated by John Bradshaw about 1 month ago
Hi everyone,
I've a IC-R6 and bought CS-R6... it's not great so keen to help with Chirp.
Have decoded the command that "clones out" the radio and written a small Python script which sends that command to the radio and captures the memory dump on stdout:
#!/usr/bin/python3
# pip install pexpect-serial
# Don't have "serial" package installed, use the above instead.
import serial
import sys
from pexpect_serial import SerialSpawn
from pexpect import TIMEOUT
with serial.Serial('/dev/ttyUSB0', 9600, timeout=0) as ser:
ss = SerialSpawn(ser)
ss.write(b'\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xee\xef\xe2\x32\x50\x00\x00\xfd')
do_loop = True
while do_loop:
index = ss.expect(['.', TIMEOUT])
if index == 0:
a = ss.match.group(index)
sys.stdout.write(f":{a.hex()}")
if a == b'\xfd':
sys.stdout.write("\n")
elif index == 1:
do_loop = False
ser.close()
Have another Perl script that converts the output of the above to "ASCII encoded hexadecimal", it let me use diff and similar tools to compare small config changes... happy to share if anyone wants it (updating it as I learn more about the memory layout).
Started on the layout for the channels (they're 16 bytes each starting at location 0000).
Found some of the bytes that control frequency (see below) as well another higher block of memory that shows if a channel memory is enabled or not. There's other memory locations which change too - think they're display/name related but haven't tried decoding them as yet.
Sorted by freq low to high: 88.000 MHz WFM 50k C0 44 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 89.000 MHz WFM 50k 88 45 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 90.000 MHz WFM 50k 10 27 F0 1A 00 00 00 08 00 72 00 00 00 00 00 00 91.000 MHz WFM 50k 18 47 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 92.000 MHz WFM 50k E0 47 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 93.000 MHz WFM 50k A8 48 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.000 MHz WFM 50k 70 49 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.450 MHz WFM 50k CA 49 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.500 MHz WFM 50k 04 29 F0 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.550 MHz WFM 50k DE 49 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 95.000 MHz WFM 50k 38 4A 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 96.000 MHz WFM 50k 00 4B 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 97.000 MHz WFM 50k C8 4B 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 97.350 MHz WFM 50k 0E 4C 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 97.400 MHz WFM 50k 18 4C 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 97.450 MHz WFM 50k 22 4C 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 98.000 MHz WFM 50k 90 4C 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 99.000 MHz WFM 50k F8 2A F0 1A 00 00 00 08 00 72 00 00 00 00 00 00 99.650 MHz WFM 50k DA 4D 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 99.700 MHz WFM 50k E4 4D 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 99.750 MHz WFM 50k EE 4D 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 100.000 MHz WFM 50k 20 4E 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 101.000 MHz WFM 50k E8 4E 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 102.000 MHz WFM 50k B0 4F 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 103.000 MHz WFM 50k 78 50 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 104.000 MHz WFM 50k 40 51 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 105.000 MHz WFM 50k 08 52 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 105.750 MHz WFM 50k E6 2D F0 1A 00 00 00 08 00 72 00 00 00 00 00 00 105.800 MHz WFM 50k A8 52 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 106.000 MHz WFM 50k D0 52 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 107.000 MHz WFM 50k 98 53 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 107.850 MHz WFM 50k 42 54 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 144.975 MHz FM 25k 43 71 00 08 00 78 00 08 00 72 00 00 00 00 00 00 145.000 MHz FM 25k 48 71 00 08 00 78 00 08 00 72 00 00 00 00 00 00 145.025 MHz FM 25k 4D 71 00 08 00 78 00 08 00 72 00 00 00 00 00 00 400.000 MHz FM 25k 80 38 01 08 00 40 01 08 00 72 00 00 00 00 00 00 429.000 MHz FM 25k 28 4F 01 08 00 40 01 08 00 72 00 00 00 00 00 00 429.975 MHz FM 25k EB 4F 01 08 00 40 01 08 00 72 00 00 00 00 00 00 430.000 MHz FM 25k F0 4F 01 08 00 40 01 08 00 72 00 00 00 00 00 00 430.025 MHz FM 25k F5 4F 01 08 00 40 01 08 00 72 00 00 00 00 00 00
The first byte of 16 is the frequency LSB, second byte is next most significant, etc.
Can anyone somebody explain why the second byte goes 49-29-49 while the third byte goes 00-F0-00?
B1 B2 B3 94.450 MHz WFM 50k CA 49 00 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.500 MHz WFM 50k 04 29 F0 1A 00 00 00 08 00 72 00 00 00 00 00 00 94.550 MHz WFM 50k DE 49 00 1A 00 00 00 08 00 72 00 00 00 00 00 00
Something similar happens between 89, 90 and 91 MHz above too.
Thanks.
Updated by Dan Smith about 1 month ago
- I read the instructions above set to Yes
ss.write(b'\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xee\xef\xe2\x32\x50\x00\x00\xfd')
This looks like standard ICF, so I suspect subclassing IcomCloneModeRadio will get you clone in and out fairly reliably, if you figure out and set _memsize. Once you do and you can attach a standard chirp .img file it will probably be easier to hash out some details. Also, chirp can load .ICF files in general, so you can probably also use that to save out from CS-R6 and tweak/test/repeat from the software instead of having to go through the device. Then you can more easily start with something clean, set a memory, then change as little as possible and suss out which bit changes. In developer mode, you can use the Radio->Reload operations to iterate quickly between CS-R6 save and load in chirp. Repeating like that is how you'll be able to figure out what each of the things does instead of just staring at a whole memory and guessing.
Once you figure out the start and offset of the memories (sounds like you're there) you can populate a memory object in chirp and then you can browse through it with the GUI and start to define bits you know about. Once you have that you can define two memories that are identical other than one thing and right-click "diff raw memories" and see only the bits that changed. Once you get to that point, you'll be able to decode all the things super fast.
Hope that helps a bit.
Updated by John Bradshaw about 1 month ago
Thanks Dan.
Yes, that's a great start.
Copied ict7h.py to icr6.py, set _memsize and made a few edits... it's now reading the radio and importing the ICF too. Was able to save out an.img file.
Need to play around with the memory structures (seem to be 3 different blocks - one with frequency, one with control bits and another I suspect is the displayed segments).