<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 18, 2014 at 5:18 PM, Dan Smith <span dir="ltr"><<a href="mailto:dsmith@danplanet.com" target="_blank">dsmith@danplanet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> [UV-5R] Prevent image upload when "special block" doesn't match<br>
><br>
> add code to compare the data image "special block" to the radio<br>
> image "special block" and abort the upload if they don't match<br>
<br>
</div>How would we ever change the special block if we can't upload it if it's<br>
different?<br>
<span class="HOEnZb"><font color="#888888"><br>
--Dan</font></span><br></blockquote></div><br></div><div class="gmail_extra">Nothing in is area of memory has ever been mapped to any settings. I have no idea what this area is used for. We've never had to change any of it for anything before.<br>
<br>All I know for sure is if you copy these 7 bytes from a KT-980HP or BF-F8HP CHIRP image to any other UV-5R variant radio, the receiver is disabled. It is actually 4 bytes (2 sets of 2 separated by 3 bytes) that cause the issue. I could check each pair independently and abort if either pair doesn't match. That would minimize the number of bytes affected.<br>
<br></div><div class="gmail_extra">Uploads of images could be prevented when the firmware versions don't match. But that would prevent some 16 (and growing) firmware versions that can currently share a common .img file to no longer be able to do it.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm definitely open to doing this some other way. Have you got any ideas or suggestions?<br><br></div><div class="gmail_extra">Thanks,<br>Jim<br></div>
</div>