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
Looks good, some obvious pattern seem to be OK.
Here's my dump, and my download in TP (yeah, I know)
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
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
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
Lol, I was just thinking today to write up little snippet in python to do same thing.
Should I bother? (yeah, I know)
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
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.
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.htmAnd my calram summary
/Bingo
Nice - I've been re-inventing the wheel
OK here's the Window's version
Alan
p.s. btw did you figure out the calram layout? and if so, how?
Alan
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
Re 9,2 yes, just answered. I retrieved v9 from TiN's site:
https://xdevs.com/fix/hp3458a/#firmwareI 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.
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.
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
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.
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.
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.pdfAnyone up for this?
Alan
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
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
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
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