Controling Holiday Lights

DMX512 (aka DMX-512, DMX512a) can read and(or) write one byte values to each of 512 addresses ~44 times per second. This is faster than the human flicker fusion frequency under most circumstances (Q: Do incandescent lights flicker when run on 50 hz power?)

There are many DIY approaches Google " dmx 512". Also some homebrew and commercial stuff here:

Chips here: (I have some left-overs I would part with cheep.)

Search eBay for "USB DMX Interface" and "DMX 512" for a panoply of lighting devices.

DMX is _designed_ for control of lights. If you've been to a rock concert, theatre, or play in the last decade, you've seen DMX512 at work. RF and ethernet implementations have emerged.

... Marc Marc_F_Hult

control and have begun investigating high-power LED's (the lamps are still to pricey for me at this time). LEDs are an arena for PWM in home lighting, especially when combined with RGB lighting control so that color as well as intensity can be controlled. High-power LED controller ICs are emerging eg from Maxim.

... Marc Marc_F_Hult

sylvan was asking about cards with four LPTs (the one cited only have two ports). In any case, LPT ports seem to be an inefficient way to get 4 x 8 =

32 'fast' TTL outputs.

In bygone days, the LPTs were convenient because they were supported by the OS. As Si implies above, attempting to control multiple LTP's in real time deterministically at 1000hz with a PC without a real- time operating system would cause one to see many more flashes and other glitches owing to OS and software timing problems in the PC than anything caused by the hardware.

I presume that sylvan gets his "1000hz" requirement from 120 zero-crossings per second * 8 positions per zero crossing = OFF + 8 other intensity values. Pretty crude. Not sure why he would go this route. Conventional dimmers do much better than that -- eg DMX512 nominally has 255 intensity values, some X-10 implementations nominally 32 different values, etc.

... Marc Marc_F_Hult

1000 on-offs per second controlling 60 hz AC lighting yields:

(1000/sec) /(120 zero-crossing/sec) = 8.33 control choices per second.

As a practical matter, about one-third of those possible on-off signals will fall so early in the AC cycle that they wouldn't produce enough current to make visible light (although they would use up electricity).

So as a practical matter, unless you first convert the AC to DC, you might have as few as 5 distinct illumination levels.

This is probably completely adequate for most scene-control purposes where slow, smooth transitions from scene to scene are unimportant, but you are touting this "1000hz" approach as being as providing "all kinds of creative fades" and "anywhere in between" when as a practical matter, your "1000hz" approach is much cruder than even the simplest X-10 dimmer.

And it pales in comparison to DMX-512 with 255 distinct values and the dimmer curves and pre-heat values (i.e, non-linear relationship between input control value and phase value) are part and parcel of even moderately sophisticated implementations.

Are you doing more work and accomplishing less with this technique? Or do I misunderstand something quite completely -- wouldn't be the first or last time ;-)

... Marc Marc_F_Hult

255 levels * 44 changes * 120 zero-crossings/sec = 1,346,400 hz = 1.35 mhz = frequency needed to bit-bang a phase-controlled AC dimmer with the same number of intensity levels and time resolution as DMX512.

(Assuming phase control. The arithmetic for amplitude control is a bit different and bumps into other limitations such as flicker.)

sylvan is asking about doing this from a PC bus with off-the-shelf LPT cards so, presumably requires a real-time OS that runs on conventional x86 PC hardware such as Windows CE, Labview RT, QNX, BeOS, VxWorks, RTLinux/FreeRTOS/Linux2.6.18+ and so on.

(I wonder what use the 100 MB release of Windows PE 2.0 might have for HA if the 24-hr run limitation could be overcome/thwarted? Not RT, but small enough for simple installation and use without a hard drive.

)

... Marc Marc_F_Hult

Or mostly as standard hardware that was easy to access both on the SW and hardware side. (though a simple design change by IBM in the original to swap the addresses of the status and control ports would have made high speed much easier!) A SW example: port write to 0x378 switches 8 lines simultaneously. 0x37a does four lines. On anything faster than a 4.77mhz 8088, the cycle time is limited by wait states on the ISA bus. (PCI (and microchannel) reduce or eliminate most of the CPU wait states.) This means that the slowest PC you can buy today can set the state of 8 lines hundreds of thousands of times per second. Compare that with an 8255 solution which takes multiple port writes to set the state of any set of the 24 output lines. If it takes two writes, you just cut your maximum rate in half. Three writes == 1/3. Etc. Even the parallel port multiplexing solutions which take five or six writes are way faster than my 1000hz target (which only requires

2000 writes per second on a standard parallel port).

The 1000hz is the design target. And modern PCs are fast enough that an ancient 386/20 laptop running linux has worked great for simple testing. It has worked so well, I may even change my stuff to be a kernel driver. The ancient PC speaker driver would produce full sound effects using

