CHIRP

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.