Project

General

Profile

Actions

Bug #10279

closed

ICOM ID-880h Upload after Download problem

Added by Lyle Giese almost 2 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
01/15/2023
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next (py3)
Model affected:
ICOM ID-880H
Platform:
Windows
Debug Log:
I read the instructions above:

Description

I have an ICOM ID-880H radiio, used but new to me. In the legacy CHIRP and in the latest CHIRP-Next(next-20230115), the Settings page is not showing all the internal settings of the radio as reported by ICOM's software(CS-80/880).

I have stumbled upon an anomaly that may be just the way it is type issue with CHIRP Next. Download from ICOM ID-880H, screen on radiio changes to CL OUT and CHIRP Next reads the radio. Try to upload, screen should change to CL IN, but does not. The following error is displayed:

Failed to communicate with the radio: Did not get clone result from radio.

Power cycle radio and now you can upload. Screen on radio changes to CL IN and when finished uploading, CL END requiring a power cycle on the radio(this is normal behavior).

CHIRP daily-20221217 (classic) on Linux does not have this problem. You can download and then upload to radio and at the end of upload, CL END requires a power cycle.


Files

chirp_debug-coj_re3lID_880h.zip (5.85 KB) chirp_debug-coj_re3lID_880h.zip Lyle Giese, 01/15/2023 09:01 PM
chirp_debug-tu4xqw8v.txt (40.3 KB) chirp_debug-tu4xqw8v.txt debug from upload session. Lyle Giese, 01/15/2023 11:09 PM
chirp_debug-1q0aea_v.txt (41.5 KB) chirp_debug-1q0aea_v.txt From today's download/upload session. Lyle Giese, 01/16/2023 09:05 PM
Actions #1

Updated by Dan Smith almost 2 years ago

  • Assignee set to Dan Smith

Please don't zip your debug logs, it makes it more work for us to view the log in the issue tracker here.

Can you try closing chirp between your download and upload steps, without power cycling the radio? That will help identify if it's something stuck in the running CHIRP or something actually with the state of the radio.

Actions #2

Updated by Dan Smith almost 2 years ago

I just dug out my ID-880 to test this. It looks like from your log you're using the speaker jack method, so I connected it with my OEM OPC-478 cable and an FTDI USB-to-serial adapter to my Windows 10 box. Download, upload, download, upload all worked properly back to back.

What kind of cable and USB adapter are you using?

Actions #3

Updated by Dan Smith almost 2 years ago

  • Subject changed from ICOM ID-880h to ICOM ID-880h Upload after Download problem
Actions #4

Updated by Lyle Giese almost 2 years ago

Valley Enterprises Icom OPC-478 USB FTDI Chipset Two-Way Radio Programming Cable Purchased via Amazon. Yes, it uses the speaker jack for it's interface.

Just downloaded from radio, good. Closed and reopened CHIRP-NEXT, upload failed. Closed upload dialog window only. Retried upload and it worked 2nd time.

Actions #5

Updated by Dan Smith almost 2 years ago

The log (both the first one and this one you just uploaded) shows that the radio does indeed respond to the second upload request. CHIRP does several back-and-forths with the radio, and then it starts sending the image, but the radio never responds with the end frame. Are you sure the radio's display never goes into CL IN?

Actions #6

Updated by Lyle Giese almost 2 years ago

Yes, the radio does not go into CL IN. CHIRP_NEXT shows the upload progress bar and fails after appearing to go through a normal upload by the speed of the progress bar.

Actions #7

Updated by Dan Smith almost 2 years ago

Okay, I feel pretty confident that something is up with the radio if that's the case. The radio should go into CL IN mode as soon as it responds to our request to send the image (before we do), which it does. I think that if you were able to download, close, upload-fail, upload-succeed that means that it's not CHIRP-next specific and it's the radio being flaky. The ICF (Icom Clone Format) module for the last chirp-daily build is almost identical to what is in chirp-next currently, for this type of radio.

Have you tried hard-resetting the radio to see if it improves its behavior? The radios do have limited write cycles on their EEPROMs, after which they start to get really flaky in that they take some writes and not others. It takes a LOT of writes, but it does happen, so it's possible that this radio is starting to suffer.

Actions #8

Updated by Lyle Giese almost 2 years ago

Yesterday, I did do a full reset of the radio. The full reset did not clear the memory however. I would have thought it would have gone back to factory. But after that, it was working.
Now today I tried again, downloaded, tried to upload, failed. Power off the radio, power up and upload worked.

BTW the download does restart the radio when complete.

We can say this radio is flaky and that's fine with me as it's a used radio I purchased in November.

Thanks for looking at this.
Lyle, W9LRG

Actions #9

Updated by Dan Smith almost 2 years ago

  • Status changed from New to Rejected

Yeah, resetting the radio should absolutely erase all the memories on an Icom. That's a huge red flag to me that something isn't right with the radio.

So yeah, I'll close this as "rejected" which is what our tool calls "not a bug".

Actions

Also available in: Atom PDF