HP 3478A: How to read/write cal SRAM

[coromonadalix]

wow great work, since im totally noob in programming, is there an updated GPIO6.1.ino available to download,

I have to reinstall my win 10  i dont have any compilers / ide ... at the moment

thks

[Miti]

That won't be necessary ! Just finished figuring out the gain constants, with the help of partial MAME emulation.
.
.
.
And, that's pretty much all there is to it.

Bravo 
Amazing work Fenugrec!
Now we need an application where you say "I want to read 10 digits more on 3V DC" and it reads the constant, calculates, modifies and writes it back.

Pigrew,

Can you code something?

[coromonadalix]

That won't be necessary ! Just finished figuring out the gain constants, with the help of partial MAME emulation.
.
.
.
And, that's pretty much all there is to it.

Bravo 
Amazing work Fenugrec!
Now we need an application where you say "I want to read 10 digits more on 3V DC" and it reads the constant, calculates, modifies and writes it back.

Pigrew,

Can you code something?

What do you mean by :  "I want to read 10 digits more on 3V DC"    you want a 10 digits resolution

[Miti]

What do you mean by :  "I want to read 10 digits more on 3V DC"    you want a 10 digits resolution

What I mean is that, compared with a calibrated instrument, my instrument reads less by 10 digits. Calibrate reads 3.00000V, mine reads 2.99990V, so I need to alter the calibration constants to bring it in line with the calibrated one. Preferably you do a full calibration but it is not always easy for a hobbyist. Another application would be to bring an instrument to a reasonable calibration state, after loosing the calibration constants due to a dead battery.

[coromonadalix]

ahhhhhhhh ok  thks for the clarification

[Pete2]

Great thread. I just got my (first?) 3478A and am planning to replace the battery. Seems like it's never been replaced (yellow Panasonic with an expiry date 00). The unit itself seems to be manufactured in 1991. Plenty of volts in the battery still: about 3.4 V

I would like to get the cal memory backed up but I'm missing a GPIB adapter and cable. I'd like to use linux, so what's the best adapter (ie. cheapest) that works?

[coromonadalix]

it would be the arduino project : http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html

[Pete2]

Thanks, I will probably get an Agilent 82357B adapter at some point, seems ebay has plenty of them at under 100 USD.

[coromonadalix]

@ pete2   be careful there's a ton of fake Agilent 82357B usb gpib adapters around .......

[Pete2]

coromonadalix, thanks for the tip. Any way to know which ones are fake? Also, do fake ones work at all? Almost all of them are listed as "new in box". If some of them are fakes, how to tell apart...

[MarkL]

coromonadalix, thanks for the tip. Any way to know which ones are fake? Also, do fake ones work at all? Almost all of them are listed as "new in box". If some of them are fakes, how to tell apart...

It's usually hard to tell from photos and descriptions, but you can be pretty much guaranteed it's counterfeit if coming from China or Taiwan.

There's a lengthy thread on it here, and someone noticed that there's a lack of metal shielding on the fakes:

  https://www.eevblog.com/forum/testgear/flood-of-new-agilent-82357b-gpib-usb-adaptors-on-ebay-the-real-deal/msg983752/#msg983752

The fakes also have poorly spelled Certificates of Authenticity (COA), non-existent serial numbers which can be checked on the Keysight web site, mismatched serial numbers on the box/certificate/unit, and really terrible soldering/rework on the inside if you open it up.  All is detailed in that thread, including someone who did an unboxing of a real one to show what to expect.

Some people have had success using the fakes.  But many are unstable, and some just don't work at all.  I don't recall reading that anyone didn't get a refund after reporting a counterfeit.

[steve1515]

In case anyone is interested, I decided to create my own program to read and write the calibration data from the HP 3478A. It also displays the gains and offsets for each range from existing calibration files.



Program Download: https://github.com/steve1515/hp3478a-calibration/releases
Instructions & Source Code: https://github.com/steve1515/hp3478a-calibration

Hope someone finds this useful. 

[ErnieW]

Hi, I am new to the blog and have just acquired a 3478A to complement my range of test equipment (which is mostly for rf measurements). I opened it to check the battery which is still 3,4V. But it is always good to backup the cal values - just in case.
Unfortunately the above program requires a Prologix GPIB Interface, which I do not have.
I have a hp 82357B GPIB - USB interface. As I am not a programmer and steve1515 has released his source code, maybe someone in the group can modifiy his code to work with my interface.   
Probably this would also be useful to other members.

Regards Ernst

[Miti]

Check reply #44. That program should work with your adapter. Thanks to member pigrew.

[ErnieW]

Thanks, this worked for me. But would be nice to see an interpretation of the cal values. 

[pigrew]

Thanks, this worked for me. But would be nice to see an interpretation of the cal values. 

I'm glad it worked. I doubt I will get around to updating the software any time soon (I don't have a business of changing 3478A batteries...). However, I would accept github pull requests.

[alocam]

Hello,

I have two HP3478A meters that I purchased recently, and it looks like your program would be nice to get the cal data our for backup purposes. However, I only have access to an HP5810a GPIB ethernet gateway.

Do you know whether it would be feasible to reconfigure the program to make it work with such GPIB interface instead of the USB one?

Regards!

[fenugrec]

HP5810a GPIB ethernet gateway

