Bug #2317

baofeng uv5R

Added by paul smith over 7 years ago. Updated almost 7 years ago.

Status:Closed Start date:02/14/2015
Priority:High Due date:
Assignee:- % Done:

100%

Category:-
Target version:-
Chirp Version:daily Platform:All
Model affected:Baofeng UV5 R

Description

when reading from radio in chirp software the radio, Baofeng UV5 R firmware BFB297 reports error code "radio refused to send block code 0x1ec0

uv5r.py (56 kB) Jim Unroe, 03/13/2015 04:30 pm

debug.log (23.4 kB) Andy Karimov, 03/14/2015 04:02 am

DebugLog.txt (34.3 kB) gary frazier, 06/19/2015 01:19 pm

debug.log (25.2 kB) Charles Estabrooks, 08/01/2015 07:26 pm


Related issues

related to Bug #2333: got a nv-5 that will not accept CHIRP Closed 02/19/2015

Associated revisions

Revision 2530:7e65cd3b658e
Added by Jim Unroe over 7 years ago

[UV-5R] "radio refused to send block code 0x1ec0" patch

Fix downloading/uploading issue for UV-5R.

Mathieu Rozon created the original patch.
Updated by Jim Unroe for better uploading compatiblilty.

Fixes #2317

Revision 2549:cf13cc95fcfb
Added by Jim Unroe over 7 years ago

[UV-5R] "radio refused to send block code 0x1ec0" patch #2

Small timing tweak

Related to #2317

History

Updated by Jim Unroe over 7 years ago

  • Status changed from New to Feedback

If your programming cable has a Prolific type USB-to-TTL chip in it, then downgrade the automatically installed Windows driver to v3.2.0.0 per the guide on the Miklor website. The majority of the programming cables that have these chips are not compatible with the latest driver. No programming software will work until the programming cable is operating properly.

Jim KC9HI

Updated by paul smith over 7 years ago

the programming cable is a genuine FTDI cable. I have programmed other UV5 R using this cable and chirp software. when turning on the radio while pressing 3 brings up BFB297. I still get this error message "radio refused to send block code 0x1ec0"

Updated by Axel Smith over 7 years ago

I receive this same error code on chirp-daily-20150210 with 2 different cables (FTDI and Prolific) and 2 different u5vr radios. On 0.4.1, I get this error 'radio refused to send block code 0x0000'. This is on a mac. Also tried on a VM with windows xp and the live cd. Radios were just purchased...

Updated by Bobby Helco over 7 years ago

Just got a new UV-5RV3+ which has firmware BFB297. Using Windows 7 64bit. Using Prolific type cable. Latest chirp-daily-20150210 software. Getting the same error from chirp. "Radio refused to send block 0x1ec0"

Will be watching this bug for updates. Also I'm willing to do any debugging you would like me to do to help solve this problem.

Updated by Bobby Helco over 7 years ago

Downloaded latest daily build chirp-daily-20150218-win32. Still having the same error.

Updated by paul smith over 7 years ago

have managed to get radio to read from a different software platform. if you are interested you could try this. http://hamfiles.co.uk/index.php?page=downloads&type=entry&id=radio-programming%2Fbaofeng%2Fsoftware_10%2Fbaofeng-uv-5r

Updated by Jim Unroe over 7 years ago

I have someone that is going to loan me one of these radios. This should help with with diagnosing the problem.

Jim KC9HI

Updated by Bradley Turner over 7 years ago

I'm in the exact same situation. I have twenty "new" Baofengs (BFB297) and each of them are giving me this error... it only happens with the new ones from Amazon, none of my older ones with the same firmware version.

Updated by Mathieu Rozon over 7 years ago

Hi, I have the same issue, with my older radios working and the error with the newer radios. All radios are BFB297.

I sniffed the serial traffic and here is the output in hex values. I did the tests multiple times and the outputs are the same.
Each line is corresponding to the packet sniffed.

  1. READ command with WORKING RADIO:
    To Radio > 50
    To Radio -> BB
    To Radio -> FF
    To Radio -> 20
    To Radio -> 12
    To Radio -> 07
    To Radio -> 25
    To Radio -> 02 06
    From Radio <
    06 AA 36 74 04 00 05 20 DD
    To Radio > 53 1E C0 40
    From Radio <
    06
    From Radio <- 58 1E C0 40
    To Radio > 06
    From Radio <
    ... "WELCOME " ...
  1. READ command with ERROR "radio refused to send block code 0x1ec0"
    To Radio > 50
    To Radio -> BB
    To Radio -> FF
    To Radio -> 20
    To Radio -> 12
    To Radio -> 07
    To Radio -> 25
    To Radio -> 02
    From Radio <
    06
    To Radio > 06 53 1E C0 40
    From Radio <
    AA 30 76 04 00 05 20 DD 06
    From Radio <- 58 1E C0 40
    To Radio > 06
    From Radio <
    ... "WELCOME " ...

I do not know the packet structures, but my quick guess is that the packets are not sent at the same intervals than previous radios for some reason.
Maybe the code is miss reading the packet when waiting for the "1E C0", because the "1E C0" seems to be received from the radio.

I hope it will help you.

- Mat -

Updated by Mathieu Rozon over 7 years ago

The strike-through text in my previous post was not intentional. Please ignore them as I don't see a way to edit the post.

Thank you.

Updated by Nikita Mogilevsky over 7 years ago

This is not a Windows specific issue. Running on Ubuntu 12.x the cable works fine with programming on my friend's Baofeng, however I get the same error code with the current latest daily build 20150301.

chirpw output:
http://pastebin.com/Keas43VD

Updated by Bradley Turner over 7 years ago

This issue is frustrating beyond all get-out. I am likely going to return these UV-5Rs and move to a 5R+ or other variation.
Did everyone on here purchase within the last 30 days or so from Amazon?

Updated by Chad Smith over 7 years ago

Bradley Turner wrote:

This issue is frustrating beyond all get-out. I am likely going to return these UV-5Rs and move to a 5R+ or other variation.
Did everyone on here purchase within the last 30 days or so from Amazon?

I purchased 3 UV-5Rs (in one order) from Amazon about 2 weeks ago. 2 of them worked with Chirp and 1 did not. I sent that 1 back and Amazon promptly replaced it. Alas, the replacement does not work with Chirp either :(

I am able to program the radio using the OEM software, as suggested earlier, but it is soooo much more trouble than Chirp.

I should also mention I ordered 2 BaoFeng BF-F8HPs from Amazon in mid-February and they both work fine with Chirp!

I would be happy to send my Chirp incompatible unit to one of the developers if that would help with troubleshooting.

Updated by Jim Unroe over 7 years ago

A local ham loaned me his radio that has this issue. I have made serial captures of the transfer using the OEM software. I have not been able to determine what is causing the problem.

The one thing I have been able to determine, at least for the radio I have, is that the firmware version is N5R-219, which is not the most recent firmware version.

Jim KC9HI

Updated by Nikita Mogilevsky over 7 years ago

Bradley Turner wrote:

This issue is frustrating beyond all get-out. I am likely going to return these UV-5Rs and move to a 5R+ or other variation.
Did everyone on here purchase within the last 30 days or so from Amazon?

Yeah, I ordered mine from amazon with firmware BFB297 and received it last Friday.

Updated by Rodney Pierce over 7 years ago

I also recently received (1 week) two UV-5R radios with BFB297. Initially I could not get my Generic USB Cable to work, so I returned it and got an actual Baofeng brand USB Cable. The drivers from Milkor.com worked fine and I am using the 3.2.0.0 Driver on a Window 7 (64bit)OS.

The Baofeng Software that came with the USB cable works but it is so limited and importing tables is non-existent as best I can tell. Wonder what Baofeng could have changed to cause this?

The problem comes in with the CHIRP daily-20150301. I get "Radio refused to send block 0x1ec0". I really was looking forward to using CHIRP instead of "fat fingering" everything.

New to forum.... any help much appreciated.

Updated by Rodney Pierce over 7 years ago

Rodney P wrote:

I also recently received (1 week) two UV-5R radios with BFB297. Initially I could not get my Generic USB Cable to work, so I returned it and got an actual Baofeng brand USB Cable. The drivers from Milkor.com worked fine and I am using the 3.2.0.0 Driver on a Window 7 (64bit)OS.

The Baofeng Software that came with the USB cable works but it is so limited and importing tables is non-existent as best I can tell. Wonder what Baofeng could have changed to cause this?

The problem comes in with the CHIRP daily-20150301. I get "Radio refused to send block 0x1ec0". I really was looking forward to using CHIRP instead of "fat fingering" everything.

New to forum.... any help much appreciated.

Updated by Jacinto Gutierrez over 7 years ago

I am having the same problem with the radios that I got from Amazon. I got a total of 4 UV-5r three with firmware BFB297 do not work with Chirp. The one with firmware BFS297 firmware works with Chirp. The Chirp software is installed on my MAC.

Updated by Chad Smith over 7 years ago

I have two that work and one that wont. According to Power-on+3, they are all 3 @ BFB297.

Updated by mike wick over 7 years ago

Greetings,

I have 2 UV-5R radios with firmware BFB297 that do not seem to want to download to chirp as well.
- Downloaded latest build CHIRP daily-20150306 (and last night daily-20150305).
- Using Baofeng branded cable with prolific driver 3.2.0.0.
- Download settings (com3, Baofeng, UV-5R) radio volume set to max.
- When I click OK, activity light on radio goes red shortly then to green, radio reboots and I get dialog box "*An error has occured* Radio refused to send block 0x1ec0".
- Without disconnecting the radio I start baofeng UV-5R Series Program Software to successfully read radio.
+ While baofeng software is reading, red activity light on radio blinks, then radio reboots after read is complete.
- I changed a couple of settings in the baofeng program software and successfully write them to the radio.
+ While baofeng software is writing, green activity light on radio blinks, then radio reboots after write is complete.

My conclusion is that my cable is working correctly as it can read and write to the radio with baofeng software. I would really love to use chirp to program my radios and would like to help test any potential fixes for what looks like an issue with firmware BFB297.

Updated by Geoff Billin over 7 years ago

Fails with CHIRP daily-20150310 to UV-5R serial 13U0985261, FW 141006N under Windows 8.1 with prolific-type chip (unsure as to pedigree).
The same machine and daily build version is successful with serial US2013248498 shipped with FW N5R-219.

Log exerpts from failed session:
[2015-03-10 11:24:46,575] chirp.logger - DEBUG: CHIRP daily-20150310 on WinVista/7 (Python 2.7.2)
[2015-03-10 11:25:05,767] chirp.ui.mainapp - DEBUG: User selected Baofeng UV-5R on port COM5
[2015-03-10 11:25:06,033] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 bb ff 20 12 07 25 00 P.....%.

[2015-03-10 11:25:06,142] chirp.drivers.uv5r - INFO: Ident: 000: aa 30 76 04 00 05 20 dd .0v.....

[2015-03-10 11:25:07,267] chirp.ui.reporting - DEBUG: Reporting exception
[2015-03-10 11:25:07,267] chirp.ui.common - ERROR: -- Exception: --
[2015-03-10 11:25:07,267] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 238, in run
File "chirp\drivers\uv5r.pyo", line 703, in sync_in
File "chirp\drivers\uv5r.pyo", line 511, in _do_download
File "chirp\drivers\uv5r.pyo", line 480, in _get_radio_firmware_version
File "chirp\drivers\uv5r.pyo", line 470, in _read_block
RadioError: Radio refused to send block 0x1ec0

Data transfer to the 13U0985261 serial works OK with VIP software 1.0.0.0 dated 9/19/2012 on a different PC running XP, same
Prolific(?) chip cable.

Sorry, no serial port sniffer available, but I could test fixes.
73

Updated by Jason Li over 7 years ago

Same problem here with the error when working with CHIRP, using the "Prolific USB-to-Serial Comm Port" cable and 3.2.0.0 driver. The Baofeng software can read/write perfectly.

The error:

An Error Has Occurred
Radio refused to send block 0x0000 (Does this mean it's not sending data at all?)

The LED only lights up green for a second, and then the radio reboots. Is this the cable's problem or CHIRP's?

Updated by Chris R over 7 years ago

Hi all,

I too am having the same issue. I bought one of the prolific cables and was getting 0x0000. I purchased an FTDI one and same problem. This was with stable build. I downloaded the daily build hoping it would work for me since the stable is a few months old and the code changed to 0x1ec0. I also bought the radio this past week.

If I had to guess (new to the forum and to chirp) the problem is in the UV5r.py read block command, line 433...which really means "if len(answer) !=4" is true in line 404. Maybe baofeng did a firmware swap messing with the expected block.

My radio is BFB297 and S/N 13U1001272.

This is a pretty cool piece of software. I'll try to set up a linux box and check out the repository.

73 and good luck!

Updated by Jeremy Vinding over 7 years ago

Also occurs on Mac with both FTDI and Prolific cables
also with BFB297
Let me know if I can give you any information that would be helpful.

Updated by Jim Unroe over 7 years ago

Yes. It is a problem with the radio. It doesn't matter which OS, programing cable or driver you are using.

Jim KC9HI

Updated by Robert Meredith over 7 years ago

I'm having this same issue with 2 new UV5Rs. Both are running BFB297 firmware. I'm running the lastest stable build, not daily. I'm using a and Prolific cable (3.2.0 driver). On CHIRP 0.4.1, I get this error 'radio refused to send block code 0x0000'. The radio then reboots automatically. I've successfully programmed both radios using the same cable and same computer - using the Baofeng VIP software (which sucks).

Updated by Jim Unroe over 7 years ago

First... Please do not use the CHIRP v0.4.x stable build for Baofeng radios. It is nearly 1 year old and is no longer compatible with the currently shipping radios.

Second... Unless your radio is about 2 years old, it does not have BFB297 firmware. All firmware versions since BFB297 report BFB297 in the [3] + Power-on message. The "real" firmware version can only be determined by using CHIRP (Settings -> Other Settings -> Firmware Message 1).

Here is a patched file that was started Mathiew Rozen. It had some issues with previously supported radios so I modified it to improve compatibility with them.

I need this to be tested by some of you before I formally submit it to be included in CHIRP.

To test please
  1. Save the uv5r.py from this issue page somewhere on your pc (click on the file link and on the following page use download link)
  2. Install last CHIRP daily build
  3. Load CHIRP
  4. Click Help in the menu bar and enable "Enable Developer Functions"
  5. Click File -> Load Module and load the file that was saved earlier

Then use Chirp as usual.

The last step must be repeated every time you start Chirp to select the modified module. Otherwise the stock one will be used. No permanent modification of the CHIRP install will be done.

Please test not only the radios that have the "Radio refused to send block 0x1ec0" issue, but also ones that used to work (to make sure they still do).

Please report the radio's Model number, "real" Firmware version and Success/Failure of this module. The faster we can get some favorable reports back, the sooner this patch can be submitted to be included into a CHIRP daily build.

Jim KC9HI

Updated by Jeremy Vinding over 7 years ago

Success! My radio was one that failed wit "0x1ec0", I have no other radios to test with.

Model: UV-5RV3+
"Real" Firmware: N5R2401

CHIRP: chirp-daily-20150312.app

Thanks very much!

Updated by Robert Meredith over 7 years ago

I tried this on a radio that was receiving the "0x1ec0" error.

1. Installed daily build using chirp-daily-20150312-installer.exe
2. Downloaded the uv5r.py file (above) and loaded it per instructions
3. Connected a UV5R (N5R-219 firmware) w/ a Prolific cable (PL-2303 XA/HXA chip, 3.4.67.325 driver)
4. Downloaded config from radio SUCCESSFULLY
5. Made changes to config and uploaded to radio SUCCESSFULLY

I also verified this works w/ the same hardware except using the 3.2.0 driver as noted in my first post.

Updated by Rodney Pierce over 7 years ago

First I would like to thank Jim KC9HI. I was able to get the software installed and running. I noticed that I had to load the uv5r.py module twice.(even after the screen showed the .py settings) Maybe it was just me.
The other thing that happened was after a cut and paste of some NOAA bands into my current band plan the Chirp Software crashed with no reported error and Windows requested a chance to fix the error.??? (not likely)
Over all I was able to get my UV-5R programed with no other problems. Wow at least I can use the software. Using Windows 7 (64bit). On a scale 1-10 I give it a 8. Thanks Again.

Updated by Andy Karimov over 7 years ago

With chirp-daily-20150314 use this file have message Incorrect 'Model' selected.
After commenting these lines

  1. if not any(type in radio_version for type in radio._basetype):
  2. raise errors.RadioError("Incorrect 'Model' selected.")

channels read but settings is empty
In browser - firmware_msg i see line1 "HN5RV01" and line2 "1FB297 "

Updated by Andy Karimov over 7 years ago

I'm sorry, I forgot to attach the log

Updated by Jim Unroe over 7 years ago

Andy Karimov,

You have a different issue than the one #2317 is for. Please open up a new issue and describe what radio model you have and a link to where you got it if possible.

Jim KC9HI

Updated by Andy Karimov over 7 years ago

Without a new uv5r.py file I have exactly this issue.

New Baofeng UV-5R (from 409shop), message "Radio refused to send block 0x1ec0" when try read data from radio.
Cable & driver work ok, baofeng "software" work ok, but CHIRP not.

Updated by Jim Unroe over 7 years ago

Andy,

I understand that. But the brand new "HN5RV01" and "1FB297 " firmware version is a different issue and must be dealt with separately.

Jim

Updated by Geoff Billin over 7 years ago

Successfully Downloaded from radio using the supplied uv5r.py to the same radio (serial 13U0985261, FW 141006N) , O/S, and connecting cable that experienced the problem as documented in post #21.

I also successfully downloaded from another radio that had worked earlier: Serial US2013248498 FW N5R-219, so I don't see any regression in function.

I say ship it!
73

Updated by Ken   over 7 years ago

BaoFeng UV5R
Power on +3 = BFB297
Power on +6 = 150110N
S/N 13U0985101
chirp-daily-20150314

Purchased new directly from Amazon (ships from and sold by Amazon.com), received a few days ago. A white sticker on the UV5R box reads B007H4VT7A and is dated February 12, 2015.

Amazon link: http://tinyurl.com/p32dquj

Cannot download from radio. It doesn't matter whether it's a Mac or PC, or a prolific or an FTDI programming cable, I always get the "Radio refused to send block 0x1ec0" error. Along with three short red flashes, one long green flash, and then a radio reboot

Loaded the uv5r.py python module mentioned above and now I get an "Incorrect Model selected" error. Plus three short red flashes, one long green flash, followed by a another radio reboot. Again, Mac, PC, Prolific, FTDI, doesn't mater, same problem.

I have no other problems with any of my other radios, just this new UV5R.

-Ken

Updated by Phillip Smith over 7 years ago

I have the same power on results as Ken.

Getting "Radio refused to send block 0x0000" from trying to download radio.

Using FTDI cable,

Attempted to load module, results in this message "Unable to load module: cannot import name RadioSettings"

Using Mac OSX 10.6.8 if that matters.

Thanks for all your work Jim, hope this all gets resolved soon.

- Phil

Updated by Vic Gaines over 7 years ago

I got "Unable to load module: invalid syntax (uv5r.py, line 1)" when I tried to load the uv5r.py file
-Vic

Updated by Jim Unroe over 7 years ago

Try today's daily build (20150316) with the patch for this issue.

Jim KC9HI

Updated by Ken   over 7 years ago

Good morning Jim.

(Radio info in post 38.)

Using today's daily build (20150316)…

With patch: "Incorrect 'Model' selected." error. (Followed by a reboot.)
Without patch: "Incorrect 'Model' selected." error. (Followed by a reboot.)

Just for the heck of it, I left the UV5R connected and selected BF-888 from the drop down. Got the expected "No response from radio." error. (With or without the patch.)

But patch or no patch, an actual BF-888S still works fine.

-Ken

Updated by Geoff Billin over 7 years ago

I just tried daily 20150316 under Windows 8.1 with the radios below. All were able to successfully download and upload:

Serial FW msg1 FW msg2
1330001873 Ver BFB281
13U0985253 N5R2401 BFB297
13U985261 N5R-219 BFB297

Additional details available upon request.
73

Updated by Vic Gaines over 7 years ago

I feel really silly. How do I use the daily build (20150316).

Thanks,
Vic KK6SJU

Updated by paul smith over 7 years ago

Ok Have updates chirp software 20150316 and the radios now programme using chirp. Many thanks for everyone's help

Updated by Jim Unroe over 7 years ago

Ken,

I think Baofeng has slipped in a new firmware version that CHIRP doesn't know about. Provide a debug.log for us to look at. Andy had the same thing. If that is the case, I will have you start another issue.

Jim KC9HI

Updated by Jim Unroe over 7 years ago

Vic,

You download it, install it and use it just like whatever you had before.

Jim KC9HI

Updated by Ken   over 7 years ago

Hi Jim. I’ve emailed you my debug logs. (They're around 170 lines each.) I hope that's OK with you.
-Ken

Updated by Phillip Smith over 7 years ago

I am also getting the "Incorrect 'Model' selected" and a reboot using the new one.

- Phil

Updated by Jim Unroe over 7 years ago

Phil,

What does the radio display when you turn it on with the [3] key pressed?

Jim KC9HI

Updated by Phillip Smith over 7 years ago

BFB297

- Phil

Updated by Ken   over 7 years ago

Well, after conferring with Jim, (thanks again Jim!), it looks like the UV-5R I received from Amazon had gotten a bad firmware flash from the factory. This is what is keeping Chirp from recognizing the radio. So back it goes!

Cheers everyone!,
-Ken

Updated by Jim Unroe over 7 years ago

Phil,

I wonder if your radio has the same issue as Ken's. The area that CHIRP uses to detect the radio has no data. The debug.log file that he email to me pretty much showed there was no data but is was later confirmed when he email a .img file that we coaxed out of the radio.

Jim

Updated by mike wick over 7 years ago

UV-5R with "Radio refused to send block 0x1ec0" issue now works with uv5r.py update.
Firmware message 1: N5R2401
Firmware message 2: BFB297
6+Power-On Message 1:141006N

Works on both windows7 and OSX 10.9.5
CHIRP daily-20150306

Updated by james bean over 7 years ago

I've been watching this thread with interest.

Have a UV-5R
Power +3 gives bfb297
Power +6 gives 150126N

I'm using the daily build & loading the uv5r.py update.

I also get "Incorrect "model selected"" and then the radio reboots.

Updated by Blaine J over 7 years ago

UV5R+ BFB297 130711N - tried daily 20150316 up to 20150325 with and without uv5r.py module loaded.
I just bought this thing from Amazon as well.
refused to send block 0x000 error. 3 quick red light flashes then reboot.

I've tried 2 different cables that work with my Wouxun radio.

Updated by Will Murray over 7 years ago

Hi. New to this site, new to Ham radios, so please be gentle if I don't follow proper protocol for this message forum. I am currently taking a course at my college to learn the things I need to know for my Technician and (hopefully also) General licenses. Don't have them yet.

Just received my new brand Baofeng UV-5R from Amazon yesterday. Finished charging, so went online to download CHIRP. I assume it's the latest daily version (it says CHIRP 0.4.1 GTK 2.24.10 PyGTK 2.24.0 Python 2.7.2 in the Help/About box). The USB cable wasn't recognized, so downloaded 3.2.0.0 from miklor.com and installed it via the instructions. It's installed now and using 3.2.0.0 (verified) on COM5. I followed the CHIRP instructions, and get the Cloning message, followed by "Radio refused to send block 0x0000", the blinking lights and reboot of the radio follow.

Power 3 gives: Ver. BFB297
Power 6 gives: 150110N
I cannot find the "settings" option mentioned above that is supposed to give me the "real" version number.

I downloaded the uv5r.py file recommended at the top of this post, but when I try to load the module, I get the error message: Unable to load module: cannot import name RadioSettings

I'd be happy to help troubleshoot, send logs, etc., but I have no idea how to find them or where to send them.

Thanks!

Updated by Jim Unroe over 7 years ago

Will,

Nope. The CHIRP v0.4.1 stable build is one year old this month. You need to upgrade to a recent daily build which provides a fix for change in the cloning protocol that Baofeng made on a few of the most recent radios.

Jim KC9HI

Updated by Will Murray over 7 years ago

Jim Unroe wrote:

The CHIRP v0.4.1 stable build is one year old this month. You need to upgrade to a recent daily build which provides a fix for change in the cloning protocol that Baofeng made on a few of the most recent radios.

Thanks for the speedy and very helpful reply, Jim. I uninstalled the old version, installed the new one, and it worked fine without needing the .py file at all.

Updated by Jim Unroe over 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 0 to 100
  • Chirp Version changed from 0.4.0 to daily
  • Platform changed from Windows to All

Thanks to all that tested the update.

Jim KC9HI

Updated by Jim Unroe over 7 years ago

  • Status changed from Closed to In Progress

Reopened to allow adding a small tweak.

Jim

Updated by gary frazier about 7 years ago

Using the "uv5r (4).py" module, using chirp-daily-20150616 in Linux, I can get my UV-5R to download, but when I try to upload I get
"The upload was stopped because the firmware version of the image ( ) does not match that of the radio (ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ)"

Radio Version is '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'

Should I return the radio, or is a fix available?

Thank you,
Gary

Updated by Jim Unroe about 7 years ago

  • Status changed from In Progress to Closed

This is a problem with the radio, not CHIRP. The data required to identify which radio that the "image" came from is missing. CHIRP cannot be change to blindly upload image files to Baofeng radios because it is understood that uploading an incompatible image can cause undesired behavior.

You can either get the radio replaced or use the OEM software since it is not affected by this missing information.

This problem with the bland firmware version is unrelated to the original so I am closing this issue.

Jim KC9HI

Updated by Charles Estabrooks about 7 years ago

Having the same "Radio refused to send block" problem. Block number varies each time. Some details:

- Using "genuine" FTDI cable purchased from AnyToneTech.com
- Mac OS X 10.8.5
- Using daily build chirp-daily-20150702
- loaded uv5r.py patch shown above

Thanks in advance,
Charles KC1ECU

Updated by Jim Unroe about 7 years ago

Charles,

Don't load the "uv5r.py" patch. You are just downgrading your Baofeng support to an older daily build version.

What happens when you use an clean install of the latest daily build?

Jim KC9HI

Updated by Clecio M almost 7 years ago

Baofeng UV-5R with the message: Radio refused to send block 0x0000

Windows 7 and XP
BFB297
15031N
Profilic Driver 3200 and 4 versions
Profilic cable

Using the Baofeng programm, works fine.

Updated by Jim Unroe almost 7 years ago

Clecio,

Don't use the CHIRP v0.4.x stable build. As mentioned above, it is 16 months old. The problem that you are having was addressed earlier this year in a daily build. And that is why this issue is "closed".

Jim KC9HI

Updated by Clecio M almost 7 years ago

I unlock my Baofeng UV-R5 with a old Chirp.

2.24
http://trac.chirp.danplanet.com/chirp_daily/LATEST/

No problem with the conexion.

Also available in: Atom PDF