Post Reply 
3421A CAL RAM
04-05-2017, 12:08 AM
Post: #21
RE: 3421A CAL RAM
(04-03-2017 02:17 AM)Dave Frederickson Wrote:  Here you go.

Thanks! I'll just cut that image out of my laptop LCD display and paste it on the bottom. :-)
Find all posts by this user
Quote this message in a reply
04-05-2017, 03:36 AM
Post: #22
RE: 3421A CAL RAM
Thanks very much for the software update, J-F!

(I did try "ENTER" immediately after the B2 command, but when I got a reading back I incorrectly assumed that command itself did some kind of reset on pending data. Thanks for the information.)

Dave: Yes, standard procedure :-)
Find all posts by this user
Quote this message in a reply
04-05-2017, 07:13 PM
Post: #23
RE: 3421A CAL RAM
(04-04-2017 08:38 PM)J-F Garnier Wrote:  I just corrected this aspect in ILCtrl v1.04 on my site. Now the calibration data can be read easily with a couple of keystroke in ILCtrl (ok, this is much less fun than setting a HP41 system up :-)

Worked perfectly, thanks!
Find all posts by this user
Quote this message in a reply
04-05-2017, 07:45 PM
Post: #24
RE: 3421A CAL RAM
(04-04-2017 05:16 PM)Dave Frederickson Wrote:  ... I loaded the CAL RAM with zeros (all @ characters) using the B3 command, ...

Which syntax did you use exactly with the B3 command? OUTPUT 1;"B3" then OUTPUT 1;A$ or OUTPUT 1,"B3"&A$ in one go?
That is: must the "B3" be terminated by CR/LF or must the 255 bytes immediately follow the "B3" string?
And must the last byte be sent as a HPIL END byte, as for the B2 read?

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
04-05-2017, 07:53 PM (This post was last modified: 04-05-2017 07:56 PM by Dave Frederickson.)
Post: #25
RE: 3421A CAL RAM
(04-05-2017 07:45 PM)J-F Garnier Wrote:  
(04-04-2017 05:16 PM)Dave Frederickson Wrote:  ... I loaded the CAL RAM with zeros (all @ characters) using the B3 command, ...

Which syntax did you use exactly with the B3 command? OUTPUT 1;"B3" then OUTPUT 1;A$ or OUTPUT 1,"B3"&A$ in one go?
That is: must the "B3" be terminated by CR/LF or must the 255 bytes immediately follow the "B3" string?
And must the last byte be sent as a HPIL END byte, as for the B2 read?

J-F

Hi J-F,

It was sent in one command, OUTPUT :1;"B3"&A$. The last nibble was also 0x40.

I also loaded Paul's data, unmodified, and it cleared my Cal RAM error.

Note, MarkL at EEVBlog has observed that the first nibble indicates the state of the Cal Enable switch. 0x40 = Disabled and 0x4F = Enabled.
http://www.eevblog.com/forum/repair/hp-3...-cal-sram/

Dave
Find all posts by this user
Quote this message in a reply
04-12-2017, 04:45 AM (This post was last modified: 04-12-2017 04:50 AM by Dave Frederickson.)
Post: #26
RE: 3421A CAL RAM
To restore the 3421A CAL RAM to default values, perform the following:

1. Configure the 3421A as the first device on the loop, Address :1
2. Turn on the 3421A
3. Turn on the 71B
4. Set the Cal Enable switch DOWN
5. Run the following program
Code:
10 DIM C$[256] @ C$=""
20 RESTORE IO 
30 OUTPUT :1 ;"RS"
40 FOR K=1 TO 16 @ READ D$ @ C$=C$&D$ @ NEXT K
50 OUTPUT :1 ;"CAL2";CHR$(13);
60 OUTPUT :1 ;C$;
100 DATA "@@@@@@@@@@@@@@@@"
110 DATA "@@@@@@@@@@@@OOOO"
120 DATA "@@@@@@@@@@@@OOOO"
130 DATA "@@@@@@@@@@@@OOOO"
140 DATA "@@@@@@@@@@@@OOOO"
150 DATA "@@@@@@@@@@@@OOOO"
160 DATA "@@@@@@@@@@@@OOOO"
170 DATA "@@@@@@@@@@@@OOOO"
180 DATA "@@@@@@@@@@@@OOOO"
190 DATA "@@@@@@@@@@@@OOOO"
200 DATA "@@@@@@@@@@@@OOOO"
210 DATA "@@@@@@@@@@@@OOOO"
220 DATA "@@@@@@@@@@@@OOOO"
230 DATA "@@@@@@@@@@@@OOOO"
240 DATA "@@@@@@@@@@@@OOOO"
250 DATA "OOOOOOOOOOOOOOOO"
6. Set the Cal Enable switch UP
7. Cycle power

