Project

General

Profile

Actions

Bug #3395

closed

Unable to read from Baofeng A58

Added by Albert Linga over 8 years ago. Updated about 4 years ago.

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

0%

Estimated time:
Chirp Version:
daily
Model affected:
Baofeng A-58
Platform:
Windows
Debug Log:
I read the instructions above:

Description

When I'm trying to read from the radio it says Radio did not respond. I'm using BF-F8HP from the model. I tried switching to other models then back to BF-F8HP and from time to time the radio led blinks but the response is incorrect model. I've looked at the debug log and found this when trying to determine the radio version:

[2016-02-29 05:42:13,187] chirp.drivers.uv5r - INFO: Radio Version is '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'

The following are the power on messages:

3 + pow on:
Line 1 = Version
Line 2 = NT5101
6 + pow on:
Line 1 = 150915N
Line 2 = WP970I

I've back read some of the issues and found that this can't be resolved since CHIRP needs the firmware version. Can't there be an option in CHIRP to select the firmware for a model? That way it won't rely on the memory block for the firmware version info? That memory block might be blank intentionally, unintentionally, or encrypted.


Files

Actions #1

Updated by Albert Linga over 8 years ago

Also i'm using the baofeng generic cable for this. It uses prolific driver. I've seen there were issues on the new driver since Prolific's design are being cloned by several manufacturers so they decided to upgrade the drivers to work only on their devices. I've used version 3.2.0.0 as adviced in Miklor.com. Hence i'm able to connect to the radio from time to time as described above.

Actions #2

Updated by Albert Linga over 8 years ago

So I tried commenting out some lines in uv5r.py

The following is a work around when I get a Radio did not respond error. I don't know what's wrong why most of the time it doesn't get the expected acknowledge return. So for the work around I assumed that the radio is responding.

#if ack != "\x06":
# if ack:
# LOG.debug(repr(ack))
# raise errors.RadioError("Radio did not respond")

When I was able to read from the radio intermittently, this solves the issue if Chirp can't get the firmware version from the memory block.

#if not any(type in radio_version for type in radio._basetype):

raise errors.RadioError("Incorrect 'Model' selected.")

After doing this I was able to download / upload from the radio. Now I do understand that this is dangerous since the checks are there in order to not mess with the radio's memory. Perhaps the developer, who has a deeper understanding on the software and how to program the radios, can shed more light to this.

73

Thanks,
Albert DW1ZEQ

Actions #3

Updated by Albert Linga over 8 years ago

The line

  1. raise errors.RadioError("Incorrect 'Model' selected.")

should be

#raise errors.RadioError("Incorrect 'Model' selected.")

Actions #4

Updated by Jim Unroe over 8 years ago

  • Status changed from New to Feedback

Albert,

Apparently the factory failed to put the firmware version into memory. When the radio returns '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' as the firmware version, CHIRP has know way to know what the firmware version of the radio is. You'll just have to continue to "hack" your CHIRP to get it to work with you radio. Sorry.

Jim KC9HI

Actions #5

Updated by Albert Linga over 8 years ago

Hi Jim,

Thank you for your response. I wonder if you have an idea on what's supposed to be the line 1 and line 2 for the firmware version? I was able to update the value when I uploaded to the radio so I was thinking if I have the version expected I could write it and won't have to do with the hack anymore after that.

Thanks,
Albert

Actions #6

Updated by Albert Linga over 8 years ago

Albert Linga wrote:

Hi Jim,

Thank you for your response. I wonder if you have an idea on what's supposed to be the line 1 and line 2 for the firmware version for baofeng A58? I was able to update the value when I uploaded to the radio so I was thinking if I have the version expected I could write it and won't have to do with the hack anymore after that. I was initially looking at the ident for A58 in the module file but the values in there when converted from hex to ascii doesn't make sense as a version number

Thanks,
Albert

Actions #7

Updated by Jim Unroe over 8 years ago

I wouldn't have any idea. And if I did, this region of memory is read only. So you shouldn't be able to write to it even if you knew what should be there.

Jim

Actions #8

Updated by Albert Linga over 8 years ago

Jim,

How are you comparing if the firmware version is supported? Also from what I have experienced, I was able to write on line 1 and line 2 of firmware version block. I was also expecting this block was read only , apparently it was not. I'm guessing since the manufacturer didn't write on that block, the write access restriction wasn't also specified.

Thanks,
Albert

Actions #9

Updated by Jim Unroe over 8 years ago

Albert,

To be detected as a BF-F8HP, tone of the following 5 strings must be found anywhere in the 14 byte region of memory that contains the firmware version.

"BFP3V3 F", "N5R-3", "N5R3", "F5R3" or "BFT"

But even if you edited the image to put "N5R3" into this region of memory, CHIRP wouldn't upload the image to the radio because the firmware version of the image must exactly match the firmware version of the radio before an upload will be allowed.

Contact me by way of email and I will see if I can get you going.

Jim

Actions #10

Updated by Bernhard Hailer over 4 years ago

  • Model affected changed from BAOFENG A58 to Baofeng A-58

The A-58 is not on the list of supported radios - were you able to make it work with any of the Baofeng drivers?

Actions #11

Updated by Bernhard Hailer about 4 years ago

  • Status changed from Feedback to Closed

Not resolvable due to firmware limitations.

Actions

Also available in: Atom PDF