Bug #7067

Baofeng 888s - Read, cannot write channels on Windows 10

Added by Fun Fong over 2 years ago. Updated 11 months ago.

Status:Feedback Start date:09/13/2019
Priority:Normal Due date:
Assignee:- % Done:

0%

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

Description

Reads COM4, Attempt write COM4 "Failed to send block to radio at 0000"

Tried it on Channel 16, no difference. Thanks for your response.

h777_test_new_model.py - h777 with additional 'Y' command (19.2 kB) Tony Fuller, 10/22/2019 06:34 pm


Related issues

related to Bug #6969: GA-2S Partially Broken Closed 08/09/2019

Associated revisions

Revision 3254:7dba74b4fa43
Added by Dan Smith over 2 years ago

Revert r3233 to address likely regression.

According to bug #7067, we regressed the h777 module for some variants, whilst fixing
the root issue. This reverts that change to the less-broken original state while we
try to figure out something that will work for all models.

Revision 3356:37379cfd09d9
Added by Tony Fuller about 2 years ago

[h777] Fix some settings not taking effect
Fixes #7653
Does not cause regression in #7067

History

Updated by Bill Ward over 2 years ago

I'm having the same exact problem. I bought a second set of radios because I needed enough for everyone in my group to have one but the new ones won't talk to the old ones (2 weeks old but from different vendors on Amazon). I tried uninstalling the drivers and re-installing with internet turned off so it would pull from the chip in the cable as someone had suggested but that did nothing (couldn't detect any drivers).
Please help. I don't know what I'm doing. I've already spent over 4 hours fighting with these stupid things!

Updated by Wendy Muncey over 2 years ago

I also am having an issue with the BF-888s recently purchased that CHIRP sends back and error "Radio refused to enter programming mode" I have tried all of the additional items including making sure that the cable is legitimate and rolling back the drivers and making sure the CHIRP sw is up to date none of the above is working. The BF-888s software reads the radio but is extremely difficult to use. Any assistance or suggestions would be helpful.

Updated by Ben Norton over 2 years ago

We are also having this problem.
Can read from radio with Chirp (9/25 version), but it will not write to the radio.
BF-888S CMIIT ID: 2012FP1918

I downloaded BF-480 (version 7.01) from the Baofeng site.
It can read from the radio, and write to the radio, but it has no way to configure DCTS tones (required by our repeater).
We have a pile of BF-888S radios that work fine with Chirp, we now have a pile that will not work.
Any help would be appreciated.

Updated by Dan Smith over 2 years ago

I'm guessing this is related to the change in r3233 from #6969. Tony was pretty sure that this was always going to be right, but I was concerned that we'd break some older models. Tony can you comment?

Updated by Ben Norton over 2 years ago

I did some more work on this today.
I was hoping to find some unique attribute of BF-888S radios that are failing.
A box of 10 radios was purchased through Amazon, they all had identical CMIT IDs (2012FP1918 printed on radio under the battery). 8 failed, 2 succeeded.
I had read somewhere of someone using BF-480 software to copy a config from a good radio, and then write it to a bad radio. That did not work for me.

We have some other BF-888S radios which do not have a CMIIT ID printed under the battery. They all work.
I think we will just throw all 10 of them back in the box and return them to Amazon as 80% defective.

Updated by Wendy Muncey over 2 years ago

After many trials and errors I have had success programming the BF-888s units with the ZT-V68 software while not my preferred method of programming it is successfully reading and writing to the radios. (Side note the Baofeng BF-888 software bricked 2 of my units in the testing process)

Updated by Mike Prior over 2 years ago

I too am experiencing the exact same issue on two new 888s i.e. in my case, reads COM3, Attempt write COM3 "Failed to send block to radio at 0000"

The BF-480 software successfully reads and writes to both radios

Updated by Bill Ward over 2 years ago

I gave up and bought the BTECH FTDI cable that is supposed to be authentic. The one described on Miklor's site that is supposed to be plug & plan and "just plain works". With it, the radios refused to enter programming mode. GRRRR. I threw in the towel and asked a friend who is an IT supernerd to look at my radios. Using the cable that came with the radios (not the "authentic" BTECH cable) he had it figured out and had them all reprogrammed in about an hour. I had failed miserably for over 8 hours spread over 3 or 4 days, and he didn't even have to try the BTECH cable that I had bought! I don't know exactly what he did (I wasn't there) but here is what he said: "the cable that says "Baofeng" works with software at www.walkietalkiesoftware.com. It did not work with Chirp. I made a fake account, selected the model and downloaded the software."
I don't know if there was anything else he did to make it work but maybe this will point some of you in the right direction. I guess some things are best left to "professionals".

Updated by Dan Smith over 2 years ago

There was a change to this driver in August which is probably related. I've emailed the developer who wanted to make that change to see if there is anything that can be done aside from reverting the change out.

Updated by Tony Fuller over 2 years ago

(Side note the Baofeng BF-888 software bricked 2 of my units in the testing process)

Wow, that's horrible. I thought I ran the gamut of various versions but apparently not (or the newer radio firmware is worse now) :(
A box of 10 radios was purchased through Amazon, they all had identical CMIT IDs (2012FP1918...

@Ben Norton, can you post a link to the amazon product page? I may be interested in purchasing it for debugging (depending on the price)

Thanks,
Tony

Updated by Dan Smith over 2 years ago

I pushed a revert of that change, so if the "me too" people on this bug could test tomorrow's build and report back, that would be very helpful.

Thanks!

Updated by Tony Fuller over 2 years ago

Has anyone had a chance to test the update to CHIRP for this issue?

Also, feel free to watch this page for updates on when new posts are added :)
https://chirp.danplanet.com/watchers/watch?object_id=7067&object_type=issue

