3458A calram

[alanambrose]

Hi,

I just wrote some code in C# (yeah, I know) to extract the calram data over gpib. Bin file attached. Can anyone verify the format/data looks OK? Or if you have a calram dump please send over so that I can check that I extracted it correctly. I'm looking to determine that there are no obvious bugs in my code before programming and replacing the DS1220Y.

TIA, Alan

[Dr. Frank]

Looks good, some obvious pattern seem to be OK.

Here's my dump, and my download in TP (yeah, I know)

Frank

[Dr. Frank]

I'm not too familiar with TP, but in your code I can't seem to find where the variable 'cmd' is declared.  Obviously, this code works, so I must be missing something.  Does TP automatically infer the variable type in this case?

Sorry, I did not copy all the global constants, just the excerpt of the dump procedure.
I also do not use object oriented code, just very old school.

cmd is a global text variable in the GPIB module, for sending / receiving GPIB text commands and echo.

Frank   

[alanambrose]

Many thanks Dr Frank,

From a quick look at the files they look a fairly good match for format etc. That's super helpful.

I can see for instance that they have different fillers (mine from '89 running v. 4,2 right now(!) has 0x00 and 0xa0a0, yours 0x55aa).

Let me do a more thorough analysis and I'll post when I have more info.

Regards, Alan

[Dr. Frank]

Many thanks Dr Frank,

From a quick look at the files they look a fairly good match for format etc. That's super helpful.

I can see for instance that they have different fillers (mine from '89 running v. 4,2 right now(!) has 0x00 and 0xa0a0, yours 0x55aa).

Let me do a more thorough analysis and I'll post when I have more info.

Regards, Alan

Think over upgrading the FW.
As HP made the revisions of the uP board always downward compatible, all newer FW versions should run on old boards.

FW 4,2 may still contain some evil bugs, like the freq./per. calibration error (for per. function)

Frank

[TiN]

Lol, I was just thinking today to write up little snippet in python to do same thing.

Should I bother? (yeah, I know) 

[alanambrose]

Hey TiN,

PHK's Python code is here:

https://github.com/bsdphk/pylt/blob/master/hp3458a.py

- actually that's what I was using as a guide for my C#.

And thanks Dr F., I've just upgraded to 9,2 - fast forward 30 years or so....

For anyone who cares, here's a summary (attached) of my calram vs. PHK's (which he published on volt-nuts some time ago). The numbers in brackets are his data.

TiN - thanks for your great webpage btw. Can I ask a question about the replacement fan you used - did you find a spec for the fan or did you just assume that the same power must translate to at least the same cfm?

Regards, Alan

[TiN]

Do you have something like a binary, so I could run and see my data? I like your summary

P.S. also if you feel like running more stuff, would be cool to see you jump in some noise testing stuff.

Fan... I just replaced it and did not bother much. It have to be pretty similar, after all. There is no magic to have double of performance with same fan power/size.

[bingo600]

Here's a port to x64 linux , and raspi-linux using linux-gpib

Based on Mark Simm's code from here (hp3458.cpp) - ohh there's an .exe too
http://www.ke5fx.com/gpib/readme.htm

And my calram summary

/Bingo

[alanambrose]

Nice - I've been re-inventing the wheel

OK here's the Window's version

Alan

[alanambrose]

p.s. btw did you figure out the calram layout? and if so, how?

Alan

[bingo600]

p.s. btw did you figure out the calram layout? and if so, how?

Alan

I didn't PHK did , and Mark used his info.

Did you see my PM ?

/Bingo

[alanambrose]

Re 9,2 yes, just answered. I retrieved v9 from TiN's site:

https://xdevs.com/fix/hp3458a/#firmware

I can put up a version of 4.6 from the late '80's if anyone's interested Will check out the noise floor stuff TiN.

A.

[bingo600]

Re 9,2 yes, just answered. I retrieved v9 from TiN's site:

https://xdevs.com/fix/hp3458a/#firmware

I can put up a version of 4.6 from the late '80's if anyone's interested Will check out the noise floor stuff TiN.

A.

Thnx Alan 

/Bingo

[TiN]

Sure, I'd like to have older versions too for historical completeness purposes.

If you guys don't mind, I'd like to include yours calram tools and dumps in article too. Readers who might not be familiar with google might need those I'll run calram on mine unit when get back home tonight. I'm on 9.2 , selfcal'd. Ofc, all links to this thread will be given.

[TiN]

Here's my result :

Win version, after ACAL DCV,OHMs, decode
Win version, after ACAL DCV,OHMs, binary
Linux version, RPI, text decode
Linux version, RPI, binary

[alanambrose]

Hey TiN,

OK great, looks like both Windows and Linux versions are basically functional. I see there's 10 bytes which are different between the two BIN versions from offset 0x1C1 to 0x1cB - which if you did an autocal in between sounds OK. This looks like these two fields:

601C0 - dci zero rear 100nA
601C8 - dci zero rear 1uA

I think a formatted compare feature and maybe a dataram dump would be useful and I can see that the exe doesn't make a great job of setting the gpib to the right state or leaving it in the right state. BTW I just did a round trip - extract using utility / program SRAM using TL866CS MiniPRO programmer / insert SRAM into 3458A / extract again using utility / compare. That all worked out OK, the hardest part was getting the old DS1220 chip off the board and putting in a new socket.

OK April '89 calling - firmware v4.6 attached. Think Phil Collins, Anita Baker and the Bangles:

https://weeklytop40.wordpress.com/1989-all-charts/

Maybe a technology archaeologist will be super interested

Alan

[TiN]

Cool.

I think would be also cool to find out where is checksum and make a tool to modify single value as well. It could be handy for some experiments.

[alanambrose]

Ah yes, that's good.

A.

[bingo600]

Nice Tin

So the Raspi version was usefull to you 
I saw you mentioned my Raspi linux-gpib thread from the froum , and that you had a NI USB adapter

/Bingo

Ps:
If you hack the CRC on th e3458 , i'm not sure HP and CalLabs would be impressed if published.
That might open up for some unwanted tampering.

[alanambrose]

Hi,

>>> If you hack the CRC on th e3458 , i'm not sure HP and CalLabs would be impressed if published.

Ah - I think this has already been figured out in your linux version - as it recalcs the checksums to verify the integrity of the dump, e.g.

>>>
check0:ADE7  sum0: ADE7
check1:AB1F  sum1: AB1F
check2:148F  sum2: 148F
check3:0D4C  sum3: 0D4C
Checksums OK!
<<<

What's your concern? Exposing a security flaw?

I assume that TiN just wanted it for education and experimenting. In any case it's easy to reload the original calram once the experiment is over and you're back to the original - so no harm done?

Now, it would be useful to try and get MWRITE working. This guy seems to have made some progress at least:

http://www.cl.cam.ac.uk/~sps32/SG_talk_SRB.pdf

Anyone up for this?

Alan

[bingo600]

That paper was excatly what i was thinking about , when writing my comments above.

They seem to indicate that it's not something the manufactor would like.

But if it's for a "one off" test  .... It's your instrument.

I see a possible "pay $$$" or we'll blow your "Cal away" in the future.
Or "we have blown away the cal", pay$$ to get it restored.

I gutss that already applies today.

Note to self : Better secure your "instrument Vlan" , and linux-gpib machines
And  change the default Cal' pass.

Good thing : We have the cal-backup of the 58'

/Bingo

[TiN]

Well, cal is blown away anytime you remove the cover from the instrument, technically speaking. Not matter if you change something in or not. Sure, people who have valid calibrations would not be wanting to messing in guts of in-spec unit anyway. It's the traceability you paying those $$$ for, not few bytes in ROM chip. I'd assume most callabs would not care what you have in your calram, as far as they can run their Cal procedure, have meter pass it and you pay asked price. Ofc, I may be terribly wrong.

And actual original checksum idea (for firmware, not CALRAM) was to have ability completely disable VFD display (no segments lit) with DISP OFF command. Now current firmware outputs 16 "--------" instead 

[alanambrose]

Attached is the list of refurb parts I used FYI - for anyone repeating this exercise (also TiN's web log of course).

Skimming the cal manual (which I've never looked at before) it seems that only 56 of the 253 calram entries are key anyway - the rest are calced by autocal. It might be useful to track their history though.

And yes, I agree, it would be helpful to totally blank the display.

Alan

[Dr. Frank]

And yes, I agree, it would be helpful to totally blank the display.

Alan

This "problem" is solved already. See 3458A repair thread.

Simply send the command DISP OFF,'    ' to the 3458A.

Frank