[chirp_devel] How to brick an FT-60

[chirp.cordless at xoxy.net]

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 at 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 at 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