Bug #4249

Baofeng 888S - "Radio refused to enter programming mode" for every radio in my latest batch

Added by Mark Schwarz over 5 years ago. Updated almost 2 years ago.

Status:Closed Start date:11/21/2016
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Chirp Version:daily Platform:All
Model affected:Baofeng BF-888S


This is my third batch of 888S models. I set the first two batches to "Low" power mode with few problems. In this month's batch, I get "Radio refused to enter programming mode".

1. What is the behavior you are seeing?
"Radio refused to enter programming mode"

2. What is the behavior you were expecting?
Radio settings to be available, as they were on my last two batches from this year.

3. Can you reproduce the problem all the time?
Yes. I can consistently read/write data from the April batch, but not from the Nov batch. I can do this consistantly, by switching from one radio to another, over and over.

4. What are the steps required to reproduce the problem?
- Plug the radio in.
- Select Radio->"Download from Radio."

5. Is this specific to a certain radio model (driver) or something that you can reproduce with another radio?
I only have 888S models.

2016-11-21 23.13.29.jpg (1.8 MB) Mark Schwarz, 11/21/2016 09:20 pm

h777.py (18.2 kB) Jim Unroe, 11/22/2016 01:53 pm

debug.log (62.6 kB) Mark Schwarz, 11/24/2016 07:58 am

h777.py - no pause between "\x02" and "PROGRAM" (17.9 kB) Jim Unroe, 11/24/2016 08:39 am

debug.log (60.4 kB) Mark Schwarz, 12/05/2016 06:16 pm

bf888s prolific retevis cable.mon - Prolific Cable with CHIRP - crashes (562 Bytes) Robert Cersovsky, 12/14/2016 01:02 pm

bf888s prolific retevis cable_VT68.mon - Prolific Cable with VT68 (Baofeng software) - works fine (25.4 kB) Robert Cersovsky, 12/14/2016 01:02 pm

bf888s CH35 cable_CHIRP.mon - CH340 cable with CHIRP - works fine (20.9 kB) Robert Cersovsky, 12/14/2016 01:02 pm

bf888s CH35 cable_VT68.mon - CH340 cable with VT68 - works fine (10.4 kB) Robert Cersovsky, 12/14/2016 01:02 pm

Related issues

related to Bug #4247: Baofeng 888S - "Radio refused to enter programming mode" ... Rejected 11/21/2016
duplicates Bug #7119: BF-888 "Refused to enter programming mode." Closed 09/25/2019


Updated by Kieran W over 5 years ago

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.

Updated by Jim Unroe over 5 years ago

  • File h777.py added
  • Status changed from New to Feedback
  • Platform changed from MacOS to All

Try the attached file with File > Load Module (you'll need Help > Enable Developer Functions checked).

Report back the results of your test.


Updated by Mark Schwarz over 5 years ago

Thanks for the quick reply!

I've done the following:
1. Downloaded the most recent daily build (11/23).
2. Loaded the module.
3. Tried four download commands: (1), (2) with the new 888 radio on. Download (3) was with the older 888 radio off. All of these gave the same response. Download (4) was with the old 888 turned on. It downloaded fine.

Log and config files are attached.

I'm a competent Python dev, so I'm also OK debugging a bit, here. If you'll tell me what to try and look for, I'm glad to dig a bit.

Updated by Jim Unroe over 5 years ago

Looking at the log, it seems to me that the radio is ignoring CHIRP's request to initiate cloning. The question is why?

Supposedly both the old and new radios work with the factory software for the BF-480. So I installed the BF-480 software and captured a download from my BF-888S to it. The only thing I can see that is possibly different in how the CHIRP driver behaves and the factory software behaves is that CHIRP has a short pause between the "\x02" and "PROGRAM" that is sent to the radio to initiate the cloning process.

I have attached a test driver that sends the 8 bytes without a pause. Give it a try and report back.


Updated by Gerhard Potgieter over 5 years ago

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
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
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

Updated by Mark Schwarz over 5 years ago

I tried again, using an older working one followed by a newer one that doesn't work. It doesn't seem like the timing change helped. What else can I check?

Updated by Mark Schwarz over 5 years ago

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

Updated by Jim Unroe over 5 years ago

I sent you an email.

Updated by Jim Unroe over 5 years ago

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)

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.


Updated by Robert Cersovsky over 5 years ago

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

Updated by Robert Cersovsky over 5 years ago

OK got it. Here it is...

this ends in radio refusing.

now comes one fun fact: during trying to get serialmon to work, I had to start it with admin rights. then I startet chirp also with admin rights. THis one time I could read the radio. But I could not repeat that .. dont know wtf...

Updated by Jim Unroe over 5 years ago

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 page. For El Capitan and later, I have heard of successful results from those purchasing a 3rd party driver from Repleo 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.


Updated by Mark Schwarz over 5 years ago

Jim, that makes sense to me.

I've been using a Baofeng cable on the older 888-S. I bought it based on Amazon reviews that seemed encouraging, rather than by cross-checking with the cable guide 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 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.

Updated by Robert Cersovsky over 5 years ago

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

This one is the CH-35 cable (very cheap and ships within 1 day in germany)

hope that will help someone...

Updated by Brian David over 5 years ago

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).

Updated by Ken Bell about 5 years ago

<<< For El Capitan and later, I have heard of successful results from those purchasing a 3rd party driver from Repleo 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.

Updated by Mike Montalvo about 5 years ago

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 and no change. Cable and driver work fine with UV-5R before and after downgrade. :(

Updated by Jim Unroe about 5 years ago

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?


Updated by Mark Schwarz about 5 years ago


I purchased the FTDI cable from the CableGuide page. It worked well! I confirmed my problem, which started this ticket, was a cable issue.

Updated by George Matthews about 5 years ago

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.


Updated by Bernhard Hailer about 2 years ago

  • Status changed from Feedback to Closed
  • Model affected changed from Baofeng 888S to Baofeng BF-888S

Solutions suggested.

Updated by Bernhard Hailer almost 2 years ago

Please also refer to issue #7119.

Also available in: Atom PDF