<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">When I was looking at the oem software file format and program, I noticed a few things.<div>1. in the .dat saved file, they only store the "main" block. i.e., without the ident.</div><div>2. they seem to only check the ident on the fly at clone time</div><div>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.)</div><div><br></div><div>With that in mind, </div><div>1. should we put the ident at the end of the memory map? (It might break some backwards compatibility unless extra logic is taken)</div><div>2. should we consider handling the aux block as sort of "volatile"?</div><div><br></div><div>-Jens</div><div><br><div><br><div><div>On Oct 1, 2014, at 7:06 AM, IZ3GME Marco <<a href="mailto:iz3gme.marco@gmail.com">iz3gme.marco@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">...mmm... another idea: it can be simplier to just compress the 12 byte<span class="Apple-converted-space"> </span><br>ident down to 8 bytes in the memory map, this avoid changing the memory<span class="Apple-converted-space"> </span><br>(and file) format.<br><br>Just e cent more ;)<br>73 de IZ3GME Marco<br><br>On 01/10/2014 11:53, Jim Unroe wrote:<br><blockquote type="cite">Marco,<br><br>It isn't just the lengh of the file. Since the "ident" that is returned<br>is written to the .img first and the rest of the radio's memory follows<br>it, all of the memory is shifted 4 bytes.<br><br>So...<br><br>#seekto 0x0B08;<br>struct {<br> u8 code[5];<br> u8 unused[11];<br>} pttid[15];<br><br>for a "normal" BaoFeng UV-5R style radio would need to be...<br><br>#seekto 0x0B0C;<br>struct {<br> u8 code[5];<br> u8 unused[11];<br>} pttid[15];<br><br>For this "odd" class of UV-6 and UV-8 radios.<br><br>I think there is a similar problem when writing to the radio. CHIRP<br>currently does this...<br><br> # Main block<br> for i in range(0x08, 0x1808, 0x10):<br> _send_block(radio, i - 0x08, radio.get_mmap()[i:i + 0x10])<br> _do_status(radio, i)<br><br>It starts a 0x08 (right after the normal 8 byte "ident"). I think it<br>would need to start at 0x0C (right after the 12 byte "ident").<br><br>Jim<br><br>On Wed, Oct 1, 2014 at 4:52 AM, IZ3GME Marco <<a href="mailto:iz3gme.marco@gmail.com">iz3gme.marco@gmail.com</a><br><<a href="mailto:iz3gme.marco@gmail.com">mailto:iz3gme.marco@gmail.com</a>>> wrote:<br><br> Just a couple of suggestions:<br> - for the communication you can try reading 12 bytes lowering timeout so<br> if only 8 are received read will bail out quickly enough<br> - i would expand the structure to the longer size to have to deal with<br> different sizes only when accessing ident field (i guess ident is only<br> used during clone)<br><br> my two cents<br> 73 de IZ3GME Marco<br><br> On 01/10/2014 01:53, Jim Unroe wrote:<br><blockquote type="cite">Hi all,<br><br>I am working on two issues, #1225 (UV-8) and #1707 (UV-6), that after<br>doing research seems to indicate both issues are caused by the<br></blockquote> same thing.<br><blockquote type="cite"><br>The problem is that after the "magic" is sent to the radio to<br></blockquote> initiate<br><blockquote type="cite">cloaning, the radio returns a 12 byte ident when every other Baofeng<br>radio that I know of returns an 8 byte ident. I have temporarily<br></blockquote> edited<br><blockquote type="cite">the driver to accept 12 bytes and CHIRP downloads from the radio. But<br>since the ident is 4 bytes longer, all of the structures are off<br></blockquote> by 4 bytes.<br><blockquote type="cite"><br>After saving the downloaded data to a .img file, I can use a hex<br></blockquote> editor<br><blockquote type="cite">to remove 4 bytes from the begining of .img file, save it to another<br>name and load it back into CHIRP and it is fine.<br><br>So I am looking for some help to figure out how to have CHIRP to be<br>tolerant of the 8 byte and 12 byte idents and also 4byte offset data<br>structures.<br><br>Got any ideas?<br><br>Thanks,<br>Jim KC9HI<br></blockquote><br><br><br><br>_______________________________________________<br>chirp_devel mailing list<br><a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a><br>http://intrepid.danplanet.com/mailman/listinfo/chirp_devel<br>Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers<br><br></blockquote><br>_______________________________________________<br>chirp_devel mailing list<br><a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a><br><a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>Developer docs:<span class="Apple-converted-space"> </span><a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a></div></blockquote></div><br></div></div></body></html>