CHIRP

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!

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.

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.

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?

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.

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)

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

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

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.

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

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!

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

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!

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

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?

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

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!

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.

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

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/

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

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.

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/

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

Thanks