Controling Holiday Lights

If you were preprogramming the loads for power usage, yes. In real life situations the user simply dims each light to whatever level he likes and then saves the setting as a scene.

I've worked with a number of automated lighting controllers over the years. Most allow you to preset all manner of scenes, cross-fades, color selections, etc. Typically, the lighting designer will preset most of the scenes with specific luminaires at approximate levels. Then the LD goes back through the scenes, fine tuning each light by eye until the scenes are as desired. It's simpler for a home theater because there are less lamps and less variables but the process is similar.

I presume that you are asking about the part of the spreadsheet that predicts the Percent Luminous Intensity of dimmed compared to undimmed. Note that the units are in are percent (%). So what this predicts (eg) is that the luminous intensity of two lamps dimmed to 50% (accomplished by turning the TRIAC and lamp on at 76 degrees = 3.5 milliseconds after zero crossing) would be equal to the luminous intensity of one lamp that is undimmed.

Human sensitivity doesn't enter to the calculation. Luminous intensity has units of candela (previously candles) and is 1/683 watt/steradian for one particular, specified monochromatic light. One can convert to lights of different wavelengths using the CIE photometric curve.

Note too that the equations, graphs and table don't predict/calculate the reduction in color temperature with reduced rms voltage. That's yet another phenomena requiring a different equation (approximation).

Human sensitivity _would_ be a useful thing to account for depending on the application. As a practical matter, that's what one accounts for manually 'by eye'. One purpose of the dimmer curves is to create a response such that the adjustment range of a slider (on a pro lighting console) or a knob (on a wall-mounted household dimmer) is not too cramped in some places and too insensitive in others.

With computer control, they can be used to create look-up tables to relate all manner of things one to another empirically (by previous direct measurement). So for example, one could create a look-up table that would make each, say,

1/8 turn seem 'twice as bright' as before (whatever 'twice' might mean to you.. .)

... Marc Marc_F_Hult

For triac control I've been playing with small tables (a dozen or so entries) which I output to the port sequentially, repeating from the beginning every time the end is reached. If alternating 1's and 0's in equal numbers, then it results in a fairly good square wave to the triac (a scope makes it pretty easy to see when task switches take away control when running under linux, or an interrupt (eg keyboard) under DOS). Repeating a few 0's or a few 1's in unequal amounts just extends the off time or on time, respectively, destroying the symmetry of the square wave.

When I connect that to a "zero switching" solid-state relay, the light has very few dim levels before it is visibly flickering.

When I use a "random switching" SSR, the behavior of the light is fine.

And of course, as expected, it works better to switch 1/0's more frequently (faster bits per second output) rather than less frequently, but more frequent switching does demand more CPU attention.

I've haven't tried any complex waveforms other than when experimenting with single-bit audio output or LEDs (no triac involved). Square waves are a natural. :) With a small bit of capacitance and a resistor (IIRC, I was using 0.1uf and 1k), I've also been able to synth OK looking sine, saw and triangle waves. Some of those required a lot more than a dozen entries in the table, but could probably be optimized a considerable amount. Then for audio, I modified a version of the linux pc speaker driver from ancient days. It is able to reproduce intelligible speech quality but that's where I left it.

sdb

As Robert posted, the "practical" way is to just set the light level you prefer. It doesn't really matter if the dimmer is passing 80% or 20%, just so long as you can set it to get what you want.

Mathmatically, it is even more complicated than just human non-linearities. Incandescent lamps are also non-linear, and a mathmatically correct 50% reduction in power will reduce light far more than 50% in every case I know of.

The whole idea of trying to relate calculated values thru a transducer to human perception is covered by "perceptual coding." It is especially critical in the fields of audio, photo and video digitization and compression. No reason to digitize outside the perceivable range, and when doing lossy compression, to save space you might as well throw away everything inside that range that doesn't cause a perceptible difference.

Of course, work in this area was done long before life-like digital media was even a remote possiblity. NTSC (and PAL and SECAM) color television all relied on humans being less sensitive to color than black and white, so color images needed only to add a little bit of data compared to B&W. But even before that, with color photography perceptual differences simplified the task of reproducing color images. And so on.

sdb

I asked if a human's non linear response to light intensity needed to be considered when dimming lights and Robert, Mark, and Sylvan wrote informative replies. Thanks to all of you.

Jon.

In article , ZsdbUse1+noZs snipped-for-privacy@Zbigfoot.Zcom.invalid (sylvan butler) writes: | On 31 Oct 2006 23:14:34 GMT, Dan Lanciani wrote: | > In article , ZsdbUse1+noZs snipped-for-privacy@Zbigfoot.Zcom.invalid (sylvan butler) writes: | >| synth a 50% on-time, and know that with a 4% error limit I would be | >| close enough. But again, that is power, not light. | >