Most likely, reading cal constants is very simple ( https://github.com/fenugrec/hp3478a_utils/blob/master/hp3478util.c#L258 ) and should be easily programmed or done manually with any GPIB interface. You'll have to work out the details of how to program yours though, how to use its API etc.

[lmester]

Thanks to code provided by steve1515 I've now added the ability to edit the gain and offset for each calibration entry into my HP3478A control program. This lets you "tweak" your cal without going through the full calibration procedure.

https://mesterhome.com/gpibsw/hp3478a/index.html

I have some questions that steve1515 or others on this thread may be able to answer.

What is the valid range for the gain value? It seems that Steve's algorithm (or my implementation of it) fails when the gain is outside the range of 1 to 1.055555. Have any of you seen a gain value outside of that range? If so, I'll need to do more work on the cal edit feature in my program.

[fenugrec]

It seems that Steve's algorithm (or my implementation of it) fails when the gain is outside the range of 1 to 1.055555.

It should be possible to have gains up to 1.077777, and below 1 probably from 0.911112 if my math was right ? (doubtful, I can't remember the results in MAME)

He wrote his algorithm slightly differently to mine, and I just noticed a bug in mine - with that fixed, they should now be fairly equivalent. I haven't look at the disasm in a while though; and looking at some cal dumps now I'm not sure what we're doing is correct (i.e. subtracting those negative digits >= 9 from the whole gain constant). But I have a spreadsheet and some tests that would tend to confirm that, so  whatever. Some example gain constants :

Code: [Select]

gain_const gain
13F1C 1.012906
fff1c 0.988906
88888 0.911112


[steve1515]

Hmm... I took a look at what my code would return for these example results and I get something different when the raw value is equal to 8. It looks like it's possible that I have a bug where I should be subtracting 16 when the nibble is >= to 8 instead of just > 8. (I'm missing the equal sign.) If I make that correction, I get the same results as fenugrec.

This is what I'm currently getting:

Code: [Select]

Raw    Gain
13F1C    1.012906
fff1c    0.988906
88888    1.088888

This is what fenugrec's code returns:

Code: [Select]

Raw    Gain
13F1C    1.012906
fff1c    0.988906
88888    0.911112

Note the difference in the last entry. I suppose I should hold off on making any correction since fenugrec believes we might both be doing something incorrect in the decoding. I'll go with whatever fenugrec says since he understand the firmware much more then I do.

fenugrec, what do you think? Should I make the correction or should we look into this some more?

[fenugrec]

Hi Steve,

Should I make the correction or should we look into this some more?

IMO it wouldn't hurt to run a few more tests. One could simply hook up the meter to a reasonably stable source (or resistor), and try a bunch of different gain constants and note the results. We did this a while ago but only crudely with 3-4 constants IIRC.

Now I'd be curious to test one range with offset=0 and gain=00000 then changing some gain digits for key values, i.e. 0,7,8,9,A,F. I'd try changing maybe the first and 3rd digit, so around a dozen tests in total (i.e. 00000, 70000, 70700, etc) plus maybe the two extremes, 77777 and 88888. Still fairly simple, and definitely easier than analyzing 8048 assembler.

[lmester]

Steve,

With the test data I get the same results as you. It looks like I did implement your gain unpack code correctly.

Code: [Select]

Raw    Gain
13F1C    1.012906
fff1c    0.988906
88888    1.088888


Since I'm allowing the user to edit a gain or offset value I first must unpack the data. After the user submits the revised value I then re-pack it with a new checksum.

It looks like the problem is in my code to re-pack the gain value.  I'm getting different results on two of the three test gains.

Code: [Select]

Decode Value Encode Value
13F1C 1.012906 13F1c 1.012906
FFF1C 0.988906 0110F 1.001099
88888 1.088888 FFFFE 0.988888


It looks like what I need is a correct algorithm for re-packing the gain into the meter calibration format. Mine is not working correctly for all gain values.

Would you or fenugrec be able to help me get the gain data properly re-packed? Also, let me know if I need to make changes in the unpack algorithm.

Below is the flawed function that I'm currently using.

Code: [Select]

function RevGain$(g)   
'reverse gain. calculate gain encoded value in hex.
'Uncompressed gain in g. Returns encoded gain in RevGain$ 
gt=g-1 '?? 1 is a constant & not used in the calc. is this correct ??
RevGain$="" 'Build new string into a null string.
for i = 6 to 2 step -1
    'Add any needed trailing 0's to get i digits in number
gd=val(right$(mid$(str$(gt)+"00000",1,i+2),1))

    if gd>5 then
        cd=gd+6
        gt=gt+(10-gd)*10^-i
    else
        cd=gd
        gt=gt-gd*10^-i
    end if

    gt=int((gt+(5*10^-11))*10^10)/10^10 'round off to fix compiler math error
    RevGain$=dechex$(cd)+RevGain$ 'Build compressed gain hex string.
 
next i
end function

[fenugrec]

Would you or fenugrec be able to help me get the gain data properly re-packed? Also, let me know if I need to make changes in the unpack algorithm.

Sure, but as I mentioned we may be slightly wrong (or at least uncertain) about the decoding; it would be really good to do some kind of test as I described, before spending too much time on a possibly-wrong encoding implementation.

[Miti]

I could help in the weekend. I have a reasonably accurate and stable 3V reference made with MAX6126A. If you can tell me exactly what offsets and gains you want to check, I’ll give you the readings.