1bit PWM under linux. As long as you kept the sounds from about 1000hz to 12,000hz and didn't mind a bit of jumpiness on the keyboard. :) Given that, I expect I could run fades on 8 lights (one parallel port) from this 386/20 without needing any "real time" anything.

In reality, not all bits on all ports will need to be toggling that fast. Mostof the time, no bits will be toggling. When a light is full-on or full-off the system is idle. It is only while fading or maintaining a dim level that any toggling will need to happen.

Again, the PC is mostly a SW development and prototyping platform. There is no OS involved. It boots DOS and loads my code which takes over the entire system. Or another way of saying it, I've written the OS. Even the really little, cheap pics can do 4 channels (bits aka loads). That's what's in many of the remotable dimmers.

Not even close.

I'm not.

Think of it as me building a DMX512 or X10 dimmer. How does it actually create the varying intensities? By turning on and off the light many times per second. That's what I'm doing.

sdb

I'm modulating D.C., or rather, creating modulated D.C. The technique of modulating the D.C. is PWM. That D.C. is then used to switch a triac to control A.C. loads. Phase syncronization is mainly needed to control R.F. and sometimes to control switching transients. With fairly low power loads (typically under 200 watts) R.F. is minimal and controllable in other ways. Switching transients aren't significant with primarily resistive or incandescent loads.

You seem to be confusing how the dimmer is controlled (with DMX or

0-10vdc or...) with how the dimmer controls the A.C. I'm doing the latter. Not real interested in the former at the present time.

Yes, very cool stuff. It is just beginning to hit the market, and looks to have potential to revolutionize ambient lighting.

sdb

If DMX could issue 44 commands per second per address, it could turn a light on and then off only 22 times per second. Is that what you meant?

A: No, because incandescent lights are very, very slow.

Q: Do fast acting lights (LEDs, fast phospher in fluorescent tubes, CRTs, LEDs, etc) flicker when run on 50hz power?

A: Yes. Even if not consciously apparent to the human eye, 50hz and

60hz and even 120hz flicker is easily detectable with primitive mechanical instruments, and is known to cause eye strain during extended exposure.

Yup, and someday I may want to add a DMX interface to my devices so they can be controlled from such a standard protocol. It's not on the vintage chart today.

sdb

I don't know how come I cannot seem to communicate this... Perhaps today's batch of posts will connect.

How do you think the X-10 dimmer actually fades the light?

And the DMX dimmers actually control the light how?

I think so!

You are looking at the problem from the "top" -- how to control a dimmer.

I'm looking at the problem from the bottom -- how to build a dimmer.

sdb

ROTFL

A TRIAC dimming household 60 hz AC can be switched on *exactly* twice every

1/60th of a second: once during 0-180 degrees and once during 180-360 degrees. And a TRIAC can _never_ be 'switched off'. So what you say you are doing (as I understand it) simply won't work. Everything that can be done to control a TRIAC can be done with no more than 120 low-to-high transitions per second. Having the ability to switch at 1000 hz is intrinsically no more useful than 120. It is _when_ during the cycle with respect to the zero-crossing that the SCR is turned ON that determines the dim level.

No, it's all quite clear to me. DMX can change the 0-255 dim level setting up to 44 times per second. Based on the 0-255 level instruction it receives via DMX (which can change up to 44 times per second) the dimmer module (in the case of household AC lighting) sets the dim level of the TRIAC/SCRs by either turning the TRIAC into conduction at 0 and 180 degrees (= Full ON), at some phase angle 0 < a < 180 and 180< a < 360 (= dimmed"), or not at all (= full OFF). This can be done (eg) with a comparator that compares the voltage of a simple (eg) 0-10 volt ramp (sawtooth signal) that begins at the zero crossing and a 0-10vdc DC control signal. When the ramp reaches the value of the control signal, the comparator goes high and causes the TRIAC to go into conduction. This is repeated 120 times a second.

So being able to switch at 1000hz or 10000hz or a gigahertz has no intrinsic advantage over switching at 120hz (at the right times) in controlling TRIACs/SCRs. But only being able to turn the TRIAS on at 1000hz/120hz = 8.33 (dimensionless) different phase angles (your 1000hz case) means that you will only have a maximum of 1000/120 = 8.33 different dimmer settings (assuming that you are synchronized with zero crossing, which you don't seem to be). In contrast DMX512 has 255 different dim levels (my previous comments about dimmer curves, preheat and un-useful phase angles not withstanding). This is the same as I wrote before. What you need to grok is that a TRIAC is not turned OFF when the TRIAC gate control signal goes low (= OFF). So turning the control signal ON-OFF does NOT turn the TRIAC ON-OFF lock-step.

... Marc Marc_F_Hult

Then please do post how you chose 1000 hz.

No. DMX512 does not "turn[] on and off the light off many times per second". DMX512 can set a new, 0-255 dimmer level up to 44 times a second, but it is the dimmer that turns the conduction of a TRIAC or back-to-back SCR ON depending on the phase at each half cycle. A TRIAC cannot be "turned off" during 0< a < 180 and 180 < a

So you first rectify the AC ?

OK. But what you end up with is a poorly-timed control signal for the TRIAC gate. What's the point? You end up with more noise and less resolution (of different dim levels) than if you were synchronized. I guess I answered my own question: you don't have to synchronize with the zero crossing ;-)

