New Model #2745

Icom IC-2730A

Added by TIm Carson almost 4 years ago. Updated over 1 year ago.

Status:Feedback Start date:07/20/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Equipment Loan Offered:Yes

Description

Icom IC-2730A please add support for this very popular radio

ic-2730a_read.log - Portmon log (102.1 kB) Rob Owens, 10/26/2016 07:13 am

ic-2730a_download.icf - Icom download of radio settings (46.9 kB) Rob Owens, 10/26/2016 07:13 am

KB2MXV 2730.icf (46.9 kB) Frank D'Amato, 04/03/2017 04:05 pm

s-l1600.jpg (71.6 kB) Aaron Crawford, 10/23/2017 06:05 pm

Icom_IC-2730A.img (20.8 kB) Rhett Robinson, 01/06/2018 02:13 pm

Icom_IC-2730A_20180115.img (20.8 kB) Rob Owens, 01/15/2018 03:22 pm

20180115.icf (46.9 kB) Rob Owens, 01/15/2018 03:22 pm

Icom Read Screen Shot.PNG - Changing of frequencies on read. (23.9 kB) Aaron Crawford, 01/28/2018 05:29 pm


Related issues

duplicated by New Model #3219: Icom IC-2730 Rejected 01/25/2016
duplicated by New Model #3153: Icom IC-2730A Rejected 01/10/2016
duplicated by New Model #3221: support IC-2370E Rejected 01/25/2016

Associated revisions

Revision 2946:ebcb6aeda1b8
Added by Rhett Robinson over 1 year ago

Adds support for a raw-mode Icom driver. This is required for the IC-2730A (part
of #2745).

Revision 2947:30023a69e963
Added by Rhett Robinson over 1 year ago

[ic2730a] Add support for Icom IC-2730A. Fixes #2745.

Revision 2948:0ac31753af9e
Added by Dan Smith over 1 year ago

[ic2730] Add test image for Icom 2730A from Rhett

Related to #2745

Revision 2951:05f340866a9c
Added by Rhett Robinson over 1 year ago

Update IC-2730 driver to swap which byte is considered DTCS.

I sniffed the traffic the official software sends to the radio, and it only
changes the second byte, so that seems to be where dtcs is stored.

Addresses #2745

History

Updated by Tom Hayward over 3 years ago

  • Status changed from New to Blocked

This is blocked until an equipment loan is offered to a developer. See rules for loaning a radio if you are interested.

Updated by Rob Owens over 2 years ago

I'm not a developer, but I'd like to help with this if I can. I just got a new IC-2730a and an aftermarket programming cable. I ran Portmon and captured a "read" using the Icom software. I've attached the Portmon log as well as the saved download of the radio's settings. The first thing I noticed is that there are two different baud rates set. Even if that weren't the case, I wouldn't know where to go from here. The advice on the wiki "You're a smart developer. You should be able to figure out the protocol from here!" doesn't really apply to me, unfortunately.

Is there a developer who would be willing to work with me on this? If there are any developers near northern NJ, I'd be willing to take the radio to you so we could work on it together. If this works out, I hope to work on getting support for my IC-2710h as well.

Updated by Rob Owens over 2 years ago

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/

Updated by Louis Erickson over 2 years ago

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?

Updated by Tom Hayward over 2 years ago

  • Status changed from Blocked to Feedback
  • Priority changed from High to Normal
  • Equipment Loan Offered changed from No to Yes

Updated by Aaron Crawford over 2 years ago

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.

Updated by Rob Owens over 2 years ago

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.

Updated by Frank D'Amato about 2 years ago

Robert Owens - Your cable works with Chirp?

Updated by Frank D'Amato about 2 years ago

I received a 2730A today. Here is a ICF file from it using the Icom CS-2730

Would like to see this model work with chirp

Updated by Rob Owens about 2 years ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Aaron Crawford over 1 year ago

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?

Updated by Rob Owens over 1 year ago

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

Updated by Rob Owens over 1 year ago

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

Updated by Aaron Crawford over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Aaron Crawford over 1 year ago

Well I got a working cable now. Turns out the other one was a dud. I tried rolling back the driver and also plugged it into my mac and attempted transfers between computers with the same results. The seller sent me a new cable no questions ask. I got it on Saturday, plugged it in it installed the latest FTDI driver, fired up the Icom CS-2730 software and it worked just fine.

Anyone looking for a cable that has the FTDI chip this one works well: Look up "OPC-478 IC-2730" on eBay or Amazon (http://a.co/7yRbJlq). Sellers name is Mark, KJ6ZWL and goes by BlueMax49ers on both sites. Once I got a good cable it was flawless. I personally have had issues with cables with Prolific chipsets, but there are some similar issues with FTDI chips too, I've just never encountered them.

Updated by Aaron Crawford over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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

Updated by Rhett Robinson over 1 year ago

I'm attaching the test image used for this radio. Patch should be sent out in a few minutes.

Turns out the radio expects certain bytes sent to the radio as part of the payload to be encoded: 0xfa should be sent as 0xff 0x0a, up to 0xff sent to 0xff 0x0f. That had me confused for a while.

Updated by Aaron Crawford over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Aaron Crawford over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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?

Updated by Rob Owens over 1 year ago

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

Updated by Rob Owens over 1 year ago

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.

Updated by Rob Owens over 1 year ago

files attached:

20180115.icf
Icom_IC-2730A_20180115.img

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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

Updated by Rob Owens over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rhett Robinson over 1 year ago

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.

Updated by Dan Smith over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Rob Owens over 1 year ago

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.

Updated by Aaron Crawford over 1 year ago

Hello Guys,
Sorry, I didn't get a chance to test and provide feedback until now.

Firstly, yes I can confirm that the "CLONE END" after writing to the radio is a normal behavior. The stock Icom firmware does this as well and specifically mentions in their PDF that you will need to power cycle the radio after writing to it.

I am testing with CHIRP daily-20180123. While I have not had the time to perform detailed testing. Here is what i have found. When I read from the radio some the frequencies out of the ham band get changed into 12GHz values in chirp. I have attached a screen shot. These are FRS/GMRS freqs. I was going to attached the IMG file, but it lock chirp up when I try to save it. I have to force quit Chirp. I tried a couple times with the same results.

I was able to save the file after deleting the dozen or so bad reads. I added 1 test channel with DTCS and I was able to write that back to the radio OK. And it shows as having DTCS on the screen.

That is just some of my quick observations at this time.

Best Regards,
Aaron - N3MBH

Updated by Rob Owens over 1 year ago

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?

Also available in: Atom PDF