| > Power at 50% is fine, but can you describe the actual waveform that you | > would synthesize to trigger the triac? | | For triac control I've been playing with small tables (a dozen or so | entries) which I output to the port sequentially, repeating from the | beginning every time the end is reached. If alternating 1's and 0's in | equal numbers, then it results in a fairly good square wave to the triac | (a scope makes it pretty easy to see when task switches take away | control when running under linux, or an interrupt (eg keyboard) under | DOS). Repeating a few 0's or a few 1's in unequal amounts just extends | the off time or on time, respectively, destroying the symmetry of the | square wave.

I understand how you synthesize the waveworm but I'm still not clear on the specific triac trigger waveform you use for 50% power. Could you describe it in terms of frequency and duty cycle or such?

Dan Lanciani ddl@danlan.*com

It isn't a simple wave. :)

I have not measured or attempted to calculate 50% power out of the triac. I don't have the scope out right now, so I just played a bit with software...

Full speed alternating on/off (a 1:1 duty cycle, which produces a fairly nice square wave on the gate) has no obvious effect on intensity. A full speed 1:4 (on:off) duty cycle noticably dims the light, maybe a 10% power reduction. At full speed with a simple wave (e.g. all on then all off for regular periods) I cannot get down to a 50% power output without flicker -- the off times are too long.

(This system was a C633 the last time I had the scope on the output, and at that time full speed 1:1 produced a square wave of about 150khz, IIRC. Now it is PIII 750, but I expect that bus waits will keep the output about the same since a k6-2/400 was also about the same.)

Crude rate limiting to approximately two samples per tick (reprogrammed the timer to 1000 ticks per second) I can get lower power but I start getting flicker somewhere around the 1:4 on:off ratio. I expect interrupt overhead is becoming significant and my delay loop between my two samples per tick is very crude.

So now I go to a sample table where I can generate more complex waves...

Full speed using a 200 sample table I get an estimated 50% power (light very orange, but still bright enough to fill the globe) when I do a pattern with a duty cycle of about 1:2 (on:off) somewhat randomly distributed within the table (it was actually 64 on, 136 off). Using the same table at 2 samples per tick (default frequency 18.x/sec) results in very dim light, sometimes a bit of flicker.

Using a PIC it might be easier to sync with the zero-crossing and get some determinism. I've googled a bit, and syncing a PIC seems pretty simple. But I don't want to input that back to my PC parallel port. Plus the real-time 120x/second is a bother. I maybe should have saved that data table... :( Just keyed it all in directly to memory with debug.)

sdb

sylvan,

Thank you for taking the time to work through this on the bench. Usenet participants and other readers will be well served by your recognition that synchronization to the AC waveform is needed to usefully dim TRIACs.

You really shouldn't have more of a problem safely bringing the zero crossing to the PC through a printer port input than safely controlling the TRIACS through an output. You can use a low-voltage ( eg 120VAC:6VAC) transformer for isolation and one of the many schematics available on the web to get a snappy TTL signal. The isolation transformer would make the zero crossing signal even safer than the outputs to the TRIACS especially if you aren't already using (you should ;-) opto-isolators on the printer port outputs. As you know, the printer port has inputs as well as outputs, so adding zero-crossing would be very little work.

You can then use the table at

to calculate the needed deterministic delays. You may find that it helps to avoid/eliminate disable disk accesses. With DOS systems this is simple enough to do by booting from a floppy and making sure the transient part of the OS stays in memory so that disk reads are not needed. Use RAM-disk for large tables/data if needed. I've lost track of what tricks are now available to get hardware interrupts from today's equivalents of the PC/AT's 8259 and 8254 but note that the 18.2 msec Timer interrupt ain't good enough ;-)

There are a variety of links to microcontroller-based dimmers on my web site.

Also, I have a couple of Artistic License AL4016 IC's (8051-based, not PIC, DMX dimmers) that each dim 16 TRIACs that I'd give you for a quarter on the dollar or so. See for complete info.

. USB->DMX converters can be had for $25 or so on eBay. The TRIACs and or SSRs you already have should work fine. Email me offline if that is of interest.

HTH ... Marc Marc_F_Hult

This certainly applies to the end user. But folks that actually design dimmers might initially choose a mathematical representation of the known physics for design purposes. (I got the equations shown on my spread sheet from Chris Pflieger, a design engineer at

about 5 years ago.)

