Electronics > Repair

HP 3478A: How to read/write cal SRAM

<< < (24/41) > >>

lmester:
fenugrec,

I think I have the gain encode function working properly. I still might have a problem.

You'd mentioned that a gain value of 0001C is equivalent to 00006 and both correspond to a gain of 1.000006. I think I see these differences in my gain encoding. It looks like my implementation of your algorithm prefers "06" encoding instead of  "1C" encoding.

I've looked at several different instrument cal backup data files. It looks like the instrument always encodes gain as "1C" instead of "06".

I've done some testing. The instrument does seem to handle the compressed gain in either format. My testing shows that both encoded gain values give the same instrument reading.

I'm just not comfortable about writing different compressed gain data into the instrument for the same gain setting.

Below are some tests.
Inst:    The value read from the cal RAM.
Re-enc:    The re-encoded value written back into the cal RAM.
Gain:    The same gain is reported for both compressed gain values.

Inst.   Re-enc.   Gain.
04C00   03600   1.0036
22C01   21601   1.021601
1CFE3   06FE3   1.005883

It'd be interesting to process some of the above gains with your code.
Do you generate 04C00 or 03600 for a gain of 1.0036?

Finally, I did some reality checks for gain updates entered using my software. The offset is set to 0. Various gain multipliers were applied and compared with the instrument reading.
This looks very good.


Readings with offset set to 0. and various gain settings.
Calc gain = .68085 * Inst. gain

Inst. gain   Inst. reading   Calc. gain
1.000000   .68085         0.68085   
1.010000   .68766         0.6876585
1.077777   .73380         0.73380447045   
 .911112   .62033         0.6203306052
 .990000   .67404         0.6740415


fenugrec:
Hi,


--- Quote from: lmester on March 21, 2020, 12:27:33 am ---I've done some testing. The instrument does seem to handle the compressed gain in either format. My testing shows that both encoded gain values give the same instrument reading.

--- End quote ---
Excellent, glad to hear.


--- Quote ---I'm just not comfortable about writing different compressed gain data into the instrument for the same gain setting.

--- End quote ---

Fair point. The only theory I have is that the original algo tries to clamp each digit value to the range [-4...+5] i.e. allowing only  C,D,E,F,0,1,...,5 . I checked a few cals (non exhaustive) and indeed the digits 6,7,8,9,A,B seem to be always absent. One reason to do this might be to limit rounding error propagation by keeping multiplications small (<= 5) ?

You're welcome to check against the annotated disassembly listing I have in my repo, but I find that reading hand-optimized BCD code is super tedious. Or you could emulate that portion of the code under MAME, but tracking 6-digit packed-BCD operations is also headache-inducing...

lmester:

--- Quote from: fenugrec on March 21, 2020, 01:20:36 pm ---

Fair point. The only theory I have is that the original algo tries to clamp each digit value to the range [-4...+5] i.e. allowing only  C,D,E,F,0,1,...,5 . I checked a few cals (non exhaustive) and indeed the digits 6,7,8,9,A,B seem to be always absent. One reason to do this might be to limit rounding error propagation by keeping multiplications small (<= 5) ?

--- End quote ---

I have six cal files that i've been using to test my program. Two from my instruments and the rest from posts on EEVBLOG. All are missing 6,7,8,9,A,B in the gain digits. It does look like these digits are not used.


--- Quote ---You're welcome to check against the annotated disassembly listing I have in my repo, but I find that reading hand-optimized BCD code is super tedious. Or you could emulate that portion of the code under MAME, but tracking 6-digit packed-BCD operations is also headache-inducing...

--- End quote ---

I must give you a big thank you for your work disassembling the code.

Many years ago I got stuck with a project to recover 6502 code from a disassembly listing. The programmer got into an argument with the company and took the source code when he left. All that I had was an EPROM with the object code. That was a really nasty job.

Working with disassembled code and no comments is certainly headache-inducing!!

For now I'm just going to use the existing gain compress code. The instrument does seem to handle the different encoding. Also, I expect that the gain adjust feature won't be used very often.

If I have any problem reports I may then adjust the algorithm to avoid the unused digits.

Mp3:
Just wanted to thank everyone involved in this effort, I am about to build one of the atmega328 adapters to back up my own calibration data, and i will share it here.

I have one unit that hasn't been calibrated since 2004 and I will soon be buying a friend's 3478A which was calibrated only six months ago. I'll be sure to share data backed up from both units.

Has anyone tested writing the backed up data to a 3478A after a battery swap? I'm wondering if this utility replaces the need to provide auxiliary power to the SRAM while replacing the internal battery.

Miti:
Yes, indeed, you don’t need to worry about hot swapping the battery anymore. And you also don’t need to design your own adapter. It’s all done and tested.

Adapter:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

Adapter with bonuses :
https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/

Free software :
https://www.eevblog.com/forum/testgear/free-hp3478a-multimeter-control-program/

You can also use the SW to “tune” the calibration if you need  and you have precision reference gear.

Bonus - backlight :
https://www.eevblog.com/forum/testgear/hp3478a-backlight-my-version/msg1506655/#msg1506655

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod