CHIRP

Yeah, the upload is failing on the first block. All icoms reset themselves after any failed clone-in operation. They also reset themselves if there's anything in the inbound image they don't like. Have you maybe upgraded the firmware in the radio since the last time it worked, or when was that? I also just talked to someone locally that used this driver with their radio without a problem.

Nothing has changed with this driver in a few years, so I don't think there's anything software-wise going on here. I would guess potentially cable driver or connectivity issues since the very short exchanges to identify the radio seem fine, but the first large block failed.

I only updated to the newest Chirp.
I found it weird that it would download from the radio with no issue but wouldn't upload. Would that be normal?

Yahoo Mail: Search, Organize, Conquer

On Tue, Oct 8, 2024 at 4:38 PM, Dan Smithredmine@chirpmyradio.com wrote:

Yeah, that's a common symptom of bad communication. On Icoms, during download, the computer just sends "okay give me what you got" and the radio spews the whole thing out (aside from a little more handshaking at the end). On upload, it's the computer doing all the talking. It's not unusual for a bad connection or OS serial driver issue to impact one method more than the other. Other radios are much more chatty during both processes which makes them more susceptible regardless of upload or download.

What sort of cabling are you using?

Any idea what version of chirp you were running before? The chirp 5100 driver was touched in June, but as part of a larger change that affected basically everything. Before that it was January 2023 that any actual runtime change was made:

https://www.chirpmyradio.com/projects/chirp/repository/github/changes/chirp/drivers/id5100.py?rev=master

Maybe go back and try the earliest build from before that wide change and see if that has any effect?

https://archive.chirpmyradio.com/chirp_next/

If so, that'll be a good data point.