[chirp_devel] IC-2730A Strange Behavior

[Tony Fuller]

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 at 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.
>  
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20221226/0126cc0c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Signature-RIck-AA0RD-Image.jpg
Type: image/jpeg
Size: 18469 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20221226/0126cc0c/attachment-0001.jpg