[chirp_devel] How to brick an FT-60

[Dan Smith]

> Chirp does not modify the checksum in the .img file after editing
> and saving. The checksum is recomputed on the fly on upload, so it's
> not like the radio will see a bad checksum as a result, but there's
> info in the file as to whether it was likely edited.

Unless of course, the cable is bad... :)

> BrickMaker.img checksums don't match. So there you go, and I think 
> that increases the probability that it _is_ the bits. Still just 
> guesses and probabilities...

If it _was_ right out of the radio, then that tells me that the data got
corrupted between the radio and the computer (i.e. in the cable, USB
adapter, etc). Sounds like we should make CHIRP check the checksum after
a clone for at least that radio.

> Some statistics: Of 248 .img files in the  directories where I'm 
> saving these, my tool says 21 checksums don't match. I did do some 
> poking around in the Browser tool exploring the ability to modify 
> bits. And some uploading to the radio to make sure the whole 
> proposition of editing settings is feasible. And some of them might 
> just be normal Memory channel edits. I didn't think I'd saved 21 
> edited files, but it's been almost two months, and that's what it 
> looks like, unless I'm missing something.

...or the cable is silently corrupting data on the way in and this is
the first time it has corrupted something that mattered.

If I were you, I'd modify the driver to check the checksum after
download, and then do a bunch of downloads of a good radio with the
original cable and see if they occasionally don't match.

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20140325/1ddf9bbc/attachment-0001.bin