Bug #168
closedcan't communicate with Baofeng UV-3R+
0%
Description
h2. 1. What is the behavior you are seeing?
The radio doesn't respond to chirp, the error is:
Radio did not ACK first command
I get this in the terminal where i started chirp:
User selected Baofeng UV-3R on port /dev/ttyUSB0 Clone thread started -- Exception: -- Traceback (most recent call last): File "/home/anarcat/dist/chirp-daily-20120507/chirpui/clone.py", line 223, in run self.__radio.sync_in() File "/home/anarcat/dist/chirp-daily-20120507/chirp/wouxun.py", line 967, in sync_in self._mmap = uv3r_download(self) File "/home/anarcat/dist/chirp-daily-20120507/chirp/wouxun.py", line 877, in uv3r_download uv3r_prep(radio) File "/home/anarcat/dist/chirp-daily-20120507/chirp/wouxun.py", line 872, in uv3r_prep raise e RadioError: Radio did not ACK first command ------ Clone failed: Radio did not ACK first command Clone thread ended --- Exception Dialog: Radio did not ACK first command --- Traceback (most recent call last): File "./chirpw", line 68, inlangs += os.getenv("LANG").split(":") AttributeError: 'NoneType' object has no attribute 'split' ----------------------------
I did not find a debug.log, looking at the source i assume this is the same.
h2. 2. What is the behavior you were expecting?
I was expecting a nice filling up of the tab with the radio data, so i can flash it back. :)
h2. 3. Can you reproduce the problem all the time?
Yes.
h2. 4. What are the steps required to reproduce the problem?
Connect a Baofeng UV-3R+ radio to a Debian Wheezy laptop using a "Kenwood/Wouxun cable".
Power up the radio.
Choose "Download from Radio" in the Radio menu, with port /dev/ttyUSB0, Vendor Baofeng et Model UV-3R.
h2. 5. Is this specific to a certain radio model (driver) or something that you can reproduce with another radio?
I am happy to say chirp looks fine with my Wouxun KG-UVD1P.
This is similar to #167, but I open a different issue because the error message is different. I also wonder if the protocol for the UV-3R+ is different from the UV-3R radio...
Files
Updated by Antoine Beaupré over 12 years ago
I have tried to applied a similar method than recommended in #167, to no avail. I have tried:
- putting the radio in memory mode, in VHF or UHF mode (before or after switching to memory mode)
- putting the radio in menu mode
- locking the radio
- having the function key "raised" (hilighted)
- with the light on...
maybe it's a combination of the above... don't know, but so far i always end up with "Radio did not ACK first command".
good thing is that it's easier to program that radio than the uv5r. ;)
Updated by Jonathan Andrews over 12 years ago
UV3R+ Seems to have different internals/firmware to the UV3R, I can confirm that UV3R+ also gives me "Radio did not ACK first command
" when I try to read as "UV3R". UVD1P and UV5R both work with chirp and the same cable.
Updated by x Smurf about 12 years ago
- File IMG_0016.cleaned.JPG IMG_0016.cleaned.JPG added
I actually got this working just fine, but you need to push the connector in hard, real hard. What I do is put the connector in and push it down onto the desk (see attached picture).
Updated by x Smurf about 12 years ago
Just to be clear, you have to hold the radio this way during the whole read/write procedure.
Updated by Jonathan Andrews about 12 years ago
Yep, me bad ... thanks for the info, radio does work...
Weird thing is when I tried it last I also used the windows code to talk to the radio with no problems, then re-booted into linux and used chirp with UV5R, then with the 3R+ .... ho hum .... guess i'm not brutal enough with my cables.
Updated by Antoine Beaupré about 10 years ago
this issue can be closed: i confirm that pushing the radio hard against the desk works, thanks x Smurf! :)