Power supply filter capacitors

Do yourself a favor and at least design in the capability of populating a snubber. I would also add a hi-feq filter cap at the gate of the TRIAC. Doing these two things will give you recorse to deal with noise at the gate and any transient dv/dt acorss the TRIAC, both which could inadvertantly turn the TRIAC on. And when you're picking components remember that you're dealing with 120V AC.

I don't think you mentioned anything about how much load the TRIAC's will be switching. Make sure that you heat sink the TRIAC's, if need be.

Reply to
Rob
Loading thread data ...

Interesting project. Comments:

120Hz is slow, compared with FPGA, so CAP sizes deal with the edges. ie Your regulator systems need to supply the 120Hz power. Suggestions to stagger the edges are very good - comes for free in the FPGA. 7mA per pin is likely to be OK, from a DC perspective.

You also do not need 100% conduction times, and even a 'relatively fat'

10% gate trigger time, will slash the power needs from just under 1A to under 100mA.

Some triac systems use burst triggering, so a simple scheme would divide the 128 into 8 or 16 timeslots, and staggered burst trigger.

Be wary of the AC Power noise, especially in the dimming mode (in Zero-cross mode, the noise will be magnitudes lower)

Also look at the actual wiring deployment, as you may find it easier to do a serial-fanout, than bring all 128 trigger lines into one FPGA. With a serial fanout, you would build a SPI (or similar) chain, and clip together blocks of 8-16 triacs per shifter. Shifters could be LVC595 class devices, or something like a HEF4794 would have speed/noise immunity matched to a mains system. Optos like H11L1 could isolate the serial chain, for improved double-isolation.

How complex are your lighting patterns/signatures ?

-jg

Reply to
Jim Granville

The size and number of caps depends on some things you haven't yet mentioned. Although the update rate is only 120Hz, what matters is the edge rate at the driver, and the latest devices switch their outputs at ridiculous speeds (it's possible to slow them down in some devices with a constraint).

You can get the switching speed information from the IBIS file, incidentally.

Another issue is how far the driven devices are. If you have an edge rate of 1nS or faster (not uncommon), then if you have devices further than 1.5 inches away, you have to consider the current in the high speed domain.

If you have high speed domain currents, then the initial current on each output pin is, for a rising edge [Ztrack/(Zdriver + Ztrack)]V(transition) / Z (track). For a 3.3V system and a typical track of 60 ohms, that's an initial

Reply to
PeteS

That point is very important.

Triac specifications don't usually quote a minimum gate time to start conduction, but 5us (and maybe much less) seems to give reliable operation and is less than 0.1% of the half-cycle time (at 50Hz or

60Hz), so the saving in PSU drain can be enormous.

Mike

Reply to
MikeShepherd564

True, we have done some CMOS Triac designs, powered from a dropper, and there power matters a lot. With a zero cross the gate trigger pulse can be required wider than 5us, as it need to be applied until past the Triac Holding current.

That's also why burst trigger is sometimes used - saves power and tolerates some current phase shifts, and you can be lazier around zero cross.

The OP is using a FPGA, so going from 1A to 100mA makes good sense, but chasing much under 100mA is pretty pointless, given the static FPGA Icc figures ;)

-jg

Reply to
Jim Granville

The main reason is board space. With the hobbyist version of Cadsoft Eagle, I can just barely squeeze in my phyiscal components at the program's maximum

100mm x 160mm board size. The second reason is cost, but with the board space constraint the cost issue is moot. There's just no room on the board for 128 transistors.
Reply to
Nevo

I'm using a freeware program

formatting link
to drive the data from the host computer to the FPGA board. The host program is bit-banging the parallel port. Since the software side was already written, I designed the hardware around the pre-existing data format.

Reply to
Nevo

If I were designing the circuit board, I'd put in pads for snubbers. I'm buying from a 'group buy' on a DIY Christmas lights forum and the existing boards don't have snubbers designed in. I'll provide this feedback for next year's designs. :)

The load for each TRIAC is typically going to be one string of mini Christmas lights at ~0.33A. I don't plan on heatsinks for these loads.

Reply to
Nevo

This is definitely on my list of improvements to make in the future. I'm going to build the first unit with the brute force approach and add in refinements. (Christmas 2008 should be killer!) :)

Not only will this change reduce total power through the circuit, it'll allow me to use a smaller transformer, which is one of the costliest parts in the design.

Reply to
Nevo
330mA should be fine w/o heatsinks.
Reply to
Rob

It's only about half a page of code :) - do it now!

A 3 or 4 bit timeslot counter(probably already there), and a 1:8 or

1:16 timeslot decode, which is 8 or 16 lines. Then you spread the power the best way. How fast are your gate optos ?

-jg

Reply to
Jim Granville

(snip)

I once thought about doing an array of christmas lights multiplexed so that I could turn each one on and off under computer control. It needs a lot of diodes to do that, though now with LED christmas lights those wouldn't be needed.

-- glen

Reply to
glen herrmannsfeldt

(snip)

How about a URL so that others interested could follow along?

-- glen

Reply to
glen herrmannsfeldt

Sure!

The software that most DIY'ers are using can be downloaded from

formatting link

The main website for most of the community is

formatting link
Most follks there have drifted over from
formatting link
which is still active and has the genesis of many of the projects.

There are several designs for driving lights from parallel ports and serial ports. My FPGA board is going to emulate the 'Horning Dimmer' design.

Reply to
Nevo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.