[volt-nuts] 3458A Questions - The Sequel

[Poul-Henning Kamp]

In message <D882AF43C6DA44169877C4AB9ADEF0AB at cardiac5f772ce>, "J. L. Trantham" 
writes:

>List members suggested that I back up 'CALRAM' ASAP.  I would agree.  How do
>I do it?  The Dallas chips are soldered in place.  By HPIB I presume?  That
>means that I am finally going to have to solve the 'HPIB issue'.  Or is it
>available from the front panel?

Yes, HPIB is the only non-solder way to do it.

The necessary commands/code to do it can be found here:
	https://github.com/bsdphk/pylt/blob/master/hp3458a.py

>I also note that on my A5 board, there is a single ST M27C4002-12F1 chip,
>soldered in place, instead of the six TM27C512's shown in the CLIP and the
>ALRM.  Unless there is a way to read the chip, installed, erase it,
>installed, and reprogram it, installed, to upgrade the firmware to ver 9
>would require the removal of the chip, installation of a socket, then
>installing a new chip with the latest data programmed in.

You can read it via HPIB, using the MREAD command.

If it has a window for UV radiation you could erase it in place,
but since it requires 12.75V for programming, it would take non-nice
hackery to program it in place, and I would only attempt it, stranded
on a dessert island with absolutely no other choice.

>latest version by replacing the appropriate components rather than replacing
>the various boards, citing the desire not to change the 'character' of the
>meter by virtue of keeping all the 'aged' components possible.

The A5 board is just a microcomputer board, there is no analog on
it at all, so I'm pretty sure they would just replace that one.

>Therefore, the question arises as to how practical is it to remove the three
>Dallas chips (perhaps it is only one that needs to be archived) 

Only the small one needs to be archived, and you can do so over HPIB.

In my case, unsoldering the NVRAMs were very easy: bit holes, small
legs and absolutely no trouble.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.