\( \renewcommand{\renewcommand}{} \)

Author Topic: EEVblog #240 - Power Supply Design Part 8  (Read 21667 times)

0 Members and 1 Guest are viewing this topic.

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #50 on: January 31, 2012, 05:12:33 AM »
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?
« Last Edit: January 31, 2012, 06:28:34 AM by slateraptor »
 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: scotland
  • Pro EE guy many years ago, now it's a hobby.
    • IanJohnston.com
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #51 on: January 31, 2012, 06:26:02 AM »
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.
 

Online Rerouter

  • Super Contributor
  • ***
  • Posts: 2239
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #52 on: January 31, 2012, 06:34:59 AM »
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,
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #53 on: January 31, 2012, 06:40:06 AM »
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.
 

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 206
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #54 on: January 31, 2012, 07:14:29 AM »
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.
 

Offline nixxon

  • Frequent Contributor
  • **
  • Posts: 255
  • Country: no
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #55 on: January 31, 2012, 10:09:41 AM »
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
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 19321
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #56 on: January 31, 2012, 10:28:42 AM »
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.
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 190
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #57 on: January 31, 2012, 02:31:33 PM »
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
« Last Edit: January 31, 2012, 02:43:34 PM by Rutger »
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #58 on: January 31, 2012, 02:55:31 PM »
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.
 

Offline Zad

  • Frequent Contributor
  • **
  • Posts: 990
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #59 on: January 31, 2012, 04:57:52 PM »
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 :D


Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: scotland
  • Pro EE guy many years ago, now it's a hobby.
    • IanJohnston.com
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #60 on: January 31, 2012, 06:44:54 PM »
It would have been nice with line numers in the code editor window, by the way

