Bug #7905: Issue with ICOM radios in general - CHIRP

Actions

Copy link

Bug #7905

closed

Issue with ICOM radios in general

Added by Brian Harbaugh almost 4 years ago. Updated over 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Martin Cooper

Category:

Target version:

chirp-legacy

Start date:

05/22/2020

Due date:

% Done:

100%

Estimated time:

Chirp Version:

daily

Model affected:

Icom (many models)

Platform:

All

Debug Log:

I read the instructions above:

Description

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_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 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

Actions

Copy link

Updated by Bernhard Hailer almost 4 years ago

Target version set to chirp-legacy
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.

Actions

Copy link

Updated by Martin Cooper almost 4 years 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.

Actions

Copy link