All,<br><br>CHIRP checks the radio and image to make sure they are the from the same firmware. For example<br><br>Image is &#39;  Ver  BFB231   &#39;<br>Radio is &#39;  Ver  BFB231   &#39;<br><br>CHIRP also verifies that &quot;Ver  BFB&quot; is in the radio_verison<br>

<br>Here&#39;s the problem with a few Baofeng UV-5R radios with BFB297 firmware. There are apparently 2 versions with BFB297 floating around.<br><br>1. Image is &#39;  Ver  BFB297   &#39;  (works OK)<br>2. Image is &#39;BFB299 BFB297   &#39;  (upload failure)<br>

<br>The upload failure is caused by the &#39;Ver  BFB&#39; check failure. There is no &#39;Ver  &quot;<br><br>A possible solution is to narrow the requirements of the check<br><br>-     if &quot;Ver  BFB&quot; not in radio_version:<br>
+    if &quot;BFB&quot; not in radio_version:<br><br>There would still be an issue of one type of BFB297 radio not being able to load the &#39;aux block&#39; of the other type. I believe that is could be overcome by limiting the part of the string that is matched<br>
<br>-    image_version = _firmware_version_from_image(radio)<br>-    radio_version = _get_radio_firmware_version(radio)<br>+    image_version = _firmware_version_from_image(radio)[7:]<br>+    radio_version = _get_radio_firmware_version(radio)[7:]<br>
<br>Which should make the comparison like this<br><br>Image is &#39;BFB297   &#39;<br>Radio is &#39;BFB297   &#39;<br><br>Is it safe to swap the &#39;aux blocks&#39; of this two similar firmware versions? I don&#39;t know. Maybe. Every other part of the &#39;aux block&#39; is identical between the two images. But that is at the &#39;factory&#39; delivered state.<br>
<br>Anyone else have any thoughts about this issue?<br><br>Jim<br><br>