CHIRP

To read the *.icf file I attached, you can download Icom's software for free here:
http://www.icom.co.jp/world/support/download/firm/IC-2730A_E/1_00/

I have a radio I'm not using much right now that I could loan to a developer to get this feature implemented. I have the (horrible) ICOM software for it as well.

I'm willing to do the shipping two-step described in the link above.

Who do I need to talk to next?

I have an IC-2730A as well. I would love to see chirp support added for this and it's encouraging to see someone has offered a loaner to a developer. I am a web developer, but am still working to learn how to make chirp drivers. Still a steep learning curve for me. I am trying to make a driver for a KG-UV8T using a KG-UV8D driver but still learning how things work.

I am willing to test the IC-2730A driver with my radio and offer feedback. I don't have a cable for it, so I would need to pick something up or cobble one together with a USB to TTL converter. Let me know if I can help in that way.

I bought this cable for $14 and it works with my IC-2730a: https://www.amazon.com/gp/product/B0092D3E8Q/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

If you search amazon for OPC478 you'll find several cables available. There is even one for $9, although there are no reviews for it. Even at $14, it's way cheaper than Icom's cable.

Robert Owens - Your cable works with Chirp?

Frank D'Amato - Sorry, I wasn't watching this thread so didn't get an email notification. My cable works with the Icom software on my IC-2730a. So I assume it'll work with Chirp once Chirp supports this radio.

Just giving this issue a kick to see if it's still alive... I would love to see support for this radio. Hopefully Louis Erickson is still willing to loan his equipment.

Rob, I just purchased a similar cable from a vendor on eBay that does programming cables. Mine has the FTDI chipset in it where I think the one you listed on Amazon has the Prolific chipset. I don't know if there is issue with the cable or not, I am still trying to work that out with the vendor. I cannot get the Icom CS-2730 software to work. The cable shows up in device manager with a com port number but when I start the Icom software, it lets me select the port, but gives me an error that it cannot communicate with the transceiver. It is suppose to be a half duplex cable I believe, but without the cable plugged in I can do a loop back test on it with a terminal program...which I find weird.

I tried another usb/serial converter (Silicon Labs CP2102) and tried to breadboard an interface, but when I try to communicate with the radio the Icom software tells me that it cannot find find/open the com port. The comport works just fine in a loop back test. So I am getting 2 different errors from the icom software depending on the converter being used. Do you have any trick to make it work? Do I need to set my baud rate, parity, stop bits, etc to a certain value?

Aaron, I did not have to do any special tricks. I checked my cable today. Device Manager shows it is a Prolific chip and it reports the COM port number. In the Icom software, all I needed to to was specify the correct COM port for my cable and it worked.

Be sure you have the cable plugged into the correct speaker jack on the radio. Only one of them will work. I don't remember off the top of my head which one it is.

Also, take a look at this site to see if you are affected by the FTDI driver that disabled counterfeit chipsets: http://www.miklor.com/COM/UV_ClonedChips.php

It looks like FTDI did it again more recently: https://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/

The cable is suppose to plug into SPK 2.

Well I did some more testing last night with the cable. The weird thing is, it shows up in device manager and gets a port number. I can get it to do a loop back test on itself and get legit data back, but that is without it plugged in. I wouldn't think it would do that if it is a half duplex cable.

I tried some additional test with other interfaces and the OPC478 cable.

Computer to Computer (CoolTerm) - Same port settings

• Wouxon/Baofeng Cable (FTDI) to Silicon Labs CP2102 UART Bridge - This has no problems communicating in either direction. Text comes out as expected on both ends.
• Generic OPC478 cable (FTDI) to Silicon Labs CP2102 UART Bridge - TX from CP2102 is received by OPC478 but garbled characters, TX sent from OPC478 is not received by CP2102. The CP2102 is validated as working in the above test, It receive it's own loop back on the chip set, but it doesn't seem to get out the cable. My guess is there is something either internally wrong with the chip or there is something wrong on the cable side circuitry, perhaps a solder bridge?

I wanted to see if I could breadboard an interface to bypass the cable and rule out the radio using the CP2102, but the Icom software doesn't seem to like that chipset for whatever reason. When I try to connect to it it gives me the error that it cannot connect to that comport, even though it works fine with CoolTerm (yes CoolTerm is closed). I get a different error with the generic OPC478 cable, It seems like it tries, but comes back and say that the transceiver is not responding. So it recognized the FTDI chip, but doesn't get farther than that...likely because of the test results above.