Updated by Matt Willis over 2 years ago

I have tried the 20191018 version and still have the same problem. I can read from the radio but can't write.
My cable uses the driver version 3.5 from this website:
http://www.wch.cn/products/CH341.html

(Previously with driver version 3.3 I was not even able to read from the radio.)

I have four radios I can't program now.

Your work is appreciated!

Updated by Tony Fuller over 2 years ago

Hi Matt (and all affected users)

I have an experimental driver based on (official Baofeng Software I've been using) if someone could test it, I would be very grateful. (No guarantees though)

It can be downloaded and loaded into CHIRP from the File menu -> Load Module
CHIRP will turn red, then go ahead and read from the radio, change something, and then write to the radio.

Updated by Matt Willis over 2 years ago

I tested now with version 20191022 without your module, then with your module. Neither worked unfortunately.

Updated by Remigiusz Borek over 2 years ago

I had the same problem with my new baofeng 888s, I use ch430 chip based cable.
I am not sure if this problem is due to radio or cable issue, but when I added time.sleep(0.1) between sending block and reading ACK it has started working.

On different computer, but the same cable I had a problem with putting radio into programming mode, and time.sleep(0.1) before reading ACK also helped.

@@ -121,6 +121,7 @@ def _h777_enter_programming_mode(radio):

     try:
         serial.write(CMD_ACK)
+        time.sleep(0.1)
         ack = serial.read(1)
     except:
         raise errors.RadioError("Error communicating with radio")
@@ -174,6 +175,7 @@ def _h777_write_block(radio, block_addr, block_size):

     try:
         serial.write(cmd + data)
+        time.sleep(0.1)
         if serial.read(1) != CMD_ACK:
             raise Exception("No ACK")
     except:

Can anyone confirm if it helps?

Updated by Mike Prior over 2 years ago

Tried writing to radio BF-888s with latest CHIRP (2019-11-09) but still not allowing data to be written

Updated by Hardy Pottinger over 2 years ago

I'm having a similar problem. Baofeng's 888 software and their supplied cable couldn't read from the BF-888S. I switched to their ZT-V68 and my old Retevis (prolific chip) cable and that was able to read/write ok. I tried the 20191029 and 20191109 versions of Chirp with my Retevis cable and the radio refused to go into programming mode. I ran it again with Eltima's serial port monitor to see what was going on. Chirp successfully sends the string 'PROGRAM' to the radio, then attempts to read from the radio, gets 6 bytes of an 8 byte string (50 33 31 30 37 f7 P3107รท )and times out. I would attach the log file but it's a binary format.
Hope that helps. I'm done for the day!

Updated by Andrew Farris over 2 years ago

Hardy Pottinger wrote:

I'm having a similar problem. Baofeng's 888 software and their supplied cable couldn't read from the BF-888S. I switched to their ZT-V68 and my old Retevis (prolific chip) cable and that was able to read/write ok.

Since I just ran into this issue as well with a new BF888s set, trying to program similarly to my other set I wanted to comment. I have two cables, one Baofeng branded, one not. I'm not certain which chips they have but they may both be FTDI.

I have just installed Windows 10 chirp daily 20191110. First time trying on Windows (used on Fedora Linux before release 31 which removes python2 support so chirp is broken).

I found out that using both my cables, the same behavior is present for the two new radios but is different from the old ones. The old radios can download/upload repeatedly once the cable is connected and have no issues. But the newer radios have an issue when they can download repeatedly, but an upload fails with this reported error if I have downloaded first since the cable was connected. If I disconnect the cable and reconnect and then immediately upload I can upload once successfully, and then download as many times as I want... but I could not upload again. I could upload only once, even if I did not try to download again between, only the first upload works. If I disconnect and reconnect (without any windows reboot), it works fine again for a single upload or any number of downloads.

Updated by Andrew Farris over 2 years ago

I looked at device manager and both my cables show up as ch430.

Updated by Bart Thom about 2 years ago

Having the same issue. I installed chirp-daily-20190102-installer.exe... it worked, uploads to radio and downloads with no errors. ??? I would say it has to be software related.

https://trac.chirp.danplanet.com/chirp_daily/daily-20190102/

Updated by Ivan Huter about 2 years ago

Bart Thom wrote:

Having the same issue. I installed chirp-daily-20190102-installer.exe... it worked, uploads to radio and downloads with no errors. ??? I would say it has to be software related.

https://trac.chirp.danplanet.com/chirp_daily/daily-20190102/

Hi Bart Thom,
I created login account just to say 'THANK YOU!'. Be safe.
--Ivan

Updated by Tony Fuller about 2 years ago

Just to confirm, the 02 Jan 2019 build of chirp does not have the "Radio refused to enter programming mode" error but later versions do? If there wasn't a major rewrite of the code in the last year it should be fairly easy to track down.

Updated by z Hiking about 2 years ago

Same issue exists and error message with Baofeng GT-22 (functionality/specs equal to Baofeng 888, different form factor).

Same workaround - downgrade CHIRP daily-20190102. https://trac.chirp.danplanet.com/chirp_daily/daily-20190102/

Updated by Marc Fleming over 1 year ago

Can anyone send me or link me to chirp-daily-20190102?

Thanks

Updated by Bernhard Hailer 11 months ago

  • Status changed from New to Feedback
  • Target version set to chirp-daily
  • Model affected changed from (All models) to Baofeng BF-888S
  • Platform changed from Windows to All

I assume this issue is resolved? Thanks.

Also available in: Atom PDF