[chirp_devel] Need help with some Baofeng radios

[Jim Unroe]

Hi Jens,

On Wed, Oct 1, 2014 at 10:30 AM, Jens Jensen <af5mi at yahoo.com> wrote:

> When I was looking at the oem software file format and program, I noticed
> a few things.
> 1. in the .dat saved file, they only store the "main" block. i.e., without
> the ident.
>

And the .dat file seems to be common across any of the UV-5R variant
radios. That is, a .dat file from a UV-5R can be loaded into the software
for a UV-82 or a UV-6 and so on.

2. they seem to only check the ident on the fly at clone time
> 3. they don't store the "aux" block, but this is read and written back on
> the fly. (Probably because there can contain radio specific, i.e.,
> calibration fields that shouldnt be shared across radios.)
>

Correct. The VIP software can read and write the "aux" block on the fly but
not save. The CPS (non VIP) software can't read or write the "aux" block.

Someone gave me a hacked version of the Baofeng VIP software that had many
additional setting available. I believe that it might have been you that
gave it to me. Settings like Stun, Kill, Deviation, Squelch, User password,
Super password and many more. I have mapped out virtually every one of
these settings and, yes, they are all in the "aux" block. My testing seems
to indicate that even though that these settings appear to be mapped to
valid data, they are not being used. Possibly these were used in the
initial development of this type of radio and then later moved to the
firmware. Or maybe they were use in a model that is no long available or
yet to be released.

>
> With that in mind,
> 1. should we put the ident at the end of the memory map? (It might break
> some backwards compatibility unless extra logic is taken)
>
2. should we consider handling the aux block as sort of "volatile"?
>

Even since Baofeng released the UV-5R with BFB291 firmware and change the
location of the band limits, the "aux" block has been considered to the
extent that if the firmware version doesn't match, the upload of the "aux"
block is aborted. (I just wish I knew how to make the message look more
"information looking" and less "critical error looking". Too many times
I've had CHIRP users think the whole upload failed or even that CHIRP had
crashed because they either didn't read the message or didn't understand
what the message meant. See attached image.

Unfortunately Baofeng made a firmware change in the last few months that
made the "main" block also sort of volatile. Although they may need some
fine tuning, I think the recent patches address this issue.

>
>
>
>
This is the pre-BFB291 "ident"

AA 42 46 42 32 33 31 DD     ªBFB231Ý

It is the radio's firmware version

This is the BFB291 "ident"

AA 36 74 04 00 05 20 DD

It basically is the band limits.

36 = 136 MHz VHF low band limit
74 = 174 MHz VHF high band limit
[04] 00 = 400 MHz UHF low band limit **
05 20 = 520 MHz UHF high band limit

** the byte in [ ] is what CHIRP looks at to determine if the radio is
VHF/UHF [04] or VHF/220 [02]

The OEM VIP software does update these values in addition to the band
limits in the "aux" block. The radio must not use these values since CHIRP
leaves then alone and there doesn't seem to be a problem as a result of
them not being changed.

This is the new 12 byte "ident" showing up in the UV-6 and UV-8 radios

AA 01 01 36 01 74 01 04 00 05 20 DD

The 36 and 74 were expanded to 01 36 and 01 74 (2 of the added 4 bytes)
Each low band limit is preceded by an additional 01 (the remaining 2 added
bytes)

Jim KC9HI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20141001/2dd2af7b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: An error has occurred.jpg
Type: image/jpeg
Size: 49958 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20141001/2dd2af7b/attachment-0001.jpg