Prema 6048 teardown

[dietert1]

Thanks, that patent of 2001 used the term "best-fit line" instead of "linear regression" but it shows the idea. Interesting enough they considered the method a good substitute to the multislope method like used in the Advantest R6581 with several different current sources, meant to solve the same problem at end of run-down.

Of course, if one can do it with a MCU and its built-in ADC, that's interesting. I thought a MCU built-in ADC might be to noisy and to produce more jitter. Maybe it just needs a slope amplfier (same as comparator). And it depends on how ADC sampling/trigger reacts to the 3.6864 MHz PWM time base. The LTC part is near ideal in that respect (psec aperture jitter).

Regards, Dieter

[Kleinstein]

Best fit line and linear regression is the same, just different words.
The idea with an ADC to measure the charge is also used in the HP multislope 3 and 4, just with a much faster modulation. In case of the MS3 the modulation is with rather large blocks and thus a large range covered by the auxiliary ADC. AFAIK the MS4 ADC uses a more PWM like feedback and thus a much smaller residual charge.  The MS3 and very likely (because of the patent) also the MS4 uses a single ADC reading and than a slow measured up front. The linear regression is kind of a way to average over more readings and repeat the the scale factor calibration for every zero crossing.

The ADC should still be relatively fast, so that one can get a decent number of readings in the time. However I don't see a real need for very high resolution. The point is getting a little more resolution, like maybe some extra 4 or 6 bits. So enough to get an effective time resolution in the 5-10 ns range. Within limits one can trade resolution for speed. A µC internal ADC may be a bit on the slow side. Some 10 bits at 5 MSPS would ideally resolve the 200 ns in 500-1000 parts. To get a bit more averaging and less noise bandwidth one would however loose some of the resolution. It may still be good enough.
The main point of the prema ADC are using reference switching with drive and sense switches. This can be precise with no effect of the switch resistance, but it still adds a bit switching error and needs relatively long settling time. So this requires the relatively slow modulation and large integrator capacitor.
Another point with the 6048 is the ADC for only 1 polarity with the reference path switching on / off and not both polarities. This leads to a noise that depends on the input voltage. So with 0 input the ADC can be quite low noise, but with high voltage there can be quite some extra noise. A bit like adding much of the ADC noise to the reference side and not to the input.

The simple direct feedback control with the comparator works OK with the rather strong reference (1.4 mA for the 6048), which is not ideal noise wise.  My understanding / guess that the MS4 ADC uses the 2nd auxiliary ADC for the Feedback control to get away with a weaker reference. The solartron DMMs use the extra forcing signal to support the feedback. Otherwise they are quite similar.

I am not so sure how much it would help, but a possible way to improve on the noise would be some filtering the reference. The LTZ1000 is low noise but still relatively high noise compared to OP-amps. The reference is only used for relatively short (less than 30% duty cycle) pulses and this increses the BW for the reference side. So ref. noise in the 100 Hz + harmonics bands can have an effect. Filtering could reduce this higher frequency noise contribution.

[Mickle T.]

The solartron DMMs use the extra forcing signal to support the feedback. Otherwise they are quite similar.

Prema is known to have several proprietary types of pulse feedback ADCs, including those with a convergence acceleration signal (US5066955).
Thaler uses the same topology as in the early Prema patents (1973, 1982).

[dietert1]

As far as i understand one can improve timing resolution at the end of run-down by using a TDC-like circuit to measure the timing of the comparator relative to the integrator timebase. The TDC involves another integrator for a reference current during the delay so one can later digitize the delay with good resolution, to get a fractional, sub cycle time measurement.

Regards, Dieter

[Kleinstein]

