CHIRP

Do you have a copy of the CS-R6 software? This would likely be needed (or a loaner receiver) to add support.

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.

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?

I can loan my IC-R6 to a developer to get this added to CHIRP. Just let me know.

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

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.

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).

John Bradshaw wrote in #note-8:

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).

Did you have any success? I'd be interested, too. What edits did you make?

Hi Karsten,

Have most of it working now... except the frequencies (the sequence changes every 9 tuning steps). I need to clear a few evenings to get it done, some of the other developers have shared frequency code from a previous Icom model which should help.

Device settings are mapped but yet not coded in the GUI (easy enough to change via the keypad so I'll upload the code once the frequency part is done rather than get it 100% working first)
Need to add some checks to stop people entering invalid settings (for example only allowing certain Tuning Steps based on channel frequency and/or blocking some frequencies based on model) too.

If anyone has CS-R6 and a programmed IC-R6 please attach a ICF file. I've the European (100kHz to 1.309995 GHz range) model so just working on that. The USA model has weather channels and frequency gaps, the French model has frequency gaps)... happy to add variants if I can get ICF files from those other models.

Regards,
John.

John Bradshaw wrote in #note-11:

Have most of it working now... except the frequencies (the sequence changes every 9 tuning steps). I need to clear a few evenings to get it done, some of the other developers have shared frequency code from a previous Icom model which should help.

Do you have a fork available on github? I'd be happy to test, perhaps help. I have a usb cable and IC-R6 and working python virtual environment.

Thanks Dave.

That ICF had an "Auto" setting which I hadn't put into the Tune Step lookup... now added.

Loading that file into CS-R6 1.1 gave a "data file version" warning the first time and saving it out changed exactly one character.
It's mapping to one bit of device settings I haven't decoded yet.

Icom are also using the EtcData comment in the ICF for that warning (I changed it to 002A on a copy of your file and it showed the warning).

$ head -4 ic-r6_dave_ratcliffe_7-8-24.icf
32500001
#Comment=
#MapRev=1
#EtcData=0003

$ head -4 icr6_default_2channels.icf
32500001
#Comment=
#MapRev=1
#EtcData=002A

Your ICF also shows 2 new channel columns under "canceller": (1) OFF/TRAIN1/TRAIN2/MSK options and (2) training frequency (greyed out but shows 2280, can be changed in steps of 10)
They only appears when EtcData is 0003 (I changed one of my existing dumps and it toggles).

So I'll need to figure out how to handle that comment/value in Chirp and see where your additional fields map inside the channel settings, should be easy enough to figure out now I know how to put CS-R6 into "0003" mode.

Hi Mike,

I need to give IC-R2 source code that Rich Cochran (AG6QR) kindly shared a proper look, that should help decode the frequency formatting (he found a few strange things and coded around them).

Would like to try test more ICF files (I can validate them inside CS-R6 rather than sending to hardware and possibly bricking a radio) before uploading a fork for beta-testing.
Dan says if it's reasonably close better to get into the main codebase for others to look at but I really want to crack frequency (or admit defeat) first.

If you could run the code in note 6 (you need to install the pexpect-serial python module, not the serial one) and attach the output I can convert that into ICF and test in CS-R6 and Chirp.

Might redo that code to generate the ICF directly (now I know the CS-R6 format) which means anyone else with a IC-R6 and cable could directly generate their own backups.

Thanks,
John.

Thanks Mike,

Yeah, once code gets to ~90% working I'd happily upload... frequency will get it over that line.
If I can't get there after looking at Rich's code then we'll get more eyes on :-)

The script should exit (time-out) on its own after a few minutes, see it's lost some data at the end but I can splice it from another file and get a reasonably valid ICF. Dan saw the dump from it, said it was ICF and to write the framework in Chirp so I've been able to use that and CS-R6 for the memory mapping.

I'll make the time and update the script to generate ICF directly rather then a hex dump... been a while since I used it in anger.
Let everyone get a backup of their radio now if they wish (and hopefully upload for alpha-test).

Linux shop here too. CS-R6 fine runs under Windows inside a VirtualBox VM with USB pass-through.

Just rechecked regedit in Windows and it's now changed the value for EtcData key there - that's making CS-R6 change mode between Global and USA models so that needs replicated in Chirp too.

Hi everyone,

Made progress thanks to Rich Cochran AG6QR's code. It mentioned 6.25kHz steps which I hadn't tested before.. threw some into CS-R6 and found what look like flags changing. Did the same with 9kHz steps and the strange jumps in comment 6 became apparent. The flags are consistent for 6.25 kHz steps and 9kHz steps.

It happens every 9x 5kHz steps which was throwing me off), if the frequency is multiple of both 5kHz and 9kHz then the IC-R6 codes it as 9kHz multiple frequency instead of 5kHz multiplier... even if the TS is set to 5kHz.

Next steps:

1. Code a validator for each entered frequency - round off to nearest supported and return that (this will make Chirp match CS-R6's GUI) - and return the best step size for that frequency.
2. Figure out the mapping for 9kHz steps (IC-R6 preferred), 5kHz steps, 6.25kHz and 8.33 kHz steps. Other steps appear to be coded as a multiple of 5kHz. Mapping seems fairly consistent now.. just need to look at each group in turn.
3. Code, test and get a pull request uploaded for beta testing.

Have added the canceller options and training frequency from Dave's dump... not documented and unsure what they do (if anything) but it's there anyway.

Few asks:

1. If anyone else has ICF files or can run the dumper above (haven't got rewritting that to make it dump CS-R6 compliant files yet, on the list) please keep uploading them... really want to do as much testing as possible on frequencies before uploading anything.
2. If you have a US model could you provide a dump with the WX alert enabled and disabled? Want to find that flag but it's not showing in CS-R6. Using the python code above is fine if you don't have CS-R6.

Thanks,
John.

John Bradshaw wrote in #note-17:

Hi everyone,

Made progress thanks to Rich Cochran AG6QR's code. It mentioned 6.25kHz steps which I hadn't tested before.. threw some into CS-R6 and found what look like flags changing. Did the same with 9kHz steps and the strange jumps in comment 6 became apparent. The flags are consistent for 6.25 kHz steps and 9kHz steps.

It happens every 9x 5kHz steps which was throwing me off), if the frequency is multiple of both 5kHz and 9kHz then the IC-R6 codes it as 9kHz multiple frequency instead of 5kHz multiplier... even if the TS is set to 5kHz.

I guess you are using the manual but just in case, this is the manual I am using:
https://www.icomeurope.com/wp-content/uploads/2019/07/IC-R6_ENG_IM_6.pdf

Reminds me of this text in the manual from the specifications page... (page 78 on the pdf ... manual page 65)

• Frequency resolution : 5, 6.25, 8.33*, 9*, 10, 12.5, 15, 20,
25, 30, 50, 100, 125, 200 kHz
* Selectable depending on the operating frequency band.

Not sure where 9 was used, but 8.33 is on air band.

Next steps:

1. Figure out the mapping for 9kHz steps (IC-R6 preferred), 5kHz steps, 6.25kHz and 8.33 kHz steps. Other steps appear to be coded as a multiple of 5kHz. Mapping seems fairly consistent now.. just need to look at each group in turn.

There was also a description of the commands and frequency mappings (bcd nibbles) on page 88 of the pdf. Some differences depending on the band. The cloning process is not described in the manual, and I understand that there are probably some differences.

1. Code, test and get a pull request uploaded for beta testing.

Thanks! It's great to to follow the progress!

I would be interested to see the Perl script you used... Not promising anything, but it would be interesting to play with... and maybe add to the python memory dumper.

Best regards,
... Mike

John, the dump I sent before includes several airband frequencies,
channels 3-10. I don't pretend to understand most of what you are
talking about, just wanted to mention it in case you missed it.

Dave

On 7/18/2024 8:55 PM, John Bradshaw wrote:

Thanks Dave.

Sorry, was referring to your ICF in the reply to Mike but attributed it to him.
I need to look at his file in more detail.

Just checked your file in CS-R6 v1.1 - those channels all show as "Auto TS" but it allows 8.333kHz as a step for them which agrees with the docs.
That 8.333kHz step option is disabled on your non-Airband channels 0 through 2. The broadcast 630kHz on channel 2 allows 9kHz TS.
Need to bring that validation into the driver code (Chirp's GUI blocks obvious nonsense such as if freq isn't a multiple of any known TS but we need to further restrict it on the IC-R6).

Karsten Rohrbach wrote in #note-22:

Here's a dump from my IC-R6.
(EU version)

Thanks Karsten,

That's been a great help.

Used your repeater channels to check the 5k/9k step theory... now coded and working with 5/6.25/8.333/9 kHz steps.
The others are stored multiples of 5k even if TS is 10k or higher multiple.

Also found duplex offsets depend on the frequency-step (and not the shown TS) by using your 2m frequencies... that's been fixed too.

Still need to code some other areas such as program scan edges and channel banks - will use your ICF for those too.

Hi everyone,

Will look at Tox testing and a Pull Request some stage next week - first time doing those, unsure how long it takes.
Not 100% ready but would let everyone backup their radios (hopefully encourage others to buy the serial cable and get involved) and allow some beta tests.

Happy to validate Chirp-generated ICF files through CS-R6 before anyone tries writing to physical radios... hopefully that'll shake out the remaining issues.

Hi,

Thank you John for your work on this !

It's been quiet recently. I've been eagerly following this issue here for news every few days. :-)

I did a little digging and found the PR in the Chirp github. If interested in the progress see: https://github.com/kk7ds/chirp/pull/1082
Looks like a little more work on the requested changes before it is merged into master.

Thanks again! Looking forward to the merge and testing.

Hi Mike,

Code had a good clean-up following Dan's notes on that PR. More work needed to reduce the bit shifting (radio has both big and small endian words) which I'll ask Dan to check on the next PR. Currently working on using icf.warp_byte_size() for the compressed channel names instead of bit shifting.

Will pop a few PR up this weekend... doubt it'll get merged (it's mainly to get feedback and ask some new questions) before fixing the endian-related definitions but it'll work locally.
Cloning CHIRP master into another directory on your PC and then adding "chirp/drivers/icr6.py" and "tests/images/Icom_IC-R6.img" from that PR will allow some beta-testing.

If anyone can use that to read their radio and post a few ICF files (or CHIRP image files) that'd be great.
Happy to validate any ICF files in CS-R6 before anyone writes to hardware with CHIRP.

Attach the driver file here and then people can use LoadingTestModules to pull and test it automatically. Would definitely like to hear some feedback from others that it works before we merge if possible.

Hi everyone,

Dan added a change in another file to help simplify some of the IC-R6 code, will modify the driver this week for that. Probably won't be uploading another version for a few weeks... some changes needed around readability. Would appreciate if anyone could test the driver uploaded last week (item #28) and feedback here.

Thanks,
John.

Hi everyone,

Did anyone try the test version attached above? Any feedback/issues?

Regards,
John.