From J-F's data I guessed that the default parameters are zeros with a checksum of 0xFFFF.

Run RCAL3421
0000000000000000
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
000000000000FFFF
FFFFFFFFFFFFFFFF


The DATA statements can be populated with the existing calibration parameters from the program in Post #16.
http://hpmuseum.org/forum/thread-8061-po...l#pid71121

An old CAL RAM battery can now be changed and the parameters restored without having to connect an external battery or apply AC power.

Dave
Find all posts by this user
Quote this message in a reply
01-31-2018, 11:19 PM
Post: #27
RE: 3421A CAL RAM
Hi there!
I recently bought an HP 3421. I made the Pilbox and I am trying to save the cal data. I am kind of new to hp programming language and I am struggling to do it. I am able to send and receive simple commands (like measuring voltage or resistance) but I don't now if i'm doing the correct procedure to read the cal data.
Jeff's version of ILCtrl (v1.04) doesn't recognize my pilbox so I'm using Cristoph ILCtrl v1.17.
I put B2 in "Data" and press "Send". Then I erased B2 and press "Enter" but I'm only getting a bunch of 8s (-8.88888E+8 to be precise)
Am I doing it wrong?
I would appreciate a "for dummines" version of the precedure.
Thanks and sorry for my broken english
Find all posts by this user
Quote this message in a reply
02-01-2018, 01:28 AM
Post: #28
RE: 3421A CAL RAM
(01-31-2018 11:19 PM)juani_cer Wrote:  Hi there!
I recently bought an HP 3421. I made the Pilbox and I am trying to save the cal data. I am kind of new to hp programming language and I am struggling to do it. I am able to send and receive simple commands (like measuring voltage or resistance) but I don't now if i'm doing the correct procedure to read the cal data.
Jeff's version of ILCtrl (v1.04) doesn't recognize my pilbox so I'm using Cristoph ILCtrl v1.17.
I put B2 in "Data" and press "Send". Then I erased B2 and press "Enter" but I'm only getting a bunch of 8s (-8.88888E+8 to be precise)
Am I doing it wrong?
I would appreciate a "for dummines" version of the precedure.
Thanks and sorry for my broken english

B2 is the command to read the cal data from the 3468 DMM and CAL1 is the command to read the data from the 3421A. See the programs in this post.

http://www.hpmuseum.org/forum/thread-806...l#pid71121

Dave
Find all posts by this user
Quote this message in a reply
02-01-2018, 08:45 AM
Post: #29
RE: 3421A CAL RAM
(01-31-2018 11:19 PM)juani_cer Wrote:  Jeff's version of ILCtrl (v1.04) doesn't recognize my pilbox so I'm using Cristoph ILCtrl v1.17.

I'm pretty sure ILCtrl 1.04 works with the PIL-Box :-)
Note however that, contrary to Christoph ILCtrl v1.17, my VB version doesn't include auto com speed, so you have to manually set the right speed 115k/230k (the PIL-Box is normally delivered configured as 115k - JP2 jumper installed).
But of course, it's even better to use Christoph's version :-)

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
02-01-2018, 11:46 PM (This post was last modified: 02-02-2018 01:31 AM by juani_cer.)
Post: #30
RE: 3421A CAL RAM
(02-01-2018 01:28 AM)Dave Frederickson Wrote:  B2 is the command to read the cal data from the 3468 DMM and CAL1 is the command to read the data from the 3421A. See the programs in this post.