From your post above Rob, I am wondering if it could be a driver issue / counterfeit chip. Maybe I will see if I can find an older driver just to see. It seems like it is garbling text in one direction. I am waiting to hear back from the cable guy, he mentioned about sending another cable, but I haven't heard from him since Friday. I will give him a fair shake before, I go down the dispute road.

Hopefully I will get it resolved soon. The Icom Cable is 3 times the price and I want to find something that will likely work with Chirp once someone else, or myself get around to trying to write a driver for it.

The garbled text in one direction could be this (from the hackaday.com article): "the latest FTDI drivers will inject garbage data into a circuit." I guess trying an old driver would be a good move. Just be sure to avoid the ones that brick the counterfeit chips.

I see there is a supported driver for the previous generation radio, the IC-2720H. Hopefully when one of us gets around to trying to figure out a driver this will serve as a good code base. I cannot imagine ICOM would have changed a whole lot. It basically looks like a refresh of the same radio.

I recently purchased one of these and am making progress on supporting it. I hope to have a patch ready in a few more days. There are some notable differences from existing ICOM drivers requiring changes in icf.py to support, but not too significant.

Excellent! Let me know if there's anything I can do to help, test, etc.

Status update: I have successfully written to my IC-2730A with Chirp! I am still working on finishing mapping the memory (need to map out skip settings and the two call channels, at least, and see if there's anything else). Plus I haven't yet looked at tests.

The differences I've found so far for the new driver:

• It uses raw bytes instead of BCD
• The bytes coming out of the radio need to be decoded by having their high-order bit flipped (⁼ 0x80)
• The weirdest, when writing the checksum, if the checksum > 249, the checksum becomes two bytes: 0xff, checksum & 0x0f.

The first one can be easily supported in icf.py. The second one can be supported in the driver file, although it's a bit awkward, because the way icf and the driver interact, you need to special case get_mmap so when saving the images to a file you save the decoded bytes, but don't double decode them when loading the image.

The third one, however, I'm going to want to spend a bit more time thinking about. Granted, this is the only Icom radio that sends bytes raw, but it feels like a very weird thing to do, and I'd prefer to write that in a way that this Icom radio can customize without there being too much custom code in icf.py. One option might be to add a get_checksum(bytes, raw=False) that returns the string, and call that from within send_clone_frame, and override it for this radio.

Also incidentally, while the checksum sometimes works, it doesn't always, so I am still working on trying to figure that out.

Rhett, I will see what I can do to help you out with testing. Unfortunately, my IC-2730a is permanently mounted in my truck and is not easily removable to bring into the shack. when I program it, I have to go out to the vehicle with a laptop and fold down rear seat and plug into the RF deck. I would just need to test while I have an evening or weekend with some free time and it's not freezing outside. But I'd definitely be willing to try and offer you some feedback.

Aaron,

I have programmed my IC-2730a through an extension cable and it worked fine. Here's a link:
https://www.amazon.com/iMBAPrice-Professional-Quality-Nickel-Extension/dp/B008R5J51U/ref=sr_1_8?ie=UTF8&qid=1515595824&sr=8-8&keywords=1%2F8%2Bstereo%2Bextension%2Bcable&th=1

Mine was 12 feet. Not sure if you will run into problems with longer lengths or not. Anyway, maybe that will allow you to program the truck radio from inside the house. This cable is also useful if you plan to install a remote speaker on your radio.

My car, with my IC-2730a in it, is in the shop and I plan to test as soon as I get it back.

Rob Owens wrote:

Aaron,

I have programmed my IC-2730a through an extension cable and it worked fine. Here's a link:
https://www.amazon.com/iMBAPrice-Professional-Quality-Nickel-Extension/dp/B008R5J51U/ref=sr_1_8?ie=UTF8&qid=1515595824&sr=8-8&keywords=1%2F8%2Bstereo%2Bextension%2Bcable&th=1

Thanks for the suggestions Rob. I had considered a shorter extension so that I could program from the front seat where I can see the control head display. It is mounted in my center console and angled up. I don't need to worry about the remote speaker as I already have that in place. I made up a bunch of custom wiring (remote head extension, mic extension, speaker extension, and power) for mine and everything is concealed nicely. My programming cable is only 3ft so it is long enough where I can fold down the split rear seat, jack in to the rf deck, and sit the laptop on the folded down seat. I can then sit in the other back seat and program it. Only inconveince is I have to jump out of the back seat and up to the front seat to verify the programming and power cycle the radio. I may still pick up a 6 foot cable at some point. I just don't have a garage and it can get cold this time of year where I'm at.

I used daily build 20180115 to download from my IC-2730a this morning. Everything appeared to go well. No errors were shown on the radio or in Chirp. But only some of my memories were downloaded.

Chirp displays a grayed-out "ERROR" in the Name field for some of my memories, and no other data from those memories. Memories that were downloaded correctly seem to be assigned the correct Banks. The Bank Names tab contains no data. The Settings tab contains only a single setting: "Use Hi-Speed Clone". It is set to Enabled.

I retried the download and got identical results. Let me know if it would be helpful for me to list the exact memory locations had problems. The fact that Chirp didn't alert me to any problems should laso be considered a bug. I realize we are still in the early stages of support, so it's ok if that gets pushed off for a while.

Yes, if you can let me know how you have those memory locations configured that got errors programmed, that would be helpful. Also, were you running such that you could get output errors? If so it might have left a stack trace or an error message that can help narrow down which field in memory caused an error. Did it correctly load memory locations after that slot?

I'm also still fairly new at both chirp and amateur radio, so it wouldn't surprise me if I've missed some things, yet.

Incidentally, I opened the test image from the 2820 and the 2720 and neither of those had any settings, so can you list out the settings you would expect to see?

I can't seem to upload attachments. Let's see if this comment makes it through.

I tried uploading my Chirp image and the Icom file, so you could compare, but the upload failed several times. The first error I see is in location 31. There are some "good" memories after that, then some more errors.

If you tell me how to get the trace you mentioned, I'll get it and upload it once uploads start working for me again.

Regarding settings, I'd expect to see just about everything that shows up in the radio's menu system. For example: screen contrast, beep volume, home channel, etc.

On the radio, what is memory location configured as? From the dump:
17 bytes at memory 0x020f: 00 72 db 00 78 00 18 08 ff 00 18 57 42 32 4e 51 56
Which translates to:
147.015 Mhz
0.6 Mhz offset
TS = 5.0
MODE = WFM
RTONE = 151.4
CTONE = 88.5
DTCS = 0xff, that one makes no sense, and seems likely where your read is failing.
DTCS1 (my notation) = 0x00 which would map to 23
TMODE = Tone
DUPLEX = +
DTSC_POLARITY = NN
NAME = WB2NQV

So based on that, I'm guessing the DTCS is where this failed at parsing.

When I was mapping the memory, it seemed that the radio was writing the DTCS index into two bytes (which was odd, so I arbitrarily chose the first byte), so let me play with reading it out of my radio a bit more and see if maybe I misread that or something. Other than that, the memory looks okay mostly, so let me know if what I wrote above matches the configuration you had stored. It seems likely there's a bit of a hiccup around those two bytes, I'll try to narrow in on that.

DTCS is not set for any of the memories. The Icom software shows a value of 023, but it is grayed out. This is the same for all the memories programmed into the radio. I guess "not used" is a better description than "not set".

All the other data you listed looks right to me. CTONE and DTCS_POLARITY are not set / not used, but the Icom software shows grayed out values which match the values you read.

If you have the Icom software available, you can see this for yourself using the attached 20180115.icf file. I don't mind checking for you, though.

Yeah, if it is set to the default, I think it'll show up as not used.

I do have the Icom software (running via wine, but it seems to work). On my radio, it seems like the DTCS code is stored redundantly in two bytes (e.g. when the only thing I do is change the DTCS code, the memory diff shows two bytes updated to the same value). It's possible that I can just treat the second byte as the correct byte instead of the first. Based on my radio, that will work just as well, and based on your radio, at least what I'm seeing, it ought to work. I'm curious what that other byte is doing, though. I haven't figured that out.

For the other settings, I'll need to study the chirp code a bit to see how other radios add settings to the UI; I mostly copied the existing IC 2820 driver, and it didn't have settings that I saw, which is why I don't have them in the UI. I've mapped at least some of them in memory, though, so hopefully won't take too much longer to add those.

Are you sure you didn't enable DTCS and set the DTCS code at the same time? Have you tried different DTCS codes to see if they all get saved identically in two bytes? Did you change the DTCS code through the Icom software or using the radio front panel?

If the other settings are easy to implement, great. If not, I'd put a much higher priority on getting the memory locations working well.

Yes, I tried multiple DTCS bytes. What I found is that the radio seems to set both bytes. I just set two different DTCS values on two different channels in the official software and sniffed the traffic, and sure enough, it sets DTCS in the second byte, not the first of those two. I'm submitting a patch to swap which byte is considered the DTCS byte, which I believe will address it.

I don't know why your radio had the other bytes set to 0xff, but this patch will ignore that rather than crash when parsing.

I'll continue looking at the settings, though at a lower priority until I find some more time again (the holidays were great for finding time).

On another radio I was working on, I found that if I made changes using the radio's front panel, a hexdiff showed that two memory locations had changed. When I made the changes using the manufacturer's software, only a single memory location would be changed. If you have been using the radio's front panel to change the DTCS values, I'd suggest trying to use the manufacturer's software to do it and see if you still see a change in two bytes.

I'll give a long-winded example of what I described above:

Tune the VFO to frequency 111.000. Save this as channel 1. Download and save the Chirp image.
Tune the VFO to frequency 222.000. Save this as channel 1. Download and save the Chirp image.
Do a hexdiff to find out where channel 1 is stored.

I found two memory addresses had changed, each from value "A" to value "B". In my attempt to change only the frequency saved in channel 1, I had also changed the frequency saved in the VFO. So it appeared that channel 1 was being saved identically in two different memory addresses, because "I only changed channel 1".

I think we're talking about two slightly different things. When I said it is setting two bytes, I mean this: for every memory channel, there are 17 bytes that store all the information for that channel. For example, the first three bytes store frequency, in kHz, divided by 5. For example, to store 111.000 MHz, it would store 111000 / 5 = 22200. In bytes, that is 0x00 0x56 0xb8. Of the remaining 14 bytes, when I set the DTCS on the radio front panel and dump the memory, two of the bytes get updated identically when I take a memory dump. For example, if I store DTCS = 23, those two bytes are 0x00. If I set it to 25, those two bytes both become 0x01. If I set all the way up to 754, those two bytes both become 0x67. However, if I set the DTCS within the manufacturer's software, it only sets one of those two bytes: the second byte. So far, I haven't found any use for that first byte. It is possible it's something I've overlooked.

So in this case, it is the memory contents of the channel. I haven't mapped out just the VFO/unsaved contents, I'm sure they are in there somewhere. I've also occasionally observed random other bytes that seem to change when I make only an isolated change. In some cases, when I repeat the change back and forth a few times, those bytes no longer appear in the delta, so I can reasonably ignore them and assume they're not relevant for that specific change. Yet another example I've found is a location that seems to simply increment on every change. I don't know why the radio would think it's important to keep track of how many times you've made a change to memory.

Anyhow, I do believe the patch I've got out will fix the issue, but will wait until it's been patched into daily and see if it works for you after that.

I used today's build to download from my radio, and the "ERROR" notations I spoke about in comment #27 are gone now. I'll do some more testing, but so far everything looks good. I do see memories 35-39 have no frequencies programmed, but a grayed out "S" appears in the Skip column. I can't remember if this radio ever had anything programmed in those memories or not.

Do you think it's reasonably safe to try writing to the radio? If so, I'll fill up every memory slot and make sure it all works.

If you are only worried about damaging your radio, yes, I think it's reasonably safe. I certainly hit mine with all kinds of bad data and nothing harmed it. If you're worried about actually correctly saving all your updates, I would say it's probably safe, but I'm not 100% sure I haven't missed any other edge cases like the DTCS snafu. Please give it a try and let me know how it works!

By the way, if you've only tried reading, that should be a non-destructive operation, so you can check your radio to see if 35-39 has anything in them. If it does and chirp didn't read it out correctly, I'd like to know that too.

I verified that the Banks tab is showing correct information, regarding the bank assignment and the index.

I verified that the radio does not have any frequency programmed in 35-39. I also used the Icom software to download from the radio and nothing shows in 35-39 (not even grayed out).

I don't know if this will be useful information to you or not: When I use Chirp with my Baofeng UV-5R, I've seen the phenomenon where a deleted channel retains grayed-out settings. For instance, if I select a memory location and choose "cut" rather than "delete", all the settings get grayed out rather than removed. If I then upload the image to the radio, the grayed out settings seem to be uploaded but the memory is not "active". If I then manually save a frequency into that memory location, the memory becomes active and it gets all those grayed out settings. So I'm always careful to "delete" any memories that contain grayed-out settings. I'm not sure if a similar thing could be happening with the grayed-out "S" in the Skip column, but I figured it was worth mentioning.

As of yet, I have not uploaded anything with Chirp to this radio. I will give that a try as soon as I have a chance -- hopefully in the next couple of days.

That makes sense. I believe Icom drivers in chirp by default zeros out memory when you delete a memory slot, but it's technically driver specific, so I don't know if all drivers do that. For this driver, if you save a memory as unused, it will get wiped when it's uploaded to the radio. It would be possible to set it to some other default value, but I don't know if it makes a huge difference.

I copied a bunch of memories from my Baofeng UV-5R image to an IC-2730a image. Several memories failed to copy (with an appropriate error message) because "Duplex off" is not supported. I don't know if it's possible to support that with this radio, but it is a handy way of disabling transmit. I use it in particular for the NOAA weather frequencies.

It would be nice if there was a way to add memories to a Bank in bulk. Currently you have to check a box for each one you want to add. If it could be done like the Properties dialog box allows you to change a setting for multiple memories, that would be great. I realize I'm getting a little picky here, so feel free to put this into the "wishlist" category.

I uploaded to the radio, and it seemed to correctly write the two memories I added. However, the radio never came out of clone mode. It said "CLONE END" on the radio front panel, if I remember correctly. I had to power off/on the radio in order to use the radio. I repeated this test and got the same results. I was testing with a very slow Windows laptop. I can test later tonight with Linux on faster hardware and see if there is any difference.

I think I get the same behavior when doing that with the official software. I have to restart the radio there too, and the official software prompts me to restart. I think that is working as intended for this radio.

All Icom amateur radios require a restart after cloning. CLONE END means "successful".

I think they do this to prevent you from automating usage of the radio by just pushing new memory into the radio and then having it reboot and start working (i.e. to make a dynamic receive station for example). On some part-90 radios, they do this because part-90 prevents you from having automated frequency agility capability in the radio. Perhaps it's a holdover from Icom's commercial gear.

Anyway, every icom I've ever programmed from the computer does this, so .. nothing new.

You guys are right. I guess it's been a long time since I uploaded with the Icom software, because it does behave the same way.

Using Chirp, I uploaded about 80 memories and assigned them to a bank. It all looks to be working fine.

Tonight I'm going to try to find the addresses for the C0 and C1 calling channels. They are a little different from the other memories because they can't be assigned to a bank and they can't be set to skip in a scan. But I'd like to get them into the Chirp gui if possible.

One thing I noticed is that if I cut and paste a memory from one location to the other, it loses its bank assignment. I'm not sure this is a big deal. I'm not even sure if I consider that behavior right or wrong. I'm undecided, I guess. But I wanted to mention it.

It looks like the C0 and C1 call channels are simply memory numbers 1000 and 1001. Can these be added to the GUI? Would it be easiest to put them in another tab, separate from memories 0-999, since the Skip column doesn't apply to C0 and C1?

A few observations after testing with my radio for the first time:

I'm able to read and write using CHIRP daily-20190601 on Linux. On the Mac version, however, a write ends in "All Reset" message (and a reset radio) rather than "Clone End".

Banks:

• The banks seem to be read (mostly) correctly from the radio, but I cannot assign or unassign them in CHIRP. If I click on a checkbox, it doesn't change.
• When I read from the radio, if a memory channel is programmed without a bank on the radio, it shows up as '0' frequency in the banks tab (as opposed to '0.000000' for empty memory channels), with everything grayed out. I'm still learning ICOM's banks, so I'm not sure what to expect here.

Thanks for your work on this!

I experienced similar behavior running CHIRP daily-20190601 on Mac. I could read from the radio successfully but the write never completed. The upload got stuck around the 30% mark and I eventually aborted the process, which resulted in a "All Reset".

Shout-out to all the contributors!

Looking forward to the update, Rick.

In my case it was a not a faulty frequency. I updated to 20190626 and tried the following: Programmed two stations on the radio, downloaded those from the radio (success) and tried to upload again, which never completed. Tried both, the high speed clone on and off.

Any debug output that would be helpful?

I finally realized what was preventing the banks from working as expected for me. The status message says '[0] Getting Bank information for memory xxx' where 'xxx' is a memory it doesn't like. So far, I've seen it balk at FM receive-only frequencies like 159.810 (railroad), but also 70cm frequencies with 12.5kHz steps like 444.862500, and 443.762500. So it seems to get stuck reading bank info on certain memories, rendering the banks tab unusable. Once I remove those from memory, the banks work fine for me.