Hi Jens,

On Wed, Oct 1, 2014 at 10:30 AM, Jens Jensen <af5mi@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