EEVblog #240 - Power Supply Design Part 8

[IanB]

I think I would do the experiment implied by darrenb's question: successively increment the lsb of the data word you are sending and see what the delta of the output voltage is each time you increase it by 1. Are you getting the output precision you expect to be getting?

With a 2048 mV reference voltage and 10 bit resolution (= 1 part in 1024) I think you would expect the DAC output to increase by 2 mV with each step of the input word. If something is wrong the output would change in larger steps with every 2 or 4 increments rather than one small step per increment.

[jaapiyo]

I don't know if anyone pointed this already, but I think it would be nice if Dave made diffident kits for different mains power specifications. (Like EU, US etc.)

[slateraptor]

But..  Are you sure you're not just sending 8 bits to the ADC.  The ADC wants two bytes or 16 bits.  The first four bits are config bits so you're left with twelve.  You're sending two zeros (discard bits) at the front and then 10 bits of data but the last two are being dropped by the ADC.  12 - 2 (at the front) - 2 (at the end) = 8 bits of significant data being sent.

Based on the blog at 20:03 maybe the discard bits should be back at the end after the data bits instead of in front?

Dave is using a 12-bit DAC shifted out MSB first for the test; of the 12 bits, only the lower 10 bits are used. I don't know where you're getting the "- 2 (at the end)" part from.

If you pay close attention to the bit-bang code after the corrections were made, you'll see:

SPI_DATA <= 4 config bits
SPI_DATA <= 0
SPI_DATA <= 0
SPI_DATA <= (temp >> 9) & 1
SPI_DATA <= (temp >> & 1
...
SPI_DATA <= (temp >> 1) & 1
SPI_DATA <= temp & 1

If something is wrong the output would change in larger steps with every 2 or 4 increments rather than one small step per increment.

The issue is simply that the significance of datasheet specs, in particular non-linear error, was overlooked; the chip is within spec.

[baljemmett]

I don't know if anyone pointed this already, but I think it would be nice if Dave made diffident kits for different mains power specifications. (Like EU, US etc.)

I think it's designed to run off a plugpack or similar, rather than including the mains side of things -- so there shouldn't be anything that needs to change between mains systems.

[IanB]

Dave is using a 12-bit DAC shifted out MSB first for the test; of the 12 bits, only the lower 10 bits are used.

That doesn't make sense from a design perspective. In an output word the least significant bits affect the resolution while the most significant bits affect the magnitude. If you masked the most significant two bits to zero in a 12 bit word you would completely change the output value, whereas if you masked the least two bits to zero you would keep the same value but lose a bit (two bits) of precision. If you wanted the different chips in the family to be plug-compatible you would want to be masking off the lower two bits of the 12 bit word to leave a lower precision 10 bit word.

Although I have not had a chance to read the datasheet, I would be surprised if the chip designers dropped such a clanger.

[slateraptor]

That doesn't make sense from a design perspective. In an output word the least significant bits affect the resolution while the most significant bits affect the magnitude. If you masked the most significant two bits to zero in a 12 bit word you would completely change the output value, whereas if you masked the least two bits to zero you would keep the same value but lose a bit (two bits) of precision. If you wanted the different chips in the family to be plug-compatible you would want to be masking off the lower two bits of the 12 bit word to leave a lower precision 10 bit word.

Although I have not had a chance to read the datasheet, I would be surprised if the chip designers dropped such a clanger.

Yeah, I see my error. Corrected code for 12-bit D/A using only 10 bits should have been:

Code: [Select]

SPI_DATA <= 4 config bits
SPI_DATA <= (temp >> 9) & 1
SPI_DATA <= (temp >> 8) & 1
...
SPI_DATA <= (temp >> 1) & 1
SPI_DATA <= temp & 1
SPI_DATA <= 0
SPI_DATA <= 0

EDIT: Now that I really think about it, the previous code snippet I posted would work depending on how Dave worked out the arithmetic of value before storing into temp for the shift operation (which isn't shown). I'm confusing the crap out of myself.

EDIT EDIT: Ok. Head straight. Direct-no-modification interchangeability between 12-bit and 10-bit D/A won't work without some code modification.

If 2-bit zero mask is in MSB, then interchanging from 12-bit to 10-bit requires code modification because the 2-bit don't-cares is the last two bits sent on a 10-bit. For 12-bit, there's no scaling required for value, but for 10-bit, the zero mask will cause only 8-bit ranging if the value isn't scaled by a x4 multiplier.

If 2-bit zero mask is in LSB, then interchanging also requires code modification. 12-bit D/A would have to /4 scale for the desired mapping; popping a 10-bit without getting rid of the /4 scalar would limit output to 255.

Was the D/A even supposed to be interchangeable? Why bother if it can be shown that one performs better than the other?

[IanJ]

I think I would do the experiment implied by darrenb's question: successively increment the lsb of the data word you are sending and see what the delta of the output voltage is each time you increase it by 1.

I'd be inclined to do this also....but not just to rule out things like further code problems, but rather to test things like noise on the board amongst other things. Sure the datasheets seem to back up what he's getting but didn't Dave get some inconsitency with the repeatability of the output on his DMM?.........I haven't re-run the video to check again.

PS. Dave, have you been told yet how many folks are jealous you get to play with this stuff all day!!!

Ian.

[Rerouter]

jaapiyo the supply is made to run off a plug-pack, all that needs to be changed is that and it would safely meet most foreign standards, being how you would be playing with plain DC on your end,

[slateraptor]

I'd be inclined to do this also....but not just to rule out things like further code problems, but rather to test things like noise on the board amongst other things. Sure the datasheets seem to back up what he's getting but didn't Dave get some inconsitency with the repeatability of the output on his DMM?.........I haven't re-run the video to check again.

PS. Dave, have you been told yet how many folks are jealous you get to play with this stuff all day!!!

Ian.

How would measuring and recording the delta of 1024 steps rule out further code problems or test for noise? 12-bit INL alone is specified at +/-12LSB = +/-12mV at x2 gain. Even with all that data, you'd be hard pressed to determine if the error is internal to the D/A or external noise with just a delta snapshot.

[ndictu]

Well what do you know, today one webcomic I'm subscribed to posted this, kind of relevant:


Source: Abstruse Goose 432 - O.P.C. - visit the authors website to support him and see the alt-text.

[nixxon]

Another great episode, many thanks Dave.

It may not be important but the video shows you missing one more SPI_CLK typo, see @11:12 and later near the video end. The first line of a function is always the trickiest, and the last line, that's the trickiest too. Come to think of it... Anyway...

digitalWrite( SPI_CLK, LOW)

I guess this should be SPI_SCLK, as it is your DAC is missing 1/2 of the first clock cycle ?

I noticed that as well. It must be completely insignificant, because I can see no comment to your post regarding the uncorrected SPI_CLK string in the code:

I.e. at 13 minutes into the video there is a code line (3 lines below the code line that is altered) that is not changed:

digitalWrite(SPI_CLK, LOW);

It would have been nice with line numers in the code editor window, by the way

nixxon

[EEVblog]

Another great episode, many thanks Dave.

It may not be important but the video shows you missing one more SPI_CLK typo, see @11:12 and later near the video end. The first line of a function is always the trickiest, and the last line, that's the trickiest too. Come to think of it... Anyway...

digitalWrite( SPI_CLK, LOW)

I guess this should be SPI_SCLK, as it is your DAC is missing 1/2 of the first clock cycle ?

I noticed that as well. It must be completely insignificant, because I can see no comment to your post regarding the uncorrected SPI_CLK string in the code:

I.e. at 13 minutes into the video there is a code line (3 lines below the code line that is altered) that is not changed:

digitalWrite(SPI_CLK, LOW);

It would have been nice with line numers in the code editor window, by the way

nixxon

I'm well aware of thanks, thanks.
It doesn't matter because it's only a first time initialise thing, the line is already low when it comes into the subroutine on the second pass.

Dave.

[Rutger]

I can't understand why Dave moved the zero bits from the end of the bit banging sequence to the front?

From the formula in the datasheet, the output voltage would have been too high. I wanted 1mV/mA output.

Dave.

I agree that the zero bits need to be at the end as per the datasheet. This why when Dave start of at the low end of the mA range nothing seems to be happening, this is not noise but is cause by the truncation of the those low bit.  Put the zero bit at the end and give it a try. This is also why the DAC seems to produce an output that is to low.

Rutger

[slateraptor]

I agree that the zero bits need to be at the end as per the datasheet. This why when Dave start of at the low end of the mA range nothing seems to be happening, this is not noise but is cause by the truncation of the those low bit.  Put the zero bit at the end and give it a try. This is also why the DAC seems to produce an output that is to low.

Rutger

That was the first thing that came to my mind earlier today. I eventually dropped the idea after a bit of thought and convinced myself that the error is internal to the D/A.

[Zad]

Something that has occurred to me, and I need to follow up later with a good look at the schematic. Could it be that the offset is being partially imposed with the following op-amp's input offset bias?

Don't jump down my throat if this is clearly a load of crap, I have only just woken up and it is 5 to 6 in the morning here