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

0 Members and 1 Guest are viewing this topic.

#### electrode

• Regular Contributor
• Posts: 141
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #100 on: February 01, 2012, 10:58:15 pm »
Fair enough. Just saying it can be done, and it usually successful. Other than quick and dirty tests on breadboards, I usually stick a couple of 4k7 or 6k8s, as my time in potential troubleshooting is worth more than 2 cents.

#### ModernRonin

• Contributor
• Posts: 44
##### Closed loop voltage control for the DAC?
« Reply #101 on: February 02, 2012, 09:47:29 pm »
Since the DAC seems to be inaccurate, I wanted to ask what everyone thought about using some kind of closed loop control scheme for it. I realize this is probably the wrong answer; the right way to do things is to get a DAC that doesn't suck.

But if there are no DACs that don't suck, or the non-sucky ones are so expensive as to be prohibitive and/or not available in through-hole... what needs to be done to close the control loop on the DAC?

I mean sure, you can feed the DAC voltage back to the ADC and measure it. Now you're depending on the accuracy of the ADC. My guess is that high precision ADCs are a lot more expensive than high precision DACs.

So, is there any way to do some kind of analog wizardry with the voltage reference we already have? Off the top of my head, my idea goes something like this... we already have a uCurrent on the board, so let's use it. Take the voltage reference and the output voltage of the DAC and connect them with a 1k resistor. Then use the uC to measure the amount of current flowing through the resistor. Said current being proportional to the voltage differential between the two sources. Then feed that number back into the AVR and do some math, and adjust the data being written to the DAC accordingly.

Am I being completely insane here?

#### ejeffrey

• Super Contributor
• Posts: 2000
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #102 on: February 02, 2012, 10:00:11 pm »
Any way you slice it, you have to trust your DAC or your ADC.  How are you going to read the ucurrent?  With an ADC.

The best thing to do is to use an intrinsically linear DAC architecture.  For instance, compared to a string DAC, an R2R DAC has much better INL although the DNL may be worse.  PWM and sigma-delta DACs are nearly perfectly linear by nature, so they are a good choice when that is important.  They work on the principle that a 1-bit DAC can't be non-linear as there are only two states.  Two points define a line.  Thus the techniques use interpolation in time to make intermediate values.  This works because we can generate very stable clocks.

#### Rufus

• Super Contributor
• Posts: 2094
##### Re: Closed loop voltage control for the DAC?
« Reply #103 on: February 02, 2012, 11:52:05 pm »
Am I being completely insane here?

Not completely

The way to improve performance of DACs and ADCs with loose specification it so calibrate them (which would also calibrate out other error sources like the reference voltage and resistor matching).

It is only software and an bit of NV memory and requires 5 minutes and a decent multimeter to perform. I think I remember Dave saying or writing he couldn't be bothered with scaling and calibration. If the PSU ends up being popular someone will write the software to do it properly.

#### alm

• Guest
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #104 on: February 03, 2012, 01:57:40 am »
Doing that 5 minute calibration for a production run could be a pain, however, although it wouldn't be such an issue with a kit. For a batch of 50, like with the uCurrents, it would require about four hours. I guess Dave could think of a more enjoyable way to spend those four hours, for example by ranting about Microchip DACs . It also requires the error to be stable.

#### Rerouter

• Super Contributor
• Posts: 4431
• Country:
• Question Everything... Except This Statement
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #105 on: February 03, 2012, 11:09:28 am »
software calibration procedure wouldn't be that bad if the user had to do it, turn on kit, hold in 2 buttons as it starts up,

then measure and trim in with the rotary encoder, and have it update on each time you fill in the value to narrow the error, until each value matched up exactly?

then one could probably get away with a correction formula, maybe a bit complex to make something to accurately calculate over the whole range, (please shoot me down if i am wrong, just thinking) or are math functions really that performance prohibitive, as i can neither see any way to calibrate the reference, DAC or ADC short of software,

#### dcel

• Regular Contributor
• Posts: 179
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #106 on: February 03, 2012, 02:07:20 pm »
Hi all...

I believe I found a possible answer to the last addendum of the video regarding the I2C bus problem with the LCD. I think it is the -ACK from the LCD trying to pull that line low. I found this info in my datasheet for the MCP23016 that I have.  Apperantly, there are a few protocols for I2C and some slaves -ACK and some dont, esp., if being read from exclusively. If someone more knowledgeable than I about I2C would chime in that would be great.

Chris

#### FreeThinker

• Frequent Contributor
• Posts: 791
• Country:
• Truth through Thought
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #107 on: February 03, 2012, 05:16:20 pm »
Hi all...

