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