See my other comments.

No I am not ;-) What you describe is a very low-resolution way ( max 8 dim levels at 1000 hz) to dim AC power using TRIACS or back-to-back SCRs.

... Marc Marc_F_Hult

No it is not. I mean what I wrote. It can change the steady-state 0-255 dim level 44 times per second. The dimmer does the dimming.

But they are what you are controlling, no?

They do not turn on-off faster than the human flicker fusion frequency which is what I wrote. And you can't change the 60 hz frequency of the light intensity modulation by turning the TRIAC gate control signal ON-OFF at

1000hz or one gigahertz or any other frequency for reasons I have posted tediously already ;-)

... Marc Marc_F_Hult

To expand and clarify: In order to provide the gate control signal for a TRIAC/ Back-to-Back SCR dimmer with the 256 dim levels achieved by DMX512, your fixed-frequency scheme needs to operate at a frequency of 120*256 =

30720 hz.

So your 1000hz target, which you suggest/imply is itself extravagant, is a factor of 30 slower than what is needed to accomplish what off-the-shelf, (relatively ;-)inexpensive, globally accepted, ANSI-standard,

DMX-512 lighting can do.

You can change the arithmetic co9mpletely by timing the gate control voltage with the AC line zero crossing, but if you do that with a PC, all you've really done is create the world's largest (? I dunno ;-) dimmer controller at a substantial cost in time expended, size, power consumption, complexity, and difficulty of repair and maintenance by others.

'Course I do things related to HA just as time-consuming and idiosyncratic, so no criticism is implied ;-)

... Marc Marc_F_Hult

The discussion has moved on but these statements need to be corrected. With MIDI, a command to 'turn something on' with up to 128 'intensities' is 3 bytes worst case and 2 bytes best case. No where near the 'few dozen bytes' stated by the previous poster.

MIDI runs at 31.25Khz. A byte can be sent in 320 microseconds. That's about 3 bytes per millisecond or 3000 bytes per second. That's a few more than the previous poster's 'several bytes per second' I think.

Most use triacs.

Not any more. You explained that already and I understand you. I'm fairly certain Marc does, too. His point is that your design criteria may not yield what you want.

FWIW, Marc has built a DMX-512 compatible lighting controller for home use. I had references to his work on my FAQ... until hurricane Charley came along. Oh, well.

I'm quite interested in your design. I hope you can make it work to your satisfaction. These kinds of projects tend to inspire people to produce commercially viable products and that is good not only for the DIY folks here but also for retailers like me who cater to them. :^)

Whatever protocol you choose one you're at that point, I hope you'll share about it here as the job progresses.

Yup. And the triac is controlled by a microprocessor switching the gate current on and off at least 120 times per second.

Of course, you (Robert) are responding to a message intended for Marc. :)

I am confident he does not.

I wonder if he created the software that actually runs in the microcontrollers inside each dimmer / load controller...

sdb

With 1000hz I can smoothly synthesize any waveform from D.C. up to 500hz and of course squarewave up to 1000hz. Then the interface electronics will allow me to use D.C. lights (with a class-D amplifier) or A.C. lights (with a triac or SSR).

DMX doesn't, but the DMX dimmer does. That is EXACTLY how EVERY SOLID STATE DIMMER works. Even a DMX dimmer and same with an X10 dimmer.

Read

if you don't want to believe me. (microprocessor controlled dimmers simply replace the analog R.C. timing circuit with a digital output pin)

I don't.

When gate (trigger) current is available for the triac, it will conduct the A.C. waveform. When gate current is not available, it will not conduct beyond the zero crossing. Basic electronics.

sdb

The microprocessor will switch on and off the gate current. The triac will cease conducting within 1/120 of a second (at 60hz). That's rather faster than your hand can interrupt the A.C. using a mechanical switch. It is also reasonable compared to typical mechanical power relays. If you don't want to call that "switched off" that is your prerogative nit.

But I can see it does.

Yup. Now how would your DMX dimmer generate the 0-10vdc control signal for the comparator? Nyquist might help you understand how, and also how/why I can simplify the whole mess with a bit of software and make a generic controller, just as long as I keep my switching frequency many times faster than line frequency. (And 1khz just so happens to be a typical lower bound in many PWM designs.)

sdb