On Mar 22, 2014, at 5:51 PM, Dan Smith - dsmith@danplanet.com wrote:
If I can download from the radio and upload the same file and do this, that's a little scary.
Well, it sounds like it's not 100% clear that that's what happened, and like you, I can't imagine that actually causing a problem.
Well, for anyone still interested, there is a new piece of data.
I realized there _is_ a telltale in the image file as to whether it was modified - the checksum. 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.
So I slapped together a tool to compute checksums on FT60 .img files and compare to what's in the file. Tested it by tweaking a bit in a file, and it behaves as expected.
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...
The computed checksum is 0xC5 vs saved 0x95, which would be consistent with changing some data field from -001----b to -100----b somewhere in the file. Or something equivalent, of course. But sorry, that was Feb 7, and I can't remember what that might have been. Maybe I'll stare at the file and see if there's any inspiration there. But it's a plausible thing for me to have done early in this process.
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.
However, the way most Yaesus do (or don't do) their checksums, it's easy for a bad cable or connector to corrupt data on the way in without the radio knowing. By the time the radio gets to the end and determines that the checksum is wrong, the bad data is already in place. If it's not going to do a full reset (automatically or when asked), then a bad cable could absolutely end up with you getting broken data into the radio.
I'm sure you're not looking for any sarcastic remarks here, but if anything, the above makes me even less likely to spend money on Yaesus in the future. I know brand loyalty is based on lots of things, and people choose radios based on a lot more than what is under the hood, but honestly, bricking a radio through the user-accessible serial port should *not* be possible, IMHO.
As a retired design engineer, I agree most emphatically. If that's actually what happened, it's really not excusable. Refuse to boot and require a RESET-ALL is reasonable if the checksum is wrong or the data is internally inconsistent, but unrecoverable bricking for corrupted flash data that can be reloaded with factory defaults is not.
As I said in another reply: - The new radio has gone back to Yaesu. Chirp wasn't mentioned. No further decisions until I see where that goes.
- I've ordered another cable from Valley Enterprises. Cheap insurance in case it's a bad cable, or at least it might provide more data.
Thanks and regards,
-dan