CHIRP

Re Bug # 1113

I too have an Icom 2100H 2m transceiver and I also get the message "Unexpected response from radio" when I try to upload/download from the radio. This is under Linux Mint with the most recent version of Chirp.

I set the environment variable DEBUG=30, try Chirp and get the error.

The laptop is dual boot, Linux Mint and Windows7.

Last lines of debug.log when Chirp (Linux Mint)was tried to 'detect' radio:
...
[2020-04-17 13:23:02,391] chirp.ui.reporting - DEBUG: Server reports version daily-20200409 is latest
[2020-04-17 13:23:51,102] chirp.ui.reporting - DEBUG: Reporting exception
[2020-04-17 13:23:51,103] chirp.ui.inputdialog - ERROR: --- Exception Dialog: 'Serial' object has no attribute 'get_payload' ---
[2020-04-17 13:23:51,105] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 175, in run
cs.radio_class = detect.DETECT_FUNCTIONSvendor
File "/usr/lib/python2.7/dist-packages/chirp/detect.py", line 76, in detect_icom_radio
result = _detect_icom_radio(ser)
File "/usr/lib/python2.7/dist-packages/chirp/detect.py", line 43, in _detect_icom_radio
md = icf.get_model_data(ser)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 140, in get_model_data
send_clone_frame(radio, 0xe0, mdata, raw=True)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 174, in send_clone_frame
payload = radio.get_payload(data, raw, checksum)
AttributeError: 'Serial' object has no attribute 'get_payload'

[2020-04-17 13:23:51,107] chirp.ui.inputdialog - ERROR: ----------------------------

So then I retry, putting in the values for the port ttyUSB0, choose the vendor as Icom and model 2100 and when I click clone from radio, I get this error report:

last lines of debug file
[2020-04-17 13:27:51,235] chirp.ui.mainapp - INFO: Skipping existing stock config
[2020-04-17 13:27:51,238] chirp.ui.reporting - DEBUG: Checking for updates
[2020-04-17 13:27:51,483] chirp.ui.reporting - DEBUG: Server reports version daily-20200409 is latest
[2020-04-17 13:28:02,317] chirp.ui.mainapp - DEBUG: User selected Icom IC-2100H on port /dev/ttyUSB0
[2020-04-17 13:28:02,324] chirp.ui.clone - DEBUG: Clone thread started
[2020-04-17 13:28:02,578] chirp.ui.reporting - DEBUG: Reporting exception
[2020-04-17 13:28:02,579] chirp.ui.common - ERROR: -- Exception: --
[2020-04-17 13:28:02,581] chirp.ui.common - ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 256, in run
self.__radio.sync_in()
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 657, in sync_in
self._mmap = clone_from_radio(self)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 318, in clone_from_radio
raise errors.RadioError("Failed to communicate with the radio: %s" % e)
RadioError: Failed to communicate with the radio: Unexpected response from radio

[2020-04-17 13:28:02,581] chirp.ui.common - ERROR: ----------------
[2020-04-17 13:28:02,581] chirp.ui.clone - ERROR: Clone failed: Failed to communicate with the radio: Unexpected response from radio
[2020-04-17 13:28:02,587] chirp.ui.clone - DEBUG: Clone thread ended
[2020-04-17 13:28:02,598] chirp.ui.reporting - DEBUG: Reporting model usage: Icom_IC-2100H,download,True
[2020-04-17 13:28:02,612] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Failed to communicate with the radio: Unexpected response from radio ---
[2020-04-17 13:28:02,613] chirp.ui.inputdialog - ERROR: None

[2020-04-17 13:28:02,614] chirp.ui.inputdialog - ERROR: ----------------------------
[2020-04-17 13:28:02,614] chirp.ui.reporting - DEBUG: Reporting exception

And yes, I am a member of the dialout group. There is only one USB port connected to the usb-serial cable.

So, then I reboot into Windows7, no change in cable or usb port, and it all works!

I prefer to work in Linux so any suggestions would be welcome!

Peter, VE3BBN

More feedback:
Some Icom radios are known to deny cooperation with FTDI cables (even genuine ones). Please try a cable with a genuine Prolific chip.
Unfortunately cables with fake "Prolific" chips make the vast majority of cables on the market; genuine Prolific cables are on the more expensive side.