HP 3478A: How to read/write cal SRAM

[fenugrec]

I've just recently found this thread.  I don't check EEVBLOG very often. Im very late geting to this party 

I know, the traffic on these forums is insane - come back after a few days, there's enough "recent posts" to fill a few pages !

Glad you managed to port the checksum code succesfully.

I've been working a bit on analyzing the firmware for these, I almost wanted to resurrect the 3-year old thread https://www.eevblog.com/forum/testgear/3478a-cal-ram-readout-idea/25/
but I don't have much to add yet. However I did add my annotated copy of the disassembly on my repo, https://github.com/fenugrec/hp3478a_utils/tree/master/ROM_disasm . I've identified GPIB code, lots of BCD arithmetic, some leads into the display code (hint : the're not saved as plain ASCII strings...).

Anyone else interested in working on the disasm ? I'm trying to accomplish two things,
- determine the format of the cal constants
- long-term : change one button function to enable relative measurements (save offset when pressed, subtract from display).

[Miti]

Nice !
can't wait to try this on my unit. In the meantime I've written a small utility that verifies checksums and dumps each cal "entry" . Not super useful yet but it's mainly a starting point for when we figure out what each cal entry does.

I was thinking, when I altered the calibration values in my meter (on purpose) to validate the write function in pigrew's program , it shows "UNCALIBRATED" for a moment but then it works. However, when you select the range that was altered, it shows the "CAL" sign. This way we can play with the calibration entries and see what ranges they affect. No risk at all now that we know how to restore it.
Moreover, reading the manual, only 15 ranges need to be calibrated (DCV 30mV, 300mV, 3V, 30V, 300V, ACV 3V, DCA 300mA, 3A, Ohms 30, 300, 3K, 30K, 300K, 3M, 30M). ACA constants are calculated using DCV, DCA and ACV, unless you want to calibrate that range.
Looking at all the dumps posted and saved from my meters, there are 3 entries that are always @@@@@@@@@@@OO so I assume they are not used and above the first row of @@@@@@@@@@@OO there are 5 entries... maybe DCV?
Just saying...

[fenugrec]

This way we can play with the calibration entries and see what ranges they affect. No risk at all now that we know how to restore it.

Agreed. It could also be done simply be setting one range on the dmm, and writing bogus entries to the cal RAM until the reading changes.

Looking at all the dumps posted and saved from my meters, there are 3 entries that are always @@@@@@@@@@@OO so I assume they are not used

Good observation, and my analysis of the firmware agrees - there are no references to those 3 entries (5, 0x10 and 0x12)

Also, there is definitely a separation between the first 6 nibbles and the last 5. Look at the "beautified" data of one of the dumps posted here (iainwhite) :

Code: [Select]

**** \dev\hp3478\hp3478a_utils\hp3478util.exe
**** (c) 2018 fenugrec
entry 00: 0 0 0 2 1 9 2 D C F D
entry 01: 0 0 0 0 2 2 2 C 4 E 2
entry 02: 0 0 0 0 0 2 2 D D D 1
entry 03: 9 9 9 9 9 5 2 D 0 D C
entry 04: 9 9 9 9 9 9 2 D 3 D 1
entry 05: 0 0 0 0 0 0 0 0 0 0 0
entry 06: 0 0 0 6 6 3 1 4 1 1 3
entry 07: 9 9 9 8 7 9 1 C C 5 1
entry 08: 9 9 9 9 8 8 0 5 3 3 0
entry 09: 9 9 9 9 9 8 1 C C 0 1
entry 0A: 9 9 9 9 9 9 0 5 4 5 D
entry 0B: 9 9 9 9 9 8 0 5 4 3 4
entry 0C: 9 9 9 9 9 9 1 C C 0 C
entry 0D: 9 9 9 9 9 9 0 5 4 2 5
entry 0E: 0 0 0 2 6 2 3 C 3 1 0
entry 0F: 0 0 0 0 2 6 3 C 5 1 5
entry 10: 0 0 0 0 0 0 0 0 0 0 0
entry 11: 0 0 0 6 6 3 2 4 2 2 3
entry 12: 0 0 0 0 0 0 0 0 0 0 0

I like to think those 999999 values are "negative BCD" numbers but I haven't made it that far in my analysis. If someone would like to help me look at the BCD arithmetic, that would be awesome. So far I've made some pretty good progress - identified GPIB, display and keypad code, as well as some of the internal comms to the floating ADC controller.

[Miti]

First 6 nibbles = Gain, next 3 = Offset, last 2 = Checksum?

[fenugrec]

First 6 nibbles = Gain, next 3 = Offset, last 2 = Checksum?

Not quite, my tool already strips the checksums - what is printed is all data.

[Miti]

Ahh, I missed that but my theory stays. For the first 5 entries the first 6 nibbles are all around zero if, as you said, 999... meas negative and the last 5 nibbles are all around  2Dxxx so one may be the offset and the other the gain. I expect the offset to be pretty close to zero.
It becomes Interesting, I may play with the numbers over the weekend.

[Miti]

OK, so I couldn't wait until the weekend and today after work I played with my "lab rat" again and check    this    out!

Cal entry #    Range
1                  30 mV DC
2                  300 mV DC
3                  3 V DC
4                  30 V DC
5                  300 V DC
6                  Not used. It doesn't even show "UNCALIBRATED" if altered, you can put your name there.
7                  All AC Volts ranges
8                  30 Ohm 2W, 4W
9                  300 Ohm 2W, 4W
10                3 KOhm 2W, 4W
11                30 KOhm 2W, 4W
12                300 KOhm 2W, 4W
13                3 MOhm 2W, 4W
14                30 MOhm 2W, 4W
15                300 mA DC
16                3A DC
17                Not used
18                300 mA and 3A AC
19                Not used

I also experimented with the constants for the 30V range. I used a 9V battery to see changes. I've attached the results. The first 6 nibbles are the offset, the next 5 are a kind of a gain and the last 2 the checksum. The checksum is an 8 bits constant made of the last two nibbles. If you add the checksum with all the nibbles in that entry, you get 255. The "gain" doesn't really do what I expected so it needs more thinking but the offset is bang on. The 999 thing is like the zero level is at 1000000 but you only see the last 6 digits. So for a positive  value of 136 you just add 136 to 1000000 and the constant is 000136. For -136, you subtract from 1000000, so  the constant is 999864. I know, it doesn't make sens... at least to me. Maybe it's a bingo moment for a software guy.
As you can see, the calibration constants are common for 2W and 4W Ohm ranges. That's why the manual says that you should calibrate in the mode that you are using it.

Checksum example:
@@@A@IADOD@MM -> hex 0 0 0 1 0 9 1 4 F 4 0 D D  Checksum = 0xDD       1+9+1+4+F+4+DD = 0xFF

[fenugrec]

OK, so I couldn't wait until the weekend and today after work I played with my "lab rat" again and check    this    out!

Awesome !! And you did a pretty thorough job, thanks for that.

Cal entry #    Range
...
17                Not used
18                300 mA and 3A AC
19                Not used...

hehe I did a double take on the unused entries but simply because you started your numbering at 1, where I used 0 !

I also experimented with the constants for the 30V range. I used a 9V battery to see changes. I've attached the results. The gain doesn't really do what I expected so it needs more thinking

Interesting - I'll see if I can find some hints in the firmware.

The 999 thing is like the zero level is at 1000000 but you only see the last 6 digits. [...]

makes sense. As I thought, this is 6 digit BCD, right, so adding 999 999 + 1 , rolls over to 0.

[Miti]

So you say the calculations are done in BCD? Looks stupid out of fashion to me...but hey...it works.

[fenugrec]

So you say the calculations are done in BCD? Looks stupid to me...

Hehe, say not stupid, but rather out of fashion. Think of the advantage : numbers are already in a format ready to be displayed, or sent over GPIB as text with minimal work. Looking at firmware disassembly it's very obvious it wasn't easy to fit all this in an 8kB ROM and get decent performance !

Pros :
- add 0x30 to each digit and you have ASCII !
- adding and subtracting is not much harder than on multi-byte base2 on these CPUs because they have special flags and opcodes to help with BCD ops
- no overhead required to convert between base 10 and 16 - save on code size but also speed (5.6Mhz clock , but throughput is IIRC closer to 1MHz)

Cons :
- mult / div probably require more code in BCD, this is beyond my experience
- ADC readings are most likely plain base2, so at least one bin-to-bcd conversion is required

[Miti]

So you say the calculations are done in BCD? Looks stupid to me...

Hehe, say not stupid, but rather out of fashion.

Sorry, I corrected it. 

Interesting, the offset constants seem to be BCD but the "gain" is in hex. Maybe all the calculations that involve mult/div are done in hex, then it comes the conversion to BCD and the offset is applied right at the end.

[fenugrec]

Interesting, the offset constants seem to be BCD but the "gain" is in hex. Maybe all the calculations that involve mult/div are done in hex, then it comes the conversion to BCD and the offset is applied right at the end.

Quite possible. Would you have time to run a few more tests ? As long as your 9V battery is stable (ideally to the last digit) that would be fine. Or maybe on one of the resistance scales, the readings will probably be even more stable .
The test would be to modify, individually, some of the the 5 "gain" digits, by + 1 and - 1. I think that would give more insight into the math used. For example these test values for the 30V range:

Code: [Select]

13F1C  (your initial gain)
23f1c
03f1c

14f1c (change just the second digit)
13e1c (change just the third)

I'd do it myself, but I'm away from my gear for a few weeks !

[EDIT]
Check it out, I updated the dump format :

Code: [Select]

# offset gain? range
00 000109 14F40 30 mV DC
01 000009 13411 300 mV DC
02 000001 134F5 3 V DC
03 999994 13F1C 30 V DC
04 999999 13FE1 300 V DC
05 000000 00000 (Not used)
06 000324 135D3 ACV
07 999977 05D30 30 Ohm 2W/4W
08 999998 04210 300 Ohm 2W/4W
09 000000 042F2 3 KOhm 2W/4W
0A 000000 04F35 30 KOhm 2W/4W
0B 999999 0403F 300 KOhm 2W/4W
0C 999999 04F0E 3 MOhm 2W/4W
0D 999999 03552 30 MOhm 2W/4W
0E 999844 2315D 300 mA DC
0F 999984 23D24 3A DC
10 000000 00000 (Not used)
11 000118 23EF1 300 mA/3A AC
12 000000 00000 (Not used)
See how the "gain" values are similar within a same mode !

[Miti]

Quite possible. Would you have time to run a few more tests ? As long as your 9V battery is stable (ideally to the last digit) that would be fine. Or maybe on one of the resistance scales, the readings will probably be even more stable .

I forgot to mention that the battery went down a bit during my experiment yesterday so for stability to the last digit I'll have to use a 3V reference that I have (a 0.02% linear regulator). Give me the values that you want to try for the 3V range.

[fenugrec]

I'll have to use a 3V reference that I have (a 0.02% linear regulator). Give me the values that you want to try for the 3V range.

Perfect ! how about

Code: [Select]

134F5 (orig value)
234F5
034F5

144F5 (2nd digit)
135F5 (3rd digit)

optional:
134E5 (4th)
134F6 (5th)
The last two (4th and 5th digits), not really necessary I think.

I'm still not sure if that 5 digit "gain" group is actually two or more separate constants - as you know, the ranges can be calibrated either using a fullscale value or 1/3 FS (1V, 10V etc..) , maybe that makes a difference on the constants.

What would be sad is if this was just a raw number/command sent to the ADC section that directly affects the conversion process, and don't really equate to a linear gain correction.

[Miti]

Here you go.
Every more significant nibble is 10 X the one before it. I would expect 16 X...or?
Regarding the calibration at FS or 1/3 FS, I don't think it needs separate variables. The gain can be calculate either way, you just need to detect the level and you loose some precision at 1/3 FS.

[fenugrec]

Here you go.

Thanks!

I ran those numbers in a spreadsheet a bit. I ran solvers with different possible linear equations (all equivalent, strictly speaking, but the solver didn't converge equally well )

• test #1 = offset + adc * (g0 + g1*gain)

Didn't go too well; poor correlation when the most significant digit of the gain changed.

• test #1b (naive) = offset + adc * gain

same thing, the gain's first digit screwed things up.

• test #2 nothing special
• test #3 = offset + adc * (gain + g0)

This is very similar to test #1 but I tried to give the solver some better initial guesses for the constants. In the end I get an almost believable correlation with these hand-tweaked numbers :

  adc = 0.0452413 (well, 452413 counts / 1E8 ; a 19-bit ADC would give max 524288 counts so this is reasonable)

  g0 = 6553600 (ho ho, = 100 * 2^16 )

the solver actually came up with g0 around 6557000 which felt too close to be a coincidence.


The numbers are a bit disappointing. Note how for some reason the 5th line is way off compared to the others !

Code: [Select]

reading theor. error
300054 300072 -17.7864747599815
303014 303037 -22.7216222800198
297093 297107 -13.8513272400014
300350 300257 92.9050785200088
300083 300084 -0.684941919986159
300051 300071 -20.0626136400388
300054 300072 -17.8317160800216

This is of course all a bunch of guesswork on my part. I can't explain how they do the unpleasant math of all that shifting and multiplying with ~19bit ADC readings + at least one internal constant + the gain correction. The answers are in the firmware but there's a lot happening in that 8kB file...

[Miti]

Do you think there's a fixed, ideal constant that is expected by design and the calibration constant correct that fixed constant?

[fenugrec]

Do you think there's a fixed, ideal constant that is expected by design and the calibration constant correct that fixed constant?

Well that's what my model indicates, and it would certainly be reasonable : they knew the actual realized gain is going to be very very close to their design gain. If they were to save the exact gain factor determined during calibration, it would need a lot of significant digits - and that's a waste of cal RAM !

In other words, if the nominal gain is supposed to be (random number) 0.54, but when calibrated it might be, say, 0.54010033. Storing that kind of number takes lots of space, unless you save just the "10033" part, knowing you have to shift then add it to the nominal 0.54 .


In other news - I was looking at some data in the firmware... Some ASCII like "UC", 0x20 (space)...

Code: [Select]

00000000   13 05 0C 06 20 14 05 13  14 20 20 20 00 55 43 20  12 01 0D 20 06 01 09 0C  20 00 55 43 20 12 0F 0D   ¶¶¶¶ ¶¶¶¶   ¶UC ¶¶¶ ¶¶¶¶ ¶UC ¶¶¶
00000020   20 06 01 09 0C 20 00 FA  FA FA FA FA FA FA FA FA  FA FA FA 00 15 0E 03 01  0C 09 02 12 01 14 05 04    ¶¶¶¶ ¶úúúúúúúúúúúú¶¶¶¶¶¶¶¶¶¶¶¶¶
00000040   00 81 04 20 0C 09 0E 0B  20 06 01 09 0C 00 81 04  20 14 05 13 14 20 06 01  09 0C 00 08 10 09 02 20   ¶¶ ¶¶¶¶ ¶¶¶¶¶¶ ¶¶¶¶ ¶¶¶¶¶¶¶¶¶
00000060   01 04 12 53 20 54 4F 00  20 20 0F 16 0C 04 20 20  00 20 20 20 20 20 20 20  20 20 20 20 20 00 13 05   ¶¶¶S TO¶  ¶¶¶¶  ¶            ¶¶¶
00000080   0C 06 20 14 05 13 14 20  0F 0B 00                                                                    ¶¶ ¶¶¶¶ ¶¶¶
But looks a bit like garbage ? well the LCD driver doesn't accept straight ASCII so they mapped A-Z starting at 0x01. Here's the actual strings :

Code: [Select]

00000000   53 45 4C 46 60 54 45 53  54 60 60 60 40 55 43 60  52 41 4D 60 46 41 49 4C  60 40 55 43 60 52 4F 4D   SELF`TEST```@UC`RAM`FAIL`@UC`ROM
00000020   60 46 41 49 4C 60 40 3A  3A 3A 3A 3A 3A 3A 3A 3A  3A 3A 3A 40 55 4E 43 41  4C 49 42 52 41 54 45 44   `FAIL`@::::::::::::@UNCALIBRATED
00000040   40 01 44 60 4C 49 4E 4B  60 46 41 49 4C 40 C1 44  60 54 45 53 54 60 46 41  49 4C 40 48 50 49 42 60   @¶D`LINK`FAIL@ÁD`TEST`FAIL@HPIB`
00000060   41 44 52 53 60 54 4F 40  60 60 4F 56 4C 44 60 60  40 60 60 60 60 60 60 60  60 60 60 60 60 40 53 45   ADRS`TO@``OVLD``@````````````@SE
00000080   4C 46 60 54 45 53 54 60  4F 4B 40                                                                    LF`TEST`OK@
cool !

[relmes]

Update 2018/04/26 - Note there was an error in the script which led to a few memory locations reporting incorrect information.  Correct script (Version 0.2) attached now but you also need to patch the GPIO6.1.ino file to tweak how it processes ESCaped input.  Many thanks to xxb for feeding back on the issue.

Patch for GPIO6.1.ino:

Code: [Select]

--- GPIB6.1.ino
+++ GPIB6.1.new.ino
@@ -226,8 +226,8 @@
   
         case CR:
         case NL:
-         // if (isesc) goto loadchar; 
-          if (isesc) { Serial.println("CR or LF inserted");goto loadchar; }
+          if (isesc) goto loadchar; 
+          //if (isesc) { Serial.println("CR or LF inserted");goto loadchar; }
           
           *comp = NULL; // replace USBeos with null
           if (gotplus == 2) {  // got a "++" at the beginnig: its a command!


The original message follows (note the outputs shown below contain errors in some values as they are from the original script

----

Has anyone had luck using an Arduino based GPIB adapter to accomplish this?

I think I have, created a rather hacked together system.

Centronics 36 Way printer cable + a Dremel got me a 24 way Centronics GPIB plug.
Added that to an Ardunio with the code from http://egirland.blogspot.co.uk/2014/03/arduino-uno-as-usb-to-gpib-controller.html

Python script used to communicate to the Arduino  attached.  (Excuse the python code - it works but isn't exactly optimal. Rename extension to .py)
Update the code to set the relevant HPIB Address and com port for your Arduino connection.
Once running you can send commands to the device or use the special command "read-sram" and it will read the sram of the HP 3478A and print the output to screen.

At present I've not got it writing the SRAM data to file or implemented anything to write it back.

Example output (from my HP 3478A):

0000000: 40 40 40 40 40 49 41 41 42 4e 40 45 4d 40 40 40   @@@@@IAABN@EM@@@
0000010: 40 40 41 47 41 42 4f 4d 41 4d 47 40 40 40 40 40   @@AGABOMAMG@@@@@
0000020: 41 41 42 4d 44 4c 4d 4e 49 49 49 40 49 45 41 43   AABMDLMNIII@IEAC
0000030: 4e 44 4f 4a 48 49 49 49 49 49 49 41 43 4d 4f 44   NDOJHIIIIIIACMOD
0000040: 4a 45 40 40 40 40 40 40 40 40 40 40 40 40 40 49   JE@@@@@@@@@@@@@I
0000050: 49 48 40 40 44 41 4e 4d 45 4d 4b 43 40 40 40 41   IH@@DANMEMKC@@@A
0000060: 40 46 41 4c 40 45 4c 4d 4a 40 40 40 40 40 49 41   @FAL@ELMJ@@@@@IA
0000070: 4c 42 41 4e 4d 48 40 40 40 40 40 40 41 4c 41 4c   LBANMH@@@@@@ALAL
0000080: 40 4e 45 40 40 40 40 40 41 41 4c 41 4d 4c 4d 47   @NE@@@@@AALAMLMG
0000090: 40 40 40 40 40 40 41 4c 4f 42 45 4d 4c 40 40 40   @@@@@@ALOBEML@@@
00000A0: 40 40 40 41 4c 42 4c 43 4e 41 40 40 40 40 40 41   @@@ALBLCNA@@@@@A
00000B0: 41 4d 40 41 4f 4e 40 49 49 49 49 43 44 42 40 44   AM@AON@IIIICDB@D
00000C0: 42 44 4c 48 49 49 49 49 49 42 42 40 45 42 40 4c   BDLHIIIIIBB@EB@L
00000D0: 47 40 40 40 40 40 40 40 40 40 40 40 40 40 49 49   G@@@@@@@@@@@@@II
00000E0: 47 48 45 42 42 4c 44 4e 41 4b 46 40 40 40 40 40   GHEBBLDNAKF@@@@@
00000F0: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40   @@@@@@@@@@@@@@@@


Output looks to in keeping with what others have so I think it is all good, but I've not tried writing data back yet.

Hope this helps.

[xbb]

Output looks to in keeping with what others have so I think it is all good, but I've not tried writing data back yet.

Thanks for your script, I tested it with an Arduino and while the output looks ok, the checksum verification with fenugrec's tool fails.

There are some more characters which require escaping (LF 10, Forward Slash 47 in my case), so I tried to just escape every character and the output now validates fine.

However you need also to remove or comment out the line 232 from GPIB6.1.ino which prints "CR or LF inserted" when you escape the CR/NL chars

Diff:

Code: [Select]

--- HP3478A-SRAM.txt    2018-04-26 00:57:24.031777400 +0200
+++ HP3478A-SRAM_2.txt  2018-04-26 00:58:02.302675400 +0200
@@ -104,10 +104,7 @@
 # This code reads the sram from HP 3478a and stores output in 2 arrays

         for addr in range(elements):
-            cmd = "W" + chr(addr)
-            # If we are at the ESC char then add again to allow it to pass through to Device
-            if addr == 27:
-               cmd = cmd + chr(addr)
+            cmd = "W" + chr(27) + chr(addr)

             ser.write(cmd +'\r\n')
             out = ser.read(1)

This is the output before:

Code: [Select]

0000000: 4c 40 40 40 43 45 47 42 4f 4d 4c 41 4c 4c 40 40   L@@@CEGBOMLALL@@
0000010: 40 40 43 45 42 4f 40 43 45 4d 4e 40 40 40 40 40   @@CEBO@CEMN@@@@@
0000020: 44 42 4f 4e 4f 42 4c 4b 49 49 49 4c 49 44 42 4f   DBONOBLKIIILIDBO
0000030: 4d 44 4d 49 4f 49 49 49 49 49 49 42 4e 45 4e 44   MDMIOIIIIIIBNEND
0000040: 4a 42 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49   JB@@@@@@@@@@@OOI
0000050: 49 48 47 40 44 42 4c 45 4f 41 4b 47 49 49 49 48   IHG@DBLEOAKGIIIH
0000060: 44 47 40 45 45 42 44 4c 41 49 49 49 49 48 45 41   DG@EEBDLAIIIIHEA
0000070: 4c 4e 4d 45 4a 41 49 49 49 49 49 48 40 45 45 43   LNMEJAIIIIIH@EEC
0000080: 45 4b 48 49 49 49 49 49 48 40 45 45 41 4e 4b 41   EKHIIIIIH@EEANKA
0000090: 49 49 49 49 49 48 40 45 43 41 4c 4b 45 49 49 49   IIIIIH@ECALKEIII
00000A0: 49 49 48 40 45 45 41 4e 4b 41 49 49 49 49 49 48   IIH@EEANKAIIIIIH
00000B0: 40 45 45 43 40 4b 4d 40 40 40 40 43 46 43 4f 45   @EEC@KM@@@@CFCOE
00000C0: 42 4c 4d 41 40 40 40 40 40 43 43 40 4d 42 42 4e   BLMA@@@@@CC@MBBN
00000D0: 48 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49 49   H@@@@@@@@@@@OOII
00000E0: 48 47 40 44 43 4d 41 45 41 4c 43 40 40 40 40 40   HG@DCMAEALC@@@@@
00000F0: 40 40 40 40 40 40 4f 4f 40 40 40 40 40 40 40 40   @@@@@@OO@@@@@@@@
And after:

Code: [Select]

0000000: 4c 40 40 40 43 45 47 42 4f 4d 45 41 4c 4c 40 40   L@@@CEGBOMEALL@@
0000010: 40 40 43 45 42 4f 40 43 45 4d 4e 40 40 40 40 40   @@CEBO@CEMN@@@@@
0000020: 44 42 4f 4e 4f 42 4c 4b 49 49 49 49 49 44 42 4f   DBONOBLKIIIIIDBO
0000030: 4d 44 4d 49 4f 49 49 49 49 49 49 42 4e 45 4e 44   MDMIOIIIIIIBNEND
0000040: 4a 42 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49   JB@@@@@@@@@@@OOI
0000050: 49 48 47 40 44 42 4c 45 4f 41 4b 47 49 49 49 48   IHG@DBLEOAKGIIIH
0000060: 44 47 40 45 45 42 44 4c 41 49 49 49 49 48 45 41   DG@EEBDLAIIIIHEA
0000070: 4c 4e 4d 45 4a 41 49 49 49 49 49 48 40 45 45 43   LNMEJAIIIIIH@EEC
0000080: 45 4b 48 49 49 49 49 49 48 40 45 45 41 4e 4b 41   EKHIIIIIH@EEANKA
0000090: 49 49 49 49 49 48 40 45 43 41 4c 4b 45 49 49 49   IIIIIH@ECALKEIII
00000A0: 49 49 48 40 45 45 41 4e 4b 41 49 49 49 49 49 48   IIH@EEANKAIIIIIH
00000B0: 40 45 45 43 40 4b 4d 40 40 40 40 43 46 43 4f 45   @EEC@KM@@@@CFCOE
00000C0: 42 4c 4d 41 40 40 40 40 40 43 43 40 4d 42 42 4e   BLMA@@@@@CC@MBBN
00000D0: 48 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49 49   H@@@@@@@@@@@OOII
00000E0: 48 47 40 44 43 4d 41 45 41 4c 43 40 40 40 40 40   HG@DCMAEALC@@@@@
00000F0: 40 40 40 40 40 40 4f 4f 40 40 40 40 40 40 40 40   @@@@@@OO@@@@@@@@

[relmes]

Thanks for your script, I tested it with an Arduino and while the output looks ok, the checksum verification with fenugrec's tool fails.

There are some more characters which require escaping (LF 10, Forward Slash 47 in my case), so I tried to just escape every character and the output now validates fine.

However you need also to remove or comment out the line 232 from GPIB6.1.ino which prints "CR or LF inserted" when you escape the CR/NL chars

You are right.  It needs to escape some other chars as well as GPOB6.1.ino processes a few chars specially.  (Namely , ESC, LF, CR and +).  You're method of just escaping all is a great idea.  Thank you - if I can I'll edit my original post to highlight the issue.

For completeness this is the patch for the GPIB6.1.ino file (swapping which goto loadchar line is commented - it needs to call loadchar just not print back to the serial):

Code: [Select]

--- GPIB6.1.ino
+++ GPIB6.1.new.ino
@@ -226,8 +226,8 @@
   
         case CR:
         case NL:
-         // if (isesc) goto loadchar; 
-          if (isesc) { Serial.println("CR or LF inserted");goto loadchar; }
+          if (isesc) goto loadchar; 
+          //if (isesc) { Serial.println("CR or LF inserted");goto loadchar; }
           
           *comp = NULL; // replace USBeos with null
           if (gotplus == 2) {  // got a "++" at the beginnig: its a command!


[sundance]

Any new insights on how the calibration SRAM data is encoded? (esp. the gain part)

[fenugrec]

Just found something hidden in plain sight : the HP Journal, 1983-02 issue, has an article about the 3478A, which is presented as the "HP-IB version of the 3468".

They mention a few things about cal :

- offset is applied to raw ADC reading, *then* gain factor is applied. Makes sense since the calibration process makes you short/zero the reading first, then test full-scale.

- They also say this about the checksums:

[...] the two constants for each function and range have parity bits associated with them so that the 3468A's microprocessor can locate single-bit errors and detect double-bit errs. The processor can correct a single-bit error in a cal constant and the instrument will remain calibrated. If the processor detects more than a single-bit error, the CAL annun is displayed and the error bits are set [...]

Interesting, but I wonder if at some point they removed parity-correction; either that or it's pretty well hidden in the disasm...

[Miti]

I wonder what's the meter showing during calibration. Is it showing the raw numbers? If yes, maybe it's worth calibrating a range, 3V DC range for example, now that we know which is which, and see how the raw numbers correlate with the calibration constant.

[fenugrec]

see how the raw numbers correlate with the calibration constant.

That won't be necessary ! Just finished figuring out the gain constants, with the help of partial MAME emulation.

My cal dumper produces output like this for each range :

Code: [Select]

entry # offset  gain?   range
00      000368  3EDC5   30 mV DC
The offset is BCD, we knew this. I thought the gain was an actual hex value, but not quite - it's a weird mix of signed hex digits and decimal scaling  (...) I'll try to explain.

1) ADC gives a raw, 8-digit packed BCD reading (4 bytes). (ex.: 1021520, 1 021 520). This is sign-extended into 5 bytes. I'm not sure the lowest digit is significant or always 0.

2) Add offset : pregain = ADC + cal_offset * 10 == ADC + 3680 == 1 025 200

2.5) not sure exactly why , but it seems we add 50 here. Maybe for rounding ? 1 025 250

3) then we need the gain factor "gain_const". In the cal dump, it's printed as "3EDC5" and must be interpreted this way :

Code: [Select]

get digit_n as hex;
if digit_n > 8, then factor_n =  digit_n - 16

gain_const = 1 + (digit_1 / 100) + (digit_2 / 1000) + ... (digit_5 / 1E6);
So for the example above "3EDC5", we have

Code: [Select]

gain_const = 1 + (3 / 100) + (-2 / 1000) + (-3 / 1E4) + (-4 / 1E5) + (5 / 1E6);
gain_const = 1.027665


4) display_raw = pregain * gain_const , so 1 053 614. Well, simulation gives 1 053 610, but rounding / trunction, so yeah.
5) display = display_raw / 10 and/or adjust decimal point. I lost track of the number of trailing 0's !

And, that's pretty much all there is to it.