Marco,

It isn't just the lengh of the file. Since the "ident" that is returned is written to the .img first and the rest of the radio's memory follows it, all of the memory is shifted 4 bytes.

So...

#seekto 0x0B08; struct { u8 code[5]; u8 unused[11]; } pttid[15];

for a "normal" BaoFeng UV-5R style radio would need to be...

#seekto 0x0B0C; struct { u8 code[5]; u8 unused[11]; } pttid[15];

For this "odd" class of UV-6 and UV-8 radios.

I think there is a similar problem when writing to the radio. CHIRP currently does this...

# Main block for i in range(0x08, 0x1808, 0x10): _send_block(radio, i - 0x08, radio.get_mmap()[i:i + 0x10]) _do_status(radio, i)

It starts a 0x08 (right after the normal 8 byte "ident"). I think it would need to start at 0x0C (right after the 12 byte "ident").

Jim

On Wed, Oct 1, 2014 at 4:52 AM, IZ3GME Marco iz3gme.marco@gmail.com wrote:

Just a couple of suggestions:

• for the communication you can try reading 12 bytes lowering timeout so

if only 8 are received read will bail out quickly enough

• i would expand the structure to the longer size to have to deal with

different sizes only when accessing ident field (i guess ident is only used during clone)

my two cents 73 de IZ3GME Marco

On 01/10/2014 01:53, Jim Unroe wrote:

...

Hi all,

I am working on two issues, #1225 (UV-8) and #1707 (UV-6), that after doing research seems to indicate both issues are caused by the same

thing.

...

The problem is that after the "magic" is sent to the radio to initiate cloaning, the radio returns a 12 byte ident when every other Baofeng radio that I know of returns an 8 byte ident. I have temporarily edited the driver to accept 12 bytes and CHIRP downloads from the radio. But since the ident is 4 bytes longer, all of the structures are off by 4

bytes.

...

After saving the downloaded data to a .img file, I can use a hex editor to remove 4 bytes from the begining of .img file, save it to another name and load it back into CHIRP and it is fine.

So I am looking for some help to figure out how to have CHIRP to be tolerant of the 8 byte and 12 byte idents and also 4byte offset data structures.

Got any ideas?

Thanks, Jim KC9HI

...mmm... another idea: it can be simplier to just compress the 12 byte ident down to 8 bytes in the memory map, this avoid changing the memory (and file) format.

Just e cent more ;) 73 de IZ3GME Marco

On 01/10/2014 11:53, Jim Unroe wrote:

Marco,

It isn't just the lengh of the file. Since the "ident" that is returned is written to the .img first and the rest of the radio's memory follows it, all of the memory is shifted 4 bytes.

So...

#seekto 0x0B08; struct { u8 code[5]; u8 unused[11]; } pttid[15];

for a "normal" BaoFeng UV-5R style radio would need to be...

#seekto 0x0B0C; struct { u8 code[5]; u8 unused[11]; } pttid[15];

For this "odd" class of UV-6 and UV-8 radios.

I think there is a similar problem when writing to the radio. CHIRP currently does this...

 # Main block
 for i in range(0x08, 0x1808, 0x10):
     _send_block(radio, i - 0x08, radio.get_mmap()[i:i + 0x10])
     _do_status(radio, i)

It starts a 0x08 (right after the normal 8 byte "ident"). I think it would need to start at 0x0C (right after the 12 byte "ident").

Jim

On Wed, Oct 1, 2014 at 4:52 AM, IZ3GME Marco <iz3gme.marco@gmail.com mailto:iz3gme.marco@gmail.com> wrote:

Just a couple of suggestions:
- for the communication you can try reading 12 bytes lowering timeout so
if only 8 are received read will bail out quickly enough
- i would expand the structure to the longer size to have to deal with
different sizes only when accessing ident field (i guess ident is only
used during clone)

my two cents
73 de IZ3GME Marco

On 01/10/2014 01:53, Jim Unroe wrote:
 > Hi all,
 >
 > I am working on two issues, #1225 (UV-8) and #1707 (UV-6), that after
 > doing research seems to indicate both issues are caused by the
same thing.
 >
 > The problem is that after the "magic" is sent to the radio to
initiate
 > cloaning, the radio returns a 12 byte ident when every other Baofeng
 > radio that I know of returns an 8 byte ident. I have temporarily
edited
 > the driver to accept 12 bytes and CHIRP downloads from the radio. But
 > since the ident is 4 bytes longer, all of the structures are off
by 4 bytes.
 >
 > After saving the downloaded data to a .img file, I can use a hex
editor
 > to remove 4 bytes from the begining of .img file, save it to another
 > name and load it back into CHIRP and it is fine.
 >
 > So I am looking for some help to figure out how to have CHIRP to be
 > tolerant of the 8 byte and 12 byte idents and also 4byte offset data
 > structures.
 >
 > Got any ideas?
 >
 > Thanks,
 > Jim KC9HI

---

chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

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