Thanks Dave!
In the first post of the thread you clearly said which command to use. I completely misread the whole thing Sad

(02-01-2018 08:45 AM)J-F Garnier Wrote:  I'm pretty sure ILCtrl 1.04 works with the PIL-Box :-)

Hi Jeff!
I didn't put JP2. it worked flawlessly after that. My bad...
I made a diy PIL-Box. Let me thank you for all your work and for share it. I really appreciate it.
Find all posts by this user
Quote this message in a reply
04-25-2019, 05:24 AM
Post: #31
RE: 3421A CAL RAM
(04-04-2017 05:16 PM)Dave Frederickson Wrote:  Here's what I've learned about the cal data for the 3468.
...
It looks like the first 7 nibbles in each row are the Zero, the next 5 the Gain, and the last 4 the checksums.

Dave, thanks for working this out. Did you investigate further?

I've been staring at the hexdumps for a little while, the 9999s jump out at me. Maybe an artifact of the parity algorithm? Assuming you are correct about the nibbles, from my 3468B:
Code:
RRRR YYYYYYY GGGGG SSSS

     0000000 00000 ffff
0.3v 9999974 f5d05 1968
3v   9999998 f45de fa53
30v  0000004 f43c2 fd58
300v 0000000 f4024 f2d0
acv  0000240 f3b2f 95eb
300r 0000000 01e11 f0c3
3kr  0000000 01cd5 fad7
30kr 0000000 002b5 f3e7
300k 0000000 00121 fde0
3Mr  0000000 0005c f6ff
30M  0000000 012ee fcc3
3A   0000016 02d04 e2cf
     0000000 00000 ffff
...
     0000000 00000 000
Find all posts by this user
Quote this message in a reply
04-25-2019, 08:44 PM
Post: #32
RE: 3421A CAL RAM
(04-25-2019 05:24 AM)djd328 Wrote:  Did you investigate further?

I've been staring at the hexdumps for a little while, the 9999s jump out at me. Maybe an artifact of the parity algorithm? Assuming you are correct about the nibbles, from my 3468B:

No I did not. Once I was able to save, restore, and reset the CAL RAM data I concluded my investigation.

Regarding the 9's, like your YYYYYYY value for the 3v range, I would think that would be a negative offset from zero.

Dave
Find all posts by this user
Quote this message in a reply
04-26-2019, 02:56 AM
Post: #33
RE: 3421A CAL RAM
(04-25-2019 08:44 PM)Dave Frederickson Wrote:  
(04-25-2019 05:24 AM)djd328 Wrote:  Did you investigate further?

No I did not. Once I was able to save, restore, and reset the CAL RAM data I concluded my investigation.

Regarding the 9's, like your YYYYYYY value for the 3v range, I would think that would be a negative offset from zero.

Dave