With a different control hardware one would not be limited to the rather low 3.6x MHz clock for the timing. Just a higher clock for the PLL may be enough for a little more timing resolution. There is anyway the noise limit for the comparator. Due to the relatively large capacitor and thus moderately slow slope the noise could well be limiting:
In the 6048 this is 1.4 mA/0.5 µF = 2.8 mV/ µs , which is more comparable to the slow slopes in a normal MS ADC. The noise voltage is given by the integrator ( ~ 10 nV/sqrt(Hz)) and if added slope amplifier with about a comparable noise. The BW is set by the comparator or ideally the slope amplifier. To get reasonble fast response for short pulses one would likely need 100 kHz or a bit more. So one can expect a noise voltage of some 4.4 µV or a timing noise of some 1.6 ns  (more with a high BW).

With the long integration time one would likely not need that much resolution anyway.

[Rax]

Just found a little trap while nulling the instrument. When you press the null button, you can hear the polarity relay without any delay. Seems they assume you already had the input short for some time and there is a valid null measurement for the current polarity. So they switch the relay to acquire the null reading of the other polarity. With long integration times, if you insert the short and press the null button you may get "Error 4" if the last valid reading is outside limits, like open inputs.

I accidentally just stumbled into this nugget, dieter1. Very insightful - I've ran into this many times and had no idea what may cause it. I always thought my meter has some sort of low level issue that's rearing its head once in a while (like caused by some minor leakage, or some data being a bit off somewhere, etc.). I always just sort of shook it into nulling by changing the integration times, range, etc. until it'd be willing to null.

[Rax]

I am registering some success connecting to my 34401A via RS232. I have not yet been able to make GPIB work yet under any of my meters and any of the programs I tried. I mention this because these are my baby steps on this pursuit. I am cursorily controlling my Audio Precision System One via APIB/USB, but that's a whole different story (that's an actively maintained solution).

I think some of you have been able to connect to the Prema via GPIB. Can you offer some guidance? If worth a different thread, I'd be happy to start one.

I am currently doing some pretty extensive monitoring of a bunch of references - a Fluke 931B, 5440A, a VREF10-001 r9, etc. - the first two displaying incredible accuracy and stability (I've been watching last night, overnight, and this morning the 931B being within something like .02ppm of Prema's 9.9999990V... This is in an unconditioned garage, though the weather here is aways very mild. And the 5440A is in the same ballpark, both comfortably within less than about .5ppm of 10.0000000V for some weeks of observations now, under good discipline of performing INT CALs on the 5440A and "zeroings" on the Prema; the 931B needs no such fluff!).

It'd be great if I could log these by monitoring them automatically.

[dietert1]

Yes, i have a similar setup logging a Prema 6048 and other meters over GPIB. The GPIB interface is DIY based on a STM32 with a USB.
I wrote a very small Win32 app that uses a serial comm device to talk to the USB-GPIB adapter and to cycle the meter(s). Results get written to text-with-tabs dayfiles that are easy to use e.g. with Excel/OpenOffice. Or with some averaging app to reduce a large amount of raw data before.

Initialization (once)
--------------
Configue GPIB
   Manual: Connect GPIB cables and USB cable of interface
   GPIB interface setup (open and configure the driver)
   Bus initialization with IFC bus signal
   Bus and device configuration concerning generation and handling of interface
      signal EOI and/or line terminators

Configure P5017
   The 5017 defines the pace of data acquisitionn, others follow using trigger commands.
   Manual: Bus address=8, 30 V DC, 4 seconds
   sprintf_s(cBuffer,sizeof(cBuffer),"GD %i",iGPIBAddr_P5017);
   iStatus=GPIB_Write(hSerialGPIB,cBuffer);
   iStatus=GPIB_Send(hSerialGPIB,"S0"); // continuous readings
   iStatus=GPIB_Send(hSerialGPIB,"CN1");

Configure P6048
   Manual: Bus address=7, 20 V DC, 4 seconds
   sprintf_s(cBuffer,sizeof(cBuffer),"GD %i",iGPIBAddr_P6048);
   iStatus=GPIB_Write(hSerialGPIB,cBuffer);
   iStatus=GPIB_Send(hSerialGPIB,"S1"); // single reading, trigger and query result

