EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: alanambrose on November 04, 2015, 01:55:57 pm
-
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) ;D
-
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 (https://xdevs.com/article/dmm_noise/) 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.htm (http://www.ke5fx.com/gpib/readme.htm)
And 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/#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.
-
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
-
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.
-
Here's my result :
Win version, after ACAL DCV,OHMs, decode (http://xdevs.com/doc/HP_Agilent_Keysight/3458A/fw/CALRAM/tin_3458A.log)
Win version, after ACAL DCV,OHMs, binary (http://xdevs.com/doc/HP_Agilent_Keysight/3458A/fw/CALRAM/tin_3458A.bin)
Linux version, RPI, text decode (http://xdevs.com/doc/HP_Agilent_Keysight/3458A/fw/CALRAM/tin_calram.txt)
Linux version, RPI, binary (http://xdevs.com/doc/HP_Agilent_Keysight/3458A/fw/CALRAM/tin_calram.bin)
-
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.
-
Ah yes, that's good.
A.
-
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.pdf (http://www.cl.cam.ac.uk/~sps32/SG_talk_SRB.pdf)
Anyone 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 :scared:
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 :palm:
-
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
-
Apologies for a slight offtopic.
I've checked CALNUM on the HP3458A we've just received (bought used) and it is 54. The unit is supposed to be calibrated recently. Does that number look OK for quite an old meter?
Cheers
Alex
-
Hi Alex,
It's a bit hard to tell. You can figure a rough idea of the manufacturing date either from the date codes on the chips or the device serial number (maybe from the geller labs page).
Then either 90 day cals for a serious production device or annual cals for a non-critical lab device. (And since the earliest ship was ~89 that means at least some 90 day cals.) Bear in mind that the device generally gets more stable as time goes on anyway.
But 54 cals at say min $500 a pop means someone wanted the device kept up to spec.
Alan
-
Quote from: alanambrose on November 15, 2015, 05:01:59 AM
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
I had the idea, to program the function key with that command, like I have done with the "TEMP?" function.
But I had no success yet and get error 106 String exceeds range
I used the command
DEFKEY 1, "DISP OFF, ' '"
The problem is to define the ".
Has anyone a good idea?
BR
PeLuLe
-
As described in the manual, that's not possible, if programming the function keys directly.
Quotation marks are not allowed in the DEFKEY command.
Maybe the intrinsic BASIC works.
As you can send that command via GPIB from an external program, this should also be possible with an internal program.
Therefore, you might first define a subprogram in nonvolatile RAM, just one line, which sends this command to the instrument.
Then you assign the call of this subroutine to the desired function key.
I never used the BASIC of the 3458A, but that might very probably do the job.
PS: That BASIC might also solve your running average problem. More tricky, though.
Frank
-
Bright idea O0 .. works like a charm :-+
this TP procedure defines F1 for the call of the program, and also defines the single line sub routine.
procedure SET_F1_BLANK_HP3458;
begin
clrscr;
InitCEC;
SetTimeOut(10000);
cmd:= 'DEFKEY DEFAULT'; {clear F1 .. F9}
sendstr(HP3458);
cmd:= 'DEFKEY 1,"CALL DISP_BLANK"'; {call BASIC Program on F1}
sendstr(HP3458);
cmd:= 'SCRATCH'; {delete all BASIC elements from nvRAM}
sendstr(HP3458);
cmd:= 'SUB DISP_BLANK'; {start of subroutine}
sendstr(HP3458);
cmd:= 'DISP OFF,'' '''; {single line of code...in that BASIC context, that's no direct command to 3458A }
sendstr(HP3458);
cmd:= 'SUBEND'; {end of subroutine}
sendstr(HP3458);
Goto_Local(HP3458);
EndCEC;
end;
Frank
-
Python-snake version:
# Python Display-off F7 key define GPIB app
# http://xdevs.com/fix/hp3458a/ (http://xdevs.com/fix/hp3458a/)
import sys
import Gpib
inst = Gpib.Gpib(0,3) # Instrument GPIB Address = 3
inst.clear()
inst.write("DEFKEY 7,\"CALL DISP_BLANK\"")
inst.write("SCRATCH")
inst.write("SUB DISP_BLANK")
inst.write("DISP OFF,\" \"")
inst.write("SUBEND")
Programms only F7, as I already had some other macros on other buttons.
-
I used a "quick&dirty" way. It may of interrest for others, not able to program.
I used the Agilnt USB-to-GPIB clone with installed Agilent Commuication Libraries and entered thme in interactive GPIB command tool.
Entered the following commands (defined F0 key):
END ALWAYS
DEFKEY 0,"CALL DISP_BLANK"
SCRATCH
SUB DISP_BLANK
DISP OFF,"
SUBEND
Note: DISP OFF," is the short form of DISP OFF," "
-
Now, it would be useful to try and get MWRITE working. This guy seems to have made some progress at least:
I wrote the HP3458A program (based upon the excellent work that PHK did) that John (ke5fx) includes in his GPIB Toolkit package.
I wanted to add a calram restore capability, but, as PHK discovered, writing to the cal ram is protected by several different mechanisms and you have to call some internal subroutines to get write access. This subroutines are in different locations depending upon the firmware. Writing a general purpose tool to do that would be a big problem...
-
I wrote the HP3458A program (based upon the excellent work that PHK did) that John (ke5fx) includes in his GPIB Toolkit package.
Hi texaspyro ;) :-+
Wanna play along , or is "The Lady" still taking your time ?? .. Maybe she should be in the image
https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/ (https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/)
/Bingo
-
Unknown history on my unit. Looks like someone has replaced U121 and U122, wonder why they left U132?
-
They did the bare minimum to get it to pass the self test. The main memory nvrams do seem to die before the Cal nvram. They also may not have a programmer to read/write the nvram. No matter the reason you will want to swap it out.
-
No matter the reason you will want to swap it out.
Yup! Just saved the data via the Linux utility that bingo600 provided above, thank you Sir. A new DS1220AD-150+ will be added to my next DK order.
-
Yup! Just saved the data via the Linux utility that bingo600 provided above, thank you Sir. A new DS1220AD-150+ will be added to my next DK order.
You're welcome ;)
Actually i ought to replace all 3 in my 58' too
/Bingo
-
Hi texaspyro ;) :-+
Wanna play along , or is "The Lady" still taking your time ?? .. Maybe she should be in the image
I've hacked up Lady Heather lots of times to do logging/plotting and instrument control. It provides a nice base of capabilities and now runs on Windows, Linux, macOS, and FreeBSD. Heather's plotting, logging, and drawing routines are fairly generic. So are the keyboard menu routines once you figure out how they work (lotsa luck with that).
For instance, if you dig through the source code you will find references to "luxor" which is my LED / power analyzer / swiss army knife device.
I've been looking at prasimix's SCPI power supply... Heather knows about SCPI...
V 5.0 added support for writing/reading log files in XML format besides the standard simple ASCII logs. It's fairly easy to add new data types to.
I just added support for allowing up to 10 external com links (serial/USB or TCP/IP). Makes it easy to talk to things in addition to a GPSDO... Time interval counter, anyone?
-
I have defined a key for this. You don't need quote if you are not displaying any message, so just this will do:
DISP MSG,
and yes you can do this by just the front panel.
8)