<div dir="ltr">Hi Jens,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 10:30 AM, Jens Jensen <span dir="ltr">&lt;<a href="mailto:af5mi@yahoo.com" target="_blank">af5mi@yahoo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">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 &quot;main&quot; block. i.e., without the ident.</div></div></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>2. they seem to only check the ident on the fly at clone time</div><div>3. they don&#39;t store the &quot;aux&quot; 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></blockquote><div><br></div><div>Correct. The VIP software can read and write the &quot;aux&quot; block on the fly but not save. The CPS (non VIP) software can&#39;t read or write the &quot;aux&quot; block.<br><br></div><div>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 &quot;aux&quot; 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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>2. should we consider handling the aux block as sort of &quot;volatile&quot;?</div></div></blockquote><div><br></div><div>Even since Baofeng released the UV-5R with BFB291 firmware and change the location of the band limits, the &quot;aux&quot; block has been considered to the extent that if the firmware version doesn&#39;t match, the upload of the &quot;aux&quot; block is aborted. (I just wish I knew how to make the message look more &quot;information looking&quot; and less &quot;critical error looking&quot;. Too many times I&#39;ve had CHIRP users think the whole upload failed or even that CHIRP had crashed because they either didn&#39;t read the message or didn&#39;t understand what the message meant. See attached image.<br><br></div><div>Unfortunately Baofeng made a firmware change in the last few months that made the &quot;main&quot; block also sort of volatile. Although they may need some fine tuning, I think the recent patches address this issue.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class=""><font color="#888888"><div><br></div><div><br></div></font></span><br></div></blockquote></div><br></div><div class="gmail_extra">This is the pre-BFB291 &quot;ident&quot;<br></div><div class="gmail_extra"><br>AA 42 46 42 32 33 31 DD     ªBFB231Ý<br><br></div><div class="gmail_extra">It is the radio&#39;s firmware version<br><br></div><div class="gmail_extra">This is the BFB291 &quot;ident&quot;<br><br>AA 36 74 04 00 05 20 DD<br><br></div><div class="gmail_extra">It basically is the band limits.<br><br></div><div class="gmail_extra">36 = 136 MHz VHF low band limit<br></div><div class="gmail_extra">74 = 174 MHz VHF high band limit<br></div><div class="gmail_extra">[04] 00 = 400 MHz UHF low band limit **<br></div><div class="gmail_extra">05 20 = 520 MHz UHF high band limit<br><br>** the byte in [ ] is what CHIRP looks at to determine if the radio is VHF/UHF [04] or VHF/220 [02]<br><br></div><div class="gmail_extra">The OEM VIP software does update these values in addition to the band limits in the &quot;aux&quot; block. The radio must not use these values since CHIRP leaves then alone and there doesn&#39;t seem to be a problem as a result of them not being changed.<br><br></div><div class="gmail_extra">This is the new 12 byte &quot;ident&quot; showing up in the UV-6 and UV-8 radios<br><br>AA 01 01 36 01 74 01 04 00 05 20 DD<br><br></div><div class="gmail_extra">The 36 and 74 were expanded to 01 36 and 01 74 (2 of the added 4 bytes)<br></div><div class="gmail_extra">Each low band limit is preceded by an additional 01 (the remaining 2 added bytes)<br><br></div><div class="gmail_extra">Jim KC9HI<br></div><div class="gmail_extra"><br></div></div></div>