Bench Power Supply

I decided to mothball my power supply project. I may come back to it one day, I may not. I sort of had a rage-quit moment this week-end, when I blew one of the channel's regulator circuits. The thing is, I didn't do anything I didn't think it could handle. Now, the voltage output is always 2 volts higher than what I set it for, and the current-limiting seems to never kick in, it goes to 1 full amp (or at least that's the max I'm capable of measuring) when I short it. Meh. I thought it was more robust than it appeared to be, and I didn't want to spend more time to complete it, only to run into more issues. It needs some re-design.

The Bench Power Supply (Powerbug 6000), in its
open casket, the mothballs are in my head.... and my heart.

So as a wrap up, I'm just going to post some pictures I (and my wife, player with an in-law's camera) took of the project.

Slowly I turned...

It's been a slow summer. I'm still making progress on the bench power supply. It's in the "just get it done so I can move on" phase.

I've got the regulator part of the circuit finalized. I don't think it's perfect, but I think if I ever want to work on something else, I need to move ahead. Since the powersupply has three channels, I plan to have 3 discrete boards.

Here is one of the boards, pre-soldering:

One channel regulator board.

On the left side of the board, there are two PWM'ed input for the voltage and current settings, and two "Vsense" and "Isense" analog outputs that will run directly to ADC inputs on the Atmega 644. The top of the board will have inputs from the ATX power supply at 12 and 5 volts. A variable 0-9V output will come form the bottom-right side.

Bench Power Supply - Progress Update

Here's a little video I shot of my power supply in action. I think it is very close to being workable. I have a bunch of placeholder parts, since I'm holding off on placing an order for final parts until I do more testing.

One thing I've been working on recently is the current-limit-mode indicator LED's. It's a little but harder of a problem than I thought it would be. My current limit comes from Q1 in the schematic. As the current flowing through R1 rises, it causes the voltage on the "+" input of the U2 op-amp to eventually exceed the ISET voltage. This drives U2's output high which in effect ties U4's output close to ground. My idea was to connect the "+" side of U4 to a spare input on my IO expander, and sample it's value in code. My initial thoughts were that a low value indicates that the circuit is in "current limit" mode. It turns out there are numerous reasons that this wont work. The face palm moment was realizing a low VSET value will also trigger the current limit logic regardless of the actual current! The other major problem was that I was using a digital input to estimate what is really an analog voltage.

Anyways here's the video:

Bench Power Supply - Point of no return

Just  a quick(not really) update.

I've got a lot of the code side of things worked out. I had a lot of "fun" doing software debouncing for my rotary encoders. After hooking up a logic analyzer, I realized that using the I2C IO expander for the encoders was not going to work. The I2C chip I'm using, an MCP23018, has a couple interrupt lines, one of which I used to alert my ATmega that the expander needed attention. Since the expander is an I2C "slave", this is the only way it can initiate communication with the microcontroller. An interrupt handler in my code would set a flag and exit. When my "main update loop" got around to checking that flag it would then issue a series of I2C commands to query the expander for the encoder line change that triggered the original interrupt. All of this turned out to be way too slow to process encoder input. The main culprit was the fact that it depended on the main code loop getting around to checking that flag. From my logic captures, I could see that encoder edge transitions could happen sometimes 5ms apart. When there was a lot going on, such as heavy LCD updates, my main loop could sometimes take 20-30ms to complete one loop. Ouch.

You can't easily, if at all do I2C in an interrupt handler, you can not be sure of what state the I2C line is in when the interrupt fires. In the end, rather than figuring out a way to do I2C in an interrupt, or doing more flag checking (which would have been a hack, sometimes most of the CPU time is spent deep in the LCD bit bang code), the simpler solution was to move the encoders to the AVR itself. I had to give up UART functionality that I was planning, since I'm tight on allocated pins, but I was leaning toward doign that anyways.

Bench Power Supply: Power Control

In this truly awful video, you can see my bench power supply at work.

For testing, I coded a function to cycle the voltage between 0-5.0V.  In reality, 0-100% duty cycle is the parameter the code changes. A "PWM'ed"  square wave(yellow trace) is fed to an RC filter, which is then buffered with an op-amp(the op amp output is the blue trace).

You can also see the LCD updating in realtime. The voltage reading is coming from the ADC on the ATmega 644. It's has a hard time keeping up with the displayed "SET" value, but there probably several factors, the biggest of which purely software related, I simply don't refresh the "widget" that displays the voltage reading any faster than 3Hz. 

