Testing DAC performance

[aheid]

Based on the currently active microcontroller DAC thread, I got inspired to test the actual performance of the DAC in the STM32F303 boards I got.

As a fair n00b to things like this, I thought I'd get some input on my testing methodology before I waste a lot of time.

I've got my STM32F303 board ("bluepill" form factor) hooked up to a Raspberry Pi via USB-serial port. I've written some simple code for the STM32 which reads lines from the serial port, convert the input to a number and sets the DAC value to that number.

I've also got a Siglent SDM3055 DMM which I've connected to the Pi via LAN so I can control the DMM via LXI tools. I've written a Python script which sends a value to the micro, and then runs a SCPI command to read a few samples. This is working well.

Now, for the stuff I'm not sure how to do right.

The DAC has an unbuffered mode, where it has an output impedance of 15kOhm according to the datasheets. As such I figured I might as well just hook up the DMM only to the output, setting it in its 10MOhm input impedance mode. This seems to give me quite accurate results, but due to the capacitance of the cables it takes a while to settle. For testing the "static" performance like DNL, is this setup reasonable enough?

When testing say DNL, how should I take the DMM measurements? My measurement instinct was to take a few samples and take the mean or the median, but not sure if that is proper in a context like this? For now I'm writing the DAC value, waiting a second to let the output settle, then read 5 samples using the slow DMM mode.

The SDM3055 has 240000 counts, and switches from 2V to 20V range if set to Auto. So I figured having it fixed in the 20V range for all codes would be more consistent. That leaves me with only 100uV precision, but since each code is supposed to be 3.3/4096 = ~805uV it should be enough, no? Or should I leave it on Auto and maximize precision at the cost of consistency?

I'm probably making a mountain out of a molehill again, but first time I'm doing anything like this so lots of questions as usual

[Kleinstein]

The DMM is already slow by itself. So there is no real need to do extra averaging. Still taking a few more values could help to see if the value is stable. So the scattering may be also helpful.

Even with cable and input capacitance (tends to be more than the cable) of the DMM the time constant should not be so long. More like 1 nF *15 K = 15 µs . So it is more about a few ms. However the DMM may have internal delay that need settling of maybe 1/10 second or so.

Using only the 20 V range is probably the better way, as the resolution is sufficient.

Doing a slow run across all values is good for testing the DNL.  For getting the INL, the rather long times needed may add extra errors from drift. So here it may be better to reduce the number of points and not wait / average as much. For a consistency check maybe run the loop twice instead of one slow run.

[thm_w]

The DAC has an unbuffered mode, where it has an output impedance of 15kOhm according to the datasheets. As such I figured I might as well just hook up the DMM only to the output, setting it in its 10MOhm input impedance mode. This seems to give me quite accurate results, but due to the capacitance of the cables it takes a while to settle. For testing the "static" performance like DNL, is this setup reasonable enough?

Sounds completely reasonable since we are dealing with a DC signal.

Please post the results in this thread or another when you are finished. 

[aheid]

Thanks a lot for the feedback, much appreciated!

Ran one run each, DMM is less than one year old so should hold calibration, and was left on for an hour before starting. Room temp is stable at 23C.

The board is sporting the STM32F303CCT6 microcontroller. I supplied it using a USB power supply. Measured Vdd (= Vdda) = 3.3196 in both runs. For the buffered run I had an 8kOhm load, for the unbuffered I disconnected the load, so the output saw only the DMM's 10MOhm input impedance.

I ran the DMM in the "slow" setting, with 20V range, filtering off. One sample per trigger. The output in the files is the last of three samples taken, and the std dev was calculated using those three (mainly for consistency check). I used 1 second settling time after changing DAC code, the DMM is quite slow in the slow mode. In "medium" mode it settles instantly even in unbuffered, but then I lose a digit which I need.

If I ran the numbers right, DNL and INL is ~1LSB in both cases? For the buffered case I ignored the first and last hundred codes or so, where the buffer amp saturates.

edit: looking at the unbuffered data, it seems there's nearly a missing code, ~0.3mV step rather than 0.8mV, at positive multiples of 512. Bad resistor in the ladder? I'll re-run tomorrow to see, I also have another board for cross-checking.

So far so good, or did I miss something?

[Kleinstein]

Seeing an DNL / INL error in the range of 1 LSB is about normal. The specs allow for a maximum of  2 LSB DNL and 4 LSB INL. The errors can die different between units - much is likely because of tolerances. I am not sure if the DAC uses resistors or capacitors - my guess is more with capacitors as they can be made more accurate on a chip. There could also be internal correction for the worst case steps like near 512,... and this could kind of bring that error ideally to just < 1 LSB.

The calibration of the DMM does not really matter, as there is some uncertainty in the DAC gain and the DAC reference anyway.

[iMo]

Save as .csv file.
Cut off the flat data at the beginning and end.
Add the trendline..

[aheid]

Thanks again for the feedback.

So overall the DAC performance for this board, at least in terms of DNL and INL, can be said to be decent then I guess?

[mikerj]

The DNL performance looks remarkably good.  You will notice a DNL spike every 256 codes, which suggests this is an 8 bit DAC concatenated with a 4 bit DAC, and every 256 counts you get a "major carry" where both DAC codes get changed together.

Just for comparison I have attached the DNL measurement of an STM32F103RE I made back in 2012 using a Keithley 2010 (7.5 Digit) bench meter.  I was unimpressed with the DAC performance back then but seems they have greatly improved things.

[exe]

Do you have an INL chart?

[mikerj]

Fairly similar unbuffered INL performance, though the very poor DNL on my part can be seen.  The buffered INL is a disaster area on these parts if you include the ends of the range.

I tried making one, not sure if I did it right. It plots the difference between the measured value and the interpolated value between code 0 and 4095.

INL is the difference between the measured value and the ideal value expressed in units of 1 LSB e.g. (Vmeas - (DAC_CODE/4096)*Vref) / Vlsb

[jaromir]

I made the INL chart from OPs data, I cut off the non-linear part from start and end of range.
The DAC seems to fit the specs.

[exe]

thank you all very much. To me plots look good. Is it a cheap dev board from China?

[aheid]

thank you all very much. To me plots look good. Is it a cheap dev board from China?

As I mentioned above, it's this board from RobotDyn: https://robotdyn.com/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html

They have an AliExpress webshop as well: https://www.aliexpress.com/item/33016045350.html?spm=2114.12010612.8148356.22.529287d4PKhlJX

The form factor is identical to the cheap "bluepill" STM32F103 boards, but they've done their own PCB layout which is, AFAIK, better. For one, USB actually works. They also use slightly different components. This is reflected in the price of course which is a tad higher, but worth it in my view.

When measuring a LM385Z-1.2 using the built-in ADC, I got much less noise with the RobotDyn STM32F103 board compared to the "classic" bluepill board I got, simply by swapping boards on the breadboard (~1LSB vs ~3LSB).

Overall been very pleased with the stuff from RobotDyn.