CHIRP

I have just had the same problem with 4 new BF-888s bought yesterday.
Chirp says Radio 'refused to enter programming mode'
Plug in an older BF-888s and it works fine so not a cable issue etc.
Had to use the Baofeng BF-480 programme which reads and writes to the radios OK.
I used the BF-480 software to read the config from a radio which was programmed correctly and then cloned this to the 4 new radios.

I am just a novice but if anyone needs any more info on these newer BF-888s then I will do my best to help if it helps to fix the problem.

I am getting the exact same issue with recently purchased BF-888s radios. Works fine with the official software on windows, but no go on Mac with latest chirp daily from 23/11/2016. I have tried the attached module but still nothing.

@
[2016-12-05 08:28:32,494] chirp.directory - INFO: driver re-registration enabled
[2016-12-05 08:28:32,499] chirp.directory - WARNING: Replacing existing driver id `Baofeng_BF-888'
[2016-12-05 08:28:32,499] chirp.directory - INFO: Registered Baofeng_BF-888 = H777Radio
[2016-12-05 08:28:35,436] chirp.ui.mainapp - DEBUG: User selected Baofeng BF-888 on port /dev/cu.usbserial
[2016-12-05 08:28:35,445] chirp.ui.clone - DEBUG: Clone thread started
[2016-12-05 08:28:35,445] chirp.ui.mainapp - DEBUG: download
[2016-12-05 08:28:35,446] chirp.ui.reporting - DEBUG: Reporting exception
[2016-12-05 08:28:35,446] chirp.ui.common - ERROR: -- Exception: --
[2016-12-05 08:28:35,446] chirp.ui.common - ERROR: Traceback (most recent call last):
File "/Applications/chirp.app/Contents/Resources/chirp/chirp/ui/clone.py", line 249, in run
self.__radio.sync_in()
File "/Users/gerhard/Downloads/h777.py", line 288, in sync_in
self._mmap = do_download(self)
File "/Users/gerhard/Downloads/h777.py", line 187, in do_download
_h777_enter_programming_mode(radio)
File "/Users/gerhard/Downloads/h777.py", line 111, in _h777_enter_programming_mode
raise errors.RadioError("Radio refused to enter programming mode")
RadioError: Radio refused to enter programming mode
@

I'm glad to donate a radio if that might help, too, Jim. PM me if you're interested.

Mark,
I sent you an email.
Jim

Today I received a BF-888S that is supposed to have this issue from Mark. So the first thing I did after getting home from work was to get it out of the package and try it. Unfortunately I can't get it to fail.

I've tried the following programming cables:
Prolific (genuine chip)
Prolific (counterfeit chip)
FTDI

I've tried the following operating systems:
Windows 7 64-bit
Linux Mint 17.3
Windows 10 64-bit (virtual machine)

CHIRP reads the BF-888S the first time and every time with all OS and programming cable combinations.

Unless someone can supply a serial port capture of a failed download, which will provide detail that that the debug log doesn't, I'm not sure what else can be done.

Jim

I have a Retevis labeled cable where it does not work. Seems to be genuine Prolific. I changed to a CH340 caple and now it works fine. If you could tell me how I do the serial port capture, I will provide it...
Windows 10 64bit as well as OSX latest - same behavior

OK. I think I have replicated the problem. It has to do with an incompatible device driver.

When you have a programming cable with a counterfeit Prolific PL-2303 chip (nearly all programming cables that report they are a Prolific chip to the OS are counterfeit. Especially the Baofeng branded one and and I would expect the Retevis branded one as well.), Windows and Mac users must not use the Prolific written drivers that have been available since about 2008. At around this time is when they became intentionally designed to be incompatible with counterfeit in hopes to curb the use of these chips. The Windows device driver installation used to fail with an error code 10 when a counterfeit chip was detected. Recently (within the last year of so) the driver was updated to complete the install but to still not operate properly with a counterfeit chip.

Apparently the older BF-888s radios were tolerant to whatever the device driver does to be incompatible with the counterfeit chip. Apparently the newer BF-888s radios are no longer tolerant (the same as nearly every other radio has always been).

What Windows users must do is download, install and select the older Prolific v3.2.0.0 driver for Vista, 7, 8 and 10 (v2.0.2.1 for XP) that was available before the drivers were change to not cooperate with counterfeit Prolific chips. The v3.2.0.0 driver is the one I use in Windows 7 64-bit computer that I use for CHIRP development and my Windows 10 virtual machine (and why both Mark's new BF-888s radio and my older radio work fine).

Mac OS X users prior to El Capitan have to install one of the generic drivers linked to on the "MacOS_Tips":http://chirp.danplanet.com/projects/chirp/wiki/MacOS_Tips page. For El Capitan and later, I have heard of successful results from those purchasing a 3rd party driver from "Repleo":https://www.mac-usb-serial.com/ for €7.90 (approximately $8.23).

Linux users don't have to worry about it because their drivers for the PL-2303 chip. That is why both radios downloaded fine on my Linux Mint 17.3 computer.

An alternative to messing with drivers is to switch to a programming cable with a chip from a different manufacturer. That is why the cable with the CH-35 chip read the new radios fine. The FTDI chip is a popular alternative.

Jim KC9HI

Jim, that makes sense to me.

I've been using a "Baofeng cable":https://www.amazon.com/Baofeng-Programming-Cable-BF-888S-Driver/dp/B008RZJHJU on the older 888-S. I bought it based on Amazon reviews that seemed encouraging, rather than by cross-checking with the "cable guide":http://chirp.danplanet.com/projects/chirp/wiki/CableGuide page. That cable apparently doesn't work with the latest revision of the 888-S, as you worked out. I'll add an Amazon review to say the same.

I'll order a "FTDI cable from Amazon":https://www.amazon.com/Valley-Enterprises-Programming-Weierwei-Quansheng/dp/B0097E2I2S at the point I need to program another batch of radios. Expect that to be many months from now.

Does it make any sense to link to a specific cable on Amazon from the CableGuide page? If that'd been there, I'd probably have clicked through to purchase from there, rather than checking for keywords in Amazon reviews.

Let's close this, based on your clear research. Thanks again, Jim.

Jim, I need some time to verify this, as have the old PL-2303 v3.2.0.0 driver running on my office notebook (which I left in office for vacation) - but it makes sense what you say. Additionally I want to point out, that in Germany its quite hard to get a FTDI named cable. Most of the times the cables descriptions have no hint for the chipset whatsoever. So I came to the idea to select the cable for its plug shape. I bought both of the below. I Also ordered a "genuine FTDI cable" from the US but this ships now since 4 weeks and I have no idea when it will arrive here.

The link below shows the look of the probably counterfeit Prolific cable
http://www.ebay.de/itm/like/261535252406?lpid=106&chn=ps&ul_noapp=true

This one is the CH-35 cable (very cheap and ships within 1 day in germany)
http://www.ebay.de/itm/like/262384231533?lpid=106&chn=ps&ul_noapp=true

hope that will help someone...

I ended up here after going through much of the same experience.

I have four new 888s devices, zero of which connect - all producing the "Radio refused to enter programming mode" as described above.

I am using this cable (probably a knockoff) - https://www.amazon.com/gp/product/B00CP0I474/

HOWEVER, that cable + CHIRP DOES readily program two UV-5R devices that I bought at the same time.

Additionally, the same cable does program the 888s devices with the OEM software on Miklor's page. Using the BF-888s software gives me the error some have experienced where it only programs the first half of the channels but it does communicate with the 888s - and using the ZT-V68 software all channels program properly - so it doesn't appear it's a limitation of the cable being able to communicate with the 888s.

I'm happy to run any diagnostics that might help but I mostly wanted to offer that I am experiencing the same issue - and it does not appear the cable prevents the devices from communicating (because it works fine with the alternate programs).

<<< For El Capitan and later, I have heard of successful results from those purchasing a 3rd party driver from "Repleo":https://www.mac-usb-serial.com/ for €7.90 (approximately $8.23).>>>

Just spent the $8.23 to buy and install the driver on a Mac Book Pro with Sierra 10.12.4 Went through all of the tips on the Repleo page. Driver is loaded, new port appears in the drop-down... all appears to be working very well, but still get the 'Radio Refused to Enter Program Mode' error.

I just bought 6 BF-888S and have the same experience as Brian. Guess I should have checked about programming before I purchased them. I always assume Chrip works for everything lol. I downgraded my Prolific driver as per Jim to 3.2.0.0 and no change. Cable and driver work fine with UV-5R before and after downgrade. :(

One of these unprogramable radios was sent to me so I could have something to troubleshoot with. I couldn't make it not work. My guess is that your radios would work here as well.

I would look at the 2-pin connection. I have been working with someone else with another radio and they were unable to get it to program. He eventually discovered that the socket is not positioned in the radio properly allowing the pins to go in too deep. He said pulling the top of the plug out (I assume the small pin side) about 1/32" allows it to work 100%.

Have you tried the factory software?

Jim

Jim,

I purchased the "FTDI cable":https://www.amazon.com/dp/B0097E2I2S from the CableGuide page. It worked well! I confirmed my problem, which started this ticket, was a cable issue.

I too had the issue with recently purchased Baofeng 888 radios. CHIRP worked with 55 but not the new 888.
After reading many posts I concluded that the converter must include a genuine FDTI chip.
Reluctant to purchase an expensive cable, I recalled that my Ardunio programming cable had a FDTI chip. I created an adaptor from the defective cable and that now works very well with both Baofeng 55 and 888.
This is a link to an article describing how to make an adaptor cable.

[[[https://docs.google.com/document/d/1pC-FwTcE87fitmRTje63M63VPYXi9CGn5jOClGmM5SY/edit?usp=sharing]]]

Please also refer to issue #7119.