(Ignore the Amperage settings/reading, they're not coded yet, the analog portions of that have me the most intimidated)

Anyways, crappy quality aside, this is a great demonstration of how PWM signals can be used to generate analog voltages from a digital MCU pin, and how "duty cycle" affects what comes out of a simple low-pass RC filter.

--P

Bench PSU: AVR JTag update #4 (I think I can stick a fork in it now)

I've slowly but surely made progress on my bench power supply. I think my JTAG issues are a thing of the past. I've done a couple things to ensure reliable communications, and I've now got the AVR Dragon running at 2 MHz with 0 errors so far. First, I put the 20pf capacitor on the JTAG clock line, at the breadboard side. I know I derided the lowly 20pf cap in the past as a pawn of the Capacitor Cartels, but I'm eating crow now.

The second thing I did was to create a JTAG "Bread Head", so named in and inspired from this post on Blondihacks: Bread Head. I'm not a great photographer, and macro shots seem to be even harder, but here it goes:

My Atmel 644 (and pin compatible DIP 40s) JTAG
Breadboard adapter. I could probably trim a little more
perfboard off the top.

Bench PSU: AVR JTag update #3

In my last post, I reported that I got my AVR Dragon to work in a 5V circuit by creating what I called a "shielded JTAG cable":

I speculated that "cross talk" interference might have been causing my un-reliable JTAG when running my circuit at 5V. (It worked fine at 3.3V, but some components in my final circuit are 5V parts, I also noticed that many 20 Mhz AVRs are only rated to run at a full 20Mhz above about 4.5V)

I got my DSO Quad hobbyist class digital scope last week, and I was all set to write up a really scientific post documenting my construction and testing of a shielded AVR cable, then something strange happened. I switched to another 2x5 "unshielded" JTAG cable to reproduce my original problem. When I hooked up my DSO to the JTAG clock line, the programming functionality worked flawlessly at 5 Volts! Curse you, Heisenberg! (Yes, I know that this is not really the meaning of the Uncertainty Principle, but any time I run across a case where the act of measuring something alters the quantity I'm trying to measure, I think it it).

Bench PSU: AVR JTag update #2 (it's alive!)

I think I figured out the noise issue on my ATmega setup.

After I posted my ATDH1150 teardown yesterday, I got to thinking about the "JTAG-X" port on the device:

It's a 2x7 JTAG port that looks to be wired to the same lines as the 2x5 "JTAG-A", except that one of the two rows is almost, if not all, connected to GND. I'd seen this done other ribbon cable type connections, but I never really thought much about why this was done. The effect of it is to make every other wire in the ribbon a GND line. I'm probably butchering terminology here, but I think this is a form of shielding. It helps to reduce electromagnetic interference, or cross-talk(is that the right term?) between the signal lines.

My experiments so far with my AVR Dragon-breadboard setup lead me to strongly suspect that noise was the culprit, and contrary to my initial intuition, many types of noise can become more of  problem with higher voltages.

Bench PSU: AVR JTag update

I did some more experimenting with my AVR Dragon JTAG woes today, despite not really having the time (I was supposed to file my taxes, but thanks to the District of Columbia, I get one more day. Why put off until tomorrow what you could easily do the day after tomorrow?

To summarize my last post:

ATmega 644 in a breadboard, JTAG functionality only seems to work reliably when powered at 3.3V vs 5V.

I was a little distraught that I had to spend time with dumb issues like this, and not on to cooler stuff. In building this power supply though, I'm sure that I'm going to face a lot of noise issues. I felt dumb.

Well, I'm an Engineer, and what do Engineers do when they feel dumb? They get empirical. Hypothesize, Measure, Test, Rinse, Repeat. Through process of elimination, I knew I could come up with a list of things that were not the cause of my problems. I made a list of random notes as I tried various things that might show a different behavior.

AVR JTAG programming oddities

I recently launched a new project, I'm working on a bench power supply. I've wanted to do the "old ATX PC PSU to bench power supply" thing for a while, and there was a recent series on the EEVBLOG whose design I'm taking a lot of inspiration from. (That David Jones is a freakin' genius). I want to have a little more "kapow" than his design, 0-9 V, 3 channels. I don't know if that's a folly on my part, but time will tell.

I finished up the "thinking a lot about it" phase, where I watch TV and daydream about what I want to do, and I moved into the prototype/experiment/pre-design phase.

I'm going to use an ATmega 644 as the main MCU to drive my logic. I'm wavering between that and the ATmega 328, but I just think the 328 probably doesn't have enough pins.

I've thrown together a few lines of code for doing the LCD display logic, using a "HD4478x" library for AVR's I found on the internet(I'll wait until my project is farther along before giving credit, since I might swap it out or roll my own in the end).

I went to test on a breadboard tonight and I discovered something very perplexing that I've not run into before...