Bug #7905

Issue with ICOM radios in general

Added by Brian Harbaugh 11 months ago. Updated 9 months ago.

Status:Closed Start date:05/22/2020
Priority:Normal Due date:
Assignee:Martin Cooper % Done:


Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:Icom (many models)


I have an ICOM radio I am attempting to verify my install of Chirp with. I keep getting the same error every time

ERROR: --- Exception Dialog: 'Serial' object has no attribute 'get_payload' ---
ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 176, in run
cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port)
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 42, in _detect_icom_radio
md = icf.get_model_data(ser)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 141, in get_model_data
send_clone_frame(radio, 0xe0, mdata, raw=True)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/icf.py", line 176, in send_clone_frame
payload = radio.get_payload(data, raw, checksum)
AttributeError: 'Serial' object has no attribute 'get_payload'

ERROR: ----------------------------

This would seem to indicate that the "radio" being passed to the send_clone_frame function is in fact a serial object. I can't find anywhere in the documentation of pyserial where get_payload was ever supported. If it was, which version of pyserial do I need? I have tried pyserial-2.7 as well as 3.4 to no avail. I feel like this is probably a simple issue, but I can't figure it out to save my life.

Someone had a similar issue with #5531 in which Bernhard Hailer said it was a duplicate of #4545, but not only is the issue different, but the problem persists and no solution was offered. So, I am opening a new bug report.

Related issues

related to New Model #5531: ID-51A plus2 Closed 01/27/2018

Associated revisions

Revision 3396:dc90fed296f5
Added by Martin Cooper 9 months ago

Fix Icom radio detection

Icom radio detection has been broken for a long time, because the
detection code is expecting to be passed a radio instance, but is
being passed a serial port instead. Since we are trying to determine
the model, we don't have the relevant class yet. Instead, create a
minimal radio instance to allow us to query for the model.

These changes fix both the 'Detect' option in the 'Download From
Radio' menu and the 'chirpc --id' command.

Fixes #7905


Updated by Bernhard Hailer 11 months ago

  • Target version set to chirp-daily
  • Model affected changed from ICOM (All models) to Icom (many models)

#5531 was a New Model Request for an already supported radio, and therefore was closed. I probably should have converted it to a bug report - my apologies.

From combing through this ticket database, I must agree with this ticket here: something in the serial communication code for many Icom radios isn't quite right.
For Windows, I found that using (genuine!) Prolific cables seem to work better than FTDI.
That's no good solution for MacOS, which generally doesn't like to play well with Prolific; and MacOS users report similar issues with FTDI cables.
Under Linux it appears that newer computer hardware sometimes helps. Linux usually works quite well with most USB to Serial adapters.

This might point to a timing problem within the serial code; I hope that one of the developers with Icom experience can have a look.

Updated by Martin Cooper 11 months ago

Brian is correct. This is not related to serial communications, but is a bug in the detection code. The problem is that the get_model_data() function in icf is expecting a radio object (an instance of IcomCloneModeRadio or a subclass of it), but is being passed a serial port instance instead. The same bug surfaces when attempting to use the --id function of chirpc [1], since that also passes a serial port instance to get_model_data(). The code is simply broken.

From my reading of the code, it looks like get_model_data() is correctly being passed a serial port instance. If it had to be passed a radio instance (with a get_payload method), then the caller would have had to have already known what type of radio it had, to create an instance of the correct class - but presumably it's calling get_model_data() in order to discover that. Catch 22. So it seems that get_model_data() needs to create a radio instance itself, before proceeding. (It may well be that it needs to create a "tentative" instance first, in order to discover what it's really talking to.)

Another issue with get_model_data() is that it is written assuming that it is checking a clone mode radio. The first thing it does is call send_clone_frame(). That's not going to be a happy camper if the radio is a live mode radio instead of clone mode. A number of Icom radios are live mode, so this is definitely an problem. I don't know how chirp would discover whether a radio is clone mode or live mode without being told, but if there's code to do that somewhere, it would need to be called here before send_clone_frame().

1) There is another bug that you hit, before running into this problem, with 'chirpc --id'. That is an import issue, where the import on line 208 of chirpc needs to be importing from chirp.drivers, not chirp.

Updated by Martin Cooper 9 months ago

  • Status changed from New to In Progress
  • Assignee set to Martin Cooper
  • % Done changed from 0 to 90
  • Platform changed from Linux to All

Updated by Anonymous 9 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Applied in changeset dc90fed296f5.

Also available in: Atom PDF