Yep, the IDE sucks........so I use UltraEdit (IDE in external editor mode).
In UE you can configure custom buttons on the toolbar (with a bitmap of your own choice). The button simply runs a wee bit of VBS code which sends keystrokes to the IDE to perform the compile/upload (next best thing to command line arguments which the IDE doesn't support).

Net result, once you've opened your sketch in the IDE you just leave it there and never touch it again....everything is done from within UE.

Code: [Select]
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.AppActivate "Arduino 1.0"
objShell.SendKeys "^u"

Ian.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 19321
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #61 on: January 31, 2012, 07:51:58 PM »
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?

Not when it's less than expected result.

Dave.
 

Offline shebu18

  • Frequent Contributor
  • **
  • Posts: 291
  • Country: ro
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #62 on: January 31, 2012, 09:16:39 PM »
Dave, what IDE are you using? i recommend 0022 or 0020. They seem more stable and work better.
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 1900
  • Country: gr
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #63 on: January 31, 2012, 10:27:27 PM »
0022, 0020 is not just a different IDE. The API has changed.

Alexander.
Become a realist, stay a dreamer.

 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #64 on: February 01, 2012, 06:09:15 AM »
Dave. Can you explain to me why you went through the trouble of laying out the design and having a board made etc, and then trying to program the board? I am very new to electronics, and I would have put it all on bread board and the cranked out the code to make sure I had everything right while still on the bread board. Is one way preferred over the other?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 6656
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #65 on: February 01, 2012, 06:14:04 AM »
I guess Dave felt he could separate the hardware aspects from the firmware/software aspects in the design by keeping things modular. Once you are confident about the hardware part you can fix that into a board layout since the conceptual functions of the micro are already accounted for in the big picture. Developing the program on the micro won't change the overall system configuration.
I'm not an EE--what am I doing here?
 

Offline PeteInTexas

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #66 on: February 01, 2012, 06:42:43 AM »
I guess Dave felt he could separate the hardware aspects from the firmware/software aspects in the design by keeping things modular. Once you are confident about the hardware part you can fix that into a board layout since the conceptual functions of the micro are already accounted for in the big picture. Developing the program on the micro won't change the overall system configuration.

Yeah, but these pins with "alternative functions" is a " real trap for young players".  Your reading the pin out diagram and thinking that is enough but once you start writing the software it turns out you can't use them that way (or simply not recommended to use them that way) in conjunction with some other choice you made for some other pins; eg that reset pin.  Personally, I would have started with the software since that is the hardest part.  I know, everyone seems to think its the other way around dismissing it as just a "small matter of programming".
 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #67 on: February 01, 2012, 06:43:09 AM »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 6656
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #68 on: February 01, 2012, 07:00:46 AM »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?

That's probably just a matter of being confident in how things will work out, and finding a circuit board more convenient to work with than a tangle on a breadboard...

(There can always be another board revision to iron out wrinkles.)
I'm not an EE--what am I doing here?
 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #69 on: February 01, 2012, 07:09:55 AM »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?

That's probably just a matter of being confident in how things will work out, and finding a circuit board more convenient to work with than a tangle on a breadboard...

(There can always be another board revision to iron out wrinkles.)

I guess I am from a  way of thinking that once you pay to get a board, or whatever, then you should already  have the wrinkles ironed out. I may be looking at it in the whole wrong way since I am new though. and of course I thinking that from video 241 that the board cost $90. Maybe I am cheep, but seems like a lot of money to me to not be 100% sure. Is this normal in the industry?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 6656
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #70 on: February 01, 2012, 08:07:44 AM »
It's called "professional confidence". Once people reach a certain level of experience they can take steps like that and have sufficient confidence the design is going to work. Every now and then there will be a stumble, but on balance overall progress is faster when taking big steps than when taking smaller steps. Experienced practitioners tend to do the same in other fields too. You might also call it "impatience", but "professional confidence" sounds better  ;)

Also remember that in industry $90 is small change, whereas for the hobbyist it is much more significant. I guess Dave is somewhere in between right now...
I'm not an EE--what am I doing here?
 

Offline Short Circuit

  • Frequent Contributor
  • **
  • Posts: 428
  • Country: nl
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #71 on: February 01, 2012, 08:28:31 AM »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?
He doesn't... EEVblog #17 – I hope your next project DOESN’T work!   8)

Quote
I guess I am from a  way of thinking that once you pay to get a board, or whatever, then you should already  have the wrinkles ironed out. I may be looking at it in the whole wrong way since I am new though. and of course I thinking that from video 241 that the board cost $90. Maybe I am cheep, but seems like a lot of money to me to not be 100% sure. Is this normal in the industry?
Of course this is normal practice in industry; $90 is less than an hour worth of work.
Also prototyping and breadboarding does not eliminate errors. Build 2 or 3 real prototypes, and you can easily seperate stupid accidental mistakes from the real design errors.
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 1371
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #72 on: February 01, 2012, 08:28:58 AM »
Another thing to consider is that breadboards suck :)  They are hard to use, harder to debug, and unreliable (wires that look like they are in sometimes don't make good contact.  They are hard to use for SMD, and get ugly quickly for a moderately complicated design.  The worst part is that once you get your circuit working, it is very hard to see what you have, and very easy to make mistakes when converting it to a PCB.

If you can afford it, it is much nicer to make a PCB that you know is 95% correct, make some layout choices to facilitate debugging and repair, and then fix it up with bodge wires until it works.  Once you get all the bugs worked out, it is much easier to make the handful of changes to your PCB and send it out for a second spin.  Considering there is a good chance you will make errors in your first PCB even if it is based on a working breadboard, it isn't necessarily much more expensive on average.

In the professional world, if it saves an engineer a couple of hours of swearing at a breadboard, $90 is cheap.  For a hobbyist that may or may not be the case. You can also etch your own boards to save money.  This also takes some time, but has the advantage over a professional PCB of instant gratification.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 19321
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #73 on: February 01, 2012, 08:42:09 AM »
Dave. Can you explain to me why you went through the trouble of laying out the design and having a board made etc, and then trying to program the board? I am very new to electronics, and I would have put it all on bread board and the cranked out the code to make sure I had everything right while still on the bread board. Is one way preferred over the other?

Because to me it's important to have something real in my hands to play with, I prefer that to mucking around with a breadboard, as other have explained.
A real board let's you play with the case and physical aspects early in the design process, and gives you a better sense of project being on track and keeps your enthusiasm up for the project.
Most of my designs are SMD, so going to a PCB early is practically essential. That thinking just naturally follows over to through-hole projects.

Dave.
 

Offline asgard

  • Regular Contributor
  • *
  • Posts: 94
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #74 on: February 01, 2012, 08:47:29 AM »
Well, this is where I get to put my two cents worth (Yup, that's U.S. money, so that, and a banana will get you lunch for a monkey  :)

On the matter of the rolling/unrolling of loops:  After more than a decade in the RTOS business (MIPS/68xxx/PPC) it always amazes me that in a memory-constrained architecture it is the time component that is consumed first.  On the x86 and 68K the branch predictors are total shite.  No matter that the pipeline "knows" in advance where the branch is going to be, and the prefetcher knows to start working even before the branch is taken, the lookaside cache gets flushed for _any_ passage through a conditional branch instruction, even if the branch is not taken.  Believe me when I tell you that re-filling a flushed cache just sucks micro-ops, especially when the compiler optimizes nicely and ensures reference locality.  You might also note which real-estate on the CPU die represents the cache manager, as you can put an LC film over the die and see which parts are heating up the most.  Sometimes I have found out the bottlenecks in the application code that way.  It also might reduce the design-life of the part. :)

On the matter of the MCP DAC.  I had a good and hard look through the datasheet and really don't have any idea of the internal architecture of the DAC.  Is it successive approximation?  Is it some kind of screwy Sigma-Delta method?  How about double-buffered?  If the output is going to a R-2R resistive ladder just how good is the trimming process?  Hellifino.  I too can remember the day when _really_ accurate 8-bit DACS (Burr-Brown comes to mind) required great chunky bricks of epoxy with hand-trimmed resistors with an actual eyeball making laser decisions for every single part.  My brain curdles at the though of that job.


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf