New Model #2795
openIcom IC-R6
0%
Description
Icom IC-R6
Files
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.
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.
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?
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.
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
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.
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.
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).
Updated by Alexandre J. Raymond 6 months ago
- Has duplicate New Model #10647: CHIRP 2 and IC-r6 - Roberto from Italy added
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?
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.
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.
Updated by Dave Ratcliffe 4 months ago
- File IC-R6 7-8-24.icf IC-R6 7-8-24.icf added
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:
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.
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.
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.
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:
- 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.
- 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.
- 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:
- 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.
- 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.
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:
- 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.
- 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
- File decode_icf.pl decode_icf.pl added
- File lots_of_145_named4_no_key_beep_vol26.icf lots_of_145_named4_no_key_beep_vol26.icf added
- File lots_of_145_named4_no_key_beep_vol26.txt lots_of_145_named4_no_key_beep_vol26.txt added
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
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>
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?
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:
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).
Updated by Karsten Rohrbach 4 months ago
- File 20240720+air600.icf 20240720+air600.icf added
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.
Updated by Karsten Rohrbach 4 months ago
Karsten Rohrbach wrote in #note-22:
Here's a dump from my IC-R6.
(EU version)
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.
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.
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.
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.
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
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.
Updated by John Bradshaw about 2 months ago
Hi everyone,
Did anyone try the test version attached above? Any feedback/issues?
Regards,
John.