Automated DP832 Calibration

[garrettm]

You've given me some great ideas Thomas. I'll play around with both interpolated "measured" values for cal points that measure negative and also try skipping negative cal points as JDubU has done. If either of these actually make a difference using the standard point list from TooOldForThis, I'll upload a new version of the Java cal script using the improved routine.

It'll probably be a few days until I can work on this, but it shouldn't take much effort to do. I only need to run voltage calibrations for ch 1 and 2 a couple of times and run another script to save measurements of the output as a CSV file for plotting and comparison.

[Gandalf_Sr]

I've modified the Python calibration script to help optimize the near zero calibrations. 
It finds the lowest value calibration point that produces a non-negative dmm read back and uses it for the first calibration point in the sequence.  Any calibration point in the tables that would produce a negative dmm read back are skipped

The file DP832Cal.py is in the attached zip file.  Just replace the one that is already in the cal folder.  Be sure to save the old file, this one has had very limited testing and may have bugs.

Thanks, is this one 34461A-compatible?

[JDubU]

Thanks, is this one 34461A-compatible?

Yes, there are no changes to the way it communicates with the dmm.

[skander36]

I was running the calibration using your last version. Output attached.
Negative offset on CH2 is no more present. Channels 1&2 are outputting positive values at about 2 mV but they are a little unstable  as they slow vary between 0.4 -2 mV. I thing that the source must be warmed more time (over two hours) before calibration , but this will affect values at start-up .
CH3 is the more precise and stable .
I think that this approach is a good way as it eliminate negative offset .
Thank you for your work .

[JDubU]

Negative offset on CH2 is no more present. Channels 1&2 are outputting positive values at about 2 mV but they are a little unstable  as they slow vary between 0.4 -2 mV. I thing that the source must be warmed more time (over two hours) before calibration , but this will affect values at start-up .

Thanks for testing the new version.
I've also found that the DP832 definitely must warm up and stabilize in temperature before doing a calibration.
I see from your calibration log that your DP832 has a 0.356V negative DAC-V offset on CH1 and a 0.41V negative DAC-V offset on CH2.  As an experiment, it might help to remove the 0.5V calibration point from those calibration tables so that the next point is farther away at 0.7V.

[skander36]

Thanks for testing the new version.
I've also found that the DP832 definitely must warm up and stabilize in temperature before doing a calibration.
I see from your calibration log that your DP832 has a 0.356V negative DAC-V offset on CH1 and a 0.41V negative DAC-V offset on CH2.  As an experiment, it might help to remove the 0.5V calibration point from those calibration tables so that the next point is farther away at 0.7V.

Hi ,
Attached is the output without 05. value.
Unfortunately I have found that running the script with "update_calibration = False" is not preserving previous values. It delete calibrated values and leave the default one.
I has mention negative offset on output of source as no more . Before, I always used to have on CH2 -40 mv for 0V set.

[JDubU]

If "update_calibration = False", the previous calibration data is temporarily cleared but should return if you power cycle the DP832. 
Setting "update_calibration = True" records the new calibration data into non-volatile memory just before the script finishes. 
If you stop the script part way through the calibration, power cycling should also return the previous calibration. 

Did removing the 0.5V calibration point make any improvement in the accuracy near zero?

[skander36]

If "update_calibration = False", the previous calibration data is temporarily cleared but should return if you power cycle the DP832. 
Setting "update_calibration = True" records the new calibration data into non-volatile memory just before the script finishes. 
If you stop the script part way through the calibration, power cycling should also return the previous calibration. 

Did removing the 0.5V calibration point make any improvement in the accuracy near zero?

Hi JDubU,
As you can see from the script , it was done until his end , so no ctrl+c was press . It was worked in previous versions , maybe something has changed and is affecting this function. Values has not been restored after power cycling .
Removing 0.5V step was not improved accuracy , it was slightly worse . Better results I has get after two consecutive calibrations with 0.5 V value .

