Project

General

Profile

Actions

New Model #2795

open

Icom IC-R6

Added by Johan Nilsson over 9 years ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/13/2015
Due date:
% Done:

0%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:
Yes

Description

Icom IC-R6


Files

IC-R6 7-8-24.icf (69 KB) IC-R6 7-8-24.icf Dave Ratcliffe, 07/08/2024 12:31 PM
dump.hex (200 KB) dump.hex Mike G, 07/09/2024 04:42 PM
decode_icf.pl (5.2 KB) decode_icf.pl Perl IC-R6 ICF decoder - draft John Bradshaw, 07/18/2024 05:21 PM
lots_of_145_named4_no_key_beep_vol26.icf (69 KB) lots_of_145_named4_no_key_beep_vol26.icf Example ICF from CS-R6 John Bradshaw, 07/18/2024 05:22 PM
lots_of_145_named4_no_key_beep_vol26.txt (379 KB) lots_of_145_named4_no_key_beep_vol26.txt John Bradshaw, 07/18/2024 05:23 PM
20240720+air600.icf (69 KB) 20240720+air600.icf IC-R6 EU config with one air channel at 600 Karsten Rohrbach, 07/19/2024 04:00 PM
icr6.py (20 KB) icr6.py John Bradshaw, 08/10/2024 09:16 AM

Related issues 2 (0 open2 closed)

Has duplicate New Model #4897: Icom IC-R6Closed06/11/2017

Actions
Has duplicate New Model #10647: CHIRP 2 and IC-r6 - Roberto from ItalyRejected06/17/2023

Actions
Actions #1

Updated by Eric Dropps about 9 years ago

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

Actions #2

Updated by Johan Nilsson about 9 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.

Actions #3

Updated by Kristian Sørensen about 8 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?

Actions #4

Updated by Mark Schaffer about 2 years ago

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

Actions #5

Updated by Steef Pieters 10 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

Actions #6

Updated by John Bradshaw 8 months 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.

Actions #7

Updated by Dan Smith 8 months 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.

Actions #8

Updated by John Bradshaw 8 months 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).

Actions #9

Updated by Alexandre J. Raymond 6 months ago

Actions #10

Updated by Karsten Rohrbach 4 months ago

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?

Actions #11

Updated by John Bradshaw 4 months ago

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.

Actions #12

Updated by Mike G 4 months ago

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.

Actions #13

Updated by Dave Ratcliffe 4 months ago

I have an RC-6 that's been on a shelf for a bit. Here's the ICF file I
just dumped from it using iCom's software V. 1.0

There's a mix of aircraft, and 2m, along with the local WX freq.

Hope this helps.

On 7/8/2024 12:06 PM, John Bradshaw wrote:

Actions #14

Updated by John Bradshaw 4 months ago

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.

Actions #15

Updated by Mike G 4 months ago

John Bradshaw wrote in #note-14:

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.

I agree with what Dan said and understand understand your point of view. :-)

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.

I needed to CTRL-C at then end, the scanner showed that it was done uploading but the python code was still running, maybe buffering or something. Anyway output is attached.

I don't have much configured in my radio, I bought it in Canada a few years ago. It should have the full untinterrupted frequency range.

Let me know if there is anything else I can do. I can't make an ICF.. no windows, just Linux. :-) But I can init/reset my radio and send a new dump if needed.

Actions #16

Updated by John Bradshaw 4 months ago

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.

Actions #17

Updated by John Bradshaw 4 months ago

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.

Actions #18

Updated by Mike G 4 months ago

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

Updated by John Bradshaw 4 months ago

Hi Mike,

It's hacky Perl and only works with the ICF generated by CS-R6, buyer beware but see attached :-)
Doesn't have everything that's in my local Chirp repo, mainly using it to extract certain fields of interest across all memories (frequency being the main one so you'll see "Freq:< 70>< 1>< 0>" and binary decodes of those for all channels).

Reads/writes stdin/out...
./decode_icf.pl my.txt

I could upload the current memory map and see what you make of it.. still a few unknowns in there which need explored but want to keep my head in frequencies (and get the code merged)

CS-R6 ICF has 16-bytes of data per line (without checksums), the radio sends 32-bytes at a time (with checksums)
If you're up for some Python coding it might be useful to update the radio reader script to generate 16-byte ICF lines. That'd let everyone dump their radios into CS-R6 compliant ICF format which Chirp can also open.

Have attached a random ICF and the text decode of the same.

CS-R6 has an "Auto" TS-step (it's in your ICF) and rounds frequency to the closest valid frequency if that's set. Chirp just rejects anything that's not a multiple of the known steps. I prefer the CS-R6 approach, but we might need to force the TS to a numeric value when opening an ICF or reading a radio in Chirp just to keep things moving. Going to ask on the developers' email list about that.

That "Auto" model isn't documented in the manual but it's definitely in the ICFs... decoder will show it as 14 decimal: "TS:<14>". I'll have to check if I can set it via the "front panel" on my global model.

The BCD nibbles are only for the C-IV commands, it's saved as multiples of the TS internally (see it increment by 1 for each 5kHz frequency step, there's other flags there which make the radio use the 6.25, 8.333 or 9kHz steps as part of those 3 bytes).

Page 14 talks about the 9kHz band: "Typically, the AM mode is used for the AM broadcast stations (0.495–1.620 MHz) and air band (118–135.995 MHz), and WFM is used for FM broadcast stations (76–107.9 MHz)."
Have confirmed CS-R6 only allows 9kHz TS for frequencies in that broadcast band, anything just either side of that has the 9kHz option disabled (red cross/X beside it) in the GUI. Want to add those checks in Chirp (don't want to brick someone's radio for lack of checks). The GUI offers some protection by rejecting invalid frequencies (that aren't a multiple of any known TS) but need to further restrict the 9kHz TS to only the "radio allowed" AM band.

I've swept the 9kHz AM band (easily done in CSV then importing into CS-R6) and see same increment of 1 for each 9kHz step - but with some flag bits set.
That logic should extend to the 9kHz multiples in the other bands (even if CS-R6 says the TS is 5kHz it's storing the freq as a multiple of 9kHz - that's what was apparently breaking the pattern of frequencies very 9x 5kHz lines). Going to try that out soon as it seems to be preferring that encoding to 5kHz jumps and then the rest should be fairly easy to code.

May leave the 8.333kHz aircraft mode for now, get something uploaded and put aircraft into the "10% backlog". Unless any aircraft followers have an ICF or are willing to run the Python dumper above?

Actions #20

Updated by Dave Ratcliffe 4 months ago

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:

Actions #21

Updated by John Bradshaw 4 months ago

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

Actions #22

Updated by Karsten Rohrbach 4 months ago

Here's a dump from my IC-R6. I added an AM channel with 8.33kHz tuning step at memory position 600.
Don't hesitate to tell me when I should try something different. I'd be happy to help.

Actions #23

Updated by Karsten Rohrbach 4 months ago

Karsten Rohrbach wrote in #note-22:

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

Actions #24

Updated by John Bradshaw 4 months ago

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.

Actions #25

Updated by Mike G 3 months ago

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.

Actions #26

Updated by John Bradshaw 3 months ago

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.

Actions #27

Updated by Dan Smith 3 months ago

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.

Actions #28

Updated by John Bradshaw 3 months ago

Icom IC-R6 Driver

To do:

  • Some settings not coded in GUI as yet (mappings are present in memory if anyone wants to test them)
  • TS (Time Step) is disabled at present
  • 8.3kHz aircraft frequencies need checked (this is main channel frequency, not TS)
  • TSQL
  • DTCS
  • Channel Bank entries
  • Scan Edges
  • Scan Links
Actions #29

Updated by John Bradshaw 3 months ago

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.

Actions #30

Updated by John Bradshaw about 2 months ago

Hi everyone,

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

Regards,
John.

Actions

Also available in: Atom PDF