CHIRP

It looks to me like you have a very old copy of chirp. Since you're running from source, there's no build number to see for sure. Not sure where you got it, but please update to the latest source and try again. See https://github.com/kk7ds/chirp .

Hello Dan,

thank-you for your fast answer.
As written above, I was using the version coming from the Debian "Bookworm" repository, via apt-get.
I will try to install from source, in any case.

Regards
U

PS By the way similar error ("unexpected response from radio" is happening on my Windows 11 "today" Chirp version, but I will open a different issue tomorrow

As written above, I was using the version coming from the Debian "Bookworm" repository, via apt-get.

Your only mention of debian was in the uname output so I didn't realize. I have no idea what rev they have, but it's very (very) old and would definitely not be expected to work on modern python.

I will try to install from source, in any case.

If you install the wx deps that you'll need for source, the whl file I publish should be fine at that point. See Running_Under_Linux.

PS By the way similar error ("unexpected response from radio" is happening on my Windows 11 "today" Chirp version, but I will open a different issue tomorrow

That's a very different error, but yep, open a new bug with a debug log and I'll have a look later today.

Hello,

sorry for the delay in answering.
At the moment :

a) I have installed the today version from git clone https://github.com/kk7ds/chirp.git
b) I have executed chirpwx.py without "setup"
c) the result is different from before, but still negative : any attempt to connect the E90 returns "Failed to communicate with the radio: Unexpected response from radio" error
d) despite the execution of chirpwx.py in "developer mode", I'm unable to fine the debug.log in any folder (.chirp is empty), than I can not provide it to you.
I saw from some italian forums, that it's not the first time that E90 generates problems with chirp, and a version of about one year ago works well : can you provide it to me, in order to compare the result ?
Of course, no problem of connecting a Baofeng UF-5R on the same serial port (but of course using a different USB interface)

Please advise
Thank-you
Ugo

b) I have executed chirpwx.py without "setup"
c) the result is different from before, but still negative : any attempt to connect the E90 returns "Failed to communicate with the radio: Unexpected response from radio" error
d) despite the execution of chirpwx.py in "developer mode", I'm unable to fine the debug.log in any folder (.chirp is empty), than I can not provide it to you.

Please don't run chirp in developer mode, it will not make things better. If you're running from the command line, chirp won't create the debug log because it's logging to the console. Try something like this:

$ ./chirpwx.py </dev/null

Once you have reproduced the issue, your log will be in ~/.chirp/debug.log.

I saw from some italian forums, that it's not the first time that E90 generates problems with chirp, and a version of about one year ago works well : can you provide it to me, in order to compare the result ?

I don't know what version they're talking about. Perhaps the legacy python2 version, but you won't be able to run that on a modern linux system.

  File "/home/ugo/Chirp/chirp/chirp/drivers/icf.py", line 214, in get_model_data
    raise errors.RadioError("Unexpected response from radio")
chirp.errors.RadioError: Unexpected response from radio

This means it's unable to talk to the radio at all. Different from the issue you quoted in the subject line. Make sure the radio is powered on, not in clone mode, and that your serial connection to the radio is set. This error is almost always the result of a bad serial connection. Like, trying to download from the radio with no radio connected will generate that same error.

What green light are you talking about? If some light comes on when you plug in the cable, that's likely a bad sign. I have a lot of experience with Icom radios and none of them show any indication when the cable is plugged in. Is it going into transmit mode (i.e. RF transmit, like PTT) when you plug in the cable? If so, that will absolutely prevent it from cloning.

If it does go into TX mode, is that as soon as you plug in the cable, or only once chirp starts trying to download from it? Can you point me to the exact cable you have with a link or something?

One other thing, can you set CHIRP_TRACE_ICF=y and then capture a new debug log? That will give more information to confirm that it's not hearing from the radio. Something like:

$ CHIRP_TRACE_ICF=y ./chirpwx.py </dev/null

Dan,

you are too fast for me, thank-you.
I will post a picture of the green light tomorrow (I have not the radio with me).
The green light I'm dealing with is the same light that becomes red when the radio goes in transmission mode and becomes green when the squelch is fully switched off.
This led is located at the low left corner of display of the E90.
The cable I'm using it's this one :

https://www.amazon.it/dp/B0BDM1CSTL?psc=1&ref=ppx_pop_dt_b_product_details

of course not ICOM original.

Thank-you for your support
Ugo

Okay, that LED is only for squelch, not anything else AFAIK, so I would treat that as a strange sign, not a good one. I would increase squelch to see if the light goes out, and also see if the S-meter goes up when you plug the cable in.

In addition to the extra tracing I asked for, please also try from this branch:

https://github.com/kk7ds/chirp/tree/bug/11191/ice90

This was a hack added to the base icom cloning code for the E90 itself, but after some cleanup a few years ago, it seemed like it wasn't really required. So please try with that back in and let me know if it helps.

While fixing the tests to work with the un-reverted hack, I encountered your original error message (about concat str to bytes), which makes me think that we're on the right track here. When you test from the other branch, please make sure you're on a230e9bb so that the fix is applied.

Hi Ugo,

Sorry I transposed the internal and external variable in my head. The actual variable you need to set is:

CHIRP_DEBUG_ICF=y

The hash won't show up in the about menu, but before you run it, you can run git rev-parse HEAD before you run chirp to make sure. Was hoping to see some improvement with that branch, which is unfortunate...

I just pushed another debug patch to make sure that it's running the E90-specific munch code. So you should be on:

$ git rev-parse HEAD                                                     
f4861051a3127b0728deee9b9155e88ca0108632

Hello Dan,

it was the right branch.
In any case,I have cloned it again.
Unfortunately I'm at work and I can check the radio only late in the afternoon, letting tou know the result.
In any case, the machine is accessible via ssh and VNC and I can let the E90 branched, if it can help you to understand faster.

Thank-you
Ugo

Hello Dan,

you can close this issue : the problem was related to the interface cable I owned, that was wrongly declared to be ok for the E90, but this is not true.
After a couple of cable changes, I was able to synch the E90s with the current version of Chirp in Windows (I will try in Linux soon).
Sorry for the annoyance and thank-you for your help

Best regards
Ugo