[JDubU]

As you can see from the script , it was done until his end , so no ctrl+c was press . It was worked in previous versions , maybe something has changed and is affecting this function. Values has not been restored after power cycling .
Removing 0.5V step was not improved accuracy , it was slightly worse . Better results I has get after two consecutive calibrations with 0.5 V value .

Nothing was changed that would save the new calibration data when "update_calibration = False". 
It would print "Updating calibration data for channel CH<channel number>" in the log if the command that saves the calibration was called, so I cannot explain why it happened.

I just noticed that it does show "Updating calibration data for channel CH<channel number>" in your first log (22032020_calib.txt) but not in your second log (22.032020 without 05.txt). 
Did you use the same "calibrate.py" file for both or maybe it was a problem with the Python file cache not being cleared?

[skander36]

I think that it was not saying in last because I have used calibration=false. This way I have found that now is no more working 
I am using Ms Visual Studio Code , I am not aware about a cache clear method.
This is not a big problem , it is just secondary , I just want to use simulate mode to not loose a perfect calibration data that I have aquired today . But hasn't to be ... 

[JDubU]

I did an experiment to read back the output voltages corresponding to a section of one of the DP832 internal calibration tables after its calibration points had been cleared. 
The idea is to try and discover native non-linearities between the table and the output voltage that would help in optimizing the location of the calibration points.
For this initial test, I only read back a portion of DAC-V of channel 2 between 1V and 2V in 10mV increments.  The captured data is in the attached spreadsheet.
 
Also in the spreadsheet are two plots. 
The first is actual output voltage (with no calibration) vs. expected voltage (if it had been perfectly calibrated). 
The second plot is the difference between expected (calibrated) voltage and actual (uncalibrated) voltage vs expected voltage.  If it were perfectly calibrated this would be a horizontal line at zero volts.
As expected, there is a linear gain and offset difference in the uncalibrated output, but there are also some non-linearities that are more obvious in the second plot.

Comments?

[TurboTom]

That's what is to be expected if the test increments (i.e. millivolt steps) don't coincide with a whole-number multiple of the ADC DAC steps. The "ripples" of the error is just the result of the "interference" of the two, slightly offset "frequencies" (simplified speaking...  ).


Edit: meant DAC but typed ADC... I hope this eliminates the confusion, sorry for that.

[JDubU]

That's what is to be expected if the test increments (i.e. millivolt steps) don't coincide with a whole-number multiple of the ADC steps. The "ripples" of the error is just the result of the "interference" of the two, slightly offset "frequencies" (simplified speaking...  ).

When you say "ADC steps" are you talking about the external 6 1/2 digit dmm and not the DP832's readback ADC?  I would think that the DP832's readback ADC was not involved in the voltage output unless it is part of a voltage output feedback loop.

[garrettm]

Thanks for uploading that Excel sheet JDubU. The error plot looks to be a 2nd order polynomial, though we would need to see the whole output, probably in larger 100mV increments, to really know. Hopefully I'll have time this weekend to contribute some data on this.

The dips are where the output remains the same value. You can see there is an alternating pattern to how many increments until the next digit isn't expressible. I observed this when printing custom characters as a volume bar on a display for my ES9018 DAC (attached the Excel doc that shows this graphically). This means the folks at Rigol likely used a 14-bit DAC, as 1 mV adjustment at 32V FS requires a minimum of 15 bits to express each possible output value.

[Gandalf_Sr]

All very interesting guys, thanks for sharing.

After PyCharm Cal with my 34461A, when I dial up 5.000 V from my DP832A, I get 5.000 V.

So my question is, is this discrepancy only there at <2V levels?

[TurboTom]

