3458A How Old is to old for Battery Backed Memory?

[beanflying]

Finally getting around to some Space and the very much Harder part some Time to look at the 3458A I scored a FOUR years ago  Like most of us I don't need it and my two Calibrated 6 1/2 digit meters are more than I require.

It had a Cal 110 Error so I had assumed it was going to need a full memory fix and a dirty Cal by me and the wall of bits I have or a $$ trip to Keysight so it went on the shelf. The meter as far as I can find was never Calibrated and given how clean it is inside and still on its 1997 Memory never used or if it was very sparingly 

Before pulling boards out to remove memory and add sockets etc I loaded up IanJ's WinGPIB software and actually got a dump of the Cal memory which I thought was curious but was it garbled or trash?

Found in some searching of the Xdevs site the 3458A/KE5FX dump software and managed to get what looks like something resembling data (copy of the text version below).

So on that same page https://xdevs.com/article/hp3458a_gpib/#manual there is also the Query strings for the Cal Constants which also gave back sensible looking numbers (again below). Still cant get connection expert to recognize the 3458A but it still has the 1997 Firmware on it which might be the problem?

Can someone more familiar with the 3458A take a look at the dump and see if you think it is complete and valid? If so then any idea what might be causing the 110 error (destructive overloads?) or does is simply need a Cal to clear it when the new memory goes in or is the error just related to the likely dead or near dead battery?

Also thoughts on upgrading the Firmware, what would I gain?

TIA 

[aronake]

Do you have a error that say destructive overload? Or Error 110 - Calibration required? Any other errors? Push error button again to see these. And have you done te full selftest (or only the power on self test)? If not, may be a good start to do that and see if any more errors show up

[TERRA Operative]

Here's a python script I wrote that will download the cal values as actual numbers (same as shown when using the front panel) via GPIB.

Pull the values out and see if they are reasonable. Then I'd let it warm up for a good few hours, run a full self test and then an ACAL and pull the values out again to compare.

[beanflying]

Do you have a error that say destructive overload? Or Error 110 - Calibration required? Any other errors? Push error button again to see these. And have you done te full selftest (or only the power on self test)? If not, may be a good start to do that and see if any more errors show up

I did scroll the errors and only the 110 comes up on startup always. I seem to remember reading about resetting the destructive overloads during a Cal on Xdevs (need to go check again)

Very occasionally on a full test I had seen 204 (Flatness DAC) and 202 (Slave Test) seems common but still not always. Without talking a serious look I haven't tried tracking them down for an actual cause or solution.

The Cal in particular if it can be salvaged and Memory seemed like a good first thing to do.

[Kleinstein]

The critical SRAM is the small one with the calibration constants. This looks like it is from 1997 and thus time to replace it. How long the batteries actually last can vary with temperature, use and luck. Chances are the CAL data are still there - even if old they can be still valuable - even if just to see how much the meter drifted over the last 28 years.
As the very least one should save the data to the PC, so one could restore them if needed. AFAIK there are scripts around to download the data via GPIB. The main point are the real calibration data, not the ACAL values. Having a backup of the CAL data is a good idea even with a new battery or FRAM replacement, just in case.

The other 2 larger SRAM are not that critical. One would only loose things like user defined short cuts and previous settings. So if these run out, nothing really valuable is lost.

[picburner]

One of my two 3458A purchased time ago had also errors 110 and 202, but in my instrument the error 202 was persistent.
Finally it turned out to be the ADC A3 board with the usual faulty U180.
I hope this is not your case because it is quite an expensive repair.
There were also other small faults but they were just trifles in comparison.

[IanJ]

Before pulling boards out to remove memory and add sockets etc I loaded up IanJ's WinGPIB software and actually got a dump of the Cal memory which I thought was curious but was it garbled or trash?

Can you post the file WinGPIB produced so I can take a look?
The files are not text readable if thats what you were looking for.

Here's a screenshot of the top of the file in HxD hex editor so you can see the hex and ascii equiv. Yours should look somewhat similar.

Ian.

[beanflying]

Before pulling boards out to remove memory and add sockets etc I loaded up IanJ's WinGPIB software and actually got a dump of the Cal memory which I thought was curious but was it garbled or trash?

Can you post the file WinGPIB produced so I can take a look?
The files are not text readable if thats what you were looking for.

Here's a screenshot of the top of the file in HxD hex editor so you can see the hex and ascii equiv. Yours should look somewhat similar.

Ian.

Two copies taken just in case (extension changed to txt so they post). The decoded version in the first post was from the Xdevs Windoze software and is legible.

Any thoughts about if you can use the bigger FM18W08-SG-ND for the Cal Ram? I know it is way to big but I ordered a couple of spares.

[TERRA Operative]

Here's a link to a video I just made about putting FRAM's into a 3458A.

youtu.be/uNbI3SUZ7oI


I have some spare PCB's I can throw in an envelope and send to you for a couple bucks shipping if you need.

[beanflying]

Here's a link to a video I just made about putting FRAM's into a 3458A.

youtu.be/uNbI3SUZ7oI


I have some spare PCB's I can throw in an envelope and send to you for a couple bucks shipping if you need.

Not sure if to fully blame/thank you or a little of IanJ as well for this getting on the bench in the last week YouTube actually fed me your Video out of the blue so the boards left heading for me a few days ago but thanks anyway. I hadn't been looking at anything 3458A for a long while so the Algorithm is a strange strange thing. 

I will load up your Python thing tomorrow for a play too. Feet up with a Scotch time.

[IanJ]

Two copies taken just in case (extension changed to txt so they post). The decoded version in the first post was from the Xdevs Windoze software and is legible.
Any thoughts about if you can use the bigger FM18W08-SG-ND for the Cal Ram? I know it is way to big but I ordered a couple of spares.