I believe I found a possible answer to the last addendum of the video regarding the I2C bus problem with the LCD. I think it is the -ACK from the LCD trying to pull that line low. I found this info in my datasheet for the MCP23016 that I have.  Apperantly, there are a few protocols for I2C and some slaves -ACK and some dont, esp., if being read from exclusively. If someone more knowledgeable than I about I2C would chime in that would be great.

Chris
Yes This has been pointed out by a couple of people. Seems logcal to me that the device SHOULD ack data sent but not all devices do (apparently) not very helpfull in a fault situation. Don't think it is a big deal but easily fixed (I think)
Machines were mice and Men were lions once upon a time, but now that it's the opposite it's twice upon a time.
MOONDOG

#### Rutger

• Regular Contributor
• Posts: 205
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #108 on: February 05, 2012, 01:25:45 am »
Dave, I was looking at the different options for the DAC, because I was looking at the dual version of your power supply (eg with a negative output as well) and came across the following 4 channel 12 bit DAC:

#### firewalker

• Super Contributor
• Posts: 2347
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #110 on: February 05, 2012, 02:28:07 pm »
Are you sure there will be second board (did Dave mentioned something?)? Maybe the space is needed for a flat lead acid battery.

Alexander.
Become a realist, stay a dreamer.

#### Nick Gammon

• Contributor
• Posts: 41
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #111 on: February 05, 2012, 10:49:36 pm »
No. This is a dictatorship, I'll code the way I like, no one else gets any say in it until it's released

Forgive me if this has been covered elsewhere, but why are you bit-banging SPI in the first place? The Atmega328 has hardware SPI, and hardware I2C. Sending data to the device should be as simple as:

Code: [Select]
digitalWrite (SS, LOW);  // or high, whatever is requiredy = SPI.transfer (x);  // send a byte, get one backdigitalWrite (SS, HIGH); // finished with slave

#### electrode

• Regular Contributor
• Posts: 141
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #112 on: February 05, 2012, 10:54:11 pm »
From Dave at the video comments on the main page:
Quote from: Dave
I’ve been asked this countless times now. I am leaving the hardware SPI free for the external serial interface, for Ethernet, or other serial device that needs it.

(Would this have been a problem if all on the hardware bus anyway?)

#### Nick Gammon

• Contributor
• Posts: 41
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #113 on: February 06, 2012, 12:02:04 am »
Er, but ...

SPI is designed to be paralleled up. Not using it in the core device, but leaving it free for something people might or might not add, seems to me to be doing it backwards.

You already have the separate chip selects, which you need to activate each chip. Now all you have to do is share the SPI pins (MOSI, MISO, SCK). The only (device) output line (MISO) goes high-impedance whenever the target device is not selected. It's designed like that.

That is not at all taking away the ability to use other chips like Ethernet, SD cards or whatever. They would each just need their own chip select, and I see you have four free on the MCP23008 chip anyway.

The hardware SPI has buffers, interrupt capability etc.

In fact, freeing up your SPI-DIN, SPI-CLK etc. pins would mean you can probably bypass having to use the port-expander just to toggle the chip select lines. So, the whole thing becomes much simpler.

(Would this have been a problem if all on the hardware bus anyway?)

No, that's my point.

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #114 on: February 06, 2012, 12:21:29 am »
Nick, you've missed the whole point.
The point is that keeping the bus entirely free allows people to do anything they want with it, not just SPI.
Beginners can play with the pins and port, or the SPI or whatever and not have to worry about screwing up the existing ADC/DAC interface.
And it allows the separate DAC/ADC interface to operate on it's own timer interrupt or something similar as well without having to worry about conflicts.

Dave.

#### Nick Gammon

• Contributor
• Posts: 41
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #115 on: February 06, 2012, 12:42:16 am »
OK, Dave.

Adding an Ethernet interface to a sophisticated power supply doesn't sound to me like a beginner project, but you're the boss!

I look forwards to seeing it.

#### electrode

• Regular Contributor
• Posts: 141
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #116 on: February 06, 2012, 12:45:09 am »
Speaking of looking forward, is there an ETA on part 9?

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #117 on: February 06, 2012, 01:07:45 am »
Adding an Ethernet interface to a sophisticated power supply doesn't sound to me like a beginner project, but you're the boss!

The whole point of going the Arduino route is that it does become trivial for anyone to add such a feature.
I'm not that fussed myself, but people may very well want to add such a thing.
Or experiment with the ports in unknown ways for their own purposes etc.
The more you decouple the core function like ADC/DAC from the expandability ports, the easier it all is.
Why do you think many modern micros have more than one SPI and I2C port?
If this AVR had two hardware SPI ports I still would have used two separate hardware SPI ports for this very reason.

