Programmable Electronic Load - ADC and DAC BoosterPack test

Hi Jan,

I notice on your table of measurements for the DAC, that channel B was outputting +5mV for an input of 0; max for this channel was +6mV; channels C and D were -1mV at max.  I was reading through your calibration post to see how you dealt with this but it didn't cover DAC calibration.  Are you able to share how you calibrated this output: in particular, I'd be interested in understanding how (if) you dealt with the +5mV offset error.

Hi Jan,

I notice on your table of measurements for the DAC, that channel B was outputting +5mV for an input of 0; max for this channel was +6mV; channels C and D were -1mV at max.  I was reading through your calibration post to see how you dealt with this but it didn't cover DAC calibration.  Are you able to share how you calibrated this output: in particular, I'd be interested in understanding how (if) you dealt with the +5mV offset error.

Use with caution, because I haven' been able to define a stable and linear solution yet.

I'll include links to the source code in gitub....

I use two calibration functions. One that deals with offset, one with scale (I use a corrective multiplier):

My calibration functions are in this API: https://github.com/jancumps/msp432/tree/master/MSP432_SCPI_ElectronicLoad/calibration_impl

The function that uses the calibration corrections: https://github.com/jancumps/msp432/blob/master/MSP432_SCPI_ElectronicLoad/control_impl/control_strategy_constantcurrent.…

I have several of those offset + multiplier correction pairs. I'll focus on the DAC:

// current write calibration


bool calibrationSetCurrentWriteMultiplier(float value) {
    if(_bCalibrationActive) {
        _CalibrationData.current_write_multiplier = value;
    }
    return _bCalibrationActive;
}


float calibrationGetCurrentWriteMultiplier() {
    // The DAC drives the FET todo in my case the DAC setting multiplied by 0.000116 gives current
    float fRetval = 0.0;
    fRetval = _CalibrationData.current_write_multiplier;
    return fRetval;
}


bool calibrationSetCurrentWriteOffset(float value) {
    if(_bCalibrationActive) {
        _CalibrationData.current_write_offset = value;
    }
    return _bCalibrationActive;
}


float calibrationGetCurrentWriteOffset() {
    // The DAC drives the FET todo in my case the DAC runs 0.008 A when not driven
    float fRetval = 0.0;
    fRetval = _CalibrationData.current_write_offset;
    return fRetval;
}

Then in the current set function, I use these (stored in EEPROM) values to correct the DAC seting:

void ConstantCurrentStrategyControlFunction () {
    if (bConstantCurrentChanged) {
        uint32_t value = 0U;
        value = ((fConstantCurrent/calibrationGetCurrentWriteMultiplier())-calibrationGetCurrentWriteOffset()); // todo: double check if it is - or plus offset
        eloadRawSetDac(0, value);
        bConstantCurrentChanged = false;
    }
    return;
}

I've tried to explain the calibration approach:

Programmable Electronic Load - Calibration Steps (focus on Configure the Input Current Set Correction)

Programmable Electronic Load - Calibration Data in Flash

Perhaps I missed it when I read through the calibration steps - but I understand what you are doing above and I am trying to do the same, coincidentally!  It's effectively compensating for the gain (multiplier) and offset (addition).   I can see with my DAC that it isn't linear so I was expecting that I'd need to keep a look up table, which, again, seems to be the approach you have taken.  What I was hoping to understand is how you drove the DAC output to 0 when it has an offset of 5mV or to 2.040 when it has an offset of -1mV.  My DAC has a 0 offset of +7mV and a max offset of -2.5mV so it can't get a full range through a simple software adjustment - I think, I was hoping to get an insight from the work you have done here.

Thanks

I was expecting that I'd need to keep a look up table, which, again, seems to be the approach you have taken.

I haven't. I just store the offset and the correction factor. 2 values. But I haven't been able to turn this in a precise result.

My DAC has a 0 offset of +7mV and a max offset of -2.5mV so it can't get a full range through a simple software adjustment - I think, I was hoping to get an insight from the work you have done here.

I have tried to use an external additional OpAmp to deal with that offset. On the output of my DAC, I wired up  that opamp as analog adder, and provided the offset error as input.

So that if the DAC outputs 0.0001 V at 0, I would feed - 0.0001 into the opamp, and the offset would be erased.

It didn't work in my case. I blogged about it, but couldn't find it back right now. I'll search for it ...

I's a rough read, because it's a series of comments and tests, but here we're trying to address the offset: https://www.element14.com/community/docs/DOC-88254/l/programmable-electronic-load-analyse-the-summing-node-zero-point#co…

I made a PCB to test it. It fixed the DAC offset but never fixed the issues of the eLoad at the near-0 point...

Can you run a test that shows the output of the DAC vs the input value, for a range

• starting from DAC input == 0
• to a point where the output is showing a linear rise, then some additional poins?

In my case, the DAC did not react for a number of input values (until the offset was reached),

then started to work linear once that point was reached.

I tried with just two values (multiplier and additive), but it wasn't accurate enough (so why I thought a lookup table in EEPROM would be needed) and I had read that an OpAmp approach may help but I haven't investigated that at all.  The problem is the offset and the gain are not linear across the output range so a formulaic approach won't be enough.  Can't ignore the impact of INL and DNL on the output.  I have made a start on the test you mention, but only just so it will take a little while to get some results.  Once I have a set of results I can see if there's something within the data that allows me to derive a formula from it but that's highly unlikely - the datasheet states that the gain error only really kicks in at the higher range so it may be possible to do something simpler below that range. 

I've not built/designed a DC load for this, I was just thinking about a control board at the moment, but it is a similar approach to the one you and Peter took.  I am mainly doing it to have a play with a DAC and ADC and the problems that arise.  I guess there are only so many ways you can hook a DAC and ADC up, but I found what you did very interesting.

I was just thinking about a control board at the moment, but it is a similar approach

Yes, this is not load specific.

I tried with just two values (multiplier and additive), but it wasn't accurate enough (so why I thought a lookup table in EEPROM would be needed) and I had read that an OpAmp approach may help but I haven't investigated that at all.  The problem is the offset and the gain are not linear across the output range so a formulaic approach won't be enough.  Can't ignore the impact of INL and DNL on the output.

I experienced that too, but I don't want to spend time on this if I don't get feedback. I got no animo on this subject here on e14. I didn't have a burning need so I stopped where the blog stopped.

If you're going down this path, I'd like to join and share/compare experiences. I have the hardware and firmware to try out some approaches with you.

Tthat would be great - I’m sure I could learn a lot from you.  What I’ll do is write up what I’m doing and ping it over.  I’m using a 4Duino - spare one from when building my power supply - as the mcu.  I’m at the point of having the circuit breadboarded and a number of test sketches to drive it.  The dc/dc isolator has arrived so I will be trying that out tomorrow as it’s the biggest issue I have right now.

Andrew J , have you read the blog I did when building Jan and Peter's load?  That has some material on the low end of the DAC. Long story short, I adapted the analogue stuff after the DAC so the output didn't need to get to zero.

Programmable Load Build

There's also something along similar lines for a Microchip DAC in the following blog. I didn't do anything about the low end there because I didn't need to, but it illustrates what the internal op amp buffering the DAC output is doing and might be of interest:

FPGA: Making Waves

Yes, I read through the whole set of material, more than once, over the last year - I found it really interesting although I'd be a liar if I said I understood half of it. 

I'd originally started following Peter's series on power supply but that sort of faded away and instead led into the work that Jan carried on with the DC load.  I hadn't made the connection between the offset of the DAC I'm using (a Microchip one as it happens) and what you and Jan were/are seeing here.  The datasheet implies that the offset measured with an input code of 0x000 applies across the range and can be removed by software.  How, it doesn't say, and I'm not wholly convinced because it's not possible to feed a -ve input code to it which would be needed to drop 7mV down to 0.  That then leaves the gain which can be measured and applied at different points in the output and factored out.  Overall, that's the equation that Jan is using:  ActualInput = (Input * GainCompensation) - Offset Compensation.  That still leaves INL and DNL errors.  The compensation values on that formula I think will change through the range of outputs because I don't think they are linear - it's hard to tell of course, because the INL and DNL errors skew things.  Also, I haven't had time yet to do any comprehensive measurements to get a better feel for it.

Overall accuracy requirements will impact as well I guess: if a 1V output should genuinely be 1.000000V then that's going to be a lot more work than allowing for 0.999nnnV to 1.001nnnV.  I haven't made that decision yet as I'm still happily designing and trying out my own version.  In any case, from what I've investigated so far, it would seem that DACs will have errors in their outputs and that will have to be dealt with as part of downstream design as appropriate for need.  Something that you have done by the sounds of it.