Products > Test Equipment

HP3478A 2W/4W calibration

(1/1)

cv007:
I have an HP3478A which had a broken battery pin so is uncalibrated and is mostly becoming a 'fun' project.

The battery will be no more as I am using an mcu to do the sram duties, and currently have a mega4809 nano board connected (eventually will make a 22 pin dip sized board). I also have an lcd (largish 4x20 char lcd) and will be replacing the front panel using that lcd along with replacement buttons (fewer, larger). The reset circuitry will be modified to account for the missing 3v (replace a diode with a resistor, put a resistor where battery was), but for now the battery positive point is grounded so the reset line rises sooner than it normally would (but does not seem to matter).

Would there be an advantage to storing calibration data for both 2wire and 4wire ohms? I can toggle the ram table by looking at what addresses are being read- like maybe toggle to the (default) 2wire table when ACV is selected and the 4wire table when ACA is selected (these both have a single entry in the table). For 2Wire, first select ACV then 2W Ohms, for 4Wire first select ACA then 4W Ohms. Or could come up with some other scheme to toggle the table just by looking at addresses being read.

Kleinstein:
The scale factor should be the same for the 2 W and 4W resistance. An extra zero constant for 2 W ohms could compensate for the wire and switch resistance. Ideally this would be separate for the front and rear terminals. On the other side 2 wire ohm is never really accurate for small resistors and if needed the way would be a manul zero / relative measurement that includes the cables. So there is limited need for an extra constant.

It is an interesting idea to replace the battery buffered RAM with a µC.

cv007:

--- Quote ---It is an interesting idea to replace the battery buffered RAM with a µC.
--- End quote ---
I did not want to deal with a battery ever again, so could either load sram values via gpib at startup or put something in place of the sram. I really don't want to deal with gpib, and calculated an mcu could handle the sram duties.

The mcu sram replacement may be a moot point, as I intend to replaced the lcd/buttons as I indicated. I think the display/button mcu could do the duties of translating the lcd data (displayed value) with its own offset/gain data and output the corrected value. The main mcu would use the default offset/gain since there would be no sram, the display mcu would have its own custom calibration data and create whatever interface it wants to let a user customize that data, or change on the fly (usb,serial,whatever). With the display mcu having the display value, and will know the meter state as it will be doing the button presses, it could also send the data out externally in whatever format/method it wants. Maybe would not be as easy as I think, but also not at that point yet.

It looks like I can get the data pins set on a read about ~300ns before the rd rising edge so looks like its taking close to 20 cpu cycles to do the work.

I have only been running the mcu for a few days, so do not know if there are problems yet to discover. The CS pin is set to a falling edge irq, and the isr is in a loop looking for rd/wr pulses until the CS pin rises again. This allows the main loop to check for any need to update eeprom, and can be interrupted anytime without a problem (isr code only reads/write from ram).


--- Quote ---So there is limited need for an extra constant.
--- End quote ---
I think I will scrap this idea then. Thanks.


--- Quote ---Ideally this would be separate for the front and rear terminals
--- End quote ---
I'm also removing the front/back switch so will only have front terminals. I have no need for rear terminals, and also don't want to deal with that switch in the new front panel. No need to have those wires/switch hanging around inside if I'm not going to use it.

Kleinstein:
The rear terminal path is also used for the optional scanner for switching with multiple inputs. This of cause mainly makes sense in combination with GPIB (or other PC interface).
A 2nd set of terminals can be quite useful for some measurements, as swapping the cables at the input can introduce thermal EMF for some minute or so.

Doing the scaling form the display data would add rounding errors.

cv007:

--- Quote ---Doing the scaling form the display data would add rounding errors.
--- End quote ---
I guess I do not understand. We seem to know how the display value gets from its raw form (bcd values from the analog mcu) out to the display- (offset applied to raw adc value+add a rounding value)*gain. With offset set to 0 and gain set to 1, it seems basically you get the raw adc value at the display with the (known) rounding value included.

Was just a thought and am getting ahead of myself. I will be happy getting the mcu sram working reliably (so far, so good), and getting a readable display working.

Navigation

[0] Message Index

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