Bug #7119

BF-888 "Refused to enter programming mode."

Added by John Gray about 2 years ago. Updated over 1 year ago.

Status:Closed Start date:09/25/2019
Priority:Normal Due date:
Assignee:- % Done:


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


When I try to read from new BF-888 radios, I receive the error message "refused to enter programming mode."

Using Baofeng branded programming cable. Cable programs UV-5R just fine. Cable programs the BF-888s fine using ZT-V68 software downloaded from Baofeng.

Same error occurs on Windows 10 and Linux.

ZT-V68 software from Baofeng works on Windows 10.

Related issues

related to Bug #5363: Baofeng BF-888s "Radio Refused to enter programming mode" Closed 11/22/2017
duplicated by Bug #4249: Baofeng 888S - "Radio refused to enter programming mode" ... Closed 11/21/2016
duplicated by Bug #4247: Baofeng 888S - "Radio refused to enter programming mode" ... Rejected 11/21/2016

Associated revisions

Revision 3291:f065867849f8
Added by Nicklas Lindgren almost 2 years ago

[h777] Increase some serial timeouts #7119

This solves the BF-888 refused to enter programming mode problem in
some cases where more time is needed waiting for radio identification

This change also increases the timeout when uploading data blocks,
which is required for some individual radios.


Updated by Jens Ellerbrock about 2 years ago

I'm having the same Problem on a few newly bought bf-888s and an original Baofeng cable
the BF-888s Software from http://www.miklor.com/BF888/software/BF-888S_v1.05.exe runs fine with old and new bf-888s's (I now just read the config from an old one and was able to program the new ones without any problems. Chirp (actual version 20190925) only runs with the older ones....

Updated by Nicklas Lindgren almost 2 years ago

I had the same problem with a pair of BF-888S radios.

But while testing i found that the command line utility, chirpc, could download the memory from the radio without problems.

When looking for differences in the code, i found that serial.Serial objects with different read timeouts are used. While chirpc uses a timeout of 0.5 s, chirpw uses timeouts of only 0.25 s.

By applying this patch which changes chirpw to use the same longer read timeouts, downloading and uploading BF-888S configs starts working:

diff -r b5589aa94c1e chirp/ui/mainapp.py
--- a/chirp/ui/mainapp.py       Thu Dec 05 21:14:35 2019 +1100
+++ b/chirp/ui/mainapp.py       Wed Dec 11 20:50:57 2019 +0100
@@ -728,7 +728,7 @@
             ser = serial.Serial(port=settings.port,
-                                timeout=0.25)
+                                timeout=0.5)
         except serial.SerialException, e:
             d = inputdialog.ExceptionDialog(e)
@@ -774,7 +774,7 @@
             ser = serial.Serial(port=settings.port,
-                                timeout=0.25)
+                                timeout=0.5)
         except serial.SerialException, e:
             d = inputdialog.ExceptionDialog(e)

Updated by Alt Ctrl almost 2 years ago

Nicklas Lindgren!

Thanks for advice about chirpc.

I tried CLI tool (chirpc) with my OLD stations. It works.
But when I tried CLI tool (chirpc) with my new stations - no reaction. Here is what it produces:

ERROR: No response from radio

In any case, thanks for the advice. Maybe I'll try other timeouts.
And by the way, how to apply this patch for chirpw?

Updated by Bernhard Hailer almost 2 years ago

  • Status changed from New to Resolved
  • Target version set to chirp-daily
  • Model affected changed from BF-888 to Baofeng BF-888

A patch has been submitted applied on 12/28/2019.
Please let us know whether it works, or whether there are still problems. Thanks!

Updated by Bernhard Hailer over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF