Project

General

Profile

Actions

Bug #3353

closed

Radio NAK'd block at address 0x0f10 on Baofeng UV-B6

Added by Mike Crabtree almost 9 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/18/2016
Due date:
% Done:

0%

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

Description

UV-B6 seems corrupted and will not let me reset, so issues could be a firmware/hardware fault.

However, when I try to send a file to the radio, I always get this error at about 94% completion of clone.

Radio NAK'd block at address 0x0f10

This UV-B6 has 27 MENU items and often shows corrupted text in menus and frequencies, hence the reason why I am trying to get it rewritten.

I cannot see the Firmware identifiers in the CHIRP settings after download from radio.

Using the BAofeng software directly seems to complete the upoad to the radio with no errors, although I still have issues with getting the radio working again.

Standard radio RESET functions do not work.


Files

1.jpg (59.1 KB) 1.jpg Jonathan Roe, 11/21/2016 03:12 PM
2.jpg (33.7 KB) 2.jpg Jonathan Roe, 11/21/2016 03:12 PM
uvb5.py (25.7 KB) uvb5.py Jim Unroe, 11/21/2016 05:47 PM
Screen Shot 2016-11-21 at 19.19.01.jpg (28.8 KB) Screen Shot 2016-11-21 at 19.19.01.jpg Jonathan Roe, 11/21/2016 07:19 PM
debug.log (31.2 KB) debug.log Jonathan Roe, 11/22/2016 01:58 PM
Actions #1

Updated by Jim Unroe almost 9 years ago

  • Status changed from New to Feedback

The latest UV-B6 radios with 27 menus no longer support the "service settings". The radio still dumps the full memory when CHIRP reads the radio, but once the upload gets to the point where the service setting were (they are the last thing in the image), the radio stops acknowledging the remaining blocks so CHIRP aborts with this error.

Once the upload gets to the 94% point, everything that the radio uses was uploaded successfully. The upload just doesn't end gracefully. So it is safe to just ignore the error.

Jim

Actions #2

Updated by Mike Crabtree almost 9 years ago

Jim,

Thank you for clarifying at least that part of my problem.

It looks like I just have a brick of a radio now that doesn't want to be reset and cannot be forced into good behaviour by reprogramming.

Unfortunately no support from the vendor that sold it to me at a local hamfest and nothing online that really helps.

Luckily I have some radios from those good old manufacturers that just keep running and do work with CHIRP, so I know where I should focus my time in the future.

Mike

Actions #3

Updated by Jim Unroe almost 9 years ago

Have you tried uploading a "factory" image into it? There is a UV-B5 image "here":http://kc9hi.dyndns.org/uv5r/programming/CHIRPrecovery/. It doesn't sound like you have anything to lose.

Jim

Actions #4

Updated by Jim Unroe almost 9 years ago

I tried to fix this upload issue back when it was first discovered that these new radios with 27 menus reject the service settings part of the image. I don't have one of these radios to test. I am not going to buy one (I already have 1 to many UV-B5 radios) so I need someone with one of these radios that is willing to volunteer to do a few tests over the period of a few hours (or possibly few days).

Jim

Actions #5

Updated by Mike Crabtree almost 9 years ago

Jim,

I would be willing to do this, but because of the current state of this radio, I am not so sure I can confirm succesful results, unless ofcourse the development happens to make the radio work.

I can upload the factory image you pointed to, but it doesn't seem to work succesfully the whole time. and as soon as I change one thing, it can mess the radio up again.

Even sending the factory image, then adding one single frequency into memory and then downloading from the radio can cause the radio to get messed up.

Mike

Updated by Jonathan Roe about 8 years ago

Jim Unroe wrote:

I tried to fix this upload issue back when it was first discovered that these new radios with 27 menus reject the service settings part of the image. I don't have one of these radios to test. I am not going to buy one (I already have 1 to many UV-B5 radios) so I need someone with one of these radios that is willing to volunteer to do a few tests over the period of a few hours (or possibly few days).

Jim

I just got a UV-B6, downloaded from radio, copied my UV-B5 settings over, uploaded to radio, and got this 0x0f10 error.

Best times for me to volunteer are between noon-5PM & 7PM-midnight (Pacific). In exchange I could use some help with test mode power settings - it came from the factory as 255 255 255... all the way down (even the squelches, which I modified to 23 for squelch 0, ascending by 23 every step up).

Also a look at my UV-B5's factory power settings (attached) would be appreciated, as they were set vaguely parabolic, yet it seems like I can't reliably key up the highest elevation local repeaters even in the best of transmitting conditions on hi power. Maybe its transmitter is busted.

Actions #7

Updated by Jim Unroe about 8 years ago

  • Platform changed from Windows to All

Jonathan,

You can't change the test mode settings. They were removed from the radio. That is why you see the 0x0f10 error. Once the upload gets to the part that would have been the test mode settings, the radio ignores the remainder of the upload. Everything that the radio will accept has been uploaded, the error is just an annoyance.

Jim KC9HI

Actions #8

Updated by Jim Unroe about 8 years ago

Jonathan and Mike (or anyone with a 27 menu UV-B5 or UV-B6 that does not support Test Mode Settings),

Try the attached file with File > Load Module (you'll need Help > Enable Developer Functions checked).

Report back the results of your test.

Jim KC9HI

Actions #10

Updated by Jonathan Roe about 8 years ago

Post-module loading, an overwrite with the same .img gave "Radio NAK'd block at address 0x0f10" again.

Actions #11

Updated by Jim Unroe about 8 years ago

Please attach a clean debug.log file.

Actions #12

Updated by Jonathan Roe about 8 years ago

Actions #13

Updated by Jim Unroe almost 8 years ago

  • Status changed from Feedback to Closed

CHIRP daily-20170212 should resolve this issue. See #2109

Jim KC9HI

Actions

Also available in: Atom PDF