[chirp_devel] Patch for UV5R driver to fix communication on Ubuntu 16.04 with pl2303-based cables (fixes #4165)
Hello,
Bernhard Hailer has asked me to resubmit my patch for the issue with modern Ubuntu serial drivers having DTR low, at least when the port isn't open, causing the radio to be in transmit mode and not ready to accept CHIRP's commands as soon as the port is open. This fixes #4165.
Issue: https://chirp.danplanet.com/issues/4165 Original patch submission (did anybody get it?): http://intrepid.danplanet.com/pipermail/chirp_devel/2016-October/004329.html
I tried to send this message earlier after subscribing to the list and clicking the confirmation link in the subscription e-mail, but I think web based confirmation is broken. When I sent the patch I got a message saying it was held for moderation because I wasn't a member of the list. I had to subscribe again and confirm by e-mail instead to actually get onto the list.
Thanks, -Adam
Hey Adam,
Looking at the patch, it says the real fix is the sleep for 1 second, correct? I did verify that setting DTS = True is redundant as you said, it's included in pyserial as a default state. I don't see anything wrong with the patch in general, but do have one question for the more senior devs here:
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
Tony ________________________________ From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com on behalf of interfect--- via chirp_devel chirp_devel@intrepid.danplanet.com Sent: Saturday, September 5, 2020 11:45 PM To: chirp_devel@intrepid.danplanet.com chirp_devel@intrepid.danplanet.com Subject: [chirp_devel] Patch for UV5R driver to fix communication on Ubuntu 16.04 with pl2303-based cables (fixes #4165)
Hello,
Bernhard Hailer has asked me to resubmit my patch for the issue with modern Ubuntu serial drivers having DTR low, at least when the port isn't open, causing the radio to be in transmit mode and not ready to accept CHIRP's commands as soon as the port is open. This fixes #4165.
Issue: https://chirp.danplanet.com/issues/4165 Original patch submission (did anybody get it?): http://intrepid.danplanet.com/pipermail/chirp_devel/2016-October/004329.html
I tried to send this message earlier after subscribing to the list and clicking the confirmation link in the subscription e-mail, but I think web based confirmation is broken. When I sent the patch I got a message saying it was held for moderation because I wasn't a member of the list. I had to subscribe again and confirm by e-mail instead to actually get onto the list.
Thanks, -Adam
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
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
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.
Yeah, well, I don't really think it's a good idea for us to put a hack in place for a buggy driver on a single release of a single OS, for a single radio (or a small set of them).
Thanks for letting us know that you can't repro it anymore, that's helpful.
--Dan
participants (3)
-
Dan Smith
-
interfect@gmail.com
-
Tony Fuller