EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: dimmog on September 11, 2020, 08:48:52 pm
-
i just acquired a very interesting edition of 34401A multimeter. It has some additional sub-menus in the sys menu. I attached pictures.
This meter can save their state and after next power-on it returns to this state. It has quite popular firmware 07-05-02 and hardware looks the same.
I wonder if anyone knows how to activate this sub-menu?
-
Mine has 10-05-02 and I do not have that menu.
-
I have several 34401A with different firmware versions and they don't have this menu either.
-
My two units have 11-05-02 and 11-05-03 (which should be the latest release). The menu does not exist on them, it can be a handy feature, I wonder why it was removed.
I wonder if all meters with 07-05-02 has this feature.
-
i just acquired a very interesting edition of 34401A multimeter. It has some additional sub-menus in the sys menu. I attached pictures.
This meter can save their state and after next power-on it returns to this state. It has quite popular firmware 07-05-02 and hardware looks the same.
I wonder if anyone knows how to activate this sub-menu?
Mine also has 07/05/02 and does not have these menus available (at least be default). The service manual that came with the meter makes no mention of them.
-
I have another meter with 07-05-02 without this menu.
Further more I just swapped eeprom U505 chip to my meter with 10-05-02 and hidden menu appears on it.
So it's definitely not related to firmware version. There is some option in eeprom.
-
same here 07-05-02 nothing past option 8
for the version 11 display FW you need to send the meter at Keysight to have an upgrade, they wont sell you the FW 11 cpu
-
The 07-05-02, 10-05-02, and 11-05-02 firmware binaries here contain the 9 STORE STATE, 10 RCL STATE, and 11 POWER ON menu strings. The 05-01-01 firmware binary does not.
https://xdevs.com/doc/HP_Agilent_Keysight/34401A/fw/
34401a_05-01-01-mcu_program.bin
34401a_07-05-02-mcu_program.bin
34401a_10-05-02-mcu_program.bin
34401a_11-05-02-mcu_program.bin
-
Agilent 34401A 6½ Digit Multimeter Quick Start Tutorial
https://literature.cdn.keysight.com/litweb/pdf/34401-90015.pdf
Front Panel Menu Reference
D: SYS MENU
1: RDGS STORE > 2: SAVED RDGS > 3: ERROR > 4: TEST > 5: DISPLAY > 6: BEEP >
7: COMMA > 8: REVISION > 9: STORE STATE > 10: RCL STATE > 11: POWER ON
So the menu items aren't completely undocumented, even if by default they are not accessible.
-
The 07-05-02, 10-05-02, and 11-05-02 firmware binaries here contain the 9 STORE STATE, 10 RCL STATE, and 11 POWER ON menu strings. The 05-01-01 firmware binary does not.
https://xdevs.com/doc/HP_Agilent_Keysight/34401A/fw/
34401a_05-01-01-mcu_program.bin
34401a_07-05-02-mcu_program.bin
34401a_10-05-02-mcu_program.bin
34401a_11-05-02-mcu_program.bin
Interesting. They also contain 'G: TEMP MENU' and 7 sub-menus for it. I've never seen 34401A with temp option activated.
-
Interesting. They also contain 'G: TEMP MENU' and 7 sub-menus for it. I've never seen 34401A with temp option activated.
This 34401-90005 version of the Quick Start Tutorial does include those menu items.
https://literature.cdn.keysight.com/litweb/pdf/34401-90005.pdf
G: TEMP MENU
1: TEMP FUNC > 2: UNITS > 3: RTD TYPE 4: RTD Ro > 5: T/C TYPE > 6: THERM TYPE >
7: JUNCT TEMP
-
It is a little know fact, that Agilent has produced special versions of some instruments for large customers, like the military. John Kenny confirmed this in his interview with Dave.
So, maybe this menu is built on such special customer version.
-
How can we activate this ?? is there a hack ... ? im willing to hack one of my 34401a ic's put some ic's sockets in it ...
Its a red plugs only with the blue shift button
display pcb 34401-66512 the repairable one
main pcb 34401-66501 rev B
-
How can we activate this ?? is there a hack ... ? im willing to hack one of my 34401a ic's put some ic's sockets in it ...
Its a red plugs only with the blue shift button
display pcb 34401-66512 the repairable one
main pcb 34401-66501 rev B
I attached dump of my U505 eeprom with 'save state' function activated.
If you have firmware version 07-05-02 or higher you can program it to your chip but your meter will require calibration thereafter.
-
are you talking about theses ?
D: SYS MENU
9: STORE STATE > 10: RCL STATE > 11: POWER ON
-
are you talking about theses ?
D: SYS MENU
9: STORE STATE > 10: RCL STATE > 11: POWER ON
Yes
-
and the
G: TEMP MENU
1: TEMP FUNC > 2: UNITS > 3: RTD TYPE 4: RTD Ro > 5: T/C TYPE > 6: THERM TYPE > 7: JUNCT TEMP
how do you know if its in the eeprom bin ??
-
and the
G: TEMP MENU
1: TEMP FUNC > 2: UNITS > 3: RTD TYPE 4: RTD Ro > 5: T/C TYPE > 6: THERM TYPE > 7: JUNCT TEMP
how do you know if its in the eeprom bin ??
As I said, in my eeprom I have only 'store state' option. I've never seen 34401A with active Temp menu.
-
ok :-+ thks will try when ill find my ic's sockets, dont know where i put them loll
-
I´m also interested in decoding the eeprom in the 34401A!
I my experiments with the eeprom I was able only to decode the calibration message string (the string that can be set with GPIB "CAL:STR xxxxx").
(https://www.eevblog.com/forum/repair/hpagilent-34401a-eeprom-checksums/msg950165/#msg950165 (https://www.eevblog.com/forum/repair/hpagilent-34401a-eeprom-checksums/msg950165/#msg950165))
This message-string is stored in the eeprom-bin-file at position 0x22, the checksum is in 0x4a und 0x4b, but I don´t know the algorithm :-(
Time to disassemble the ROM? :-)
@coromonadalix: there´s no need for an adapter, if you have an eeprom-reader : https://www.eevblog.com/forum/metrology/read-and-restore-calibration-constants-from-a-hp-34401a/msg1743833/#msg1743833 (https://www.eevblog.com/forum/metrology/read-and-restore-calibration-constants-from-a-hp-34401a/msg1743833/#msg1743833)
-
Maybe dump the rom before and after enabeling the 10mA range as described here: https://www.keysight.com/main/editorial.jspx?cc=DE&lc=ger&ckey=1000001267:epsg:faq&nid=-31895.536880933.02&id=1000001267:epsg:faq (https://www.keysight.com/main/editorial.jspx?cc=DE&lc=ger&ckey=1000001267:epsg:faq&nid=-31895.536880933.02&id=1000001267:epsg:faq)
to shed some light on the poke command?
It might als point to the general area where such option bits are stored.
edit:
@meandeev:
Can you elaborate in what formate the cal string is stored, when looking at dimmog's dump there do not appear to be ASCII chars after 0x22 :-//
edit #2:
It appears to be "Packed 7bit ascii" but the offsets might vary with FW version?
I can find:
"HP034401" starting at 0x64
"EQUIP.NET" 0x72
A lot different from the dump i found on xDevs.
"HP9000" (might be coincidence) 0x18
"CAL: 35.7C; 3 Mar" 0x26
".7C; 3 Mar 1992;09" 0x2D
"ar 1992;09:33:58" 0x34
"09:33:58" 0x3B
-
the 10ma range should be stored in the eeprom ??
Im not at home .. with this command, is it stored until you disable it thru the other command, does it stay permanently ???
Damn i'm intrigued by the temp measurements menu loll
-
They make it seem like the only way to remove the 10 mA range is to send the second command, and the eeprom is the logical place to store it.
Can you check what cal info string is shown on the device?
You could go crazy with some poke 24,0,1 23 or 26,27 and just see what happens BECAUSE YOU HAVE A BACKUP. DO NOT DO THIS WITHOUT CAL BACKUP. CAL MEMORY CORRUPTION IS LIKELY.
But doing just the one poke to show what bit is flipped (and IF a bit is flipped...) in the dump might shine some light.
Also storing a setting (then dump) and then changing one part of that setting and store it again (dump again) should point to the memory are where settings are stored.
And IF the state settings are stored in the eeprom at all...
edit: In the service manual the "Cal eeprom" is the only place I can find information can be stored in a persistent way by the device itself. Let's see if 10mA and state settings turn up?
-
I firmly support the above advice to not go poking around without first backing up the EEPROM. That's where the calibration info is stored, because it is the only writeable memory in the device (check the schematic!).
Not only is standard cal data stored there, but also special factory cal data that cannot be restored by going through the usual cal procedure, such as the PWM DAC setting for the input switch precharge amp.
These can be altered through undocumented POKE commands, and some PEEK commands might have side effects as well.
-
Gonna rig something up, i have a pomona soic 8 socket, just need to make place on my bench loll
Need to make something to put the cpu in reset while making a eeprom dump, i dont have gpib adapters.
Should work in serial terminal ?
I have an elnec programmer
-
You cannot put/hold cpu in reset with GPIB adapter or serial port.
I used 2 mini grabbers connected with an 1k resistor.
Take a look at the picture in https://www.eevblog.com/forum/metrology/read-and-restore-calibration-constants-from-a-hp-34401a/msg1743833/#msg1743833 (https://www.eevblog.com/forum/metrology/read-and-restore-calibration-constants-from-a-hp-34401a/msg1743833/#msg1743833)
there you can see which cpu pins have to be connected to hold it in reset mode.
-
Just found a YouTube video that proves the "TEMP MENU" exists in the real instrument!
https://youtu.be/lOqVhv5Ca08?t=49
-
I was able to decompile the cal-message, here you can find my result of the gambling with bits and bytes ~2 years ago. I put it in something that looks roughly like a C program-file.
But it´s rather useless, because it fits only the 05-01-01 firmware and without the crc-routine one cannot change anything without an error.
Thats why I suggested to decompile the firmware ROM.
-
:-//
No compressor, I used yesterday a fresh downloaded Version of Pelles-C, compiled it with full debugging Info.
But you can compile it by yourself, source code is included.
My local Windows defender is fine, Virustotal says 4/68 detected :o
-
doesnt want to run on my win 10 too even defender disabled ???
Im gonna take the 34401a who served as a guinea pig for the 34401a oled display variant thread, but t will take a few days to test the poke command and grab the changes int the eeprom ... i do lots of overtime :(
Dmm has the 07 05 02 fw too
-
This "Memory Information and Procedures" also clearly states that ALL non volatile storage is in the eeprom.
https://www.keysight.com/upload/cmc_upload/All/34401A_Mem_external.pdf (https://www.keysight.com/upload/cmc_upload/All/34401A_Mem_external.pdf)
-
fyi - the above calmsg.zip downloads and builds here (Win10).
My HP's rev fw is 10-05-02 and no menu 9 and above.
Would be great to enhance the fw (without deleting cal constants).
PS: the doc above says the operating system is in an OTP ROM (one time programmable), but the service manual (Agilent) shows in the schematics AM27C020 which is an EPROM.
Below the BOM from the same service manual - the U502 is an M27C2001 "2Mbit OTP ROM" (aka 34401-88806). But the M27C2001 is an EPROM afaik.. :-//
It could be the older - pre 1999 "HP" models - are using OTP ROM there, later models (Agilent, KS) have replaced it with an EPROM..
The CAL constants and a few other I/O parameters are stored in an EEPROM (U505).
-
Those menu items look awfully similar to the ones on my (HP) 34970A, a DMM that's also made by HP/Agilent and that's basically a 34401A with a multiplexer connected to it. Wouldn't surprise me if they use the same firmware and just added the capability to switch between different channels for the 34970A (the 34401A already kinda has that with its 4 wire measurements). In a 34970A, the store state/recall state options are to save different channel configurations and the power on option configures if the DMM should continue scanning its channels after a blackout or abort the scan. Also, it definitely has a TEMP menu, but i can't recall the exact names of the options there, but there are quite a lot (types, temp units, int/ex ref (and the temp of the ext reference), etc).
So it could be the case that some 34401A are running on software designed for the 34970A...
-
PS: the doc above says the operating system is in an OTP ROM (one time programmable), but the service manual (Agilent) shows in the schematics AM27C020 which is an EPROM.
Below the BOM from the same service manual - the U502 is an M27C2001 "2Mbit OTP ROM" (aka 34401-88806). But the M27C2001 is an EPROM afaik.. :-//
It could be the older - pre 1999 "HP" models - are using OTP ROM there, later models (Agilent, KS) have replaced it with an EPROM..
An EPROM in a plastic package as used in the 34401A instead of a ceramic windowed package is an OTP part. Can't reprogram it if there is no way to erase it.
-
Those menu items look awfully similar to the ones on my (HP) 34970A, a DMM that's also made by HP/Agilent and that's basically a 34401A with a multiplexer connected to it. Wouldn't surprise me if they use the same firmware and just added the capability to switch between different channels for the 34970A (the 34401A already kinda has that with its 4 wire measurements). In a 34970A, the store state/recall state options are to save different channel configurations and the power on option configures if the DMM should continue scanning its channels after a blackout or abort the scan. Also, it definitely has a TEMP menu, but i can't recall the exact names of the options there, but there are quite a lot (types, temp units, int/ex ref (and the temp of the ext reference), etc).
So it could be the case that some 34401A are running on software designed for the 34970A...
Could be it, the 34970 has the same asics, and go up to 300v not 1kv .... never saw any leaked eeprom / roms / firmwares ?
-
The missing 1 kV spec is probably due to the fact that designing a board with screw terminals for 40 individual channels that has to withstand 1 kV between two screw terminals would be a nightmare (and those 40 wires would be running through a 1 cm^2 opening)... And since not that many people need to monitor multiple 1 kV lines simultaneously they just went with 300 V max instead. Also, it only goes up to 1A, probably for a similar reason.
Btw, i just checked the service manual for parts numbers and i found this entry for what seems to be the main IC on the DMM board: "U102 CUST R NET PKG, REPLACES 34401-67901"
I have the EEPROM for the chip with the calibration constants if you want it, but i doubt that it'll be usefull in this case.
-
The missing 1 kV spec is probably due to the fact that designing a board with screw terminals for 40 individual channels that has to withstand 1 kV between two screw terminals would be a nightmare (and those 40 wires would be running through a 1 cm^2 opening)... And since not that many people need to monitor multiple 1 kV lines simultaneously they just went with 300 V max instead. Also, it only goes up to 1A, probably for a similar reason.
Btw, i just checked the service manual for parts numbers and i found this entry for what seems to be the main IC on the DMM board: "U102 CUST R NET PKG, REPLACES 34401-67901"
I have the EEPROM for the chip with the calibration constants if you want it, but i doubt that it'll be usefull in this case.
If you have a eeprom dump please post it, and your firmware revision.
-
If you have a eeprom dump please post it, and your firmware revision.
As i've said i only have the EEPROM dump of the F-RAMs that contain useless stuff... The 34970 has its DMM on a separate module, and that module alone contains at least two ICs plus one FRAM for the cal. constants, and another FRAM on the main board that keeps track of the power cycles. Since none of those ICs are socketed i really don't want to screw around with them.
I've attached the fram dumps (had that because the one in my unit died and i couldn't format those chips via GPIB). The DMM is from the fram on the DMM module, but i wouldn't count on it being correct since one bit toggled between two states every time i read the chip... The other dump is from the fram on the main board that contains god knows what (number of power cycles+ other stuff).
Firmware rev? Can check that when i get my 34970A out of its natural habitat in a test rig where it's sitting as a rather overqualified temperature logger (i "definitely" need a 6.5 digit DMM to measure 3 digit values...)
-
Murphy says it's propably the one you left out, what you posted looks nothing like the 34401A one's as well. :-//
-
Reading the scpi manuals for other HP products, DIAG:PEEK takes an address and a number of bits to read. I bet we can dump the non volatile memory by peeking addresses 0 through 512. The docs were clear that PEEK is a read-only operation.
It would be interesting to see if the data produced by that matches what people have grabbed directly off the eeprom chip. If it does match, then we could experiment with poking around near address 25 to see if we can enable the temp menu and other hidden functionality without clobbering calibration values in the 512 bytes of non volatile storage.
-
In fact it's likely that the number at that address is an 8 bit control "register" other bits in it may control other capabilities... Just peeking around in that byte only may yield some answers without endangering other data stored
-
Hmmmmm -- DIAG:PEEK? seems to work strangely on the 34401A - it wants 3 numeric parameters -- DIAG:PEEK? 25, 0, 0 results in the same output as *IDN? -- weird, right?
Other values produce what look to be 32 bit numbers. DOcs for other HP devices say that there are 2 paramters to PEEK? and they are address and bit_width -- the latter which must be 8 or 16. The 34401A does not seem to work like that at all.
Has anyone else tried DIAG:PEEK on a 34401A? Anyone? Buehler?
-
A little googling found this; http://instructor.physics.lsa.umich.edu/adv-labs/Tools_Resources/HP%2034401A%20quick%20start%20guide.pdf (http://instructor.physics.lsa.umich.edu/adv-labs/Tools_Resources/HP%2034401A%20quick%20start%20guide.pdf)
Node that the "hidden" menu items are documented here -- including the G: TEMP MENU!
-
yep. we already discussed this on the first page.
A little googling found this; http://instructor.physics.lsa.umich.edu/adv-labs/Tools_Resources/HP%2034401A%20quick%20start%20guide.pdf (http://instructor.physics.lsa.umich.edu/adv-labs/Tools_Resources/HP%2034401A%20quick%20start%20guide.pdf)
Node that the "hidden" menu items are documented here -- including the G: TEMP MENU!
-
excuse my ignorance - is there a logfile or equivalent that describes the features, or even dates, of the revisions?
my 34401A is Rev 08-05-02 - I don't see that f/w listed anywhere?
-
excuse my ignorance - is there a logfile or equivalent that describes the features, or even dates, of the revisions?
my 34401A is Rev 08-05-02 - I don't see that f/w listed anywhere?
Take a look at the redme.txt file ;)
https://xdevs.com/doc/HP_Agilent_Keysight/34401A/fw/
I believe they have summarized the information available from the various manuals
"The EEPROM structure looks the same from 07-05-02 to 11-05-02, so no calibration seems to be necessary when upgrading FW from 07-05-02 to 11-05-02."
You can upgrade if you want
-
Thanks - I just read the txt file - but although it says I can upgrade, I don't see any info on what an 'upgrade' changes? The list at the top focuses on the physical things - color of buttons, banana jacks, board S/N, etc. - None of that can be changed by 'upgrading' to 10-05-02, or 11-05-02, etc.?
I'm lost as to how the f/w revs differ, and also my rev (08-05-02) never seems to be listed?
Thanks
-
the upgrade problem is ; the mcu is under the vfd display, you have to put a new ic there ???
I could be wrong since i always mistake the display fw and the main fw version
-
Thought I'd update this somewhat dormant thread with a little more info.
Background is that I recently got a 34401a in decent condition/calibration (factory cal from 2007, but a few spot checks still look good), and the hidden menu looked like a nice thing to have, plus I wanted a backup of my EEPROM anyway, so I had a play:
- On boot the meter reads the first 211 16-bit words (up to word address 0xD2) of the EEPROM in order (looks like the rest is just blank and never used, so can be ignored)
- This is a nice and easy way to get a backup using a scope or LA without any EEPROM flash tools. Was a lot easier than the last time I did this with a 16-bit parallel EEPROM in a Keithley 236!
- Needs a bit of care with bus decode setup - it's not normal SPI, though my scope (RTB2k) was happy when I set it up as a 27-bit (!!) SPI bus and the correct polarity of chip select, clock (appears to be opposite for data in vs out) etc. Only the last 2 bytes of data output on each read will be valid (and the first ~10 bits will depend on the 100k pullup and your probe impedance and threshold, as it's Hi-Z for that period)
Once I had my backup, I had a bit of play with POKE commands, as per my rough notes (attached). Note that addresses listed in them are word addresses in hex, I was too lazy to append 0x most of the time.
Unfortunately I didn't have much luck finding anything useful, other than if you hate someone you should send DIAG:POKE 0,0,0 to their meter.
I then needed to restore my original backup, so I first had a crack programming the 34401a-save-state-menu.BIN previously posted into my EEPROM. Sadly my meter (on 11-05-02) didn't like this at all, throwing a number of 74x errors on boot, and no new menus appeared.
My original EEPROM dump works fine when programmed back into my meter, so I'm not sure what is the issue is with dimmog's .BIN given the previously reported success swapping the EEPROM (and activated hidden menu) into a 10-05-02 meter. Not a lot more that I think I can do now, though I'm open to suggestions while my meter is still opened up on the bench :(
-
Interesting theme... ::)
I will have a peek to see if I can add something to this quest.
@Hydron, can you share your original dump? Your checksums offsets should be dump-dependent.
-
Yeah the hope was that it is something that can be enabled via an undocumented poke like the 10mA AC range.
Seeing as I had a memory dump and the thing all wired up already to allow EEPROM access (for both write and monitoring), I thought I'd have a crack with some other POKE commands. I tried everything up to the mid 30s at least with x,0,0 without result other than what I wrote in my notes. This post suggests that other poke commands can be used to do some other tricks though, but annoyingly HPAK didn't elaborate any further: https://www.eevblog.com/forum/testgear/agilent-34401a-hidden-10ma-ac-current-range/msg400451/#msg400451 (https://www.eevblog.com/forum/testgear/agilent-34401a-hidden-10ma-ac-current-range/msg400451/#msg400451)
Edit:
A little more info - I tried again with dimmog's .BIN, but only writing up to 0x30 (the first checksum). Gave errors 740 747 and 748, i.e. Cal secure, GPIB addr. and "internal data" checksum errors, no other errors suggest that the other calibration info is stored after that point (as suspected). After changing a setting (triggering a re-write of at least the checksum) it's reset all the stuff I wrote from the .BIN to nearly what was originally there, suggesting it's back to defaults. No hidden menu enable still :'(
Edit 2:
...just realised this might be a little/big endian issue with the byte order, which would explain the total lack of success with dimmog's .BIN. Will try again with the bytes in each word swapped!
-
I'm not a programmer but I think 11-05-02 has a different EEPROM structure. The 07-05-02 and 10-05-02 have almost the same data up to 0x60 and 11-05-02 looks completely different.
-
Success!
Looks like the EEPROM structure is still compatible between versions 07 10 and 11.
Fixing the byte order worked, and I was able to load your .BIN up to word 0x30 (i.e. up to byte 0x61), which is the section that contains the magic incantation to enable the hidden menus.
It looks like my calibration (and count, message etc) is untouched, and I have the new save/recall/power-on menus, though I have not tested them in anger yet. Applying the AC 10mA range tweak also works - while the value at the address it changes is now non-zero to begin with, it only modifies one bit from 0 to 1, leaving the rest the same (via a read-modify-write cycle I guess).
Edit:
A quick test with the saved state resulted in being able to set the default number of digits on boot to 6 :)
Edit2:
- Found the byte that does it, by changing the second byte at word 0x09 (i.e. byte 0x13) from 0x98 to 0x8C (and updating the checksum at word 0x30 by subtracting the difference, i.e. 0x0C, from it) it enables the hidden menu. There aren't that many changed bytes between my original and dimmog's file (at least before the 0x30 checksum word), so it only took 2 attempts to find it!
* Update: 0x9C works too, so it's just the 4s bit in the second nibble
Also see attached the byte swapped version of the .bin that dimmog originally posted.
Anyone want to have a crack at guessing bytes to get the temperature menu working? :P
-
I'm not a programmer but I think 11-05-02 has a different EEPROM structure. The 07-05-02 and 10-05-02 have almost the same data up to 0x60 and 11-05-02 looks completely different.
As Hydron mentioned the endianness of the 11-05-02 version is wrong (probably a mistake from the dumper).
-
...and more notes:
Using the save settings option with fast 6-digit mode selected (otherwise power-on-defaults) changes words:
- 0x0C from C0D1 to C0E1
- 0x1D from 0000 to 8000
- 0x1E from 0000 to 0232
- 0x2A from 0000 to FC00
- 0x2B from 0000 to 0001
- the checksum at 0x30
This accounts for all but three bytes of the differences between my firmware dump and dimmog's (remaining differences are at words 0x08 and 0x20)
Turning on the option to recall settings on boot modifies word 0x08 from 1000 to 3000 (probably would be 0000 to 2000 without the bit being set for AC 10mA range enable)
If anyone has a 34401A with a temperature menu present, please pipe up (and even better still, supply an EEPROM dump!)
-
Based on @meandeev C program :clap:, here is a tiny contribution.
His program can be reduced to this C# snippet (others can put it in Python):
int start = 0x64;
for (int j = start, s = 0; j < buffer.Length - 1; )
{
ushort b = BitConverter.ToUInt16(buffer, j);
Console.Write("{0}", Convert.ToChar((b >> s) & 0x7F));
s += 7;
if (s > 8)
{ s -= 8; j++; }
}
This is already adapted to extract the 7-bit text from 34401a_11-05-02-EEPROM.bin (corrected version) and should work on other versions (just adjust initial start and s values if necessary).
As you can see, starting at offset 0x64 (bytes), there are these strings:
HP034401 23 JUN 2005 25.9C
34401a-save-state-menu.BIN file at offset 0x64 (bytes):
HP034401 HUBEQUIP.NET
34401a_05-01-01_eeprom.bin at offset 0x18 (bytes):
HP034401 18 APR 1995 21.3C
calrom_orig.bin at offset 0x18 (bytes):
HP900000 ZERO CAL: 35.7C; 3 Mar 1992;09:33:58
So, @Hydron, you cannot swap all the bytes as you did. That requires further investigation.
-
Hmm, curious. I've attached my original (well, after enabling 10mA AC range) bin from before I opened up my unit and started messing around too much, could you check that one too?
I'm pretty sure I have the right byte order, as it's what I get by sniffing MISO or by using a tool to read the chip, and also when I have updated the checksum it has worked in the order that I have. It's also the only order that works when flashing a .bin to it.
-
:)
That explains it! Your dump has incorrect endianness BUT it's in sync with your programmer. So that's why you should invert endiannes to flash BUT we can only proper analyze the dump if we correct the endianness.
So with endianness corrected, your dump shows at offset 0x64 (bytes):
HP034401 2 MAR 2007 24.5C
-
...and finally (well, other than endinness adjustment), I took another stab in the dark and tried flipping more bits to get the temperature menu.
Second try lucky (first try was turning on all the bits in the word which enabled the save menu) and it's the same byte as the DIAG:POKE 25,0,1 command changes - this time the high bit instead of the low bit. Word 0x08 (byte 0x10 in the endianness I'm using) is the one to tweak, along with the checksum of course.
Have attached the final EEPROM with both extra menus enabled (note endianness may not match for everyone, I can do a swapped version too but not tonight), and also a couple of pics of the patient under surgery and a PT100 temperature measurement.
-
...and finally (well, other than endinness adjustment), I took another stab in the dark and tried flipping more bits to get the temperature menu.
:-+ Way to go!
-
hi
noob question, is it the mainboard eeprom or the cpu eeprom
-
hi
noob question, is it the mainboard eeprom or the cpu eeprom
This is U505 EEPROM IC.
-
Now I'm wondering if it's possible to make a DIAG:POKE command to activate those menus..
I found some info about DIAG:POKE.
-
Second try lucky (first try was turning on all the bits in the word which enabled the save menu) and it's the same byte as the DIAG:POKE 25,0,1 command changes - this time the high bit instead of the low bit. Word 0x08 (byte 0x10 in the endianness I'm using) is the one to tweak, along with the checksum of course.
I went to bed with the feeling that you would solve it very soon. Great job! :clap: :clap:
Now I'm wondering if it's possible to make a DIAG:POKE command to activate those menus..
I found some info about DIAG:POKE.
I think so. Just a matter of processing all the knowledge gained in these last hours.
I think the cal string packing is an indicator of how all the binary structures are packed. The cal string is basically a concatenation of 7-bit chars (instead of the usual 8-bit). So, I've a feeling that all other structures are also tightly packed and don't obey to the usual byte boundaries.
-
dimmog, sadly I don't think the PEEK and POKE commands work like that on the 34401A, at least the ones which modify the eeprom. Though it might help to look at the post I linked earlier for some more examples.
Would be very useful to be able to turn the bits on via SCPI though, so not gonna discourage more testing!
-
The attached picture is the map of all the blocks (and their Checksum positions) of the EEPROM dump. This should allow (one day) a more precise understanding of the initial blocks.
I used the 34401a_11-05-02-EEPROM.bin (posted above).
This was done based on the info collected by Hydron yesterday.
In order to verify and calculate the checksums of all the blocks in a dump, I leave here a C# code that does that (should be self-explanatory):
byte[] block_sizes = { 0x02, 0x02, 0x2A, 0x1A, 0x18, 0x12, 0x1A, 0x1C, 0x22 };
if (BitConverter.ToUInt16(buffer, 0x14) != 0) // to accommodate older FWs (below version 07-05-02)
{
block_sizes[2] = 4;
if (BitConverter.ToUInt16(buffer, 0x06) != 0x16)
block_sizes[3] = 0x18;
}
for (int j = 0, i = 0; j < block_sizes.Length; j++, i += 2)
{
ushort sum = 0;
for (int end = i + block_sizes[j] * 2; i < end; i += 2)
sum += (ushort)(BitConverter.ToUInt16(buffer, i) + 1);
Console.Write("Offset: {0:X4} Checksum_Calc: {1:X4} ", i, sum);
if (BitConverter.ToUInt16(buffer, i) - sum == 0)
Console.WriteLine("OK");
else
Console.WriteLine("ERROR!");
}
(This source code can be used to verify if your EEPROM dump is OK.)
The output for 34401a_11-05-02-EEPROM:
Offset: 0004 Checksum_Calc: 0002 OK
Offset: 000A Checksum_Calc: 0018 OK
Offset: 0060 Checksum_Calc: 9147 OK
Offset: 0096 Checksum_Calc: 9B7D OK
Offset: 00C8 Checksum_Calc: 7336 OK
Offset: 00EE Checksum_Calc: 1F61 OK
Offset: 0124 Checksum_Calc: 8093 OK
Offset: 015E Checksum_Calc: 1EB3 OK
Offset: 01A4 Checksum_Calc: 3B72 OK
The output for 34401a_hydrons_ebay_unit_with_save_temp_menus_enabled_by_bit_changes_EEPROM:
Offset: 0004 Checksum_Calc: 8663 OK
Offset: 000A Checksum_Calc: 0018 OK
Offset: 0060 Checksum_Calc: 215C OK
Offset: 0096 Checksum_Calc: 0101 OK
Offset: 00C8 Checksum_Calc: 99A5 OK
Offset: 00EE Checksum_Calc: 3ADC OK
Offset: 0124 Checksum_Calc: CE20 OK
Offset: 015E Checksum_Calc: DEC0 OK
Offset: 01A4 Checksum_Calc: EFE5 OK
The output for calrom_orig.bin (floating around in the web). This old dump contains checksum errors (in my opinion):
Offset: 0004 Checksum_Calc: 8663 OK
Offset: 000A Checksum_Calc: 000A OK
Offset: 0014 Checksum_Calc: 1A66 ERROR!
Offset: 0046 Checksum_Calc: 25D4 OK
Offset: 0078 Checksum_Calc: A3A5 ERROR!
Offset: 009E Checksum_Calc: B3D6 ERROR!
Offset: 00D4 Checksum_Calc: 4359 OK
Offset: 010E Checksum_Calc: 2C46 ERROR!
Offset: 0154 Checksum_Calc: 2B1B OK
The checksum calculation has a little twist: they also sum the number of Words that are used in the calculation.
Edit: The green area contains the additional bytes that were added with the introduction of FW 07-05-02.
The red area is where the option bits reside. As we can see, this area already existed in FW 07-05-02.
-
Interesting - never found the first couple of checksums as I didn't manage to trigger anything that would mess with that area. I wonder what those first two small blocks do - my unit and dimmog's both came with different info in the first word than the 0000 I've seen from other dumps.
Good insight into the extra twist of the word number being added to the sum - I didn't manage to figure out where the offset came from when I tried (though I was also probably looking at the wrong range of words).
I guess the main questions now are a) are there any more useful hidden features to find and enable and b) can we flip the magic bits via SCPI without an eeprom programmer
On my end I had a bit more of a play this morning, but I think I'll put my unit back together soon - does anyone have further tests they want done while I still have my programmer connected?
-
On my end I had a bit more of a play this morning, but I think I'll put my unit back together soon - does anyone have further tests they want done while I still have my programmer connected?
If I understand correctly what you tested, these are the option bits:
Offsets: 0x11+0x12
00 00 98 06 - Default
00 90 9C 06 - Store State + Temp + 10mA AC
00 10 98 06 - 10 mA AC
| |
| 0001 - SCALE options in math menu
| 0010 - ???
| 0100 - Store State
| 1000 - Default (?)
|
0001 - 10 mA AC
0010 - Recall saved settings on power-up (set via SAVE menu item)
0100 - ???
1000 - Temp
Did you test the other combinations? Can you do it?
BTW, If we look at those 2 bytes as a little-endian word, the middle nibbles become:
9800
9C90
9810
|
+---+
| |
00000001 - 10 mA AC
00000010 - Recall saved settings on power-up (set via SAVE menu item)
00000100 - ???
00001000 - Temp
00010000 - SCALE options in math menu
00100000 - ???
01000000 - Store State
10000000 - Default (?)
By crossing this info with the command to enable 10 mA Option (https://edadocs.software.keysight.com/kkbopen/is-there-a-way-to-measure-low-level-ac-current-using-the-keysight-34401a-588263164.html):
DIAG:POKE 25,0,1
I could imagine this scenario: :)
0 is the bit position of the above table (that we want to change)
1 is turning ON that bit position
Can you test POKE 25 with other combinations, with this theory in mind?
(not much hope but worth a try...)
-
OK so PEEK/POKE do NOT work like that doc. However I have found:
DIAG:PEEK? -1,x,0 where x is a decimal number will read the EEPROM word at address x, answer comes back in decimal again. This is a closed-case EEPROM backup enabler :)
Trying to do the same with POKE (e.g. diag:poke -1,8,45056) doesn't seem to write anything.
As for the option bits, I have tried setting them all on, didn't notice any changes beyond what we've already found with TEMP and SAVE menus, didn't search exhaustively though. I can add a little to the table though:
0001 - 10 mA AC
0010 - Recall saved settings on power-up (set via SAVE menu item)
0100
1000 - Temp
-
OK so PEEK/POKE do NOT work like that doc.
Sure, forget the doc.
Can you try to disable the Temp by using the POKE 25 as I hint above:
POKE 25, 3, 0
-
i'm afraid i'm a little late to the party here. i do have a 34401A, but not one that i can tinker with. nonetheless...
regarding the two HP poke commands to enable/disable the 10mA AC range:
"DIAG:POKE 25,0,1"
and
"DIAG:POKE 25,0,0"
can someone post screen dumps (before and after) of what the EEPROM looks like, like the one TV48 posted in reply #65 above? preferably with any changed values highlighted?
if the 10mA AC pokes change one bit, then it seems that either the necessary checksums are automatically updated, or TWO bit locations are updated, so that one change cancels out the other when calculating any checksums.
cheers,
rob :-)
-
Can you try to disable the Temp by using the POKE 25 as I hint above:
POKE 25, 3, 0
Still only changes the 10mA AC range (turns it off). TEMP stays on.
@robert.rozee:
The POKE 25 commands only seem to change the bit for 10mA AC range (a single bit), but as you assumed, the checksum is then automatically updated (so I guess you could say it changes more than just the single bit, but the checksum only determines whether the meter throws an error).
-
so we can change the parameters to "DIAG:POKE ..." and observe how they change the EEPROM dump? ie, instead of the two we know: "25,0,1" and "25,0,0", we could try (for instance) "25,0,2", "26,0,1", and other minor variants - although initially at each step changing just a single parameter.
in a sense, we know the outcome we seek. now we just need to reverse-engineer the behavior of "DIAG:POKE ..." to figure out how it affects the pattern saved to the EEPROM.
cheers,
rob :-)
-
so we can change the parameters to "DIAG:POKE ..." and observe how they change the EEPROM dump? ie, instead of the two we know: "25,0,1" and "25,0,0", we could try (for instance) "25,0,2", "26,0,1", and other minor variants - although initially at each step changing just a single parameter.
in a sense, we know the outcome we seek. now we just need to reverse-engineer the behavior of "DIAG:POKE ..." to figure out how it affects the pattern saved to the EEPROM.
cheers,
rob :-)
I had a crack at this already - see my first post in this topic (probably on page 2). Didn't have much luck with this, and it was time consuming, as I had to go back through the logic analyser output after each test to look for write commands.
If you have the ability to write an EEPROM in case of disaster (seeing as we don't have the command for arbitrary write yet) then feel free to write a script to dump yours with the PEEK command I just discovered (or just using the programmer), and have a play.
-
The 3rd param of POKE 25 looks like it's ON (1) and OFF (0).
IMHO that should not be necessary to brute force anymore.
Assuming that this POKE 25 is the one for all options, I would bet on testing plenty of 2nd params to see if they are responsible for other bit positions (in the options bytes).
BUT AFTER HAVING A BACKUP DUMP.
As Hydron has tested, I don't thing other POKE numbers (26,, 27, etc) will do the trick...
-
we really need someone with a scrap 34401A that they can experiment with. blown up front-end or ADC for instance, but that can still accept "DIAG:POKE ..." commands from the serial port and write to the EEPROM.
next, unsolder and remote the EEPROM, with a simple mechanism to switch over to reading the contents directly in an automated fashion after sending a POKE command. perhaps TiN (of xdevs.com) has such a parts unit available?
alas, i don't feel too inclined to mess too much with my own 34401A as it is the only one i have, and i do depend on it working and remaining in calibration!
cheers,
rob :-)
-
next, unsolder and remote the EEPROM, with a simple mechanism to switch over to reading the contents directly in an automated fashion after sending a POKE command.
No real need for this TBH, you can read it (probably a bit slowly) with the PEEK -1 command, and if you hold the processor in reset (ground pin 16) then you can read or write the EEPROM with an external programmer without any issues. Alternatively, if you have a logic analyser setup you could simply look for write accesses after sending a POKE command (it only writes to addresses it needs to update, and always reads immediately beforehand too, so you know exactly what gets changed).
If your programmer puts it's pins into high-Z mode when it's not actively working (as the AsProgrammer + FT232H setup I'm using seems to do) then you can actually just leave it connected, and only ground the reset pin when you need to flash the EEPROM.
-
If I understand correctly what you tested, these are the option bits:
Offsets: 0x11+0x12
00 00 98 06 - Default
00 90 9C 06 - Store State + Temp + 10mA AC
00 10 98 06 - 10 mA AC
| |
| 0001 - SCALE options in math menu
| 0010 - ???
| 0100 - Store State
| 1000 - Default (?)
|
0001 - 10 mA AC
0010 - Recall saved settings on power-up (set via SAVE menu item)
0100 - ???
1000 - Temp
No luck with trying more POKE commands (other than POKE 27 can turn the TEMP option off, but seemingly not on), but I did try and set the other bits in the byte that turns on the SAVE menu, and one of them enables the scale option seen in the quick-start guide here (math menu): https://www.keysight.com/gb/en/assets/9018-04874/quick-start-guides/9018-04874.pdf (https://www.keysight.com/gb/en/assets/9018-04874/quick-start-guides/9018-04874.pdf)
Had a quick test and scale factor seems to work (and even gives you up to 7 digits of output!)
Will update once I figure out which of the two bits it was. It's the LSB
-
What about the 06 and the 9 in
00 10 98 06 - Default
Have you tried the bits in that byte and nibble?
I guess it could be part of the options map as (for example) an int32: 0x06981000
-
just a silly idea: perhaps the calibration lock needs to be turned off first to enable changing some of the option bits?
cheers,
rob :-)
-
No further luck or info from either of the last couple of suggestions (I'd already tried the other bits in the settings bytes, and my unit was already unlocked, though I also tried with the lock enabled).
At this point I need my desk space back so the DMM is going back together again, but now with a few bonus features thanks to everyone's efforts (particularly dimmog for starting the thread and providing the EEPROM dump). 8) :-DMM :-/O
-
Some more poke from old IntuiLink software examples.
DIAG:POKE -2,4281,0 - Close front end relay
DIAG:POKE -2,4281,4 - Open front end relay
DIAG:POKE -2,3512,0 - Force front end conf to change
DIAG:POKE 1,0,0 - Force front end conf to be sent
thanks alex.forencich for finding this
-
Yeah that set of POKE commands is what inspired me to try the PEEK? -1 which returns the eeprom contents. POKE -1 didn't seem to do anything though (and -2 seems to be for ram or something).
One thing it does make me realise is that I never tried a poke 1 after other commands - maybe that would trigger a write cycle? Very long shot though.
-
One thing it does make me realise is that I never tried a poke 1 after other commands - maybe that would trigger a write cycle? Very long shot though.
You mean changing the RAM contents with POKE -2 commands and then issue a POKE 1,0,0 to submit the info to EEPROM?
Very long shot indeed but...
(If the frontend relay state is also stored in EEPROM and the previous msg commands change the EEPROM contents then that could be possible.)
-
Yeah that set of POKE commands is what inspired me to try the PEEK? -1 which returns the eeprom contents.
What are the addresses that you used (could use) to dump the EEPROM via PEEK -1 ?
-
What are the addresses that you used (could use) to dump the EEPROM via PEEK -1 ?
DIAG:PEEK? -1,x,0 where x is a decimal number will read the EEPROM word at address x, answer comes back in decimal again. This is a closed-case EEPROM backup enabler :)
Basically run it 211 times, with x = 0 to 210, record the answers and you have an EEPROM dump once you convert to hex. After 210 you just read the 0xFFFF padding until the end of the EEPROM, then it wraps back around. FW pre 07-xx-yy might give different results I guess?
-
I'm interested in the SCALE option but, reading again and again this thread, I can't figure out if it can be activated with DIAG:POKE command, like the 10mA AC range, or it requires to physically access the EEPROM
-
Currently it needs physical access. Use a SO-8 test clip or something, plus a couple of mini grabbers to put the processor into reset (see service manual for pinouts).
If someone wanted to try and get it working without physical access by blindly testing more POKE commands (or better still by reverse engineering the firmware to try and find them) then that would be great though! (Best to backup the existing eeprom contents first though, at least we can now do that using the PEEK command instead of opening the case)
-
I landed upon this thread and thought it might be useful to leave this here from my file of useful(?) information:
With the 7-5-2 firmware in a 34401A
DIAG:POKE -2,4667,1
DIAG:POKE -2,4607,1
DIAG:POKE -2,4610,1
DIAG:POKE -2,4608,1
DIAG:POKE 25,0,1
(first is recall, second temp, third save state, fourth SCALE menus)
The last instruction is vital even if you already have 10mA current enabled. This should turn on TEMP, SAVE State, RECALL state and 10mA current.
I am not sure how stable over firmware versions it is though but it's easy to check as the EEPROM format is stored in a table at the end of the 02xxxx region in ROM. The format is a bit strange, but is specified in terms of bit groups and the memory address where they are mapped (along with a ROM address for a default). In writing to the EEPROM each new group of bits is added to the left of the stream with LSB on right always. E.g.
[F6.1 F6.0 F5.0 F4.0 F3.2 F3.1 F3.0 F2.4 ] [F2.3 F2.2 F2.1 F2.1 F1.2 F1.1 F1.0 F0.0 ]
Shows fields of length 1,3,5,3,1,1,2 (imaginary example) bits in a field. Here FX.Y is Yth bit of field X. This shows the first two bytes in an example byte1 on left byte0 on right. So basically once you think of always adding on the left it sort of makes sense.
A few useful commands are: (all addr, data are base10). Words in memory are little-endian.
POKE -3,addr,word writes word to RAM
POKE -2,addr,byte writes byte to RAM
PEEK 0,addr,0 reads a RAM addr (word)
PEEK -1,addr,0 reads a EEPROM addr (the EEPROM is not mapped into main memory)
POKE 25,0,1 turns on 10mA current by setting the RAM byte for the range and then doing a write to the lower part of the EEPROM of any changed data. This also picks up other RAM flag changes and saves them to EEPROM.
Someday I should look at the firmware and see if there were a more stable way to do this which might be stable over firmware versions.
Not sure if this is all the SCALE options - they seem to be in RAMat 4608/9 but the menus appear under MATH with just 4608 set to 1.
Now I need a temperature probe to test it.....
Thankfully 80196 code is much easier to read than Fairchild F8....
If anyone tries this I'd be interested to know how you get on; but see advice earlier about a backup before starting; PEEK -1 is your friend here.
-
Unfortunately those POKEs probably won't work on other firmware versions, because the RAM layout would be different.
In version 10 (and maybe others) there are dedicated POKEs that enable the hidden functions:
POKE 28,0,1191 math menu -> min-max: enable sdev, pp
POKE 30,0,1191 temp menu, scpi commands
POKE 31,0,1191 menu -> scale, calc:scale
POKE 32,0,1191 resolution menu -> custom aperture
POKE 33,0,1191 system menu -> store state, recall state
To disable, poke with something other than 1191, e.g. 0
To check if a function is enabled, use
PEEK -10,index,0 where index is
1 sdev, pp
2 temp
3 scale
4 custom aperture
5 save recall
-
I can confirm that those pokes do indeed provide "firmware" stable ways to set the flags which also work in 7-5-2 (they work by doing the same as the RAM pokes, but are much cleaner!). Also I checked the addresses in another firmware and for 10-5-2 the ram pokes were different viz:
DIAG:POKE -2,4665,1 ; recall on power up
DIAG:POKE -2,4605,1 ; temp
DIAG:POKE -2,4606,1 ; save/recall state
DIAG:POKE -2,4608,1 ; scale menus
DIAG:POKE 25,0,1
As an example for POKE 30 (temp) the code 7-5-2 is
046E1 CMP E2,#04A7; int(ARG2)==1191?
046E5 JNE 46EA
046E7 LDB E1,#01 ; second arg is 1191 -magic on value?
046EA ...
[Switch dispatch] for POKE 30 to 4B2B
// Case 22 (poke 30)
// E1 =1 iff second arg is magic 1191 value
04B2B STB E1,11FF[0] ; DIAG:POKE -2,4607,1
04B30 LCALL 76C3 ; Switch overlay to 0x2xxx and call 460A (write all "normal" blocks)
04B33 SJMP 4B7
-
Great work getting this "hack" to work without needing to open the case and read/write the EEPROM. I've tested the POKE 28 and 32 commands (the two I didn't have enabled already) and sure enough they work. I also noted that using a custom aperture seems to let you retain 6.5 digits at <10 NPLC, though that doesn't mean the extra digit (or the 7th digit you can get by enabling the SCALE function) is useful at that setting.
I probably actually managed to enable these during my EEPROM hacking attempts, but just didn't discover the newly activated options due to how buried they are (I only kept the bit flips which did something I noticed). Should really have looked more closely at the strings in the firmware though - they would have revealed a hint that there was an extra option or two hiding away. Not seeing any further hints with another look now though; are all of the secrets finally revealed?
@razvan784 - did you also reverse engineer the firmware like alan.bain, or did the list come from elsewhere?
I'm wondering why they hid these features in the first place, other than maybe the temperature measurement, it's hardly like they were going to cannibalise sales from their 3441x or other meters by adding them. I guess maybe they didn't want owners with earlier firmware revisions demanding the new features?
Edit: forgot to note that mine is running FW 11-5-2, so I suspect that the magic commands work from 7-x-y onwards.
-
I couldn't find any information apart from what's already been posted here, so I disassembled the v10 firmware, out of curiosity / entertainment.
The code is quite large and "twisted" and I can't say I understood it all, or most of it, but I specifically looked into the POKEs, PEEKs, menus and SCPI commands.
Those seem to be all the hidden functions, and they seem to be production-ready - no idea why hp decided to hide them, management decision perhaps.
There are SCPI commands for temperature measurement that are similar to the 34420A and 34970A.
There is a DIAG:TEMP? command that returns the internal DMM temperature measured from its on-chip sensor.
All peeks follow the format PEEK function,parameter,0.
Functions span from -12 to 3.
-10 reads if a hidden feature is enabled
-6 gets the stack dump
-4 measures the line frequency
-1 reads an eeprom word
0 reads a ram/rom byte
1 reads a ram/rom word
2 reads a ram/rom dword
3 reads a ram/rom float
All pokes follow the format POKE function,param1,param2
Functions span from -4 to 34.
-4 writes a float to ram, aligned, something like *(param1 & 0xFFFE) = param2
-3 writes a word to ram
-2 writes a byte to ram
-1 does nothing
0 increments CAL count
11 seems to mess with the PWM signal that compensates the precharge buffer offset - so yes, these pokes can ruin the performance of your instrument in subtle ways if misused :)
23 resets CAL count
34 resets the CPU.
All other peek and poke function codes do something, but I currently have no idea what. Many write to the EEPROM, so please don't go around calling these just to see what they do without doing a backup and checking that you can restore it.
Enjoy :)
-
I couldn't find any information apart from what's already been posted here, so I disassembled the v10 firmware, out of curiosity / entertainment.
The code is quite large and "twisted" and I can't say I understood it all, or most of it, but I specifically looked into the POKEs, PEEKs, menus and SCPI commands.
:clap: :clap:
-
Great work guys! While reading about your findings I've been pretty tempted to enable the functions in my meter, but still extremely cautious not to brick it or de-calibrate :)
I can confirm that those pokes do indeed provide "firmware" stable ways to set the flags which also work in 7-5-2 (they work by doing the same as the RAM pokes, but are much cleaner!). Also I checked the addresses in another firmware and for 10-5-2 the ram pokes were different viz:
DIAG:POKE -2,4665,1 ; recall on power up
DIAG:POKE -2,4605,1 ; temp
DIAG:POKE -2,4606,1 ; save/recall state
DIAG:POKE -2,4608,1 ; scale menus
DIAG:POKE 25,0,1
Unfortunately those POKEs probably won't work on other firmware versions, because the RAM layout would be different.
In version 10 (and maybe others) there are dedicated POKEs that enable the hidden functions:
POKE 28,0,1191 math menu -> min-max: enable sdev, pp
POKE 30,0,1191 temp menu, scpi commands
POKE 31,0,1191 menu -> scale, calc:scale
POKE 32,0,1191 resolution menu -> custom aperture
POKE 33,0,1191 system menu -> store state, recall state
To disable, poke with something other than 1191, e.g. 0
To check if a function is enabled, use
PEEK -10,index,0 where index is
1 sdev, pp
2 temp
3 scale
4 custom aperture
5 save recall
Could you perhaps consolidate, for example for the 10-05-02 revision (I've got here), the safest way to switch the hidden function on?
-
Great work guys! While reading about your findings I've been pretty tempted to enable the functions in my meter, but still extremely cautious not to brick it or de-calibrate :)
The instructions below should work with all firmware after 07-xx-yy (confirmed on 07, 10 and 11):
In version 10 (and maybe others) there are dedicated POKEs that enable the hidden functions:
POKE 28,0,1191 math menu -> min-max: enable sdev, pp
POKE 30,0,1191 temp menu, scpi commands
POKE 31,0,1191 menu -> scale, calc:scale
POKE 32,0,1191 resolution menu -> custom aperture
POKE 33,0,1191 system menu -> store state, recall state
To disable, poke with something other than 1191, e.g. 0
To check if a function is enabled, use
PEEK -10,index,0 where index is
1 sdev, pp
2 temp
3 scale
4 custom aperture
5 save recall
If you are concerned about calibration data, then this can be backed up without opening the unit by using the PEEK -1 command: https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4436983/#msg4436983 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4436983/#msg4436983)
Note that if you do corrupt it (should be very unlikely if you stick to the known safe POKE commands) then flashing it back would require opening the unit and flashing the EEPROM.
-
I just enabled all these on my unit with revision 10-05-02. No issues. Being able to set the power-on state is particularly a nice feature to have.
-
I started small and added the store state/recall state menus only, and it works!
It starts now with my config, except my lovely SYS/DISPLAY OFF setting which starts always on, it seems (I run the meter with display off all the time)..
-
have been watching with interest. but the problem i have here is....
i have early revision hardware. my firmware version is rev 06-04-01 so maybe that is too old?
-
have been watching with interest. but the problem i have here is....
i have early revision hardware. my firmware version is rev 06-04-01 so maybe that is too old?
And you may have to old unobtanium vfd display driver ic ???
-
You could try the diag:peek? -10,<option>,0 commands where option:
// 0 N/A
// 1 sdev,pp
// 2 temp
// 3 scale
// 4 custom aperture
// 5 Save state
// 6 N/A
If this works then it's likely the POKES 28-33 do as well. If you *really* want to check look for the byte sequence A704 (magic 1191) in the firmware e.g.
LANG=LC_ALL grep -oabP "\xa7\x04" firmware.bin and look for a hit in the bottom 64K; this is the POKE check. In the 07-05-02 firmware it is at 46E2. Disassemble from 1 byte before this and you'll seek the POKE table dispatch routine which uses a table + 2*( zeroth arg + 4) like this
46E1 CMP E2,#04A7; int(I2)==1191?
46E5 JNE 46EA
46E7 LDB E1,#01 ; second arg is 1191 -magic on value?
;; Arg too big?
46EC LD 1C,1E[18] // p=*(SP+1e) (orig p)
46EE LD 1C,2[1C] //1c = *(p+2) => command
// Table lookup
46F2 SUB 1C,#0FFFC ; +4
46F6 JLT 46FE ;; if <0 => -1
46F8 CMP 1C,#0025 ;
46FC JLE 4701; <=0x25 (max tbl, allowing for shift of 4)
46FE LDBSE 1C,#FF // -1
4701 ADD 1C,1C // table index
4704 LD 1C,470E[1C] ; base + 2* (zeroth arg+4)
4709 BR [1C]
-
You could also run strings on the FW binary - if it doesn't spit out a bunch of stuff like "SCALE" "TEMP" "RECALL" (I think the menu stuff is mostly grouped together) etc then you're unlikely to have the options in the FW.
-
Any hint how many digits the "scale" coeffs (gain, offset) allow? I can see in the 34420A manual the options, but without any indication on the precision of those coefficients..
-
7 digits with scale. Also you can use the custom aperture to get faster 6-digit readings than otherwise possible.
Edit: to clarify, you get 7 digits (no overrange though, so 9,999,999 count max) on both the output and the coefficients
-
I've been using PLC100 with 6digits ("slow 6digits"), getting 1x.xxx.xxx digits at 10V over serial, and doing the "scale" in double in an MCU (sending the scaled and TCed data over BT). I have to double check whether those 7digits of gain and offset give comparable results with my process, a great option when not using the MCU, however..
PS: yep, "7digits scale coeffs" are not enough to scale the above resolution, 8 would be the minimum (see an example below)..
-
7 digits with scale. Also you can use the custom aperture to get faster 6-digit readings than otherwise possible.
Edit: to clarify, you get 7 digits (no overrange though, so 9,999,999 count max) on both the output and the coefficients
The question is how you would enter those two coefficients into the meter.. How many significant digits of the "gain" and the "offset" you can enter into..
For example in my above example with 7digits, the required 0,999.994.67 would be entered as "0,999.995" (and it is not precise enough for 1uV resolution, even though it is an extreme example when talking 34401A..).
-
Sounds like you might be expecting a little much from an unofficial feature of a 30 year old 6.5 digit meter!
Won't hurt to enable it and see how you go though. Note that the first digit out of the 7 can be a 9 and you can move the decimal point (i.e. if you think of it as a base-10 float, the 7 digits is the mantissa, and you can change the exponent)
-
can i do all this peeking and poking over the rs232 serial port. or is this gpib only?
-
RS232 is fine, but I wouldn't do anything other than PEEK without confirmation that FW v6 can enable the extra features - looks like v5 doesn't have them, v7+ does, see post here: https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg3228980/#msg3228980 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg3228980/#msg3228980)
Unfortunately xdevs doesn't have a copy of FW 06-xx-yy to check - if the ROM read commands from this post work then you might be able to dump it to check (and add to the xdevs collection) though: https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4562218/#msg4562218 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4562218/#msg4562218)
-
Btw. - would be great to write a small piece of code or a small script for reading out all rom/flash content of the meter in a safe manner..
A no-brainer which will spit out the hex in a standard format without creating a risk, a quick Sunday's afternoon exercise for the experts here - the noobs like me would be thankful.. ;)
-
When playing with POKES and PEEKS it is worth making sure your meter is in calibration secured mode. The worst commands (e.g. the ones which alter the non-linear AD correction coefficient) are disabled then.
PEEKS other than -8 are safe. I think this is the complete peek list. PEEK -7 is rather interesting as it lets you read the raw count from the AD (a combination of the counts from processor, U501 and the residual AD value). Most of the transformations to turn this into a result are affine but there is a small non-linear correction which is a function of the voltage at the input to the AD. I don't totally understand the reason for this. If anyone is interested I could dig out the function from my old notes.
PEEK -12 lookup block table in ROM data using index to stored address
PEEK -11 lookup NVRAM data by block using the index to stored address
PEEK -10 hidden feature enabled?
PEEK -9 No of rows in the block table
PEEK -8 [unsecured] enable: ZERO DCV
PEEK -7 adc raw value (combination of T2 count, U501 count and residual AD) with MZ adjustment
PEEK -6 stack dump from last unexpected interrupt
PEEK -5 is there an ext interrupt pending?
PEEK -4 line freq 1 = 50Hz, 0=60Hz
PEEK -3 ROM ref values for specified block number e.g. PEEK -2, 70, 0
PEEK -2 NVRAM values at specified block number
PEEK -1, eeprom word from direct address by counting blocks read
PEEK 0, ram byte
PEEK 1, ram word
PEEK 2, ram dword
PEEK 3, ram float
[Thanks to razvan784 for filling some gaps here!]
The NVRAM storage is split into numbered blocks; the low part is for safe changes the high part is for calibration data and can only be written when unsecured. A few blocks as examples
70 count gain between T2 ticks and residual on 80C196 AD
71 non-linear correction coeff1 (quadratic)
73 non-linear correction coeff2 (cubic)
76 transform params for DC 1V range (multiplier, shift, NA, offset, ?) must be scaled for line/NPLC
-
.. If anyone is interested I could dig out the function from my old notes.
Any info on the internal working of the 34401A would be greatly appreciated!!
-
.. If anyone is interested I could dig out the function from my old notes.
Any info on the internal working of the 34401A would be greatly appreciated!!
You already have a full service manual for them, it's a good start ?
-
.. If anyone is interested I could dig out the function from my old notes.
Any info on the internal working of the 34401A would be greatly appreciated!!
You already have a full service manual for them, it's a good start ?
What info in this thread is available in the service manual?? Could you show it? :)
-
PEEK -7 is rather interesting as it lets you read the raw count from the AD (a combination of the counts from processor, U501 and the residual AD value). Most of the transformations to turn this into a result are affine but there is a small non-linear correction which is a function of the voltage at the input to the AD. I don't totally understand the reason for this. If anyone is interested I could dig out the function from my old notes.
That is interesting indeed. I'd be very grateful if you could find this valuable information.
I wonder if you tried to log both raw ADC value and result from the meter to see the relationship between those.
70 count gain between T2 ticks and residual on 80C196 AD
71 non-linear correction coeff1 (quadratic)
73 non-linear correction coeff2 (cubic)
Looking at reply 65 with example EEPROM dump, those are byte 0x70 (only single byte?) and word 0x71-0x72 and 0x73-0x74, right? How to interpret those values into the correction coefficients?
-
OK. Sorry about the length but I dug up various old notes. The service manual is helpful to a point, but it doesn't always seem right and there is a big caveat. Everything here was determined by reverse engineering. There may (will) be mistakes - I'm writing as if all is fact, just because too many "I believe that" gets annoying. For example I do not know what causes the need for the quadratic non-linear correction.
I was primarily interested in how the ADC worked on the DC volts ranges. The various measurement types are split into three classes "DC-like", "AC-like" and "time-like" (classed as 0 to 2 respectively).
The primary hardware is an integrator U402-A. The inputs are summed from (a) signal (which can be switched to ground (MZ), input amp (MC) or pre-charge DAC amplifier (PRE)) or (b) positive fixed current (from a precision voltage source through a precision resistor) (c) negative fixed current. The integrator output feeds to the channel 0 AD input on the 80C196KB. It also feeds indirectly to the ASIC. In operation at all times either the positive (b) or negative current is turned on (c) (this is not made clear, but implied from the calculation in the rundown gain calibration test (error 605). The ASIC checks the output every 2.66us and switches between positive and negative current inputs as required to drive integrator output toward 2.5V (input range is 0-5V).
While one sign (presumed +) of current is enabled, the ASIC counter counts pulses (assumed to be the clock) in a 256 state internal counter. Pulses are gated to not be counted while the opposite sign is active. Overflow from this 256 state counter feeds P2.3 (T2CLK) on the CPU (and because they are at least divided by 256 they fall within the timing requirements of this counter). The CPU for DC measurement is configured to interrupt on T2-capture, but not on internal AD done. By raising a sync pulse (positive edge) on P2.4 of the CPU, T2Capture latches the state of the T2 clock in CPU and also an internal U501 latch captures the value of the 256 state counter in the ASIC into a register mapped to RAM at 1FFA (byte). The values of both counters can the be concatenated bitwise to give a complete 24-bit count. The counter is NOT reset by this operation, the current value is copied to a separate latch (manual suggests otherwise but this wouldn't work for the long period integrations e.g. 100NPLC).
A sampling process is as follows:
Two Timer1 counts [1] before the sync pulse to latch T2 and the ASIC count, the AD in the 80C196KB triggers its AD sample and hold selecting channel 0 (output of the integrator). Because the CPU has clock of 12MHz is "fast" (err manual says fast is >6MHz) the internal AD uses a clock pre-scaler and its sample and hold time would appear to be 15 state times, with 1 state time to start the process. Thus the S+H gate closes at the same time as the count is latched. The sync also triggers a T2 count capture and subsequently a T2 capture interrupt. The handler for this interrupt assembles the complete count data and collects the internal AD result (interestingly no attempt is made to check that the conversion is complete e.g. from AD status, or AD done interrupt). Judging by a pointless left shift 15 places of 0 instruction (which is slow) the code execution path has been made sufficiently long that this is a given (although I have not been able to verify this, partly due to lack of clear data).
All measurements are differential and process is as follows:
* Settling time (200us) after selecting a new input switch
* AD start followed by sync pulse is used to record initial values
* CPU HSO timer used to implement fixed delay e.g. 15000 T1 ticks for 1PLC at 50Hz
* start AD after fixed delay
* 2 T1 ticks after AD raise SYNC
HSO control scheduled this way is accurate +/50ns. Long times > 10PLC are split up (and increments over each period summed) to avoid risks from complete 24-bit counter wrap arounds. In auto-zero mode for these long periods it appears that instead of a block of MZ and a block of MC there are alternating blocks.
Interim results are computed in long integrations (possibly to allow ranging decisions to be made more quickly?) so the actual structure is two nested measurement loops up to 10x 10x in NPLC 100 case, but the finished flag is only set when the full period has elapsed. For reference with a 50Hz supply
NPLC T1-cycles(50Hz) T1-cycles (60Hz) Inner Loop Outer Loop (wrap avoidances and MC/MZ switch)
0.02 300 300 1 1
0.2 2250 2250 1 1
1 15000 12500 1 1
10 15000 12500 10 1
100 15000 12500 10 10
The astute observer will see the T1-counts for < 1PLC are the same for both line frequencies (and the first is correct at 50Hz and the second at 60Hz). I cannot explain this other than by assuming it was decided that for < 1 full cycle the precise timing didn't matter. The longer periods which are integral multiples of the line period are exact.
To subtract two results we need to know about rundown gain. This may be standard but I don't have a reference to hand:
[BEGIN THEORY DIGRESSION]
With input voltage v, if we integrate for a time t clocks, and the count at start is c_0 and end is c_t then voltage at output of integrator V_t will be given by
V_t-V_0 = v* a *t + b*(c_t-c_0) - b(t-(c_t-c_0))
a is proportionality constant for measurement current & integrator capacitor
b is proportionality constant for the fixed voltage and resistor & integrator capacitor used in the multislope converter
So if V=V_t-V_0 is difference in integrator voltage over period
and C =c_t-c_0 is count diff
Then
V = (a*v-b)*t + 2*b*C
Or
(a*v-b)*t = 2*b*C -V = (rundown gain)*C -V
If we now apply v=0 (call this MZ for measure zero, in contrast to MC for measure client) and repeat
-b*t = (rundown gain)*C_MZ - V_MZ
So subtracting the two
a*v*t = ((rundown gain)*C_MC - V_MC) - ((rundown gain)*C_MZ - V_MZ)
From which v may be derived.
[END THEORY DIGRESSION]
Depending on the Auto-Zero setting one MZ measurement is made at the start of a block of measurements or MC and MZ alternating. For long > 10PLC measurements the alternating occurs within the measurement period after blocks of 10PLC. After disconnecting MZ, pre-charge is applied for a fixed time (busy loop) and then the pre-charge switch opened before connecting MC (and thus the input amplifier).
Rundown gain may be estimated by selecting MZ and integrating over two different time periods T_1 and T_2 obtaining internal 80C196KB AD count differences V_1 and V_2 and multislope count differences C_1 and C_2
rundown gain = (V_1*T_2 - V_2*T_1)/(T1*C_1 -T_2*C_2)
This is used to test the AD functionality, but not as part of the calibration, the NVRAM stored value is used to reduce measurements. Invalid results (e.g. same for both times) give errors 605/6. The calibration is repeated 8 times and the similarity of results checked (error 607) to ensure the difference between maximum and minimum values obtained is less than 0x100 otherwise the test fails.
For the purpose of reducing measurements the rundown gain is used as follows. It should be noted that fixed precision arithmetic is used throughout the result reduction process.
Value diff = (count diff)*(rundown gain param #70)/4 - (Ad count diff)
The divide by 4 is simply to allow the gain to be expressed in a finer increment of 0.25 rather than 1.0
So for more practical points:
You can see the gain with a SCPI peek
diag:peek? -2,70,0 (mine is 1694)
and after a measurement (e.g. a READ?) you can see the value diff
diag:peek? -7,0,0
Next stage is to turn this raw count into an expression voltage at the AD input. This is done by first an affine transformation (y=ax+b) in fixed precision arithmetic. This is expressed as
y = round((x-offset) * mult * 2^shift / 2^32)
where 0<=mult<2^32, and as usual in this form of representation to represent a factor c, the shift is chosen to be the smallest integer such that 2^shift>c
which is corrected by the mult/2^32. Two offsets are stored on each range, for front and rear terminals.
The coeffs from NVRAM must be adjusted for
a) integration time (and line period if NPLC)
b) to compensate for the non-linear adjustment at 10V input to ADC
Having thus determined a first value for the input to the ADC the non-linear correction may be applied. This has two terms one quadratic and the other cubic (effectively the cubic is a mid range correction). The graph shows the form.
The input to the adc is expressed as an integer value which is multiplied by 1e-7 to give ADC input in volts. The actual meter inputs may require further multiplication by powers of 10 to correct for input amp gain, or divider ratio. Let the true value in volts be x. The corrections are implemented in fixed point arithmetic but for the sake of comprehension we use floating point expressions:
First stage quadratic correction (in counts) = 0.10077 * nlc1 * x^2
Second stage correction (in counts) =nlc2 * x * ( 2.691209 - x^2 * 0.02712)
The two corrections are added to the ADC input count and this is the result. These fp values are approximate - because these adjustments have a granularity limited to 1 tick there seems little point in writing them out with loads of huge numbers.
It will be noted that only the first correction is significant at full scale, where with an input x=10V, the output reads 10^8 + 0.10077*nlc1*100 = 1e8+10+10*nlc1. Thus the raw multiplier from calib is corrected in presence of non-linear correction
mult = (calib mult) *(plc correction) * 1e8/ (1e8 + nlc1 * 10)
This ensures that the same calib coeffs can be used irrespective of the non-linear correction choices.
Data format
The range cal data can be extracted using diag:peek? -2, set, 0
Set numbers from lowest to highest range are
DCV 75-79
DCI 82-85
OHM 87-92
OHM4 94-99
ACV 104-108
Looking in more detail at one row, the DC 10V range is 77. On my meter (and obviously not yours as the calibration is probably different!) this is
2271461829,1,0,69,77,
The values are:
multiplier, shift left count, 0, offset front terminals, offset rear terminals
I have no idea if the 0 can be given a value, but when in use in the meter this value is replaced by NLC2 (the second global nonlinear AD correction)
These values are applicable for the longest standard integration time. They are converted via factors for NPLC and line frequency (again note the 0.02 and 0.2 NPLC have the same factors for 50 & 60Hz), I suspect this is actually wrong, but since it is < 1 cycle it doesn't really matter).
We have an affine form mult*(x-offset) applicable where x is measured over the longest integration time. If we integrate x over a fraction r<1 of the calibrated time we expect
ADC input count = mult * (x /r - offset) = (mult/r) * (x - offset*r)
This is the NPLC scaling.
mult -> mult/r
offset -> offset*r
Since r<1 this requires no shift and can be expressed as (offset multiplier)/2^32.
The multiplier by 1/r requires a 2^k term since it is greater than unity. For minimal loss of precision it is desirable to ensure that the multiplier (unsigned) has its leading 1 as close as possible to the MSB. This may be achieved by
Scaling
scaled multiplier = mult/r = 2^(shift)*mult * 2^{adjshift} * adjmult / 2^32
scaled offset = offset*r = offset * adjoffset/2^32
The adjustments are as follows
50Hz line
NPLC0.02 adjoffset 0x000d1b71, adjmult 0xa0000000 adjshift 0x3
NPLC0.2 adjoffset 0x00624dd3, adjmult 0xa6aaaaac adjshift 0xa
NPLC 1 adjoffset 0x028f5c29, adjmult 0xc8000000 adjshift 0x7
NPLC 10 adjoffset 0x1999999a, adjmult 0xa0000000 adjshift 0x4
NPLC 100 adjoffset 0xffffffff, adjmult 0x80000000 adjshift 0x1
60Hz
NPLC 0.02 adjoffset 0x000d1b71, adjmult 0xa0000000 adjshift 0x3
NPLC 0.2 adjoffset 0x00624dd3, adtmult 0xa6aaaaac adjshift 0xa
NPLC 1 adjoffset 0x02222222, adjmult 0xf0000000 adjshift 0x7
NPLC 10 adjoffset 0x15555555. adjmult 0xc0000000 adjshift 0x4
NPLC 100 adjoffset 0xd5555555, adjmult 0x9999999a adjshift 0x1
An example might help here. Suppose we wish to use the 10V DC range to measure the voltage of a 1.5V cell using the front panel using a 10NPLC sampling window. The cal data is 2271461829,1,0,69,77, and assume a 50Hz line supply.
The 10NPLC adjust is
NPLC 10 adjoffset 1999999a, adjmult a0000000 adjshift 4
New offset = round (1999999a * 69)/2^32 = round (0.1 * 69) = 7
New shift = 4 + 1 = 5 (subject to adjustment)
New multiplier = 2271461829 * a0000000 / 2^32 = 1,419,663,643.15
The binary representation of this begins 01... so to avoid precision loss we multiply by 2 and drop by one the shift
So
shift=4
multiplier = 2,839,327,286
[So basically offset is divided by 10 and mutliplier multiplied by 10 to account for the shorter integration time]
Now this meter has NLC1=27 and NLC2=4 (decimal) and as a result for a full scale AD input of +/-10V the first nonlinear correction results in a count value of 10^8 = 10^8 + NLC1*10. It should read 10^7 *10 = 10^8 so the multiplier correction required is
1e8/100,000,270
Offset = 7
Multiplier = 2,839,327,286 * 1e8/100,000,270 = 2,839,319,619
Shift =4
In the 7-5-2 firmware the coeffs used can be read out at location 15B2 and these are indeed the ones used.
Let us now reduce a reading; suppose we measure a 1.5V cell and get a raw count of 1510615 (peek -7,0,0 value).
Reading = round(2^(shift)*mult*(count - offset)/2^32) = round( 2^4 * 2,839,319,619 * ( 1510615 - 7) /2^32)
= 15,978,139
Now we must apply the non linear corrections; this suggests x = 1.5978139
first correction = round( 0.10077 * nlc1 * x^2 ) = ropund ( 0.10077*27*(1.5978139)^2) = 7
second correction = int ( nlc2 * x * ( 2.691209 - x^2 * 0.02712) ) = round (4 *(1.5978139)*(2.691209 - (1.5978139)^2*0.02712) = int (16.75) =16
Result = 15,978,139 + 7+16 =15,978,162
So voltage = 1.5978162V
To be continued maybe... pre-charge is worth a discussion
[1] A T1 count is 8 state times. One state time is two clock cycles (at 12MHz)
[2] Did anyone make it here or was it too boring?
[3] I don't have a similar doc on the 3458. Maybe someday if someone gave me one....?
-
OK. Sorry about the length but I dug up various old notes.
...
To be continued maybe... pre-charge is worth a discussion
[2] Did anyone make it here or was it too boring?
No worries about the length, and certainly also interested in pre-charge. As for [2] <- I did indeed make it, though I didn't look at the math too closely. Thanks for sharing!
-
Unbelievable math! Now, the question would be whether the standard calibration process sets all those coefficients/constants to new values, or, it sets some of them only.. I mean - it could be some coefficients/constants could be strongly hw related, thus replacing any ADC related parts on the board leads to a loss of validity of some coeffs which are only determined by the manufacturer upon final assembly (and are not subject to the user cal process)..
-
OK. Sorry about the length but I dug up various old notes. The service manual is helpful to a point, but it doesn't always seem right and there is a big caveat. Everything here was determined by reverse engineering. There may (will) be mistakes - I'm writing as if all is fact, just because too many "I believe that" gets annoying. For example I do not know what causes the need for the quadratic non-linear correction.
I was primarily interested in how the ADC worked on the DC volts ranges. The various measurement types are split into three classes "DC-like", "AC-like" and "time-like" (classed as 0 to 2 respectively).
Result = 15,978,139 + 7+16 =15,978,162
So voltage = 1.5978162V
To be continued maybe... pre-charge is worth a discussion
[1] A T1 count is 8 state times. One state time is two clock cycles (at 12MHz)
[2] Did anyone make it here or was it too boring?
[3] I don't have a similar doc on the 3458. Maybe someday if someone gave me one....?
Massive undertaking and effort...thanks :-+
So from an outsider looking in, this seems to convey the 34401A can resolve ~8 digits if accessed thru the remote, and has additional "hidden" features. Is this extra resolution repeatable within reasonable limits, as in doing ratio or difference measurements in a short time at same temperature?
From reviewing your description and other posts here, seems HP has "created" an instrument beyond the front panel accessible limits & features that has demonstrated an amazing life span, reminiscent of HP of old!!
We have an old HP Rev 05-01-01 and a AG Rev 11-05-02 (our first 6-1/2 DMMs), but neither has anything connected to the RS232 nor HP-IP ports. What would folks recommend as gaining remote access with an adapter, from Ethernet (preferred), with an intent of looking into these "enabling" features?
Anyway, thanks for the details, especially the ADC inner workings and analysis!!
Best,
-
The 34401A returns 7.5 digits (like 10.000.023, 100NPLC) when reading the data via rs232, and the last digit is not just a math "noise", as is sometimes mentioned here.. But the ADC of the meter and its 399 reference are "noisy", sure, therefore the last digit fluctuates, but you may see clearly it follows a trend with a stable source.. Thus during a "quiet" period the last digit flips +/-1 from time to time only..
EDIT: the 1uV resolution is actually the 8th digit above.
Below 10V, for example, it returns 9.999.994.6 where the 7th "4" is the last stable digit, the 8th "6" could be the math rounding noise..
-
We have an old HP Rev 05-01-01 and a AG Rev 11-05-02 (our first 6-1/2 DMMs), but neither has anything connected to the RS232 nor HP-IP ports. What would folks recommend as gaining remote access with an adapter, from Ethernet (preferred), with an intent of looking into these "enabling" features?
The 05-01-01 unit will not be able to use the new features (if you look in the FW the menu strings are absent), the 11-05-02 will work fine though (I have the same FW).
I'm not sure what the best ethernet options are (GPIB-Ethernet adapters are rather pricey), but a simple USB-RS232 cable plus a null modem adapter (must have TX/RX and DTR/DSR crossovers) will work fine if you go and turn on the appropriate options in the IO menu. You won't get maximum reading rate via RS232, but that's not an issue in the high-res modes.
-
We have an old HP Rev 05-01-01 and a AG Rev 11-05-02 (our first 6-1/2 DMMs), but neither has anything connected to the RS232 nor HP-IP ports. What would folks recommend as gaining remote access with an adapter, from Ethernet (preferred), with an intent of looking into these "enabling" features?
The 05-01-01 unit will not be able to use the new features (if you look in the FW the menu strings are absent), the 11-05-02 will work fine though (I have the same FW).
I'm not sure what the best ethernet options are (GPIB-Ethernet adapters are rather pricey), but a simple USB-RS232 cable plus a null modem adapter (must have TX/RX and DTR/DSR crossovers) will work fine if you go and turn on the appropriate options in the IO menu. You won't get maximum reading rate via RS232, but that's not an issue in the high-res modes.
In order to get a continuous stream of results via rs232 you have to enable the "talk only" mode in the HP-IB settings (do set the address 31 via front buttons). With the 9600 8N2 (you have to set in the meter too via front buttons) it works with some lower NPLCs as well. Simply open TeraTerm or other terminal app and you will see the values coming in..
-
If you're okay with polling using READ? (or setting up triggers and using INIT/FETCH) then you don't need to use the "talk only" mode and can adjust settings via SCPI as well. I suspect for most remote controlled operations using SCPI will be desirable. There is also a driver for HKJ's "TestController" software that can be used for graphing, scripting etc (though it needs updates to take advantage of the new TEMPerature measurement functions etc).
-
I've done a little testing of what new SCPI commands are available with the "upgraded" meters, here is what I came up with:
Commands with ? as a suffix are read only, all others are read/write unless noted (using ? and no arguments for read). As usual only capitalised letters are required, syntax is the same as used by HPAK in their manuals.
Math operations:
Scale math operations (only one math operation available at a time, e.g. no min/max simultaneous with SCALE):
CALCulate:FUNCtion SCALe
CALCulate:SCALe:GAIN
CALCulate:SCALe:OFFSet
Average math operation (in addition to existing):
CALCulate:AVERage:SDEViation?
CALCulate:AVERage:PTPeak?
Temperature measurment:
DIAGnostic:TEMPerature? <- read internal on-chip temperature sensor (I assume in U101-B), note that it operates relay(s) when reading it for some reason regardless of selected function
CONF? <- when in TEMP mode also returns transducer type and subtype in addition to range/resolution (range fixed as "1")
CONF:TEMPerature {TCouple|RTD|FRTD|THERmistor|DEF},{TC type, or (F)RTD alpha, or Thermistor type},{<range>|MIN|MAX|DEF},{<resolution>|MIN|MAX|DEF} <- Temperature measurement mode/transducer/subtype; no query possible, transducer DEF(ault) = last used, range is ignored
UNIT:TEMPerature {Cel|Far|K}
[SENSe]:TEMPerature:TRANsducer:TYPE {TCouple|RTD|FRTD|THERmistor|DEF} <- FRTD is 4W RTD, RTD is 2W, DEF(ault) = TC (unlike for CONF:TEMP)
[SENSe]:TEMPerature:NPLCycles {0.02|0.2|1|10|100|MINimum|MAXimum}
Thermocouple options:
[SENSe]:TEMPerature:TRANsducer:TCouple:TYPE {B|E|J|K|N|R|S|T} <- TC type
[SENSe]:TEMPerature:TRANsducer:TCouple:RJUNction {<temperature>|MIN|MAX} <- Reference junction temperature for TC, -1 to 55C range
RTD options (shared between 2W RTD and 4W RTD, either RTD or FRTD will work in SCPI command):
[SENSe]:TEMPerature:TRANsducer:RTD:TYPE {85|91} <- RTD alpha value, 0.00385 or 0.00391
[SENSe]:TEMPerature:TRANsducer:RTD:RESistance:REFerence {<R0 resistance>|MIN|MAX} <- RTD reference (25C) resistance, 4.9 - 2100 ohm range
Thermistor subtype option:
[SENSe]:TEMPerature:TRANsducer:THERMistor:TYPE {2200,5000,10000} <- Thermistor type (in ohms)
Custom aperture:
<measurement function>:APER {<aperture value>|MIN|MAX} <- On a normal 34401A this will only accept values which correspont to the standard NPLC settings. When custom aperture option is enabled, it will instead accept values anywhere in the range of 0.4ms to 2s. The NPLC option will not accept "non-standard" values - when set to a non-standard value the next highest standard value will be used instead.
I haven't managed to work out what (if any) SCPI commands control settings save/recall functionality (not critical for remote use tbh), and the custom aperture settings work a little differently compared to when set from the front-panel:
- custom apertures set manually via the front panel menu system (by selecting "custom" in the resolution menu, enabling the extra aperture time menu) will always show full 6.5digit resolution regardless of aperture time setting (which has a range of 0.4ms to 2s)
- There is no explicit "custom aperture" setting via SCPI that I found, only that you can use the <function>:APER SCPI command set it to arbitrary values (in the same 0.4ms to 2s range) after the POKE 32 upgrade
- any SCPI-set aperture that corresponds to a "normal" NPLC setting will result in the meter going back to showing the "normal" resolution, e.g. 5.5 digits for a 50Hz aperture of 20ms (1 NPLC)
- again this is probably not a big deal for remote control, as the resolution returned by SCPI behaves as it does normally (i.e. is independent of aperture time/NPLC and greater than display resolution)
I'll also be uploading a modified instrument definition for HKJ's SW to enable the Temperature functions here shortly: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/ (https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/)
Edit: Seems I spoke too soon about save/recall SCPI commands. I took a look at the 34410A manual and the following seem to work:
*RCL 0 (or another number, only 1 slot it seems) <- recall saved state
*SAV 0 (or another number as above) <- store current state
MEMory:STATe:RECall:AUTO {OFF|0|ON|1} <- turn power-up recall on/offThe other 34410A memory commands I tried didn't seem to work.
-
Most of the hidden SCPI functions are documented in the manual of the HP 34970A (see attachment).
I guess the custom aperture can be set with this:
[SENSe:]
VOLTage:DC:APERture {<time>|MIN|MAX}[,(@<ch_list>)]
VOLTage:DC:APERture? [{(@<ch_list>)|MIN|MAX}]
-
Look at that, my 34401a is reading a PT100 sensor 8)
(https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/?action=dlattach;attach=1699105;image)
This is awesome, thanks a lot guys! :)
-
THERMistor:TYPE {2200,5000,10000} <- Thermistor type (in ohms)
With what b-constant?
-
THERMistor:TYPE {2200,5000,10000} <- Thermistor type (in ohms)
With what b-constant?
That is a very good question that's rather poorly answered by HPAK, even for instruments that are meant to natively support temperature measurement. The only info I found was "44000 series" in the 34970A data sheet ("Thermistor 44004, 44007, 44006 series"), which has gotta be these: https://br.omega.com/omegaFiles/temperature/pdf/44000_THERMIS_ELEMENTS.pdf
I think a bit of testing is in order to verify it though (especially checking whether "2200 ohms" is actually 2252); I'm gonna stick with RTDs for now as I have a couple of nice 4W PT100 probes.
@Kosmic - I did indeed crib heavily from the 34970A manual - it actually also has the save/recall stuff, I just didn't get it to work first try as I didn't put a number after *SAV/*RCL. :) Note that my questions about custom aperture aren't regarding what the SCPI command is (that works similarly to the 34970A, see the end of the first code block where I put my notes), just that it's behaviour is a bit different to the front-panel option.
-
THERMistor:TYPE {2200,5000,10000} <- Thermistor type (in ohms)
With what b-constant?
.. The only info I found was "44000 series" in the 34970A data sheet ("Thermistor 44004, 44007, 44006 series")
Eeach of the above type from that series has a different beta.. :)
PS: 34410A service manual:
Probe types: 2.2 kW, 5 kW, 10 kW thermistors; 0.00385%/ºC RTD
-
@Kosmic - I did indeed crib heavily from the 34970A manual - it actually also has the save/recall stuff, I just didn't get it to work first try as I didn't put a number after *SAV/*RCL. :) Note that my questions about custom aperture aren't regarding what the SCPI command is (that works similarly to the 34970A, see the end of the first code block where I put my notes), just that it's behaviour is a bit different to the front-panel option.
Ok good good. I thought you were looking at the firmware and poking around in SCPI to find the cmds.
-
FYI - thermistor Beta calculated from the "44000 thermistor series" DS values (Steinhart-Hart):
It fits the common 3975 (2k2 and 5k) and 3695 (10k) betas at 25/85C..
-
A quick check with a multi turn trimpot set to the 25C and 85C values (from the table above) for each thermistor option suggests that imo's numbers are bang on - "2.2k" really should be 2252 ohms, and it's probably safe to assume that the 4400x thermistors are indeed the parts intended to be used.
My DMM6500 seems to have the same options (the manual calls out the same 4400x thermistor part numbers), and it applies for the KS 3446x/70 meters too (going by the datasheet at least) - are these three just what DMM manufacturers have standardised on supporting? Lucky for Omega if so!
Is a little disappointing that you don't have the option of custom R and beta on the newer meters at least (though adding that support with a script that would be relatively easy on the DMM6500).
-
FYI - thermistor Beta calculated from the "44000 thermistor series" DS values (Steinhart-Hart):
It fits the common 3975 (2k2 and 5k) and 3695 (10k) betas at 25/85C..
I confirm that my 34970A uses 10K thermistors with beta=3695 (ask how I know :palm:)
-
I enabled the temperature feature in my meter and tried with 6 random 10k NTCs off my junkbox (3+2+1 different type sets, unknown Betas). The quick test:
a) the 3 were +0.12, +0.2, +0.27C off the LM35 I've been using (+16bit adc), at ambient in open air, aprox 1cm apart, with cold 34401A
b) the 2+1 were +1..+2C off.
Btw. the RTD mode allows to dial in the R0 and alpha.
-
One mystery which I never solved was what is measurement type 9. These are the measurement modes I know about. The firmware definitely references a mode 9. The measurements are classed depending on how the measurement works so e.g. class 0 is DCV like - straight integration over a time window, class 1 is AC like - so sum of squares of measurements over short interval then sqrt (nobody really wants a straight time average of RMS values), class 2 is time/frequency which uses the AD channel 1.
The mystery mode 9 is DCV like. Maybe I forgot something obvious....or is there something else to discover?
1 DCV (class 0)
2 ACV (class 1)
3 ohm 2W (class 0)
4 ohm 4W (class 0)
5 DC A (class 0)
6 AC A (class 1)
7 frequency (class 2)
8 period (class 2)
9 unknown ?? (class 0)
10 continuity (class 0)
11 diode (class 0)
12 temp 4 wire RTD (class 0)
13 temp 2 wire RTD (class 0)
14 temp t/c (class 0)
15 temp thermistor (class 0)
-
can you compare it with the 34970 brother ???
-
Theoretically the mystery "mode 9" could be the Capacitance measurement (see the 34410A).
It works the same as the 2W resistance method - feeding a current into the capacitor, but measuring the ramp (ie. either measuring the time from V1 to V2, or, via a sampling of X DCV samples and calculating the ramp's slope..).
The available 34401A charging currents range is the same as with 34410A.
-
The question with the Capacitance measurement is how to define the starting point for the measurement, as the charging the capacitor via the 0.5uA to 1mA current source is made in time, and the optimal option is to have the capacitor discharged to zero volts. Then you simply make DCV sampling with a NPLC speed (class 0), till the voltage reaches a max voltage, or, you may do a fixed number of DCV samples within a sweep. Then you calculate the slope of the sampled voltage ramp and from that you get the capacitance. The autoranging from 1nF to 10mF (34410A) would require to alter the constant current value and perhaps NPLC before the ramp sweep to stay in an "optimal" DCV range. The question is how to discharge the capacitor, or how to define the "start" of a sweep. There is a lot of switches inside, they may use a lot of tricks..
PS: for example the const current 0.5uA charges 1nF in 20ms to 10V, while 1mA charges 10mF in 1s to 100mV (all from a discharged capacitor).
-
Sadly examining the CONF? command output on the 34410A (why didn't I think of this sooner) shows that mode 9 isn't capacitance but DC voltage ratio
CONF VOLT:DC:RAT range, res
Capacitance would have been much more useful... now I still need an HP4262/3 :-)
-
Looking at my old notes there's another interesting AC mode on these meters
diag:poke 27,0,1
enables 10kHz AC filter mode (in addition to the usual 3Hz, 20Hz and 200Hz filters) so you can select this with
det:band 10000
This works pretty much like DC measurement off the back of the RMS converter and allows very fast readings to be made (the normal ac modes include a software filter and sum of squares calculation, taking longer for the lower frequency knee). I don't have one of those nice Fluke AC calibrators like the 5200A so I'm not able to check how accurately it works (or test my bench for strength).
This mode doesn't seem persistent over power cycles, although the poke to set it does write NVRAM.
I'm sort of amused that in the 7-5-2 firmware the flag works by storing 34401 in 0x168c. I didn't notice this at first from a hex listing.
-
Here is the checksum tool posted in the past converted in python.
Gerry
-
Reviving an old thread:
now that we have this temperature measurement settings menu enabled: how do you set the 34401a for actual temperature measurements? Found myself a K type thermocouple, can set the tc type, units (kelvin, celsius etc)... so now how to actually measure temp?
-
To activate the measurement you need to set the "Temp func" to TC - note that a thermocouple needs a reference junction though, so it's a bit less useful than say a RTD, as bench DMMs typically aren't able to simulate this with an internal temperature measurement like most handhelds can. If you have a fixed reference junction e.g. in an ice bath, or by making the thermocouple to meter connections at a known temperature, then you can specify the temperature of that though.
-
Hm, not sure if I am completely in the clear here: Temp func lives in de G Menu right?
What I am wondering about: how to make the meter go to temp measurements, i.e. how do you make it display celsius or kelvin? Obviously there is no key for that on the frontpanel, but maybe there is a secret key combination?
Or do temp measurements only work over HPIB?
Wilko
-
You can do this from front panel but it's slightly non-obvious.
Menu G 1. TEMP FUNC followed by selection of the probe type should take you into temperature mode (same as CONF:TEMP over SCPI). You can select units from another of the G menus as well as parameters for the sensor.
-
Ah, thank you Alain. Non-obvious indeed.
Pictures show it now works. The 6-something degr C indication is before the ambient temp was entered into the meter, the 20-something degr C is after that was done. A quick test with a hot air soldering station gave me a quite reasonable measurement as compared to the hot air temp setting.
-
so with SCPI commands... maybe we could make a device to enter the ambient temperature over GPIB / external device? And update it every N seconds?
:-//
[edit] i suppose what i am really asking is:
well would that be worth doing, would temperature measurements on specific thermocouples actually benefit for the 6.5 digits precision of this meter? rather than using other dedicated equipment
-
subscribed
-
so with SCPI commands... maybe we could make a device to enter the ambient temperature over GPIB / external device? And update it every N seconds?
:-//
[edit] i suppose what i am really asking is:
well would that be worth doing, would temperature measurements on specific thermocouples actually benefit for the 6.5 digits precision of this meter? rather than using other dedicated equipment
Said thermocouple was, I think, something like €2,50 delivered on my door mat, from China. For some run of the mill, casual, temperature measurements that is hard to beat, assuming of course the DMM itself is already on your bench.
Wilko
-
I'd be interested if anyone could test this, but it seems on my 7-5-2 34401A the thermocouple mode is hard coded to use a 5K thermistor (as in you can change the R25 value via SCPI or front panel but it doesn't seem to have any effect on the output measurement). I'd suspect this might be a bug (but I can hardly call it a bug in an undocumented feature!). The conversion from value to temp is done via linear interpolation off a table which is more or less uniform in log(R). It seems to use a beta of around 3850. The other Rs supported should be 10K and 2K2 (at least that's what the input routine parses). The attached graph shows the transform function and a linear regression fit to show it's not using a pure beta law.
For quick reference:
SENS:TEMP:TRAN:THER:TYPE {2200,5000,10000}
view as SENS:TEMP:TRAN:THER:TYPE?
I also noticed a strange debug aid for the temp ranges
DIAG:POKE 29,0,1
Tells the meter to skip the conversion from measurement to temperature so displays the raw voltage/resistance (you could of course select a DCV or OHM mode yourself....) DIAG:POKE 29,0,0 turns it off.
-
FYI - I've spent a while messing with the new "SCALE" settings.
The GAIN and the OFFSET - the max number of digits to enter is 7 in many orders of magnitude (u,m,K,M,G), positive or negative.. Pretty handy.. :)
PS:
When the SCALE is ON, the display shows 7 digits (ie 9.999,954) and it prints out 8 digits via rs232 (ie. 9.999,9543).
BUT, It seems the new STDDEV (as well as the MIN-MAX/AVRG/P-P) calculation does not work when SCALE is ON.. >:(
-
Hello all,
I just found this interesting thread, basically because I was searching for a possibility, to read calibration data from my 34401a.
I also had a look on the revisions of my device, and I got 03-01-01, so it must be really old firmware. Will it be possible, to update it with a newer release in general and will that be possible without loosing the calibration information? If calibration gets lost, can the calibration information be restored form the read EEPROM content? I must say, I did not read all posts in this thread.
Thanks - Guido
-
Just saw this and want a marker. Definitely going to study the full thread. I love the 34401A.
Reg
-
Hello all,
I just found this interesting thread, basically because I was searching for a possibility, to read calibration data from my 34401a.
I also had a look on the revisions of my device, and I got 03-01-01, so it must be really old firmware. Will it be possible, to update it with a newer release in general and will that be possible without loosing the calibration information? If calibration gets lost, can the calibration information be restored form the read EEPROM content? I must say, I did not read all posts in this thread.
Thanks - Guido
I suspect that you are out of luck sorry - seems that later firmware will expect the updated display PCB even if you were able to put the newer FW onto the unit (see https://xdevs.com/doc/HP_Agilent_Keysight/34401A/fw/readme.txt.txt).
It may be possible to read back the cal (well, EEPROM including cal) data though if the same PEEK command works as in FW7+ (I think it was PEEK -1, but check previous posts to be sure). No guarantees though and at your own risk (I'd set cal to secure before trying).
-
yes there is a FW limit for the old unobtanium display ...
and normally you would need to reprogram one ic on the mainboard, and i think the display mcu too
there is tech notes about that ...
-
I’ve been playing around with the extended temperature settings on the 34401a. To turn on the function temperature feature you must select one of the TEMP FUNCTION options and then press ENTER. Below are all the available menu entries. Note that the entries for T/C TYPE don’t change anything, the only thermocouple type that is supported is N TYPE. Similarly, the entries for THERM TYPE also don’t change anything, the only thermistor type supported in 5 KOHM. I can’t imagine why all those options are there unless there are other memory locations that need to be entered to support them. Maybe somebody who has a version of the 34401a that supports temperature functions (that wasn’t hacked) could try out those options to see if they change anything (dimmog maybe?).
1:TEMP FUNC
THERMISTOR
4-WIRE RTD
2-WIRE RTD
T/C (Thermocouple)
2:UNITS
DEGREES C
DEGREES F
KELVIN
3:RTD TYPE
ALPHA-.00385
ALPHA-.00391
4:RTD Ro
Set OHMS
5:T/C Type (all types are treated as K TYPE no matter which you choose)
K TYPE
N TYPE
R TYPE
S TYPE
T TYPE
B TYPE
E TYPE
J TYPE
6:THERM TYPE (All types are treated as 5 KOHM no matter which you choose)
2.2 KOHM
5 KOHM
10 KOHM
7:JUNCT TEMP (Affects T/C only, usually set to ambient temperature before T/C is mounted)
Set DEGREES
Many thanks to all those who figured out how to unlock these features!
Chris
Update: These findings are only valid for 7-5-2 firmware. Later versions appear to support more thermistor and T/C options.
-
as we know the 34401a has a brother 34970a ... i think there could be remnants of this in the 34401a fw ???
-
as we know the 34401a has a brother 34970a ... i think there could be remnants of this in the 34401a fw ???
I think the 34401A fw was released/developed before 34970A.
-
10k thermistors worked fine here:
https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4662163/#msg4662163 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4662163/#msg4662163)
-
Strange... I tried both 10K and 5K thermistors and only the 5K ones worked. I even tested it with a 5K resistor to make sure. Maybe it depends on the firmware version you have. Mine is 7-5-2. It makes sense that later they would try out 10K thermistors as they are more common.
I wonder if later firmware versions actually support all the THERM TYPE and T/C TYPE options. My meter was likely built before the 34970a was introduced, and the later firmware versions were produced after.
Chris
-
you would need to put the ic in a socket and do fw updates ??
for the front panel mcu it's another thing ... between the old vfd pcb and the last iteration, there is a limit on the FW versions, you can not mix them
-
I have no need to pursue that as the most common thermocouple type (K) is supported, 5K thermistors are commonly available and the RTD support is fine. That's already more than I need. I compared them all and they came out with pretty much matching temperature readings. I was just curious about the differences between hacked firmware versions. I had the meter recently calibrated and I wouldn't want to have to recalibrate yet.
Chris
-
bookmarked
-
Agilent 34980A supports thermocouple, RTD, and thermistor sensors. For thermistors, manual states:
The instrument supports 2.2 kΩ (YSI Series 44004), 5 kΩ (YSI Series 44007), and 10 kΩ (YSI Series 44006) thermistors.
These are epoxy encapsulated thermistors. YSI catalog (2000) attached here for reference. The 10k device (44006) uses material H, the others use material B.
-
Strange... I tried both 10K and 5K thermistors and only the 5K ones worked. I even tested it with a 5K resistor to make sure. Maybe it depends on the firmware version you have. Mine is 7-5-2. It makes sense that later they would try out 10K thermistors as they are more common.
I wonder if later firmware versions actually support all the THERM TYPE and T/C TYPE options. My meter was likely built before the 34970a was introduced, and the later firmware versions were produced after.
Chris
Mine is 10-05-02.
On thermistor's material:
https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4659010/#msg4659010 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4659010/#msg4659010)
-
Well, it looks like the support for temperature sensors was limited with firmware 7-5-2 and more complete with later versions. Thanks for your feedback - i think the mystery is now resoloved :)
-
Btw.: for my 3458A, 34465A, 34970A, I also have found several cheaper precision thermistors as replacements, which all fit those (identical) R(T) tables.
I think that KEYSIGHT does not offer all those thermistor types any more, one value only, maybe, and for a horrendous price.
Frank.
-
Keysight does sell a 5K thermistor (E2308A) which has banana plugs and a steel tube probe for measuring temperatures in fluids (although that type can be used for a number of applications). The also sell 10K thermistor kits (34308A) that have just wires and bead probe ends. I think with the meters you mention they shifted to thermistor measurements for production line applications (needing small thermistors without banana plugs). You're right about the prices - they're very high!
-
iMo, Does your meter actually change anything when you switch to different THERMISTOR TYPE and TC/TYPE (assuming you have a thermocouple)? I think you can test it without needing different probes - just hook up what you have and see if readings change when you change TYPE selections. I tried that when I tested and nothing changed.
-
The 7-5-2 firmware in my 34401A definitely only supports 5K https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4732271/#msg4732271 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4732271/#msg4732271)
Interestingly the conversion from to temp is via a rather boring bisection search of a table rather than any kind of functional law. It's one of the least interesting parts of the firmware.
The AC volts is much more interesting. Someday I should type up some of my notes on how it works and what the calibration functions do.
-
iMo, Does your meter actually change anything when you switch to different THERMISTOR TYPE and TC/TYPE (assuming you have a thermocouple)? I think you can test it without needing different probes - just hook up what you have and see if readings change when you change TYPE selections. I tried that when I tested and nothing changed.
I will try later on and will report here..
A resistor 11.95k instead of the thermistor wired 2w:
Setting 6 "thermistor type":
2k2 ... -9.21degC
5k ... 6.25degC
10k ... 20.65degC
PS: when you go to the thermistor type try to mess with all < > up down arrows to switch around..
I somehow doubt the 5k is the only selection, as I would go with 10k if they asked me to tell a single value..
-
Are the calibration constants for the specific ranges somehow accessible?
My idea is to patch a single range (like +10V for example) with my new constant instead to go over the entire adjustment procedure..
-
Well this depends on what you mean. The calib constants for the DC/AC/Ohms ranges are readily accessible (see attached file cal_values which shows all the "secured" cal constants in my 34401 with some notes on what they are - base address in RAM for each constant is in the second column, but the bytes need reversing e.g. 5415 is address 1554, addresses are obviously specific to the 7-5-2 firmware). But basically as expected for most ranges an offset and multiplier. The AC notes are cryptic and really require some additional explanation.
But the temperature conversion is pretty unadjustable at least in rev 7-5-2. It performs a raw measurement using the meter as usual and then calls the table intepolation on the final result of the measurement.
You can see the raw measurement with DIAG:POKE 29,0,1 (don't expect much enligtenment, this is probably the same as selecting OHM or VOLT depending on sensor type and making a reading).
For interpolation data for a 5K sensor (Ytbl-D758.txt, really a CSV, but I cannot upload csv). This is as dumped from firmware image, but as I recall first colum is resitance in ohms * 10 and second column temp deg C * 1000. This data is hardcoded into the firmware as an interpolation table (notes suggest at 2D6F2 and 2D758 for x and y and interpolator is at 0x28A6F).
-
iMo, thanks for the response. This confirms my suspicion that firmware after 7-5-2 more thoroughly supported temperature functions.
I'm positive about the 5k thermistor issue (I tested thoroughly). It seems like an odd choice that they would have picked 5k instead of 10k, unless you consider the fact that HP was selling the E2308A thermistor at the time - which is a 5k thermistor.
In my testing I tried all the thermistor settings and they all resulted in the same (correct) results with a 5k thermistor and failed with 10k thermistors (I tried a few 10k thermistors). It appears that alan.bain discovered the same quirk.
I only have K thermocouples so I couldn't test other types, but I did discover that results for all the TYPE options resulted in the same (correct) readings with a K thermocouple.
It looks like they coded the menu options before they coded the firmware to support them all.
-
I looked up thermistor data for 2.2k, 5k, and 10k type B thermistors (which is what I think HP supported). They all have the same beta value. HP got a little lazy with the 7-5-2 firmware as all they would have had to do is scale the ohm readings for the 5k thermistor temperature table to support 2.2k and 10k thermistors.
I know this is some heavy math :), but here goes:
Table lookup OHMS = measured OHMS * 5 / thermistor TYPE KOHMS - a whopping one line of code!
in fact, source code wouldn't even have to add one line of code. Instead of table_lookup=measured_ohms, they could have changed it to table_lookup=measured_ohms*5/thermistor_type_kohms.
-
I looked up thermistor data for 2.2k, 5k, and 10k type B thermistors (which is what I think HP supported). They all have the same beta value. HP got a little lazy with the 7-5-2 firmware as all they would have had to do is scale the ohm readings for the 5k thermistor temperature table to support 2.2k and 10k thermistors.
I know this is some heavy math :), but here goes:
Table lookup OHMS = measured OHMS * 5 / thermistor TYPE KOHMS - a whopping one line of code!
in fact, source code wouldn't even have to add one line of code. Instead of table_lookup=measured_ohms, they could have changed it to table_lookup=measured_ohms*5/thermistor_type_kohms.
IMHO they do consider the "beta" of the thermistors as well.
https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4659010/#msg4659010 (https://www.eevblog.com/forum/testgear/hp-agilent-34401a-hidden-menu/msg4659010/#msg4659010)