EEVblog #240 - Power Supply Design Part 8

[electrode]

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]

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]

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]

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]

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]

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]

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]

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)

[Rutger]

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:
   
MCP4728-E/UN  at $ 1.44 / 100 with build in voltage reference (optional).

I know you didn't want surface mount parts but with the Maxim 4080 and the voltage ref chip you have chosen that option is already gone.

The advantage of having the extra 2 channels is that you can add/drive another power supply from the same DAC. And you can save on the cost of the parts, maybe you eliminate the external voltage ref chip.

Rutger

[Rerouter]

the thing is, until dave reveals the second board, it seems pretty clear his design had in mind only a single supply, and until he reveals his secret purpose, a dual dac is all thats needed, albeit a better quality one at a similar price is something he is likely looking out for, (about $6 for a dual dac without such an insane offset)

[firewalker]

Are you sure there will be second board (did Dave mentioned something?)? Maybe the space is needed for a flat lead acid battery.

Alexander.

[Nick Gammon]

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 required
y = SPI.transfer (x);  // send a byte, get one back
digitalWrite (SS, HIGH); // finished with slave

[electrode]

From Dave at the video comments on the main page:

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]

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]

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]

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]

Speaking of looking forward, is there an ETA on part 9?

[EEVblog]

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]

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]

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).

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]

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... 

[EEVblog]

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]

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]

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]

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

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

Dave.