[chirp_devel] Patch for UV5R driver to fix communication on Ubuntu 16.04 with pl2303-based cables (fixes #4165)
Baofeng shipped me an ostensibly pl2303-based programming cable with my UV-82, which I successfully used to program my radio with CHIRP on Ubuntu about two years ago.
Today, I am now on Ubuntu 16.04, and I couldn't get CHIRP to talk to the same radio over the same cable. It turns out that newer Ubntu versions ship a driver for the pl2303 that holds DTR low on the serial side (at least until the port is opened), and this puts the radio into transmit mode. The radio needs a little time to come out of it before it can talk to CHIRP, but CHIRP forges ahead with its commands as soon as it opens the port.
It's not crazy behavior on the part of the Ubuntu driver; DTR high means the computer is ready to talk to the device, and if the port is closed the computer is probably not ready to talk to the device. So I think it's appropriate to patch CHIRP rather than try and change the behavior on the LInux side.
This patch explicitly sets DTR high, and waits a bit, before trying to talk to the radio. I'm patching the UV5R driver, which gets used for the UV-82. This fixes issue #4165, which I reported so I could send in this patch. I have successfully used this patch to program my radio with CHIRP.
If there are any other radios that misbehave when DTR is low, and any other cables in common use based on this chip, it may make sense to patch those radio drivers as well.
This patch explicitly sets DTR high, and waits a bit, before trying to talk to the radio. I'm patching the UV5R driver, which gets used for the UV-82. This fixes issue #4165, which I reported so I could send in this patch. I have successfully used this patch to program my radio with CHIRP.
Has anyone tested this to make sure it doesn't interfere with already-working stuff?
Also, I think I'd rather try to do the ident, and if that fails, then do the DTR+sleep hack to avoid penalizing people with good cables.
Perhaps we could always set DTR high, do the first ident immediately and then just try the ident a second time after a delay if it fails the first time? Or do we need to set DTR and be quiet for a while to avoid confusing the radio?
--Dan
I've only tested it with the cable I have. Someone else will have to try it with other cables.
It might make sense to try a retry if immediate identification fails. I don't know if that would confuse the radio. But I don't know if 1 second of extra time is really a big deal, and it might be possible to cut it down.
Really it would be best if CHIRP had the port open with DTR on the whole time it was running, or could open it before I plugged in the radio. As I said, it looks like when the radio is connected and the port is closed, the radio interprets it as push-to-talk being active and starts transmitting, which is probably undesirable. But I suspect that change wouldn't be feasible.
On Tue, Nov 1, 2016 at 6:10 PM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
This patch explicitly sets DTR high, and waits a bit, before trying to talk to the radio. I'm patching the UV5R driver, which gets used for the UV-82. This fixes issue #4165, which I reported so I could send in this patch. I have successfully used this patch to program my radio with CHIRP.
Has anyone tested this to make sure it doesn't interfere with already-working stuff?
Also, I think I'd rather try to do the ident, and if that fails, then do the DTR+sleep hack to avoid penalizing people with good cables.
Perhaps we could always set DTR high, do the first ident immediately and then just try the ident a second time after a delay if it fails the first time? Or do we need to set DTR and be quiet for a while to avoid confusing the radio?
--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
participants (2)
-
Adam Novak -
Dan Smith