Bug #7119

BF-888 "Refused to enter programming mode."

Added by John Gray 10 months ago. Updated 3 months ago.

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

0%

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

Description

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.

Associated revisions

Revision 3291:f065867849f8
Added by Nicklas Lindgren 7 months 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
data.

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

History

Updated by Jens Ellerbrock 9 months 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 7 months 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,
                                 baudrate=rclass.BAUD_RATE,
                                 rtscts=rclass.HARDWARE_FLOW,
-                                timeout=0.25)
+                                timeout=0.5)
             ser.flushInput()
         except serial.SerialException, e:
             d = inputdialog.ExceptionDialog(e)
@@ -774,7 +774,7 @@
             ser = serial.Serial(port=settings.port,
                                 baudrate=radio.BAUD_RATE,
                                 rtscts=radio.HARDWARE_FLOW,
-                                timeout=0.25)
+                                timeout=0.5)
             ser.flushInput()
         except serial.SerialException, e:
             d = inputdialog.ExceptionDialog(e)

Updated by Alt Ctrl 6 months 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 5 months 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 3 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF