Power supply filter capacitors

I'm woefully undereducated to be doing this, but I figure the best way to 
learn is by doing, so I need a little help with my current project.

I'm designing a lighting dimmer around the Altera Cyclone EP1C6 in the 240 
pin package. I will be using the chip to turn on and off up to 128 
optoisolators at a frequency of 120Hz.  (The optos will feed the gate pins 
of TRIACs which will turn Christmas lights on and off. By turning the optos 
on in the middle of an AC half-cycle I plan on getting dimming in addition 
to on/off.)

Each opto will draw a maximum of 7mA.  The FPGA will be sinking the current 
from the opto, not sourcing current.

Absolute worst case would be all 128 channels switching simultaneously, 
although I doubt that would happen very frequently.  (For one, I don't have 
enough circuits to drive 128 strings of Christmas lights without tripping a 
breaker at the house.)

I have no clue how to determine what size capacitors to put between the 
VCCIO pins and GND. If anyone could give some guidance, I'd appreciate it. 
(If you happened to use my particular implementation as an example, I'd 
appreciate it that much more!)

Thanks, all!

-Matt 

Not really answering your question, but... Sink or source, 128 x 7mA
is a lot, your FPGA may not be able to handle it. You probably need
something a bit more efficient or maybe an extra level of transistors
to give current gain.

Yes, this is on my list of concerns. For the time being I plan on solving 
the problem by using the "don't do that!" method. I started *way* too late 
to be ready for a Christmas light show so I won't be able to really fix this 
problem this year.

"Chris Maryan" <kmaryan@gmail.com> wrote in message 
news:1193371715.999672.227300@y42g2000hsy.googlegroups.com...
> Not really answering your question, but... Sink or source, 128 x 7mA
> is a lot, your FPGA may not be able to handle it. You probably need
> something a bit more efficient or maybe an extra level of transistors
> to give current gain.
> 

On Oct 26, 7:39 am, "Nevo" <nev...@hotmail.com> wrote:
> Yes, this is on my list of concerns. For the time being I plan on solving
> the problem by using the "don't do that!" method. I started *way* too late
> to be ready for a Christmas light show so I won't be able to really fix this
> problem this year.
>
> "Chris Maryan" <kmar...@gmail.com> wrote in message
>
> news:1193371715.999672.227300@y42g2000hsy.googlegroups.com...
>
> > Not really answering your question, but... Sink or source, 128 x 7mA
> > is a lot, your FPGA may not be able to handle it. You probably need
> > something a bit more efficient or maybe an extra level of transistors
> > to give current gain.


You can never have too much capacitance on the VCCIO, in my opinion.
At 120 Hz, it should be easy for you to stagger the output timing
of the various triac drivers without materially affecting the dimming
quality.  This would reduce the issues of simultaneous switching and
also reduce the high-speed decoupling requirements on VCCIO.

However there may be another issue that gets you in the end.  Where
are you mounting all the triacs and how easy is it for the triac
switching noise to find its way back to the FPGA power system?  Even
with optocouplers, if your input supply shares AC wiring with the
triac AC system you may be in for trouble.  Think about any possible
coupling paths.

Have Fun,
Gabor

>...At 120 Hz, it should be easy for you to stagger the output timing
>of the various triac drivers without materially affecting the dimming
>quality

I don't understand how he can do this.  For a given brightness,
doesn't this fix when he has to switch on the triac?

(There's no choice about when to switch off:  it won't switch off
until the current falls to zero at the end of the half-cycle).

Mike

MikeShepherd564@btinternet.com wrote:

>>...At 120 Hz, it should be easy for you to stagger the output timing
>>of the various triac drivers without materially affecting the dimming
>>quality

> I don't understand how he can do this.  For a given brightness,
> doesn't this fix when he has to switch on the triac?

> (There's no choice about when to switch off:  it won't switch off
> until the current falls to zero at the end of the half-cycle).

If you stagger in nanoseconds it won't have a large effect
on the light output, which may be in the 100 microsecond range.
(A half cycle is 8.333ms, one hundredth is 83.33 microseconds.)
Even so, you can stagger them between cycles and average to
the desired value.  That would be more true for large light
bulbs (such as use in theaters) than for small christmas lights.

-- glen

>>>...At 120 Hz, it should be easy for you to stagger the output timing
>>>of the various triac drivers without materially affecting the dimming
>>>quality


>> I don't understand how he can do this.  For a given brightness,
>> doesn't this fix when he has to switch on the triac?

>> (There's no choice about when to switch off:  it won't switch off
>> until the current falls to zero at the end of the half-cycle).


>If you stagger in nanoseconds it won't have a large effect
>on the light output, which may be in the 100 microsecond range.
>(A half cycle is 8.333ms, one hundredth is 83.33 microseconds.)
>Even so, you can stagger them between cycles and average to
>the desired value.  That would be more true for large light
>bulbs (such as use in theaters) than for small christmas lights.

Staggering sub-millisecond sounds like a good idea (up to the point
where the largest brightness error is unacceptable).

Averaging over several half-cycles would need some experiment. Perhaps
it could work for very high-power bulbs (those with a lot of thermal
inertia), but for domestic bulbs (say 100W), the  flicker would soon
become visible (well before it reaches the level where the same error
in "constant" brightness would cause a problem).

Mike

On Oct 26, 6:39 am, "Nevo" <nev...@hotmail.com> wrote:
> Yes, this is on my list of concerns. For the time being I plan on solving
> the problem by using the "don't do that!" method. I started *way* too late
> to be ready for a Christmas light show so I won't be able to really fix this
> problem this year.
>
> "Chris Maryan" <kmar...@gmail.com> wrote in message
>
> news:1193371715.999672.227300@y42g2000hsy.googlegroups.com...
>
> > Not really answering your question, but... Sink or source, 128 x 7mA
> > is a lot, your FPGA may not be able to handle it. You probably need
> > something a bit more efficient or maybe an extra level of transistors
> > to give current gain.

Nevo;
Perhaps you could play (uh,experiment) with with a microprocessor
development board (PIC, AVR, etc) to get ideas on what works and
doesn't work to control your Christmas lights.  You could probably get
something working sooner than designing an FPGA project from
scratch.
-Dave Pollum

Nevo wrote:

> Each opto will draw a maximum of 7mA.  The FPGA will be sinking the current 
> from the opto, not sourcing current.

I was just yesterday wondering how much current newer FPGAs
can sink.  I was figuring if I could direct drive a floppy
disk interface without TTL buffers.   I didn't look it up
yet, though.

-- glen

>Nevo;
>Perhaps you could play (uh,experiment) with with a microprocessor
>development board (PIC, AVR, etc) to get ideas on what works and
>doesn't work to control your Christmas lights.  You could probably get
>something working sooner than designing an FPGA project from
>scratch.
>-Dave Pollum

We're drifting a little from the topic, but...

To avoid visible flicker at any brightness, the jitter between the
supply waveform and the triac switching point must be no more than a
few microseconds.  (Remember that the supply is asynchronous to the
processor clock, so you must detect its "crossing zero" on every half
cycle and start some kind of timer - hardware or software - at that
point, then drive the triac for a short time when the timer expires).

Without hardware support (and even driving only one triac), you need
very tight microcontroller code to achieve only this.  The rest of the
code (with which you're trying to experiment) would be severely
distorted by the needs of this triac driver.

For this reason, it's probably best to develop the triac timing logic
in "hardware" (probably an FPGA) right from the start, so the micro
can be devoted to the high-level control, for which it will then have
plenty of time to control several channels via the FPGA

Mike