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@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers