Bug #3723
closedUV-82 V2+ driver missing from CHIRP
Added by Paul Piva over 8 years ago. Updated over 4 years ago.
0%
Description
Hello, I just purchased a portable Ham radio from Baofeng. As noted in the subject, it is a UV-82 V2+ Ham set.
I tried to clone it with CHIRP, and noticed that it is not listed in the client.
Using the UV-82 or other variations throws an error. Is this version of the radio going to be
added in the next release of the CHIRP client? If so, do you know when?
Thanks,
Paul
Files
| debug.log (19.7 KB) debug.log | Debug log | Paul Piva, 06/10/2016 06:07 AM | |
| debug.log (31.4 KB) debug.log | Latest debug.log | Paul Piva, 06/11/2016 04:03 PM | |
| debian.log (1.54 KB) debian.log | Paul Piva, 06/17/2016 01:20 PM | ||
| debug.log (1.04 KB) debug.log | Paul Piva, 06/17/2016 01:20 PM | ||
| debug.log (18.2 KB) debug.log | Paul Piva, 06/22/2016 11:08 AM | ||
| debug-06-23-2016.log (20.2 KB) debug-06-23-2016.log | Paul Piva, 06/23/2016 08:38 AM |
Updated by Jim Unroe over 8 years ago
- Status changed from New to Feedback
Paul,
What was the error?
Does this radio have 2 or 3 power levels? If 3 did you try UV-82HP?
Please include the debug.log file (how to find it is on the "How to report issues":http://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues page.
Does the OEM software work?
More often than not, if a Baofeng radio can't be read by CHIRP, is is a problem with the programming cable (an incompatible device driver or the programming cable is not fully connected to the radio).
Jim KC9HI
Updated by Paul Piva over 8 years ago
Hello Jim,
Thanks for getting back so quickly. This is the first time working with you folks.
Responses to your questions, and some additional details.
1a. Error I am getting when selecting the U-82 driver, is "Incorrect model selected".
1b. Selecting UV-82HP results in a error: "Radio refused to send block - 0x1f00"
- This is a tri-power radio. link:https://baofengradio.us/uv-82/baofeng-uv-82-v2-tri-power-1-4-7w-dual-band-black.html
- Debug log is attached to ticket.
- There was no accompanying OEM software with either the radio or the FTDI cable. Bit surprised at that.
- The FTDI cable was purchased from the Baofeng Radio webpage. https://baofengradio.us/accessories/baofeng-usbcable2.html 6a. When Windows 7 detected the cable, it was identified as a serial cable on port COM3. 6b. The driver is identified as FTDI. Driver date: 3/9/16, Driver version: 2.12.1.0, Digital Signer: Microsoft Windows Compatibility Publisher 6c. As noted in item 4, there was not software for the cable or any identifying marks on the cable.
- Is there a way to get the firmware version off of the radio menu, without CHIRP? I read that sometimes, with newer sets, the firm ware code may be designed with a slightly different offset, that CHIRP can match up with. Hopefully the Debug log will have those details.
I tried using a Prolific driver that I had seen used with these cables before on some forums, but it crash Windows 7; Blue Screen. After rebooting in Safe Mode, I was able to remove the driver and get the OS back up.
I also did a firmware reset on the radio. I wasn't sure who touch it before me, thought it might repair the communications problem; no change.
I tried the Linux Live CD version of the CHIRP product. I wasn't any more successful getting the client to talk to the radio.
Paul
Updated by Paul Piva over 8 years ago
Jim
One last thing to add. Looking at the box the programming cable was shipped in,
the only thing identifying the cable, is that it was manufactured by
Amcrest, and manufactured in China.
The side label notes that it has a bar code of X000VE2BE9. It says Amcrest FTDI USB Baofeng..and Authentic FTDI Chipset,
and New. Hopefully, it is what is says, and not a lower quality counterfeit.
Paul
Updated by Jim Unroe over 8 years ago
Paul,
Thanks for the debug.log file. It confirms that you should be selecting the UV-82HP model.
Jim
Updated by Paul Piva over 8 years ago
I downloaded the latest code, and tried again using the UV-82HP choice. Got a different error code. Radio refused to send code. 0x0000.
I am using a different host, a laptop I have at home. The Com port is 4, unlike the previous host where it was on 3.
When CHIRP establishes a connection, the radio lights up and blinks. I have a feeling the cable is OK, Using other choices
results in a message that the radio is not found; similar to establishing a connection without the cable plugged in. I suspect
that the Windows driver is OK. I wish the cable or radio had it's own OEM software for the drivers. Windows drivers can be unpredictable sometimes.
I uploaded the latest debug.log from my host.
Thanks for staying on this.
Paul
Updated by Jim Unroe over 8 years ago
Look in Device Manager to see what chipset is in the programming cable.
Jim KC9HI
Updated by Paul Piva over 8 years ago
I couldn't find anything of any use via Windows device manager. It knows it is a FTDI manufactured device, and it knows it is a USB device. Unable to get anything identifying the chip set though. If there is a specific drop down, I should grab the details from let me know. I went through all of the choices.
I fired up a copy of Debian Jessie live CD, and did a grep of dmesg for attached USB devices, and this is what I came up with. Not sure,
if there is enough detail here to work here.
[ 161.573747] usb 1-2: new full-speed USB device number 4 using xhci_hcd
[ 161.707689] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
[ 161.707693] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 161.707696] usb 1-2: Product: FT232R USB UART
[ 161.707698] usb 1-2: Manufacturer: FTDI
[ 161.707699] usb 1-2: SerialNumber: AI035K93
[ 162.892774] usbcore: registered new interface driver usbserial
[ 162.892959] usbcore: registered new interface driver usbserial_generic
[ 162.893014] usbserial: USB Serial support registered for generic
[ 162.982486] usbcore: registered new interface driver ftdi_sio
[ 162.982719] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 162.982883] usb 1-2: Detected FT232RL
[ 162.982886] usb 1-2: Number of endpoints 2
[ 162.982888] usb 1-2: Endpoint 1 MaxPacketSize 64
[ 162.982890] usb 1-2: Endpoint 2 MaxPacketSize 64
[ 162.982893] usb 1-2: Setting MaxPacketSize 64
[ 162.984408] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
I also grabbed a copy of the firmware version on the radio. Power up, holding the number 3 key.
N82301
Paul
Updated by Paul Piva over 8 years ago
Hello Jim,
Just checking to see if there has been any updates since my last upload to this ticket.
I also contacted Baofeng, and had them do a remote session as well. They are stumped
too. They were supposed to have technical support contact me yesterday after passing my
ticket on, but I have not heard back. I asked if perhaps the cable was bad, and if it
could be replaced.
Any idea, if the firmware is something that CHIRP has not seen before?
Has anyone else reported a similar problem with this version of the radio?
I was looking as some of the other complaints with similar symptoms. The causes ranged
from a bad cable, driver, bad firmware in the radio, or they using a outdated version
of the CHIRP Product.
Just as a FYI, I tried using your LiveCD, and it is a few years old. But it is possible
to do a internet update of CHIRP. On two different workstations, the update freezes
the newer version of CHIRP. Do you have a LiveCD with a relatively current version of CHIRP?
I also tried using the Baofeng software from their website. That product is also having
a problem connecting.
Paul
Updated by Paul Piva over 8 years ago
- File debian.log debian.log added
- File debug.log debug.log added
Hello Jim,
I have a dual boot laptop with both Windows and Debian. Just to see if there is a difference in behavior,
or perhaps some strange with the Windows driver, I ran your CHIRP client from a Debian build using
your latest client release
Check out the attached logs. The Linux client doesn't appear to create a debug log.
So I pasted the activity from the Linux CHIRP build from the console into a text file. Also a copy of the
messages from /var/log/messages related to USB detection, is attached too.
Updated by Jim Unroe over 8 years ago
The debug.log doesn't appear to be a complete debug.log file.
A debug.log file is also created under Linux. I use it all the time. It is in the ".chirp" folder of the user's home folder. I believe it is a hidden folder so you must set your file explorer to "show hidden files".
Jim
Updated by Paul Piva over 8 years ago
Hello Jim.
Located the hidden directory and contents.
There are only two items inside, and no debug.log
One of the files is chirp.config, and the other is a directory called stock_configs.
The hidden directory for .chirp, was listed under /home/paul directory as previously stated under my own ID.
Earlier today, I was able to get a hold of another transfer cable. Using this cable, and Mac this time,
we attempted to clone the radio. Received the same message as before, stating that
the radio refused to send block. 0x1ec0
Paul
Updated by Jim Unroe over 8 years ago
Paul,
I need you to supply a good debug.log file.
Jim
Updated by Jim Unroe over 8 years ago
Does you UV-82 V2+ have 2 or 3 power levels?
Updated by Paul Piva over 8 years ago
Good morning Jim,
I have access to a Macintosh I can test with. I will get you a debug log later on.
Still puzzled about the Linux version of the CHIRP code.
You said that it should generate a debug log, but I couldn't find it in the hidden directory.
What version of Linux have you used your product on? I can get a LiveCD of
whatever it is, and test with that instead. I was using Debian Jessie myself.
I have worked with other Distros in the past including Centos, SUSE, Redhat etc..
This radio is a tri-power unit. It appears to be a clone of the UV-82 HP from
what I read online. Baofeng Tech, said it was a knock off of their product.
I bought the unit from baofengradio.us. Both companies are valid distributors
of these radio sets it seems; both connected to Pofung. Also competitors as well.
I am really wondering if I have bad firmware installed?
Paul
Updated by Paul Piva over 8 years ago
Jim,
No luck getting Chirp to run on my MAC. OS version 10.5.8.
It may be out of date. The application blinks, and nothing more happens.Installed the Python code
before hand.
Grabbed another debug.log from a Windows host I used to test with in the meantime.
Paul
Updated by Paul Piva over 8 years ago
Working on getting my hands on a Macbook to test with. One that is current OS wise.
As soon as I can lift of a debug.log, I will send it.
Paul
Updated by Paul Piva over 8 years ago
- File debug-06-23-2016.log debug-06-23-2016.log added
Hello Jim
I was able to get my hands on a Mac Mini, and rerun the CHIRP test.
Same error as seen in Windows and Linux.
The Debug log has been uploaded to this ticket.
Paul
Updated by Paul Piva over 8 years ago
Hello Jim,
Just a quick update. I contacted the company I bought the radio at baofengradio.us, and waiting for a RMA to have it replaced.
In the meantime, I purchased another UHF/VHF radio set from baofengtech.com which I am now using. No problems with the CHIRP client.
You can close out this ticket, as per your practice.
Thanks,
Paul
Updated by Bernhard Hailer over 4 years ago
- Status changed from Feedback to Closed
Closed as requested by submitter.