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

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