[chirp_devel] IC-2730A Strange Behavior
Here's a weird one- My IC-2730 (with icf.py IcomCloneModeRadio) Py3 driver fails uploading AFTER any previous radio I/O. I've got all the bytes/ord/chr stuff working fine. IC-2730 has new booleans: _raw_frames= true, _highbit_flip=true, Munch_clone_resp=true (works if false, too) The radio downloads fine, repeated access, even after good or bad upload. The first upload after CHIRP Open > Load File or Radio > Reload Driver works fine. Upload after download, or upload after first upload fails. The failure is in get_model_data (the first radio I/O); the radio echoes the send model command byte by byte, but does not send the data frame. I have sniffed the USB bus and can see that the outbound packets are identical for both a good and bad upload. Any ideas? Remember: good downloads, good initial upload after driver load/reload; so commands, frames and decodings are OK.
That is indeed weird behavior. It almost sounds like there's data left over in the read buffer.
You could eliminate this being a possibility by placing a call to `radio.pipe.reset_input_buffer()` (or something like that) near the top of the `_clone_to_radio` function. Maybe it will work, maybe not; but at least you'll get an additional data point.
Tony
[1] https://pyserial.readthedocs.io/en/latest/pyserial_api.html#serial.Serial.re...
December 26, 2022 at 7:32 AM, "Rick (AA0RD) DeWitt via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:
Here's a weird one- My IC-2730 (with icf.py IcomCloneModeRadio) Py3 driver fails uploading AFTER any previous radio I/O. I've got all the bytes/ord/chr stuff working fine. IC-2730 has new booleans: _raw_frames= true, _highbit_flip=true, Munch_clone_resp=true (works if false, too) The radio downloads fine, repeated access, even after good or bad upload. The first upload after CHIRP Open > Load File or Radio > Reload Driver works fine. Upload after download, or upload after first upload fails. The failure is in get_model_data (the first radio I/O); the radio echoes the send model command byte by byte, but does not send the data frame. I have sniffed the USB bus and can see that the outbound packets are identical for both a good and bad upload. Any ideas? Remember: good downloads, good initial upload after driver load/reload; so commands, frames and decodings are OK.
--
Here's a weird one- My IC-2730 (with icf.py IcomCloneModeRadio) Py3 driver fails uploading AFTER any previous radio I/O. I've got all the bytes/ord/chr stuff working fine. IC-2730 has new booleans: _raw_frames= true, _highbit_flip=true, Munch_clone_resp=true (works if false, too) The radio downloads fine, repeated access, even after good or bad upload. The first upload after CHIRP Open > Load File or Radio > Reload Driver works fine. Upload after download, or upload after first upload fails. The failure is in get_model_data (the first radio I/O); the radio echoes the send model command byte by byte, but does not send the data frame. I have sniffed the USB bus and can see that the outbound packets are identical for both a good and bad upload. Any ideas? Remember: good downloads, good initial upload after driver load/reload; so commands, frames and decodings are OK.
Are you current? I fixed a bug with icom radios only recently that manifested like this, related to the baud rate change that icom radios go through.
I've tested the 5100 and the 4100 is also tested, so I would be highly surprised if the 2730 needs any attention to work.
--Dan
Are you current? I fixed a bug with icom radios only recently that manifested like this, related to the baud rate change that icom radios go through.
This was the change:
https://github.com/kk7ds/chirp/blob/py3/chirp/drivers/icf.py#L918-L921
This was the commit:
https://github.com/kk7ds/chirp/commit/5756c34c06f1d48ed8a5f539b3c75122b79a93...
--Dan
participants (3)
-
Dan Smith -
Rick (AA0RD) DeWitt -
Tony Fuller