Dave.

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #118 on: February 06, 2012, 01:09:40 am »
Speaking of looking forward, is there an ETA on part 9?

I don't have ETA's.
I don't even know what Part 9 will be until I decide to do it.
I have the PCB layout time lapse to do, maybe something on the 10bit DAC and ADC parts if there is something worth sharing there, maybe the 2nd board or system engineering part, I don't know....

Dave.

#### Nick Gammon

• Contributor
• Posts: 41
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #119 on: February 06, 2012, 01:29:22 am »
If this AVR had two hardware SPI ports I still would have used two separate hardware SPI ports for this very reason.

It doesn't need two hardware SPI ports because you can share them between multiple devices. Ditto for the I2C port.

Having said that, though, the hardware does support "USART in SPI Mode" (page 204 of the datasheet). So you effectively have two SPI ports (although the USART one is master only, not that this would matter in your case).

I'm not sure what multiple SPI ports really gives you. Already SPI is pretty fast (eg. about 3 uS per byte, which is around 48 clock cycles). Pretty much as fast as an interrupt can be serviced. So realistically you could only use one SPI port at high speed anyway (by the time you store the data, loop, test if it's time to get another byte and so on).

Quote
And it allows the separate DAC/ADC interface to operate on it's own timer interrupt or something similar as well without having to worry about conflicts.

Once you bit-bang, interrupts become more of an issue because you are handling the timing, not the hardware.

Anyway, thanks for sharing all your design ideas, it's interesting to see how it all comes together.

#### IanB

• Super Contributor
• Posts: 9608
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #120 on: February 06, 2012, 01:33:54 am »
There's an interesting design conundrum here. One tries to separate the core functions from the bits people might want to hack, so that misguided hacks don't break the core functions. However, the whole thing inside the MCU is operating on software, and if someone hacks the software badly they could break everything. The ultimate solution here would be two MCUs--one dedicated to the core device function running a fixed program, and one for user programming separated from the core functions with protected interfaces...
I'm not an EE--what am I doing here?

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #121 on: February 06, 2012, 01:39:50 am »
I'm not sure what multiple SPI ports really gives you. Already SPI is pretty fast (eg. about 3 uS per byte, which is around 48 clock cycles). Pretty much as fast as an interrupt can be serviced. So realistically you could only use one SPI port at high speed anyway (by the time you store the data, loop, test if it's time to get another byte and so on).

In this case I've made it very clear what advantage it gives you and anyone playing around with it.
A beginner can now screw around with the SPI/serial I/O interface all they want without worrying about screwing up any of the core functionality of the project.
IMO that is a big advantage and is a main reason why I did it that way.
When designing stuff like this you have to think about those sorts of little things that might make someones life easier down the track, or give them the flexibility to do something you as the designer haven't thought of.

Dave.

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #122 on: February 06, 2012, 01:44:15 am »
There's an interesting design conundrum here. One tries to separate the core functions from the bits people might want to hack, so that misguided hacks don't break the core functions. However, the whole thing inside the MCU is operating on software, and if someone hacks the software badly they could break everything. The ultimate solution here would be two MCUs--one dedicated to the core device function running a fixed program, and one for user programming separated from the core functions with protected interfaces...

And that's the trick.
Nick is saying don't bother, forget it, just use the most elegant technical solution because you can
My approach is to do some small things in this regard that may possibly help some people people down the track (maybe even myself).
And you propose designing the Space Shuttle by committee

Dave.

#### Nick Gammon

• Contributor
• Posts: 41
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #123 on: February 06, 2012, 02:21:30 am »
Nick is saying don't bother, forget it, just use the most elegant technical solution because you can
My approach is to do some small things in this regard that may possibly help some people people down the track (maybe even myself).

You've certainly helped me, Dave.

Heck, I even made up your dummy load a couple of days ago. Picture here:

http://gammon.com.au/forum/?id=11525

What I like about your approach is that you often describe the elegant technical solutions. For example, in the first video for the power supply you showed how you could have used two voltage regulators (one for current and one for voltage) but with careful, elegant, design, you cut it down to one. I like that.

You research stuff, and you choose the right part for the job.

#### EEVblog

• Administrator
• Posts: 30256
• Country:
##### Re: EEVblog #240 - Power Supply Design Part 8
« Reply #124 on: February 06, 2012, 03:30:54 am »
You research stuff, and you choose the right part for the job.

Not always.
Sometimes I just do things because I want to

Dave.

Smf