Ok understood, it's an interesting problem, but yes I've got my constants and can reload them... the only reason to care is if I want to manually tune them (and I do have a reason to do that, but that's for another time).

9s... Yes, that seems plausible, but then 999 = 100110011001is a lot of sign bits! One parity bit and one sign bit? I think it's pretty likely that those are -ve numbers, but it's not straight sign/mag or 2's compliment. Nibble cells seem also encoded, with error detect correct code probably not limited to the 4 nibbles at the end of each row.
Find all posts by this user
Quote this message in a reply
04-26-2019, 03:17 AM
Post: #34
RE: 3421A CAL RAM
(04-25-2019 08:44 PM)Dave Frederickson Wrote:  Regarding the 9's, like your YYYYYYY value for the 3v range, I would think that would be a negative offset from zero.

Ah, looking at other posts with cal constant sets, the Y intercept field is surely just BCD encoded. Didn't see that before, simple enough, yes those are trivially interpreted -ve numbers.
Find all posts by this user
Quote this message in a reply
05-14-2019, 06:53 AM
Post: #35
RE: 3421A CAL RAM
(04-26-2019 03:17 AM)djd328 Wrote:  Ah, looking at other posts with cal constant sets, the Y intercept field is surely just BCD encoded. Didn't see that before, simple enough, yes those are trivially interpreted -ve numbers.

Building on the work of fenugrec, here is a simple decoder for 3468, minus the checksum which is different. I have managed to get the first 2 nibbles of that almost disentangled... simple xor sum mostly is correct, but there is a carry or something missing. The second 2 nibbles, not yet. Anyway:

Code:

MacPro$ cat hp3468B/hp3468B.cal.good
@@@@@@@@@@@@OOOOIIIIIGDOEM@EAIFHIIIIIIHODEMNOJEC@@@@@@DODCLBOMEH@@@@@@@OD@BDOBM@​@@@@BD@OCKBOIENK@@@@@@@@ANAAO@LC@@@@@@@@ALMEOJMG@@@@@@@@@BKEOCNG@@@@@@@@@ABAOMN@​@@@@@@@@@@ELOFOO@@@@@@@@ABNNOLLC@@@@@AF@BM@DNBLO@@@@@@@@@@@@OOOO@@@@@@@@@@@@OOOO​@@@@@@@@@@@@@@@
MacPro$
MacPro$ gcc cal.c -o cal ; ./cal < hp3468B/hp3468B.cal.good
RRRR YYYYYYY GGGGG SSSS  Offset  Gain

     0000000 00000 ffff  0000000 1.00000000
0.3v 9999974 f5d05 1968 -0000025 0.99470502
  3v 9999998 f45de fa53 -0000001 0.99446803
 30v 0000004 f43c2 fd58  0000004 0.99426204
300v 0000000 f4024 f2d0  0000000 0.99402404
 acv 0000240 f3b2f 95eb  0000240 0.99251902
300r 0000000 01e11 f0c3  0000000 1.00081098
 3kr 0000000 01cd5 fad7  0000000 1.00057507
30kr 0000000 002b5 f3e7  0000000 1.00015509
300k 0000000 00121 fde0  0000000 1.00012100
  3M 0000000 0005c f6ff  0000000 1.00004590
 30M 0000000 012ee fcc3  0000000 1.00117803
  3A 0000016 02d04 e2cf  0000016 1.00170398

And the program itself
Code:

MacPro$ cat cal.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static char *range[] = {
"",
"0.3v", "3v", "30v", "300v",
"acv",
"300r", "3kr", "30kr", "300k", "3M", "30M",
"3A",
"", "" };

static char h[] = "0123456789abcdef";

int
main (int argc, char *argv[])
{
   unsigned char cal[256];
   int i, j;
   signed char o;
   float f, s;

   read(0, cal, 255);

   for (i=0; i<255; i++) cal[i] -= 0x40;

   printf("RRRR YYYYYYY GGGGG SSSS  Offset  Gain\n\n");
   for (i=0; i<13; i++) {
      printf("%4s ", range[i]);
      for (j=0; j<7; j++) printf("%c", h[cal[i*16 + j]]);
      printf(" ");
      for (j=7; j<12; j++) printf("%c", h[cal[i*16 + j]]);
      printf(" ");
      for (j=12; j<16; j++) printf("%c", h[cal[i*16 + j]]);

      o = 0;
      if (cal[i*16] > 3) o = 9;
      printf(" %c", o ? '-' : ' ');
      for (j=0; j<7; j++) printf("%c", o ? h[o-cal[i*16 + j]] : h[cal[i*16 + j]] );
      printf(" ");

      f = 1.0;
      s = 100.0;
      for (j=7; j<12; j++) {
         o = cal[i*16 + j];
         o = o > 7 ? o - 16 : o;
         f += ((float) o ) / s;
         s *= 10;
      }
      printf("%1.8f", f);

      printf("\n");
   }
}
Find all posts by this user
Quote this message in a reply
05-16-2019, 10:02 PM
Post: #36
RE: 3421A CAL RAM
In case it's of any use in your effort, here's the cal data from my 3468A:
Code:

ASCII:
@@@@@@@@@@@@@@@@
@@@@@AG@NLLANGEO
@@@@@@A@MOA@OMED
@@@@@@G@MKADOKD@
@@@@@@A@@@LCOAGL
@@@@C@@@MDLDLNLH
@@@DADA@BKAKNMEO
@@@@DCI@BKCNHBLC
@@@@@DG@ADMDKDDG
@@@@@@G@AEKDOCEC
@@@@@@B@NK@@OHDL
IIIIIIIOC@ALOGOD
@@@@@BB@MLMLMMEC
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@

Hex:
0000000000000000
00000170ECC1E75F
00000010DF10FD54
00000070DB14FB40
0000001000C3F17C
00003000D4C4CEC8
000414102B1BED5F
000043902B3E82C3
0000047014D4B447
0000007015B4F353
00000020EB00F84C
9999999F301CF7F4
00000220DCDCDD53
0000000000000000
0000000000000000
000000000000000
Find all posts by this user
Quote this message in a reply
08-05-2024, 02:20 PM
Post: #37
RE: 3421A CAL RAM
In case anyone is still interested how to calculate the parity for the 3468 and the 3421A calibration RAM after all these years.

The 3468 and the 3421A use a two dimensional parity scheme which can correct single-bit errors and detect double-bit errors to protect each calibration entry.

To calculate the parity bits, the calibration data is arranged in 2 columns of 6 nibbles each. The first column ist holding nibbles 0 to 5, the second column nibbles 6 to B.

Code:

                            │ E: d 1101 │ F: 7 01░░ │ 1
                                  ²↑↑↑↑       ²↑↑     │
│ 0: 0 0000 │ 6: 6 0110 │ 1 ┈┈┈┈┈┈┈┘│││        ││     │
│ 1: 0 0000 │ 7: f 1111 │ 1 ┈┈┈┈┈┈┈┈┘││        ││     │
│ 2: 0 0000 │ 8: 4 0100 │ 0 ┈┈┈┈┈┈┈┈┈┘│        ││     │
│ 3: 0 0000 │ 9: 3 0011 │ 1 ┈┈┈┈┈┈┈┈┈┈┘        ││     │
│ 4: 0 0000 │ A: d 1101 │ 0 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘│     │
│ 5: 0 0000 │ B: c 1100 │ 1 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘     │
      ¹↓↓↓↓       ¹↓↓↓↓                               │
│ C: f 1111 │ D: 0 0000 │ 1 ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐┌┈┈┈┘
                                                ³↓↓⁴
                            │ E: d 1101 │ F: 7 0111 │

  1. Compute the parity of each column and make the parity odd.
    Parity goes into nibble C for the first column and into nibble D for the second.
  2. Compute the parity of each row and make the parity odd.
    Parity goes into nibble E and the two most significant bits of nibble F.
  3. Compute the parity of the column parity (nibble C and D) and make the parity odd.
    Parity bit goes into nibble F bit 1.
  4. Compute the parity of the row parity (nibble E and the two most significant bits of nibble F)
    and make the parity odd. Parity bit goes into nibble F bit 0.


CG
Find all posts by this user
Quote this message in a reply
08-06-2024, 08:27 AM
Post: #38
RE: 3421A CAL RAM
Thank you!

Do you think this might also apply to the 3478A?

Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 17B/II/II+ 28S 42S/DM42 32SII 48GX 50g 35s WP34S PrimeG2 WP43S/pilot/C47
Casio, Rockwell 18R
Find all posts by this user
Quote this message in a reply
08-06-2024, 08:53 AM
Post: #39
RE: 3421A CAL RAM
(08-06-2024 08:27 AM)cdmackay Wrote:  Do you think this might also apply to the 3478A?

Nope, the 3478A uses a simple checksum as explained in this thread

HP 3478A: How to read/write cal SRAM

There you can find also various scripts to decode and verify 3478A calibration RAM dumps.
Find all posts by this user
Quote this message in a reply
08-06-2024, 10:07 AM
Post: #40
RE: 3421A CAL RAM
(08-06-2024 08:27 AM)cdmackay Wrote:  Do you think this might also apply to the 3478A?

Look here: HP 3478A: How to read/write cal SRAM
https://www.eevblog.com/forum/repair/hp-...-cal-sram/

Apparently the 3478 stores data differently than the 3468 and 3421.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 4 Guest(s)