Continue to Site

Charging super-capacitors via PWM

Status
Not open for further replies.

ACharnley

Member
I'm just trying to get my head around whether a circuit I've built is going to work correctly. I'll try and explain it.

I have a variable voltage supply at a fairly fixed current rating (0.5A). It's of a low impedance of around 3ohm and a low saturation point, net result being it'll supply 6V/0.5A and can potentially reach 36V with no load, but with a load it'll not offer 36V/0.5A. With a load the voltage will drop dramatically. Realistically 10W is it.

So, I need to charge a large super-cap rated 50F/5.5V. Due to other power requirements it is important to limit the current going into the super-cap, which will happily sink 7A on my power supply when it's near empty. I've implemented current and voltage monitoring to do this.

I have two ways to charge the cap, either buck or PWM. Currently I've gone for PWM, which may be a mistake. Why? Because PWM is the full voltage with periods. Effectively I'm sinking up to 36V into a 5.5V rated capacitor. Although the power supply would then drop significantly there is the possibility of over-charge.

This got me thinking. If the capacitor is rated 5.5V and my bench supply gives out unlimited amps, then I can record how many amps are sinked at a particular capacitor voltage level. I can then replicate this by PWM using the voltage/current monitoring values when the PWM is at 1 and 0. The PIC I'd use would therefore stop current supply once the cap reached 5.5V. The cap would see higher voltage pulses but wouldn't go above 5.5V.

1. Would this work?

If not, I can turn it into a buck. This introduces efficiency penalties.

The second issue I have is a follow-on boost circuit uses the super-cap supply. It's max input is 5.5V so quite possibly higher voltage's will destroy it. The PWM is just that, but maybe it'll still be safe because the super-cap sinks so much power those higher pulses won't even get it. I could stick a zener or TVS across it to dampen those pulses until the load causes the voltage-drop on the power supply (which will happen very quickly).

2. Does this sound feasible?

Cheers,

Andrew

First, I need to clear up what seem to be a misconception. Applying "full voltage" to the cap in theory isn't a problem since the cap voltage must charge up and won't instantly jump to the applied voltage.

In practice, the voltage will rise too fast in the cap and the switching circuits can't respond fast enough (if they could we would never use inductors in our buck converters). That's why we have an inductor in a buck converter. It basically just slows things down so our switching feedback loop is able to respond in time to stop the cap from overcharging. A resistor works too but is lossy so we don't use one.

For this reason, your answer to question #1 and #2 is that it won't work due to the speed reasons It won't work as long as you need to rely on a feedback loop without some non-existent futuristic hyper fast switches and controllers. You need to go buck with soft-start.

PWM will only work in open-loop mode where there is no feedback loop response time (since the converter basically knows ahead of time what's going to happen so it can react fast enough). However, this is obviously very inflexible and if your load on the cap varies then you are SOL.

The second issue I have is a follow-on boost circuit uses the super-cap supply. It's max input is 5.5V so quite possibly higher voltage's will destroy it. The PWM is just that, but maybe it'll still be safe because the super-cap sinks so much power those higher pulses won't even get it. I could stick a zener or TVS across it to dampen those pulses until the load causes the voltage-drop on the power supply (which will happen very quickly).
Is there a reason you need a separate buck converter followed by a boost converter? A SEPIC converter can do everything in one stage. Your concerns about the buck are are moot if you just use a buck converter on the cap input to begin with.

Last edited:
The voltage in the cap won't rise fast at all, they are that big it will take several minutes for them to charge. It is less of a concern when they are empty but when the cap reaches close to it's nominal voltage some of that 5-36v is then going to start hitting the boost IC (I think). The MCU will however be sending less current which is why I thought a TVS might work (as it won't be getting hit that much).

Reason(s) for not using Sepic; efficiency, inability to run down to 0.9V, MCU based power source switching for several circuits (chooses best efficiency) would be unavailable.

Edit: sorry it's not obvious why sepic wouldn't work, let me explain better.

Think of three sources; vDirect, vStore, vBoost

And several systems requiring power, the source being controlled by MCU based on source voltage level. For example consider a 3V LED, if there's input power the MCU switches to vDirect, if not it checks vStore > 3V and if so uses that, otherwise it goes to vBoost.

Last edited:
The voltage in the cap won't rise fast at all, they are that big it will take several minutes for them to charge. It is less of a concern when they are empty but when the cap reaches close to it's nominal voltage some of that 5-36v is then going to start hitting the boost IC (I think).

Hard for me to imagine it charging up that slowly but it is a very large cap. If that's the case, have you heard of hysteretic control (without the inductor that is typically used)? It's basically like your PWM idea but you don't need chart out the system response or the current draw vs capacitor voltage. If the voltage is too high, turn off. If the voltage is too low, turn on. Plus a deadband.

It's simple, responds as fast as you can get, is inherently stable and efficient at low duty cycles. It doesn't need an MCU and can be built from just a comparator and transistor. In your case, you would also need to also add something to override and shut off the transistor when overcurrent so that's probably an extra comparator and an AND gate.

The disdvantages are increased ripple and variable frequency response. There are variations on this theme to alleviate these issues at the expense of response time, such as the constant-on-time scheme which adds a form of feedforward, but these are more complex than just a comparator.

Last edited:
Hmm I don't follow, it sounds like you're saying to sink all the power if the capacitor voltage < max? That wouldn't work as the capacitor is a variable load - it'll act as a short up to about 3V and then some of the excess current will hit the boost IC. That's where my idea of mapping the current output to capacitor voltage via the MCU came from.

I'm probably confused!

Why can't you use a plain old constant current supply to charge the cap?

Hmm I don't follow, it sounds like you're saying to sink all the power if the capacitor voltage < max? That wouldn't work as the capacitor is a variable load - it'll act as a short up to about 3V and then some of the excess current will hit the boost IC. That's where my idea of mapping the current output to capacitor voltage via the MCU came from.

I'm probably confused!
You are. It just tops the cap off at the setpoint voltage as needed. Connects the source to the cap only as long as the cap is below the setpoint voltage, disconnect otherwise.

Ah, I'm actually doing that already to prevent backflow into an active rectifier. It would be easier (and simplier) not to current control via PWM and to cut based on voltage alone, but there's a reason for the current limiting. Upon system start-up the capacitor is effectively a short, however power must (a legal requirement) be available for 2 of the 3 sub-systems. Hence the need to current share, at least, if these sub-systems are turned on.

One of the reasons for using an MCU and voltage/current sensing at every stage is it gives the ability to decide which mode to use on a dynamic basis.

I have some degree of confidence the super-cap is not going to blow up, but less in the boost IC surviving the PWM pulses once the capacitor has a lot of charge.

Status
Not open for further replies.