So, some news:

My newer radio was returned from Yaesu, working. No charge. Same s/n, so they did repair it, not replace it. From the manifest, they replaced the 24C256 eeprom and charged 0.5 hours labor.

So first, compliments to Jon jon@jonshouse.co.uk I'm still not believing eeprom wearout, but

You may not agree with my justification but its still the logical cure?

appears spot on.

I followed up with an email asking several questions to try to get a little more info, but most of them were ignored. All I learned was that they don't see many eeprom problems, and the opinion that it was a defective IC (i.e., infant mortality). Which, given the scenario, I don't believe.

Maybe they don't actually track labor for warranty repairs and that's just nominal, but 1/2 hour to open up the radio, remove and replace the IC, and close it up seems like it would be more performance art than tech work. Adding any kind of eeprom formatting beyond what the radio reset itself does seems unlikely. But I didn't get an answer to that as well as a number of other questions I asked.

==========

On Mar 25, 2014, at 7:48 PM, Dan Smith - dsmith@danplanet.com wrote:

...

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.

Excellent idea, and I will do that. ...

I might also implement an optional check for a couple of bits in the image being set. ...

Without knowing what caused two eeproms to fail, I've reversed my opinion again on the old cable. I don't know how, but maybe there's an electrical problem that might manifest itself on read. I'm curious, but not enough to risk another radio. The new cable is doing downloads and I think I'll just move forward with that. If someone wants to borrow the old cable to try on _their_ FT-60, I'm open to that...

I did implement the download parity check, and I think that will be the first bug I request to integrate. I need to spend a little more time on the chirp developer instructions, which I'd been putting off while I was having fun in the code itself. Soon...

I also implemented a check on upload for the "bits of death", but I can't find a way to make it work as I intended with the existing upload sequence. By the time I can get control in ft60.py, the "Cloning ..." window is already open, and opening another dialog with that up doesn't work gracefully. I didn't want to mess with the core upload code that affects all radios by adding another callback method to the parent class. As I said, OOP is not my comfort zone.

So I hardcoded it, controlled by a boolean set to False, so that tested code can be enabled easily by changing that to True in the ft60.py code. Shall I put that back along with the parity check? Or other thoughts on this piece?

========= Returning to Jon's advice on replacing the eeprom: I opened up my old bricked FT-60. From the board layout diagram in the service manual, I'm pretty certain I've found the eeprom, but on top of my limitations with soldering smt devices:

1) It's down in a hole between the headphone jack, the display, and a crystal.

2) It's marked "456M 41B3 06". Doesn't correspond to any IC nomenclature google knows about. Nor the Yaesu part number, which per the service manual is G1093837. So I'm not even 100% sure I've identified the right IC, although I think I have.

I don't think it's prudent to ship that back to Yaesu for (paid) repair, at least for now. I don't have a real need for a spare HT. I'll let it marinate for awhile.

-dan