[chirp_devel] Patch for UV5R driver to fix communication on Ubuntu 16.04 with pl2303-based cables (fixes #4165)
interfect at gmail.com
Tue Sep 8 20:24:18 PDT 2020
All I can say is that I'm unable to reproduce the issue now, on Ubuntu 18.04 which I now use, no matter whether the radio is on or off when I plug it in.
Presumably the person who was bothering me to apply the patch still sees the issue; it might still be broken on 16.04. Maybe something about the serial driver has changed again.
September 8, 2020 6:10 PM, "Dan Smith via chirp_devel" <chirp_devel at intrepid.danplanet.com> wrote:
>> A question for the larger group here, I wonder if we could/should just push that line of code,
>> time.sleep(1), up to the higher level serial class so that all drivers could take advantage of it?
>> Specifically, do_upload() and do_download() in ./chirp/ui/mainapp.py
>
> I definitely really don't want to do that if we can help it, because it penalizes everyone that
> doesn't have a broken radio.
>
> Are you sure that if you plug in the radio before turning it on that it will go into transmit
> immediately at startup? Some of them will do the "I think I should be transmitting" thing if you
> hot plug the programming cable while the radio is on, but will behave properly if they power up
> into that state. It really sucks to have to introduce a sleep (which may not be long enough in all
> cases, depending on how quickly the driver, USB chip, and radio respond) for just dumb radios.
>
> That said, I'd prefer keeping hacks like this to specific drivers where we know there are problem
> children, if that's really the case.
>
> Can you confirm the cable plug ordering step before I apply that?
>
> --Dan
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
More information about the chirp_devel
mailing list