I'ld rather say Rigol uses at least 16 bit DACs in the DP832 PSU which are sufficient for a 1mV resolution at an output voltage range of 32V. The problem is that -- due to tolerances of the analog circuitry, and some DAC range "wasted" at the bottom and top end of the adjustable range for calibration purposes -- it cannot be made certain that every millivolt preset step can be represented by an integer number of LSBs of the DAC. I tested on my DP832 the 1mV increments to be more like 1.05mV with every tenth or so being only 0.5mV to stay within range (i.e. to compensate for the cumulative error). I assume that I see mostly 2LSB increments and 1LSB in case of the "small" step. CH3 is likely equipped with the same DAC, but since the voltage range is much smaller, here this problem isn't as visible.

At least every individual preset change is accompanied by an output voltage change in the correct direction. What else to ask for? 

[JDubU]

Using the Python program that eliminates the negative calibration points, I did a full calibration of my DP832.  I then ran sweeps of each of the channels and plotted the difference between the set and actual output voltages vs the set voltages.  The results are attached.   A spreadsheet of the calibration points used for each channel is also attached.

On channel 3, you can see that the zero crossovers in the difference sweep are close to the small number of calibration points. 
Not so much for channels 1 and 2 (much wider voltage range and many more calibration points).



Edit:  Fixed plot axis ranges for channels 1 and 2

[Gandalf_Sr]

I decided to try the Visual Studio running Python route as things were weird in my PyCharm setup.  I am however worried about the issue reoccurring that hoses my DP832 Cal.

Any chance of a few pointers as to how to proceed now that I've installed MS Visual Studio Community Edition with Python3.x 64 bit?  Can I get the calibration code from GitHub?  VS is offering me to get a project from GitHub.

[skander36]

I dont think you need to use GitHub unless you want to share a project ...
Just open the file and press F5 key (CTRL+F5 to debug).
Of course you have to install packages needed .
But what kind of problems do you have with PyCharm ?

[Gandalf_Sr]

....But what kind of problems do you have with PyCharm ?

Every time I open the project, the plugins are missing and the changes I made are gone. I'm pretty sure it's because Windows is fighting the installation from a security position.

[skander36]

It seem that you have set interpreter into the temp folder . Its location (base interpreter) must not include a TEMP in the path .
Anyway Visual Code need installing the packages you need (python-ivi + python-vxi11 + numpy) only one time (using pip3), and the they will be shared with other projects you will work in the future .

[Neuromodulator]

Hello,

I coded a script from scratch to perform calibration, but I've some questions about the cal points.
When I try to enter calibration measurements manually I get some default measured values that are different to the cal point voltage list. The  chan 1 DAC V sequence begins with "0.2, 0.6, 1.2, 2.0, 3.2, 4.1, ...", while the list I found in many  scripts begins with "0.2, 0.5, 1.2, 2, 3.2, 4.1, ...". There are 38 items on the manual input list while scripts contain just 36.

Can I use just any arbitrary value?

[garrettm]

Can I use just any arbitrary value?

Basically yes. You can make your own cal point list at upto 80 or 52 points. Note that adding more points can improve accuracy, but also does not guarantee getting better accuracy. Channels 1 and 2 are tricky to get into better cal than the default point list while channel 3 is very easily improved with extra points. At least from my experience. I've been meaning to play around with this futher, but work has derailed me at the moment, along with other projects I've been working on.

[garrettm]

I forgot to mention these threads:

https://www.eevblog.com/forum/testgear/rigol-dp832a-automatic-scpi-calibration-script/

and near the bottom of this thread and the next page

https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/675/

[Wolfgang]

Hi to all,

first thanks to all for the very useful links and scripts I found here, I have quite a few DP832s, and they *are* a bit drifty and *long* for a calibration after some time.
Neither sending them in not doing a manual cal was much help, so I decided to build a SCPI-based appliance that does all the signal routing from the PSU to the DMM (Keysight 34461A or better), plus a Python script that does all the settings, so the procedure now is just 1 click.

If interested, I'll put some more info on the web.

https://electronicprojectsforfun.wordpress.com/an-automatic-calibrator-for-rigol-dp832a-power-supplies/