Project

General

Profile

Actions

Bug #7119

closed

BF-888 "Refused to enter programming mode."

Added by John Gray over 4 years ago. Updated almost 4 years ago.

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

0%

Estimated time:
Chirp Version:
daily
Model affected:
Baofeng BF-888
Platform:
All
Debug Log:
I read the instructions above:

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.


Related issues

Related to Bug #5363: Baofeng BF-888s "Radio Refused to enter programming mode"Closed11/22/2017

Actions
Has duplicate Bug #4249: Baofeng 888S - "Radio refused to enter programming mode" for every radio in my latest batchClosed11/21/2016

Actions
Has duplicate Bug #4247: Baofeng 888S - "Radio refused to enter programming mode" for every radio in my latest batchRejected11/21/2016

Actions
Actions #1

Updated by Jens Ellerbrock over 4 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....

Actions #2

Updated by Nicklas Lindgren over 4 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,
                                 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)
Actions #3

Updated by Alt Ctrl over 4 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?

Actions #4

Updated by Bernhard Hailer about 4 years ago

  • Status changed from New to Resolved
  • Target version set to chirp-legacy
  • 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!

Actions #5

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF