HP 3478A: How to read/write cal SRAM

[pqass]

Specifically, the -d switch forgets to remove the end-of-line line-feed character (0x0A) before processing the line.

Hi, I got the notification on github concerning this issue, but I can't access my code and crap so I have nothing to suggest until I get back in ~2 weeks. Ping me again if you don't hear from me by then.
But if it's just a processing issue it should be trivial to patch in the meantime (I think we got the math part mostly perfect ? except maybe clamping the gain digits to [-4..+5] , I forget the details)

False alarm.  You're good.  User fed cal data with embedded new-lines ("\n") for -d.

Although, it wouldn't hurt to put warnings if data in a particular field is suspect. 
eg.  non-BCD digits appearing in raw offset, offset and gain fields without leading "4" hex nibble, should check crc behind the scene when executing -d to validate the line, etc.

[cbueche]

pqpass with your script I now get the same results, so let's assume all is good and proceed to the new battery soldering :-)
Fenugrec no worries and no stress, thanks for your great utility ! I haven't worked with C since 1991 but I think there is no bug, only a user's messing-up :-)

[cbueche]

ok I messed up I followed the instructions : soldered a 4V battery-pack + serial-diode parallel to C510, measured the tension there (had ~ 3.5V), removed the old calibration-battery, still had about 3.5V over C510 so life was good... soldered new battery in place (my soldering iron is fully-isolated and the multimeter wasn't connected to anything), life was still good... removed the backup 3V source and power-cycled the HP3478A... life wasn't that good anymore... got the infamous "Uncalibrated" error at self-test Really not sure at what step I messed up, maybe a short when desoldering or measuring on C510. Anyway. Time to see how to recover my calibration data...

I adapted my getval.py to be a "putval.py" and passed it my calibration dump, with of course the front-panel "cal" in write-mode.

Code: [Select]

#!/bin/env python3
# usage : python ./putcal.py calibration_data/hp3478_cal_dump_1.bin

import sys
import pyvisa

rm = pyvisa.ResourceManager()
dvm = rm.open_resource('GPIB::16::INSTR')

calfile = sys.argv[1]
with open(calfile, 'r') as file:
    data = file.read().replace('\n', '')

ldata = len(data)
print("got {} bytes from {}".format(ldata, calfile))
if ldata != 256:
    print("input file must be 256 bytes after filering newline chars. Now {} bytes, exit".format(ldata))
    sys.exit(1)

for addr in range(256):
    dval = data[addr]
    print("writing position {} with value {}".format(addr, dval))
    dvm.write_raw(bytes([ord('X'), addr]))
    dvm.write_raw(dval)

dvm.close()
rm.close()

After setting the front-panel "cal" to read-mode again and a power-cycle check, I get "self test ok" again I was able to read back the same calibration data using getval.py and life is good again, the saved data matches what I had at the begining of the whole trip and my HP3478A is good for the next 30 years. Time for pizza + beer

Thanks all for the help !
Charles

[pa3gyf]

Hi all,

Sorry for the likely necrobump here, but I managed to back up the calibration data of my HP-3478A mostly using the info from this thread! So big thanks!

And here's the cal data <tried but failed to get this into mono-spaced font>:

[jan@rush ~]$ hexdump pa3gyf-hp3478a-01.cal

0000000 4040 4040 4842 4140 4543 4440 484e 4040
0000010 4040 4742 4341 4f45 4d4e 4040 4040 4040
0000020 4142 4443 4045 404f 4949 4949 4549 4341
0000030 4544 4b45 494b 4949 4949 4149 4443 4c41
0000040 444b 4040 4040 4040 4040 4040 4f40 404f
0000050 4040 4543 4143 4d41 4542 4e4d 4949 4849
0000060 4349 4c41 4c43 4a4c 4948 4949 4849 4149
0000070 424c 4d4f 4f49 4949 4949 4949 4c41 4441
0000080 4a4c 494b 4949 4949 4148 4f4c 4540 494a
0000090 4949 4949 4949 4c41 4e40 4a42 494c 4949
00000a0 4949 4148 4f4c 4540 494a 4949 4949 4849
00000b0 4540 4145 4b44 404b 4040 4341 4240 4545
00000c0 454d 4d4d 4040 4040 4341 4542 4e42 4e41
00000d0 4043 4040 4040 4040 4040 4040 4f4f 4040
00000e0 4340 4345 4342 444c 4d43 404c 4040 4040
00000f0 4040 4040 4040 4f4f 4040 4040 4040 4040
0000100


73,
Jan -pa3gyf

[pqass]

Hi all,

Sorry for the likely necrobump here, but I managed to back up the calibration data of my HP-3478A mostly using the info from this thread! So big thanks!

And here's the cal data <tried but failed to get this into mono-spaced font>:

[jan@rush ~]$ hexdump pa3gyf-hp3478a-01.cal

0000000 4040 4040 4842 4140 4543 4440 484e 4040
0000010 4040 4742 4341 4f45 4d4e 4040 4040 4040
0000020 4142 4443 4045 404f 4949 4949 4549 4341
0000030 4544 4b45 494b 4949 4949 4149 4443 4c41
0000040 444b 4040 4040 4040 4040 4040 4f40 404f
0000050 4040 4543 4143 4d41 4542 4e4d 4949 4849
0000060 4349 4c41 4c43 4a4c 4948 4949 4849 4149
0000070 424c 4d4f 4f49 4949 4949 4949 4c41 4441
0000080 4a4c 494b 4949 4949 4148 4f4c 4540 494a
0000090 4949 4949 4949 4c41 4e40 4a42 494c 4949
00000a0 4949 4148 4f4c 4540 494a 4949 4949 4849
00000b0 4540 4145 4b44 404b 4040 4341 4240 4545
00000c0 454d 4d4d 4040 4040 4341 4542 4e42 4e41
00000d0 4043 4040 4040 4040 4040 4040 4f4f 4040
00000e0 4340 4345 4342 444c 4d43 404c 4040 4040
00000f0 4040 4040 4040 4f4f 4040 4040 4040 4040
0000100



73,
Jan -pa3gyf

Since you're into necro, I just want to add that I've verified each record of your cal data.


I've reconstituted the raw cal data from your hexdump output by:
1. removing the first 8 chars (address), then
2. swaping each pair in the hex quad, then
3. removing all spaces, then
4. converting each hex pair to ascii to get:

@@@@BH@ACE@DNH@@@@BGACEONM@@@@@@BACDE@O@IIIIIEACDEEKKIIIIIIACDALKD@@@@@@@@@@@OO@@@CECAAMBEMNIIIHICALCLLJHIIIIHIALBOMIOIIIIIIALADLJKIIIIIHALO@EJIIIIIIIAL@NBJLIIIIIHALO@EJIIIIIIH@EEADKK@@@AC@BEEMEMM@@@@ACBEBNANC@@@@@@@@@@@OO@@@CECBCLDCML@@@@@@@@@@@OO@@@@@@


I then fed the raw cal string into my verify.sh script (see my post #123 on the previous page):

000001 40 40 40 42 48 40 41 43 45 40 44 4e 48  >@@@BH@ACE@DNH<   00: raw_offset=000280 raw_gain=13504 offset=+000280 gain=1.013504 crc=ff  30 mV DC
00000e 40 40 40 40 42 47 41 43 45 4f 4e 4d 40  >@@@@BGACEONM@<   01: raw_offset=000027 raw_gain=135fe offset=+000023 gain=1.013488 crc=ff  300 mV DC
00001b 40 40 40 40 40 42 41 43 44 45 40 4f 40  >@@@@@BACDE@O@<   02: raw_offset=000002 raw_gain=13450 offset=+000002 gain=1.013450 crc=ff  3 V DC
000028 49 49 49 49 49 45 41 43 44 45 45 4b 4b  >IIIIIEACDEEKK<   03: raw_offset=999995 raw_gain=13455 offset=-000005 gain=1.013455 crc=ff  30 V DC
000035 49 49 49 49 49 49 41 43 44 41 4c 4b 44  >IIIIIIACDALKD<   04: raw_offset=999999 raw_gain=1341c offset=-000001 gain=1.013406 crc=ff  300 V DC
000042 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO<   05: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=ff  <not used>
00004f 40 40 40 43 45 43 41 41 4d 42 45 4d 4e  >@@@CECAAMBEMN<   06: raw_offset=000353 raw_gain=11d25 offset=+000235 gain=1.010725 crc=ff  AC V
00005c 49 49 49 48 49 43 41 4c 43 4c 4c 4a 48  >IIIHICALCLLJH<   07: raw_offset=999893 raw_gain=1c3cc offset=-000107 gain=1.006256 crc=ff  30 Ohm 2W/4W
000069 49 49 49 49 48 49 41 4c 42 4f 4d 49 4f  >IIIIHIALBOMIO<   08: raw_offset=999989 raw_gain=1c2fd offset=-000011 gain=1.006187 crc=ff  300 Ohm 2W/4W
000076 49 49 49 49 49 49 41 4c 41 44 4c 4a 4b  >IIIIIIALADLJK<   09: raw_offset=999999 raw_gain=1c14c offset=-000001 gain=1.006136 crc=ff  3 kOhm 2W/4W
000083 49 49 49 49 49 48 41 4c 4f 40 45 4a 49  >IIIIIHALO@EJI<   10: raw_offset=999998 raw_gain=1cf05 offset=-000002 gain=1.005905 crc=ff  30 kOhm 2W/4W
000090 49 49 49 49 49 49 41 4c 40 4e 42 4a 4c  >IIIIIIAL@NBJL<   11: raw_offset=999999 raw_gain=1c0e2 offset=-000001 gain=1.005982 crc=ff  300 kOhm 2W/4W
00009d 49 49 49 49 49 48 41 4c 4f 40 45 4a 49  >IIIIIHALO@EJI<   12: raw_offset=999998 raw_gain=1cf05 offset=-000002 gain=1.005905 crc=ff  3 MOhm 2W/4W
0000aa 49 49 49 49 49 48 40 45 45 41 44 4b 4b  >IIIIIH@EEADKK<   13: raw_offset=999998 raw_gain=05514 offset=-000002 gain=1.005514 crc=ff  30 MOhm 2W/4W
0000b7 40 40 40 41 43 40 42 45 45 4d 45 4d 4d  >@@@AC@BEEMEMM<   14: raw_offset=000130 raw_gain=255d5 offset=+000088 gain=1.025475 crc=ff  300 mA DC
0000c4 40 40 40 40 41 43 42 45 42 4e 41 4e 43  >@@@@ACBEBNANC<   15: raw_offset=000013 raw_gain=252e1 offset=+000011 gain=1.025181 crc=ff  3A DC
0000d1 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO<   16: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=ff  <not used>
0000de 40 40 40 43 45 43 42 43 4c 44 43 4d 4c  >@@@CECBCLDCML<   17: raw_offset=000353 raw_gain=23c43 offset=+000235 gain=1.022643 crc=ff  300 mA/3A AC
0000eb 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO<   18: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=ff  <not used>
0000f8 40 40 40 40 40 40                       >@@@@@@<   19: <padding>


CRC=ff means the record is verified.  Yay!

[bingo600]

It would be nice if someone could write a python or some other multi-platform method that implements the above in a friendly way.  There's a lot 3478A's out there.  It would make battery replacement a lot less stressful if you could back up the SRAM first and then restore it when done.  No more isolated soldering irons, etc.  Or even better, it would be good to make a backup *before* the battery goes dead.

I'm attaching a little Python script that pulls the SRAM values out and drops them to stdout. Use like this:

python cal-3478a devicename > mycal

This depends on a properly working linux-gpib setup, and devicename must be a properly configured device in /etc/gpib.conf. No multi-platform GPIB out there, as far as I know.

Thanks so much for working this out -- would hate for my 3478A to die on me. At least now I have a backup! The battery seems to be doing OK, so perhaps I don't need to replace it yet?

I needed to grab my HP 3478A calibration constants, as i soon have to change the battery.
I have adapted biot's cal-3478a to python3, used on most newer linux'es.
Script is attached as a zip file, so remember to make it executable after extracting it.
I still don't know why only tar and not tar.gz files are allowed ?

The script makes use of linux-gpib, so make sure it works first.

Edit: The zip contains the fixed version (see post below)

/Bingo


References:

Original cal-3478a (python2) here - Thnx biot
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg1182436/#msg1182436


Raspberry linux-gpip install guide (I used it on a Raspi3 running Bullseye) - Thnx MiDi
https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/msg2008349/#msg2008349

Code: [Select]

root@raspi3:~# sudo dmesg | grep -i -e gpib -e agilent
[   14.478470] usb 1-1.4: Manufacturer: Agilent Technologies, Inc.
[   14.648728] gpib_common: loading out-of-tree module taints kernel.
[   14.661207] Linux-GPIB 4.3.5 Driver
[   14.746457] agilent_82357a_gpib driver loading
[   14.748089] usbcore: registered new interface driver agilent_82357a_gpib
[   14.748122] gpib: registered agilent_82357a interface
[   15.860168] usb 1-1.4: bus 1 dev num 7 attached to gpib minor 0, agilent usb interface 0
[   15.871055] agilent_82357a_attach: attached
[  147.005668] gpib0: exiting autospoll thread
[  147.006044] agilent_82357a_detach: detached
[  147.006246] usb 1-1.4: bus 1 dev num 7 attached to gpib minor 0, agilent usb interface 0
[  147.017505] agilent_82357a_attach: attached
root@raspi3:~#


[bingo600]

Hmm ... That's a bit weird ...

I took two dual sets of backup:

One set with Win10 +
https://mesterhome.com/gpibsw/

One set with a Raspi3 (Bullseye)  + linux-gpib
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg4722449/#msg4722449

I did a compare , first "pairwise" - they matched  ... Both pairs
Then i compared a Win backup against a linux-gpib backup  .... They only matched the first part of the CalRam ... 

I prob. did a 3478 poweroff/on between the backups.

Is that CalRam used as "normal ram too ?"

Have attched the 4 images ....

Edit:
The first 128 bytes matches across platforms .. aka  on all 4 files.
The last 128 bytes matches if compared with the "other backup" taken on the same platform.
But NOT if comparing a Win vs Lin backup


Hmmm ...    - From first post in this thread

Code: [Select]

For those familiar with the 3478A, recall that the cal SRAM is 256 x 4 (NEC UDP5101L or equivalent).
So what is returned on that "GPIB Read" ... a Nibble (All 256 counts) or a Byte (HP does some magic , and presents those nibbles as bytes)

FSCK !!! - My first byte in the CalRam was 4f , this means that the guy calibrating my meter back in 15' had left Cal Write enabled ...

It looked like it was "Horisontal" , but it missed a little twist .... 



/Bingo

[pqass]

Is that CalRam used as "normal ram too ?"

Not likely since the [ground-referenced] MCU is an Intel 8039 which has 128 bytes of RAM built-in and no ROM (needs external [EP]ROM).
The only external RAM is a 256x4 which is just enough to hold 19 records (of 13 bytes each; with 3 records unused).

The first 128 bytes matches across platforms .. aka  on all 4 files.
The last 128 bytes matches if compared with the "other backup" taken on the same platform.
But NOT if comparing a Win vs Lin backup

Hmmm ...    - From first post in this thread

Code: [Select]

For those familiar with the 3478A, recall that the cal SRAM is 256 x 4 (NEC UDP5101L or equivalent).
So what is returned on that "GPIB Read" ... a Nibble (All 256 counts) or a Byte (HP does some magic , and presents those nibbles as bytes)

/Bingo

I'm not sure what's going on with the RasPi GPIB Read but since the problem appears after byte 127, it could be sign related?
Since the upper nibble doesn't exist on the bus, the MCU may just assign a fixed hex 4 to that so the byte is a valid ASCII (between '@' and 'O').

Well the good news is that the cal data from your Win10+ GPIB pull looks to be good since the CRCs are valid.
CRC=ff means the record is verified.

When I pulled my 3478 cal, I made sure I had valid CRCs before messing with the hardware.

Code: [Select]

$ ./verify.sh bingo.cal
000001 40 40 40 44 48 44 42 4f 4c 4c 44 4c 42  >@@@DHDBOLLDLB< 00: raw_offset=000484 raw_gain=2fcc4 offset=+000484 gain=1.018564 crc=ff  30 mV DC
00000e 40 40 40 40 44 45 42 4f 4e 45 4d 4c 45  >@@@@DEBONEMLE< 01: raw_offset=000045 raw_gain=2fe5d offset=+000037 gain=1.018847 crc=ff  300 mV DC
00001b 40 40 40 40 40 44 42 4e 43 45 45 4d 4e  >@@@@@DBNCEEMN< 02: raw_offset=000004 raw_gain=2e355 offset=+000004 gain=1.018355 crc=ff  3 V DC
000028 49 49 49 49 49 46 42 4e 41 40 43 4b 48  >IIIIIFBNA@CKH< 03: raw_offset=999996 raw_gain=2e103 offset=-000004 gain=1.018103 crc=ff  30 V DC
000035 40 40 40 40 40 40 42 4d 45 44 44 4e 43  >@@@@@@BMEDDNC< 04: raw_offset=000000 raw_gain=2d544 offset=+000000 gain=1.017544 crc=ff  300 V DC
000042 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 05: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
00004f 49 49 49 43 41 40 41 44 44 4d 4d 4b 4d  >IIICA@ADDMMKM< 06: raw_offset=999310 raw_gain=144dd offset=-000690 gain=1.014367 crc=ff  AC V
00005c 49 49 49 48 43 41 40 45 44 45 43 4c 47  >IIIHCA@EDECLG< 07: raw_offset=999831 raw_gain=05453 offset=-000169 gain=1.005453 crc=ff  30 Ohm 2W/4W
000069 49 49 49 49 48 42 41 4c 4e 40 4e 4a 48  >IIIIHBALN@NJH< 08: raw_offset=999982 raw_gain=1ce0e offset=-000018 gain=1.005798 crc=ff  300 Ohm 2W/4W
000076 49 49 49 49 49 49 40 45 42 41 40 4c 41  >IIIIII@EBA@LA< 09: raw_offset=999999 raw_gain=05210 offset=-000001 gain=1.005210 crc=ff  3 kOhm 2W/4W
000083 49 49 49 49 49 49 40 45 40 43 44 4b 4d  >IIIIII@E@CDKM< 10: raw_offset=999999 raw_gain=05034 offset=-000001 gain=1.005034 crc=ff  30 kOhm 2W/4W
000090 49 49 49 49 49 48 40 45 4f 41 4c 4a 49  >IIIIIH@EOALJI< 11: raw_offset=999998 raw_gain=05f1c offset=-000002 gain=1.004906 crc=ff  300 kOhm 2W/4W
00009d 49 49 49 49 49 48 40 45 4f 45 45 4a 4c  >IIIIIH@EOEEJL< 12: raw_offset=999998 raw_gain=05f55 offset=-000002 gain=1.004955 crc=ff  3 MOhm 2W/4W
0000aa 49 49 49 49 49 48 41 4c 44 41 4c 4a 4c  >IIIIIHALDALJL< 13: raw_offset=999998 raw_gain=1c41c offset=-000002 gain=1.006406 crc=ff  30 MOhm 2W/4W
0000b7 40 40 40 41 44 47 43 4e 4d 42 40 4d 43  >@@@ADGCNMB@MC< 14: raw_offset=000147 raw_gain=3ed20 offset=+000103 gain=1.027720 crc=ff  300 mA DC
0000c4 40 40 40 40 41 45 43 4e 4e 4e 4c 4c 40  >@@@@AECNNNLL@< 15: raw_offset=000015 raw_gain=3eeec offset=+000013 gain=1.027776 crc=ff  3A DC
0000d1 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 16: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
0000de 49 49 49 41 45 45 42 44 43 41 43 4c 4c  >IIIAEEBDCACLL< 17: raw_offset=999155 raw_gain=24313 offset=-000845 gain=1.024313 crc=ff  300 mA/3A AC
0000eb 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 18: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
0000f8 40 40 40 40 40 40 40 40 0a              >@@@@@@@@.< 19: <padding>
See my verify.sh script on post #123 on the previous page.

[fenugrec]

Is that CalRam used as "normal ram too ?"

No. IIRC only the first calram location is "weird"; toggled periodically by the mcu to determine whether it's write protected or not. The rest is cal records.

Since the upper nibble doesn't exist on the bus, the MCU may just assign a fixed hex 4 to that so the byte is a valid ASCII (between '@' and 'O').

That is precisely what the firmware does :
https://github.com/fenugrec/hp3478a_utils/blob/master/ROM_disasm/dc118.d48#L2805

Code: [Select]

anl p2,#0xf7 ; 14c3 - 9a f7 .w ; calRAM_CE
mov a,r6 ; 14c5 - fe ~
mov r0,a ; 14c6 - a8 (
movx a,@r0 ; 14c7 - 80 . ; read CAL!
anl a,#0xf ; 14c8 - 53 0f S.
add a,#0x40 ; 14ca - 03 40 .@
the last 3 lines: replace upper nibble with 0x40. This is why the '@' character appears so often in ascii dumps; 0 + 0x40 = '@'

[bingo600]

I found the bug 

Python3 "in it's infnite visdom" is now applying locale/character encoding Ie UTF-8 to strings.
This messes with string operations. And makes old Python2 string conversion tricks unusable 

I am NOT a python guru, so this is the way i had to change it, in order to operate on a "binary array" instead of the strings.

Code: [Select]

    #
    # Watch out !!!
    # Python3 is doing "locale/character set" conversion on strings
    # You will be BITTEN, if you use old Python2 strings
    #

    # Force a binary array by creating w. bytearray
    bytesArr = bytearray(b'\x00\x00\x00')

    gpib.timeout(devhdl, gpib.T1s)
    for addr in range(256):
        bytesArr[0] = ord('W')
        bytesArr[1] = addr
        bytesArr[2] = 10  # LF

        # The two below lines will NOT work due to the new locale conversion stuff.
        #cmd = "W" + chr(addr) + '\n'
        #gpib.write(devhdl, cmd)

        gpib.write(devhdl, bytes(bytesArr))   # Convert bytesArr back to bytes, before using it
        val = gpib.read(devhdl, 1)
        sys.stdout.buffer.write(val)

Edit: I know i could just have changed the addr part of the byte array, but the Raspi even w Python will "run circles" around the HP3478A processor.


Attached is a working Python3 - hp3478a cal readout program - It requires linux-gpib to be functional.

And my readouts on Windows and Raspi

Note:
When i took the Windows CalRam backups, i had hp3478a Calibration enabled 
This means the first byte contain 0x4f (cal enabled) , instead of 0x40 (cal disabled)

When i took the linux / Raspi CalRam backup using the new python program , i had disabled hp3478a Calibration. Making the first byte 0x40.
That is why Win and linux differs in the first byte.

/Bingo

[bingo600]

Now i get this output from hp3478util.c (attached)
https://github.com/fenugrec/hp3478a_utils

Code: [Select]

* On lnux link with -lm  : gcc -o hp3478util hp3478util.c -lm
 * And - #define WITH_GPIB 0


Code: [Select]

Raspi$ ./hp3478util -d -b hp3478a-cal-raspi3-2022022501.cal
************ hp3478util, (c) 2018-2020 fenugrec ************
entry # offset (rawgain) gain range
00 000484 2FCC4 1.018564 30 mV DC
01 000045 2FE5D 1.018847 300 mV DC
02 000004 2E355 1.018355 3 V DC
03 999996 2E103 1.018103 30 V DC
04 000000 2D544 1.017544 300 V DC
05 000000 00000 1.000000 (Not used)
06 999310 144DD 1.014367 ACV
07 999831 05453 1.005453 30 Ohm 2W/4W
08 999982 1CE0E 1.005798 300 Ohm 2W/4W
09 999999 05210 1.005210 3 KOhm 2W/4W
0A 999999 05034 1.005034 30 KOhm 2W/4W
0B 999998 05F1C 1.004906 300 KOhm 2W/4W
0C 999998 05F55 1.004955 3 MOhm 2W/4W
0D 999998 1C41C 1.006406 30 MOhm 2W/4W
0E 000147 3ED20 1.027720 300 mA DC
0F 000015 3EEEC 1.027776 3A DC
10 000000 00000 1.000000 (Not used)
11 999155 24313 1.024313 300 mA/3A AC
12 000000 00000 1.000000 (Not used)


Raspi$ ./hp3478util -t -b hp3478a-cal-raspi3-2022022501.cal
************ hp3478util, (c) 2018-2020 fenugrec ************
entry 0x00: OK (30 mV DC)
entry 0x01: OK (300 mV DC)
entry 0x02: OK (3 V DC)
entry 0x03: OK (30 V DC)
entry 0x04: OK (300 V DC)
entry 0x05 ((Not used)): bad cks (0x00) (unused entry)
entry 0x06: OK (ACV)
entry 0x07: OK (30 Ohm 2W/4W)
entry 0x08: OK (300 Ohm 2W/4W)
entry 0x09: OK (3 KOhm 2W/4W)
entry 0x0A: OK (30 KOhm 2W/4W)
entry 0x0B: OK (300 KOhm 2W/4W)
entry 0x0C: OK (3 MOhm 2W/4W)
entry 0x0D: OK (30 MOhm 2W/4W)
entry 0x0E: OK (300 mA DC)
entry 0x0F: OK (3A DC)
entry 0x10 ((Not used)): bad cks (0x00) (unused entry)
entry 0x11: OK (300 mA/3A AC)
entry 0x12 ((Not used)): bad cks (0x00) (unused entry)



[djrm]

Hello everyone,
I'm a new user of an HP3478A Multimeter, it seems to be working well though I'm keen to service it by changing caps and battery.

I have built an AR488, its working with HP3478A.exe in both Windows and Linux under Wine, I also have 'HP 3478A.exe' working in Windows only.

When I try to save the calibration using HP3478A.exe it always fails with a couple of checksum errors, the multimeter doesnt show and checksum errors in use. I think the transfer is getting corupted.

I have copied the transfered data out of the log window and massaged it to be read with hp3478a_utils to try and understand what could be the problem, with a bit of tinkering I can get all lines to have good chacksums, see diffs below.

Here is the dump before editing:

Code: [Select]

david@I7MINT:~/Github/hp3478a_utils$ ./hp3478util  -a djrm-cal.txt -t
************ hp3478util, (c) 2018-2020 fenugrec ************
entry 0x00 (30 mV DC): bad cks (0xFE)
entry 0x01: OK (300 mV DC)
entry 0x02 (3 V DC): bad cks (0x0C)
entry 0x03: OK (30 V DC)
entry 0x04: OK (300 V DC)
entry 0x05: OK ((Not used))
entry 0x06: OK (ACV)
entry 0x07: OK (30 Ohm 2W/4W)
entry 0x08: OK (300 Ohm 2W/4W)
entry 0x09: OK (3 KOhm 2W/4W)
entry 0x0A: OK (30 KOhm 2W/4W)
entry 0x0B: OK (300 KOhm 2W/4W)
entry 0x0C: OK (3 MOhm 2W/4W)
entry 0x0D: OK (30 MOhm 2W/4W)
entry 0x0E: OK (300 mA DC)
entry 0x0F: OK (3A DC)
entry 0x10: OK ((Not used))
entry 0x11: OK (300 mA/3A AC)
entry 0x12: OK ((Not used))

diff showing checksum correction, found by guesswork!


Here is the test and dump after editing the two dodgy lines.

Code: [Select]

entry 0x00: OK (30 mV DC)
entry 0x01: OK (300 mV DC)
entry 0x02: OK (3 V DC)
entry 0x03: OK (30 V DC)
entry 0x04: OK (300 V DC)
entry 0x05: OK ((Not used))
entry 0x06: OK (ACV)
entry 0x07: OK (30 Ohm 2W/4W)
entry 0x08: OK (300 Ohm 2W/4W)
entry 0x09: OK (3 KOhm 2W/4W)
entry 0x0A: OK (30 KOhm 2W/4W)
entry 0x0B: OK (300 KOhm 2W/4W)
entry 0x0C: OK (3 MOhm 2W/4W)
entry 0x0D: OK (30 MOhm 2W/4W)
entry 0x0E: OK (300 mA DC)
entry 0x0F: OK (3A DC)
entry 0x10: OK ((Not used))
entry 0x11: OK (300 mA/3A AC)
entry 0x12: OK ((Not used))


Code: [Select]

david@I7MINT:~/Github/hp3478a_utils$ ./hp3478util  -a djrm-cal2.txt -d
************ hp3478util, (c) 2018-2020 fenugrec ************
entry # offset (rawgain) gain range
00 000293 14CD5 1.013575 30 mV DC
01 000029 14C1C 1.013606 300 mV DC
02 000000 13310 1.013310 3 V DC
03 999995 14F33 1.013933 30 V DC
04 000000 14C4E 1.013638 300 V DC
05 000000 00000 1.000000 (Not used)
06 998908 15D35 1.014735 ACV
07 999603 1CE3F 1.005829 30 Ohm 2W/4W
08 999958 1CE21 1.005821 300 Ohm 2W/4W
09 999995 05524 1.005524 3 KOhm 2W/4W
0A 999995 05220 1.005220 30 KOhm 2W/4W
0B 999996 05125 1.005125 300 KOhm 2W/4W
0C 999996 053C0 1.005260 3 MOhm 2W/4W
0D 999996 1CFF1 1.005891 30 MOhm 2W/4W
0E 999974 24052 1.024052 300 mA DC
0F 999997 240FF 1.023989 3A DC
10 000000 00000 1.000000 (Not used)
11 998908 24FCE 1.023858 300 mA/3A AC
12 000000 00000 1.000000 (Not used)

My question is what could be the problem?, is it something to do with the AR488 software? I have been looking for another utility to capture the calibration data but have not found anything yet.

Any help resolving this will be greatly appreciated.
Kind regards, David.

[Kleinstein]

The AR488  is not fully at the GIPB standard when it comes to the drive strength and detection levels. So with some meters there is a chance to get borderline cases from the hardware side and thus possible bit errors.  This is more like a hardware limitation as a softwas fault. In some cases the software side may get a little better result with added delays / reduced speed.

I may need tinkering with pull-up resistors and speed settings, maybe the supply voltage.

[djrm]

.I may need tinkering with pull-up resistors and speed settings, maybe the supply voltage.

Hi & Thanks for answering,

I have tried adding delays and reducing the baudrate to 9600 without success, it seems odd to me that the error is always the same whatever I try. i.e. checksum error on first and third cal lines. I tried sending 'W' 0x00 CRLF to see if I could get an individual byte back but never received anything at all.

Kind regards, David.

[Kleinstein]

Getting the error always at the same position is indeed a bit odd.
Are other tranfers (e.g. repeated status / version reading) also getting occasional tranfer errors ?

The baud rate should be the least problem. The RS232 end of the AR488 should normally work OK - though some of the USB to UART solution can be buggy too.
At least for the receive side there should be some buffering and thus not direct link from baud rate to GPIB speed.

The weak point are the levels at the GPIB bus - AFAIK the simpel AR488 solution uses the µC pins directly and no extra drivers. This solution is borderline with some instruments.
It can be worth looking at the signal levels with a scope.

[djrm]

Getting the error always at the same position is indeed a bit odd.
Are other tranfers (e.g. repeated status / version reading) also getting occasional tranfer errors ?
...
It can be worth looking at the signal levels with a scope.

In normal use I'm getting no errors, commands are returned without any visible errors.
I'll check the signal lines with my 'scope - not sure what I'm looking for but I'll maybee see an odd looking signal line or something.
D.

[pqass]

...   I tried sending 'W' 0x00 CRLF to see if I could get an individual byte back but never received anything at all.

For a rough/baremetal read of the cal data...

Connect your terminal emulator (GTKTerm, minicom, ...) to the AR488 com port (typically at 115200-8-N-1).
Type: "++ver", enter, to confirm that your AR488 is responding.
Type: "++addr N", enter, where N is the GPIB address of the 3478A.
Type: "++read", enter, to confirm a response from the meter.
Turn on log to file.

To read a cal byte (in a fresh bash shell) type:
         "/usr/bin/echo -en "W\e\xHH\r++read\r" >>/dev/ttyUSB0"

Turn off logging in the terminal program. 
The cal byte is the first character of every log file row; ignore remaining characters to end-of-line.

If needed, to write a cal byte (after turning the "cal enable" screw on meter faceplate), type:
         "/usr/bin/echo -en "X\e\xHH\xVV\r++read\r" >>/dev/ttyUSB0"

Meaning of echo switches ("man echo" for more detail):
   \e       =ASCII escape char 1B hex (needed to tell AR488 that next byte is binary)
   \xHH  =HH is the hex of the character representing the address of the cal byte
   \xVV  =VV is the hex of the character representing the value of the cal byte
   \r        =ASCII carriage return 0D hex
  ttyUSB0 =com port where AR488 is connected (replace as appropriate for your setup).

Creating a bash script to automate calling 256 echo lines above or scraping the first character from the log file is left as an exercise for the diligent student.

[djrm]

Creating a bash script to automate calling 256 echo lines above or scraping the first character from the log file is left as an exercise for the diligent student.

Thanks, I'd been missing the escape on the address byte, I'll try again.
As for rewriting as a script, I'm not sure I'm up to that.

Just had a quick look at some signals on the 'scope. Some appear to be three state, others bit and byte pulses.
I'm not familiar with GPIB protocol, I wonder if pulseview knows about it ... it does :-)

edit, more importantly I had not been issuing any ++read commands to see the returned values!, doh

Kind regards, David.

[djrm]

Sending read cal commands by hand results in the same sequence as seen by HP3478A.exe program, I wonder if this is a true copy of what I have in the cal. I would expect the meter to show an error though.

Code: [Select]

@@@BICADLMELM : CkSum = (205 + 49) Checksum Fail.
@@@@BIADLALMF : CkSum = (214 + 41) Checksum OK.
M@@@@@ACCA@OG : CkSum = (247 + 21) Checksum Fail.


Code: [Select]

@+00.0007E-3
@+00.0007E-3
@+00.0005E-3
@+00.0004E-3
B+00.0004E-3
I+00.0007E-3
C+00.0007E-3
A+00.0004E-3
D+00.0004E-3
L+00.0006E-3
M+00.0004E-3
E+00.0007E-3
L+00.0009E-3
M+00.0009E-3
@+00.0008E-3
@+00.0013E-3
GPIB
@+00.0010E-3
@+00.0007E-3
B+00.0007E-3
I+00.0008E-3
A+00.0006E-3
D+00.0005E-3
L+00.0010E-3
A+00.0011E-3
L+00.0012E-3
M+00.0011E-3
F+00.0007E-3
M+00.0008E-3
@+00.0009E-3
@+00.0009E-3
@+00.0009E-3
@+00.0010E-3
GPIB
@+00.0011E-3
A+00.0008E-3
C+00.0005E-3
C+00.0010E-3
A+00.0009E-3
@+00.0011E-3
O+00.0009E-3
G+00.0008E-3
with ++ver every 16 bytes

The scope trace looks clean and is reaching 0 and 5V ok
D.

[pqass]

... I wonder if this is a true copy of what I have in the cal. I would expect the meter to show an error though.

If the meter boots with "SELF TEST OK" then the cal data in the battery-backed RAM is A-okay.

"M" to "N" is \x4D or \b01001101 to \x4E or \b01001110 which is 2 bits off.
"M" to "@" is \x4D or \b01001101 to \x40 or \b01000000 is 3 bits off!   Very odd!

if you call "/usr/bin/echo -en "W\e\xHH\r++read\r" >>/dev/ttyUSB0" multiple times (at the problem addresses), does it consistantly give the same bad value?  Or, does it occasionally give the correct value?

[djrm]

The bad results are consistent and repeatable, I'm going to check my AR488 wiring again.
I'm tempted to fit the LA onto the ram pins but I'm afraid I'd mess up and lose the cal completely.
If I had full confidence in the GPIB cal reading then I'd try cal writing good checksums into the device (but I won't)

I saw some discussion about newline character translation in some older GPIB firmware, but it was for another GPIB driver.

[MarkL]

...
I'm tempted to fit the LA onto the ram pins but I'm afraid I'd mess up and lose the cal completely.

Oooh... Back to basics.  There's always a risk poking at something that's working, but you can minimize the risk by not putting your probes directly on the RAM chip.  Probe the data and address lines, /RD, and the memory enable /OE1 on other chips, such as the processor and U506.  Also stay away from U515 since it is also powered by the battery when the unit is off (it holds the RAM write line high), and obviously leave the CAL switch off.

If you haven't seen it, here's some detail on how the SRAM readout was done previously:

  https://www.eevblog.com/forum/testgear/3478a-cal-ram-readout-idea/msg695908/#msg695908

If I had full confidence in the GPIB cal reading then I'd try cal writing good checksums into the device (but I won't)

That's a wise choice.

[djrm]

If you haven't seen it, here's some detail on how the SRAM readout was done previously:

Thanks, yes I spent all last night reading all the previous posts I could find including that one.

I tried another Arduino firmware with the same pin definitions but it doesn't want to read the config data at all and isn't very happy reading data from the PC programs but does at least manage it from a terminal.

I think the next step after a sleep will be to connect the LA to the GPIB lines and monitor the bus traffic

I have yet to try the special extended function GPIB firmware, I believe it is now capable of reading calibration.
D.

[lmester]

You may want to try a different AR488 firmware version and see if this fixes your problem.

I recently had users of my software getting checksum errors when they tried to read the meter calibration. I found that this was caused by problems with specific AR488 firmware versions. My program works with AR488 0.49.14 but fails with AR488 0.51.18.

[fenugrec]

Interesting...
+1 on trying different fw versions, although this is oddly specific behaviour for it to occur on the same 2 locations every time.

I'm afraid I'd mess up and lose the cal completely.

Well clearly, not *completely* - only those two ranges with questionable content. You could test writing and reading back values to the unused rows, that should be fairly harmless (unless writing somehow fails due to a bad RAM and you can't restore it, in which case you'd be hosed anyway).

diff showing checksum correction, found by guesswork!

If we're going to go that way, I'll add my own guesses :
- your correction to the 3V range (first char becomes a '@' e.g. 0x00 ) : that is probable, since it's the most significant digit. Also follows a pattern where the offset is shifted by one digit each range and very similar through those DCV ranges.
- On the 30mV range I'm not so sure that the checksum byte is corrupt.

If you're equipped to probe directly the RAM data and address lines, that will be interesting. It would be a very strange problem if the RAM is read properly on initial selftest, but not later when queried via GPIB. Have you tried triggering a selftest after a few minutes of being powered on ?