Your WInGPIB extracted .bin files look ok.
The beanflying.CAL.txt in your first post is not a file you can directly program a CalRam IC from. That file has the HEX data but along with it some addition representative data just for info.
The purpose of the WinGPIB extract is to produce a file you can save away if ever the need arises you need to directly program the file to a FRAM IC or other non-volatile I memory IC.
It's exactly 2k in size, the same size as the original Dallas Ram IC.

Here's my video on using FRAM IC's with the 3458A.
https://youtu.be/cAA1TCvwhuw

Ian.

[TERRA Operative]

I can confirm that the WinGPIB cal data output is the exact same as the data when extracted directly from the NVRAM chip in a programmer.

At least it worked for me!

[aronake]

I dont think I heard of a checksum error on the calibration RAM (has anyone?). So it may be that a 3458a deal with just a single bit wrong in the calram by returning calibration required error rather than a checksum error. Its also interesting that you do not get error that ram battery is low. So my guess is that for some reason 1 bit somewhere in the ram has flipped, which results in this calibration error, and that the batteries in the ram still have enough power to keep the memory.

With a potentially almost 30 year calibration, I would say it has limited value. The somewhat interesting items in it may be  CAL? 2 (7V ref value) and CAL? 1 (40K ohm value). But as you have no idea on how much it has been on over these 30 years, and the drift is likely not linear anyway, that probably have quite limited value too.

One way forward may to just calibrate it as good as you can now (10V source and 10K ohm source) and see if that correct the errors.

[bsdphk]

The cal data is mostly IEEE-754 64 bit binary floating point numbers with a few integers thrown in here here and there.

If you look at the hexdump you will see a lot of 0x40 and 0xbf every 8 bytes, that is the floating point exponent

[MiDi]

If it is just ERROR 110,“CALIBRATION REQUIRED — ACAL”​​, execute ACAL ALL after at least 1h warmup, followed by full self test.
Errors 204 (Flatness DAC) and 202 (Slave Test) are concerning, but might be fixed by ACAL or after a couple of days on - if you are lucky.

[beanflying]

Actually dropped something on the inputs seems how it is sort of alive. AC Board is not happy at all which is clearly why the 202 error is happening. As the 3458A is warming up it is settling closer toward 10V which is coming out of my 335D (bang on 10.00000 on the 34461A) so that is in the right ballpark. Ohms Range is close as well.

The Error 204 hasn't come up again even after several full tests but 202 every time 

Waiting for the memory and boards to turn up now and do some desoldering for sockets to get ready.

Also taking a minor risk on what is likely salvage Hitachi memory out of China.

[TERRA Operative]

If you have no luck on the Opt 001 Hitachi memory, I can get NOS chips here in Japan. I got a set of 5x HM62256BLP-10 recently for about 25 bucks or so.

[beanflying]

Must mean it is nearly done 

I dropped my current Calram dump onto one of the 16W08's I ordered (should have spare boards and IC's if anyone in Oz wants a set as I ordered spares) with my shiny new T48 programmer then soldered it on the adapter. Plugged back in it recognized that it was set at 2k but otherwise returned garbage data.

As others have found the various programmers currently around don't like talking to the 16W08 when installed on the mod board without something like IanJ's extra adapter. I might stich something together in spaghetti as I don't need any other boards done unless I have borked the one I just soldered.

Ordered a stack of Caps to replace as per TerraO's thread and also a new IEC filter as my Schaffner one in the unit has a bulge in its pants so likely it is close to release 

Likely at this stage to wait the week for the Caps to arrive then start removing boards as needed to to them and the sockets.

[MiDi]

As others have found the various programmers currently around don't like talking to the 16W08 when installed on the mod board without something like IanJ's extra adapter. I might stich something together in spaghetti as I don't need any other boards done unless I have borked the one I just soldered.

Might be useful: https://www.eevblog.com/forum/manufacture/fyi-xgecu-tl866ii-and-t48-cant-program-fm16w08-fram-chips/msg5716707/#msg5716707

[IanJ]

A 16W08 on an adaptor board to mimic the original Dallas ram won’t work in a programmer (usually). I haven’t heard of a programmer that can read/write it as a Dallas ram.
My 2nd adaptor-adaptor to set the pin assignment back to a 16W08 is the way forward, albeit your programmer will have to have the ability to read/write the first 2k and no more.

Ian

[TERRA Operative]

The adapter-adapter to turn it back into a 16W08 won't work with my 16W08-Dallas adapter board as I didn't include the extra header pins needed to break out all pins from the 16W08 chip.
So, no overhanging pins on the socket, but no programming with the adapter-adapter...

[beanflying]

The adapter-adapter to turn it back into a 16W08 won't work with my 16W08-Dallas adapter board as I didn't include the extra header pins needed to break out all pins from the 16W08 chip.
So, no overhanging pins on the socket, but no programming with the adapter-adapter...

So NOW you tell me  Fun Fabricobbling anyway, not going to win any PCB beauty contest either 

[Smokey]

I remember seeing Marco Reps made an FRAM adapter too:
https://github.com/marcoreps/Dallas-FRAM-Adapters

[TERRA Operative]

The adapter-adapter to turn it back into a 16W08 won't work with my 16W08-Dallas adapter board as I didn't include the extra header pins needed to break out all pins from the 16W08 chip.
So, no overhanging pins on the socket, but no programming with the adapter-adapter...

So NOW you tell me  Fun Fabricobbling anyway, not going to win any PCB beauty contest either 

It took me a couple tries to figure out what was up too, I only recently figured it out myself...