volt-nuts@lists.febo.com

Discussion of precise voltage measurement

View all threads

3458A - calibration constants coding

FS
Frank Stellmach
Sat, Nov 5, 2011 10:27 AM

Hello,

I have analysed the content of the calibration NVRAM (U132, DS1220Y).
I assume that the 253 cal constants are stored as 8 Bytes of Double
Real, because that perfectly fits into the 2k size, and because the
instruments already defines DReal as an output format.

The content of the first two constants by MEMREAD:
C06308E271D02044
C09C528491C5543B

might represent the actual Ohm and Volt calibration values, together
with their corresponding DReal translations according to IEEE-754:

40003.0920    40E38862F1A9FBE7
7.20509364    401CD2041131AB9F

One can easily see from the first 5 bytes of each DReal number, that the
first bit of each Byte of the DReal number read by MEMREAD is inverted.
The last three bytes deviate by rounding to 9 decimal places.

So I assume, that HP'encrypted' the constants, either directly in the
RAM, or during readout by MEMREAD.

This is my question: Is the content of the NVRAM, if read out on a
programmer, also encrypted as described above, or does this occur only
by the MEMREAD function?

This would make a difference for a future replacement and reprogramming
of the cal. NVRAM.

Frank

Hello, I have analysed the content of the calibration NVRAM (U132, DS1220Y). I assume that the 253 cal constants are stored as 8 Bytes of Double Real, because that perfectly fits into the 2k size, and because the instruments already defines DReal as an output format. The content of the first two constants by MEMREAD: C06308E271D02044 C09C528491C5543B might represent the actual Ohm and Volt calibration values, together with their corresponding DReal translations according to IEEE-754: 40003.0920 40E38862F1A9FBE7 7.20509364 401CD2041131AB9F One can easily see from the first 5 bytes of each DReal number, that the first bit of each Byte of the DReal number read by MEMREAD is inverted. The last three bytes deviate by rounding to 9 decimal places. So I assume, that HP'encrypted' the constants, either directly in the RAM, or during readout by MEMREAD. This is my question: Is the content of the NVRAM, if read out on a programmer, also encrypted as described above, or does this occur only by the MEMREAD function? This would make a difference for a future replacement and reprogramming of the cal. NVRAM. Frank
DC
David C. Partridge
Sat, Nov 5, 2011 11:11 AM

Just a thought, are you interpreting this with the appropriate "endian-ness" for the processor?

Regards,
David Partridge
-----Original Message-----
From: volt-nuts-bounces@febo.com [mailto:volt-nuts-bounces@febo.com] On Behalf Of Frank Stellmach
Sent: 05 November 2011 10:28
To: volt-nuts@febo.com
Subject: [volt-nuts] 3458A - calibration constants coding

:

One can easily see from the first 5 bytes of each DReal number, that the first bit of each Byte of the DReal number read by MEMREAD is inverted.
The last three bytes deviate by rounding to 9 decimal places.

So I assume, that HP'encrypted' the constants, either directly in the RAM, or during readout by MEMREAD.

:

Frank


volt-nuts mailing list -- volt-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.

Just a thought, are you interpreting this with the appropriate "endian-ness" for the processor? Regards, David Partridge -----Original Message----- From: volt-nuts-bounces@febo.com [mailto:volt-nuts-bounces@febo.com] On Behalf Of Frank Stellmach Sent: 05 November 2011 10:28 To: volt-nuts@febo.com Subject: [volt-nuts] 3458A - calibration constants coding : One can easily see from the first 5 bytes of each DReal number, that the first bit of each Byte of the DReal number read by MEMREAD is inverted. The last three bytes deviate by rounding to 9 decimal places. So I assume, that HP'encrypted' the constants, either directly in the RAM, or during readout by MEMREAD. : Frank _______________________________________________ volt-nuts mailing list -- volt-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts and follow the instructions there.
PK
Poul-Henning Kamp
Sat, Nov 5, 2011 11:34 AM

In message 4EB50F9C.7000602@freenet.de, Frank Stellmach writes:

The content of the first two constants by MEMREAD:

Which are the exact addresses you did MREAD from ?

You have understood that MREAD reads 16 bits so you should only
give it even addresses and that for the CALRAM only 8 of the 16
bits are valid ?

ID?
HP3458A
MREAD 393216
16569
MREAD 393218
-7239
MREAD 393220
-30791

Which means that the first three bytes are 0x40, 0xe3 and 0x87

"%x" % 16569

'40b9'

"%x" % (65536-7239)

'e3b9'

"%x" % (65536-30791)

'87b9'

This is my question: Is the content of the NVRAM, if read out on a
programmer, also encrypted as described above, or does this occur only
by the MEMREAD function?

There is no encryption or anything of the sort.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <4EB50F9C.7000602@freenet.de>, Frank Stellmach writes: >The content of the first two constants by MEMREAD: Which are the exact addresses you did MREAD from ? You have understood that MREAD reads 16 bits so you should only give it even addresses and that for the CALRAM only 8 of the 16 bits are valid ? ID? HP3458A MREAD 393216 16569 MREAD 393218 -7239 MREAD 393220 -30791 Which means that the first three bytes are 0x40, 0xe3 and 0x87 >>> "%x" % 16569 '40b9' >>> "%x" % (65536-7239) 'e3b9' >>> "%x" % (65536-30791) '87b9' >>> >This is my question: Is the content of the NVRAM, if read out on a >programmer, also encrypted as described above, or does this occur only >by the MEMREAD function? There is no encryption or anything of the sort. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.