[chirp_devel] [PATCH] [UV-5R] Prevent image upload when "special block" doesn't match

Jim Unroe
Fri Jul 18 16:07:21 PDT 2014


On Fri, Jul 18, 2014 at 6:24 PM, Dan Smith <dsmith at danplanet.com> wrote:

> > 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.
>
> Hmm, I thought there were some band limits in there or something, no?
> There's some reason we're uploading it, because it wasn't in my initial
> implementation.
>

The Aux block has the band limits. The location in memory of the band
limits changed when BFB291 was introduced. This caused some undesired
issues so since then the upload of the Aux block is aborted when the
firmware versions are different.

This new issue is in the Main block. The main block has always been
considered to be safe to upload across all models of UV-5R variants. Now it
isn't.


> Regardless, it doesn't seem useful to upload it only if it's the same as
> what is there. If we're uploading the exact thing, why not just not
> upload it?
>

If the bytes match, the image is being uploaded to the correct radio. If
the bytes do not match, the image is being uploaded to the wrong radio and
it must be aborted. Isn't that what is always done at the start of the
upload clone process? Check to make sure the right radio is on the other
end of the programming cable.

The only difference here is the bytes that are being used to detect the
radio model are also the bytes that better not be copied to the wrong radio.

Look at the attached file. What I am trying to avoid uploading images from
the bottom two rows/models to the top 18 rows/models. It is no different
than not being able to upload an image from a UV-5R to a UV-82 or a UV-82
image to a UV-5R. Fortunately with those models, Baofeng change the "ident"
between the two. In this case the "ident" is the same.

UV5R_MODEL_291  = "\x50\xBB\xFF\x20\x12\x07\x25"


>
> --Dan
>

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140718/42ce24fe/attachment-0001.html 


More information about the chirp_devel mailing list