From my at

50% dimming with respect to luminous intensity is achieved at ~76 degrees = 3.53 milliseconds delay.

50% dimming with respect to RMS voltage at ~114 degree = 5.26 milliseconds.

But in the case of TRIAC dimmer control (see thread subject) a single byte holds all the information needed to produce 2^8 = 256 levels *IF* one also knows when the zero crossing occurs as is conventional. sylvan doesn't know the z-crossing and so futilely tries/d to overcome that lack of critical data by creating complex waveforms with large data requirements that by his admission challenges the timely computing power of a PC.

So in sylvan's case, he has created the need for a much larger amount of information, that indeed does need to be reduced.

But the single byte in the conventional approach is all the information that needs to be transmitted to the dimmer, or held in a register of a microcontroller or the latched input of a digital-to-analog (DA) converter.

Applying 'perceptual coding" to that single 8-bit byte, we could usefully 'compress' it to a 4-bit nibble to produce 16 levels if that is all that is needed.

So, for example the table at:

can be used to select values for a new, equal intensity, 16-step dimmer curve with Full ON, Full OFF and 14 intermediate steps each causing about 6% reduction in light intensity. This would be 'perceptually' plenty good enough in nearly all practical home automation scenarios.

... Marc Marc_F_Hult

I have done some playing around with this and found that in order to change the intensity of a light very very slowly, without seeing any noticeable step in brightness (especially noticeable at the lower brightnesses) you need each change in time to be around 10us or so. This means for the criteria mentioned, you would need many hundreds of steps, likely about 500 or so. I would consider a 100 step dimmer marginal and a 256 step minimum. But that is just my preference :-)

If I am understanding what you are trying to accomplish I would have two possible concerns, 1) What kind of noise would be generated by switching that fast and 2) what kind of heat would be generated by having your control device switching on and off that much?

Yep. Since we don't even perceive 256 levels of dimming with the eye, this is than sufficient.

This makes the whole process elegantly simple using existing technology. While other approachs may be able to yield finer control, it may not make a difference in real world applications. I'm all for creativity, even for creativity's own sake, so I hope Sylvan has better results than what I expect. More power to him (yes, pun intended) if he can.

I'd rather have a tad finer control than intermediate 14 steps between on and off for setting up home theater and "mood" scenes involving multiple fixtures. Then again, I'm kind of picky. What I *really* would like to have is precise fade rate controls for home lighting. Working with PC-based lighting boards even a little spoils you. :^)

Note to Sylvan: This discussion has gotten a little edgy at times. We disagree on a few of your ideas but I'm interested to see what you develop. I hope that none of my comments on this matter have sounded disrespectful to you because that has not been my intention. If it seems so, I apologize.

Sending a single DIM or BRIGHT code to an X-10 LM465 lamp module results in an average change of about 0.662% as measured with a Kill-A-Watt (a 100W bulb makes things simple) and with a true RMS voltmeter. 146 steps will take the lamp from one extreme to the other. (It varies a bit with other models of lamp modules.)

Using a 25W R14 lamp in a spotlight type holder, it is easy to discern individual steps on the low end either by looking at the light projected onto a surface or, at the very lowest levels, looking at the filament itself.

With a 100W bulb in a standard table lamp, individual 0.662% steps result in larger increments in light level that, again, can be discerned by looking at the light hitting the ceiling or looking directly at the filament at very low levels.

I think that most people would not find the changes annoying - they are not readily perceived unless you are watching for them and, even then, only if the steps are fairly close in time. But, it will depend on the eye of the beholder.

snipped-for-privacy@yahoogroups.com

Not to worry ;-)

A TRIAC controlling 60hz AC can only be switched on (it turns _itself_ off) at a maximum rate of 120 hz no matter what the input. So regardless of the frequency of the input, and regardless of the waveform, there will be a maximum number of 120 transitions per second. (IOW, what sylvan is trying to do does not actually work.)

The maximum output slew rate (and potential noise) occurs when the AC waveform is at 90 and 270 degrees (= peak voltage of 170 volts, rms output voltage for the entire half cycle = 85Vrms, and ~33% output for typical tungsten lamp compared to full output). These calculations assume 120VAC and neglect the band-gap and IR drop (loss owing to resistance) of about 1-1/2 volts.

See

... Marc Marc_F_Hult

Hi Max,

What I meant would have been clearer had I written "scene" instead of "scenario" ;-) Oh Strunk and White -- where art you? )

In terms or *static* _scenes_ (WatchingTV, GoodNight, Entertainment, AllON, AllOFF) 16 different levels seem plenty. I know I could get by jist fine with

4 or 5 intermediate levels.

But as Robert wrote earlier in the thread, and you point out here, dynamic (changing) scenes such as those used in theatre and concerts need more levels. (Note though, that 256 levels are that all the great majority of professional theatres and other entertainment venues have, so if 256 is not enough, the majority of performances world wide are unsatisfactory ;-)

I realize now that fade rate may be something that is of interest to others in HA, and for that purpose, 16 levels may indeed be inadequate depending on one's preferences.

... Marc Marc_F_Hult

True, but since many HA applications also encompass HT design, it's pertinent to the discussion.

Completely agree, Marc. I should also point out for the sake of others that fade rate is independent of the number of available dimming steps between ON and OFF. I recall a *scene* we set up during a Christmas play one year. The scene called for a single fixture projecting through a star shaped gobo to create the image of a brilliant star slowly appearing in the "sky". A Source IV lamp was programmed to fade from OFF to full on over the course of several minutes. During the first minute or so it looked like all the other stars in the background. As the actors moved about the stage and the scene progressed, the "Christmas Star" slowly became the most brilliant light in the scene. It was interesting listening to the ooohs and aaahs as different people noticed what was happening.

The system stepped the dimmer through 255 levels. During programming I usually "wrote" the scenes using 5% increments (100% on, 55% ON, etc.). Once the scenes for a given performance were blocked in I would go through the script, adjusting each fixture with a wheel -- paying no attention at all to the actual output levels -- until I got the visual effects I wanted. Later, after the scenery and backdrops were done, I'd redo almost every scene -- again using the wheel and paying no attention to levels.

The above is pretty much how all small-scale (and many large scale) lighting designs are done. I realize that this is borderline OT, but thought it might be interesting to a few folks anyway.

I assumed he was talking about some device other than a triac that could be switched at a much higher frequency on and off during any point in the ctcle. I imagine this would work to give you some lesser power out. All you would be doing is chopping the AC into really small chunks and they would average over the entire wave(s). I think the problem would be noise and heat.

That gets a bit ugly (and more expensive) if you intend to control

120vac. (Of course, one could rectify the 120vac to create ca. 170vdc and use MOSFETs...)

Yup.

that's pretty much how it would work. But it is a lot easier with D.C. You would have to be really motivated to do it with A.C.

Heat is not much of a problem compared to older dimmer technologies. Switching on/off means the switch is either conducting (very low volt drop hence power loss) or not conducting (essentially no leakage current, thus no power loss). I do have some 40amp SSRs that require a pretty substantial heat sink for full power. But you figure even a small voltage drop at 40amps means a lot of waste power. Running 20amps and mounted to a metal box they don't get noticably warm.

noise, OTOH... Electrical noise can be a problem if switching large loads, inductive or capacitive loads, or attempting to pass fast pulses thru long wires. As marc pointed out, with triac switching 60hz A.C., it just isn't that fast. However, if switching large loads you prefer to not "dim" them, and to avoid electrical noise (and sometimes even bigger problems) you usually sychronize the turn on and turn off at the zerocrossing. But even a typical home-use dimmer for a few hundred watts will generate electrical noise. The standard practice is to put in a small choke (inductor) to quiet it down.

Of course, if you meant accoustic noise, well, mechanical relays don't switch that fast either. :) More seriously, sometimes you can find a resonant frequency of the filaments in the lights and hear a pretty good hum. In practice it doesn't happen very seriously, very often.

sdb

yeah, back in the days when the dim level was controlled by a variable resistor (even when controlling a triac) it was handy to know the value of that resistor and the floor and ceiling values of the total resistance.

And that will vary somewhat depending on differences in the actual incandescent light (hardware).

An 8-bit byte always does.

Marc, I neither said nor alluded to any such thing, and I thank you kindly to not put words into my mouth.

That is not perceptual coding and is not in any way related to it.

You certainly do not want "equal intensity" and equal "6% reduction in light intensity" in your steps. If you actually implemented a dimmer that way, the bottom steps (starting from dark) would appear significantly bigger jumps than the top steps (approaching full-bright). THAT is human perception.

Perceptual coding takes place at a lower level in the design, realizing that human vision can detect a very small change from dark (no lumens) to some light (lumens), but cannot detect an equal change in lumens from bright to brighter. Thus perceptual coding is used so that whether your dimmer has 16 steps or 256 steps or 65536 steps, the perception of brightness is uniform at each step even though the increase in light intensity between each step grows MUCH larger as the light gets brighter.

sdb