Data taking loop (reading meters, sending next trigger)
----------------
..
GD 8 OK after 0msec
GQRD? +10.000072E+0MRVDP01A0R3F0T7D0S0Q0M01B00 (44ms)
GD 7 OK after 0msec
GR? +01.0158152E+1MRVDP00A0R3F0T7D0S1Q0MOFB00 (3ms)
S1 OK after 0msec
..

This is the bus interface dump:
GD n selects a bus device
GQRD? sends the RD? command to query the device and receives its response.
   There is a 44 msec delay until the P5017 terminates its measurement and responds.
GR? reads a response from the selected device
   The P6048 already finished its mesurement and responds quickly
S1 is the P6048 command to trigger and query the next measurement

This is the most basic approach and very reliable. Something similar can also be done using the AR488 interface or commercial GPIB adapters.

Regards, Dieter

[Rax]

Yes, i have a similar setup logging a Prema 6048 and other meters over GPIB. The GPIB interface is DIY based on a STM32 with a USB.
Regards, Dieter

Thank you very much again, Dieter. Can you elaborate on the GPIB-USB interface? Or, maybe better - if you know - would an NI adapter work? I may have access to one on loan. If this works at all, it seems like it won't be a bank breaker. Unless all those affordable ones are bad clones (I'll take a good clone, though...).

[dietert1]

I am using DIY hardware and software for that. For debugging GPIB we have an old HP 59401A.
A beginner should rather look at industrial products. Installing GPIB automation isn't that difficult, once you have the hardware (controller and cables). If you borrow it, you could ask the owner how they used it.
After connecting the hardware (interface and cables) you will download a driver package and install it on a PC. Then you can use an interactive application included with the drivers (e.g. NI "Measurement and automation explorer") and type in commands and talk to your instrument and listen for the response. To automate the process people use data collection applications, see WinGPIB thread. There you can find examples for logging a DVM and use that as a starting point to setup your own process.
GPIB isn't from the AI age. Each instrument has it's own command set. You need to manually assign a different address to each bus device. You need to setup timeouts and EOT convention. GPIB is slow as many of those old instruments have 8 bit MCUs, so each transaction will take some 10 msec or more.
I think i needed about 3 or 4 hours to get the Prema 6048 going - without implementing SRQ though. One nasty "feature" of the Prema is that it forgets the assigned GPIB address on power-down. Maybe that can be solved using the calibration switch.

Regards, Dieter

[Rax]

Has anyone reading this successfully implemented xyphro's USBGPIB?
https://github.com/xyphro/UsbGpib

[ch_scr]

Has anyone reading this successfully implemented xyphro's USBGPIB?
https://github.com/xyphro/UsbGpib

I built a few. They seem to work fine, but no extensive test done.

[Rax]

I built a few. They seem to work fine, but no extensive test done.

Can you describe your major steps in putting one together? I don't mean hardware. From the point it's all buttoned up and ready to be connected to the computer via USB and the instrument via GPIB.

For instance, there's apparently need to "flash the microcontroller," but very cursory directions are provided on Github. I got this: "USB AVR Programmer w/ 6-Pin 10-Pin IDC ISP Connector for USBASP," as I think it allows me to perform this flashing, but I don't know the first thing about if I need it and how to use it.

I tried to simply connect one of those built kits to the computer via USB but it's not seeing it.

If all these things I'm asking have been clearly mapped somewhere, I'll give that another shot, but the Github guide is completely cryptic to me.

[Rax]

Obviously, this topic doesn't really belong in this thread, so if you don't mind, we can move it to the one II started specifically for this: https://www.eevblog.com/forum/metrology/prema-6048-gpib-comms-or-maybe-general-thread-on-gpib-readings-harvesting/.

[Rax]

It's a good idea to transfer the P6048 calibration to other standards before applying mods.
Regards, Dieter

With this, do you mean saving the constants out of the unit (maybe via GPIB), or "transfer-adjust" other references to save the various reference points of the meter (such as, for instance, adjust a 731B for the "P6048 10.0000000V" etc?)

[dietert1]

Please don't adjust any of your precision devices, but do everything on paper. Without notes it's easy to get lost. Some people use a lab notebook to keep important information like that in a safe place.

You could just measure the Fluke reference as good as possible and note down the result, maybe together with ambient temperature. After the P6048 mod you could repeat the exact same procedure and determine the new value. This way you can always calculate "unmodded", calibrated results by subtracting the shift caused by the mod. It's easier to revert the mod as long as you don't adjust the Prema calibration.

Regards, Dieter

[Rax]

It's easier to revert the mod as long as you don't adjust the Prema calibration.
Regards, Dieter

Dieter - thank you for your points, and no! I wasn't planning to touch the Prema calibration in any way. Not even close!

The only one I was considering adjusting is the 731B (to match the Prema at 10V), which, as much as it has unusually good tempco, it's a transfer standard, so literally designed for this purpose.

That said, your recommendation makes sense.

[Rax]

I finally got tonight to replacing U9 and U10 with OPA 189. I'm getting "Error 1," which doesn't let me go any further (other than, when trying to null the instrument, "Error 4").

Any thoughts?

[branadic]

Is this with something connected at the input? If not, that message is not surprising:

OVERFLOW INDICATION ... ERROR1 in the main display

page  2/7

ERROR 1 Overflow of measurement result
             Overshoot of the allowed  numerical span.

ERROR 4 Error during offset measurement
              The offset which is present at the input sockets is too large.

page 5/12

-branadic-

[Rax]

Is this with something connected at the input?
-branadic-

It comes up regardless. I start the meter with nothing at the input, so it'd run its startup checks undisturbed, and the error comes up right after the checks. The unit settles into the largest range on VDC. If I connect a short or a known voltage at the input, it stays on "Error 1," and if I try to null it with the short on the input it gives "Error 4." So no useful measurement would be rendered with both U9 and U10 replaced.

I may try to only replace one at a time and see where that takes me.

[Rax]

With just U10 replaced with an OPA189, for instance, the instrument responds correctly to commands and inputs. I'll let it warm up, null it, and see if I get more consistent behavior from it.

[Kleinstein]

There is a slight chance that the integrator gets unstable with a different, much faster OP-amp. Here it is not just the GBW, but also the phase reseve under the given conditions that can make a difference. So the OPA189 may not be suitable.  With some of the rail to rail output stages it can help to have an additional RC load (e.g. 50 ohm and 100 pF in series) at the output of the OP-amp as this can slightly reduce the gain of the amplifier and improve stability.  Even if not actually oscillating a lot of ringing may be worse than the bit slow reaction of the OP77.

Candidate OPs to test could be ADA4077 (only 3.9 MHz but still much faster than the OP77), OPA205 (a similar part from Ti), OPA182 (5 MHz brother to the OPA189) and the OPA145 (5.5 MHz) and OPA140/141/OPA1641 (some 11 MHz).

[Rax]

OPA140/141/OPA1641 (some 11 MHz).

I also have OPA140s at hand - given Dieter1's success with those - so I could try to use that for U9.

[Rax]

Before I try the OPA140 for U9, I thought I'd run more tests with the OPA189 for U10 and the original OP77 for U9.

I'm doing successive nulling operations and then measuring the FX to see if I observe any noticeable jumps in value from one nulling to another. After 5 of these or so, it seems the measurements are pretty consistent. I probably still need to run this more to fully stabilize temperature-wise, but the last few readings have been within less than .02-.03ppm from each other (averaging slight variations of the last count from one integration to another). In other words, it seems that from one nulling to another the readings seem to be very consistent (essentially identical).

Does this sound like a relevant test? Aside from a more invested INL plot which would be more than what I can really do today.

[Rax]

Next step accomplished - it turns out my sample unit agrees with using the OPA140 for U9... Yeah!

To summarize, my unit's now using:

• U9: OPA140
• U10: OPA189

And remains stable and responsive.

I'll run some nulling cycles and check for signs of similarly consistent readings as I've seen with the OP77/OPA189 combo.