It must be a timing problem.....

c56 · 2008-04-13 18:27

Well, as you will probably soon see I am pretty new to SX programming, and have run into a problem I have just not been able to figure out. I am working on a DMX-512 controlled 6 channel light dimmer. The DMX receive functions and light dimmer code are based on the work of Jon Williams, and work well. However, I have some ancillary functions that are not working. I have a bicolor LED wired across two pins of an SX 28, that should allow me to control the color of the LED as a status indicator. On the hardware side, the logic is powered by a "wall wart" to isolate the mains, and the line AC side is fuse protected (the wall wart feed is before the fuse), isolated by triacs, with an optoisolator to sense the zero crossing point. The functions I am trying to implement are as follows:

1) AC power (fuse good), no DMX - LED solid green
2) AC power (fuse good), DMX receive - blinking green LED
3) No AC power (fuse blown), DMX - blinking red LED
4) No AC power (fuse blown), no DMX - solid red LED

The problem is, I figured out how to blink the LED, but I have not been able to figure out how to change the LED color based on either the incoming DMX stream or the ac zero crossings. I have tried all kinds of algorithms, mostly variations of ideas like counting the zero crossings for a known period of time, and if there aren't any then clear a "fuse good" bit. In all cases, using an IF statement to get the color causes the dimming feature to fail (lights start flickering). In the attached code, I have commented out a couple of test cases trying to get this to work. I just do not see the connection between the dimming function and an if statement for selecting the state of a pin controlling the LED. Sigh... I am sure it's something obvious, but I have just run out of ideas.

One last note, given the short duration of the interrupt for the DMX receive and dimming, there is only room for one addition one word command in the available timing, so the LED functions need to be in the foreground.

Any help on this would be greatly appreciated!

Skip

JonnyMac · 2008-04-13 20:53

Remember that the interrupt is your one constant. X cycles through it without a change in the ZC state means no AC. Y cycles through it without a break detection means no incoming DMX data. You should be able to add a couple counters to your program to keep track of things, and also use the ISR for timing of LED blink periods. Remember to clear your ZC counter when you do detect a ZC input, and the no-DMX counter when a break is detected.

c56 · 2008-04-13 23:26

Makes perfect sense - a good algorithm concept. I am going to take a look at rewriting the interrupt to get some more "headroom" for some additional instructions. I still do not understand why changing one of the pin values has any effect on the dimming routine; as I noted in the title of this thread I am suspicious it is somehow affecting the integrated timing. I'll post my results after a coupe of days more of playing with this.

Thanks

DynamoBen · 2008-08-14 03:13

c56 I loaded your code on my demo board; I removed any·additional power sensing features. I noticed that the dimmer outputs are flickering. After·some testing·it seems the flicker is coming from the DMX code. If instead of using DMX you hardcode the levels the dimmer output is rock solid.

Have you worked on this code anymore? Are you seeing a flicker?

c56 · 2008-08-16 17:39

Yes, I have code that works in both decoding the DMX stream as well as dimming. I am still working on the dimmer part, since it does not perform as well as I would like. Specifically, at low values the lights do not turn on until up around a dimming value of 50. I believe this is due to the the physics of the lamps, since many commercial dimmers provide a "standby" voltage to keep incandescent filaments warm. Also, turning on triacs using the delay algorithm is not very linear, so there is not a lot of energy available at low dimming values; again commercial dimmers try to compensate for this with different dimming profiles. I have the attached the code, as you can see it is set up for 6 channels but can be easily extended to 8. I have not tested at 8 so I cannot swear there is enough bandwidth to successfully operate.

JonnyMac · 2008-08-16 22:58

I think you could do eight channels -- and I've attached my version of how. The thing is that since you're only processing one lamp channel per ISR you can have more lamp channels, so long as you can organize the divider such that each channel is being processed every ~32 microseconds; with eight channels it works, and SX/Sim shows that there is no problem with the ISR.

Post Edited (JonnyMac) : 8/16/2008 11:06:17 PM GMT

DynamoBen · 2008-08-17 01:06

c56 said...
...at low values the lights do not turn on until up around a dimming value of 50. I believe this is due to the the physics of the lamps, since many commercial dimmers provide a "standby" voltage to keep incandescent filaments warm.

I loaded your code and took a look at an output with my o-scope. The problem isn't related to the lamps, the problem is·your code isn't firing the outputs until DMX hits 50%.

I then·compared the zero cross input to a channel output and noticed that the output pulse seemed to be starting correctly at the trailing edge of the zero cross but was being restarted on the leading edge of the same zero cross.

Basically can only·set a channel output at a percentage of the low zero cross. This·because the way zero cross is being polled. What we want is state change (or edge detect), and clear all the outputs and counters when the low going edge is detected.

Let me see if there is an simple way to get around this. We need to see it go low to reset everying, then ignore it long enough for it to go high and then start checking it again.

Post Edited (DynamoBen) : 8/17/2008 3:37:30 AM GMT

DynamoBen · 2008-08-17 03:11

JonnyMac said...
I think you could do eight channels -- and I've attached my version of how. The thing is that since you're only processing one lamp channel per ISR you can have more lamp channels, so long as you can organize the divider such that each channel is being processed every ~32 microseconds; with eight channels it works, and SX/Sim shows that there is no problem with the ISR.

JonnyMac it appears your version doesn't actually dim the outputs, they just flicker. However what you posted is similar to what I'm doing to get 8 outputs.

Once I get the zero cross thing sorted I will post my version.

BTW I think you could·control up to sixteen channels if each interrupt set two outputs, instead of one.

DynamoBen · 2008-08-17 05:28

After spending some time looking at my scope and the code, it hit me.·If you have the zero cross line tied high (like I do)·then the problem is in the following line:

JNB ZC, Update_Ch1····'(2/4) At zero cross?

When the zero cross line is tied high the actual zero cross is a low pulse. With the above code when the zero cross line is low it updates the channel instead of clearing the channel. Basically channel update and zero cross are backwards.

Try the following instead:

JB ZC, Update_Ch1····'(2/4)·Not zero cross?

Post Edited (DynamoBen) : 8/17/2008 5:40:07 AM GMT

JonnyMac · 2008-08-17 06:24

My ZC output is tied high too, but when the AC level causes the either of the LEDs on the opto's input to conduct the output line is pulled low, hence the output from my ZC circuit is a high-going pulse every 8.333 milliseconds.

DynamoBen · 2008-08-17 15:33

I have mine wired the same way, however I'm not getting every zero cross. I'm actually getting every other, it seems to be triggering at the start of each new cycle. Very odd! I·tried swapping out the opto to see if it was·damaged but got no change.

Not sure at the moment what I'm over looking...if anything. Maybe it has to do with my 13V AC supply I'm using to zero cross.

Post Edited (DynamoBen) : 8/17/2008 3:46:23 PM GMT

JonnyMac · 2008-08-17 16:21

If you're using 13 VAC then this circuit should work for you (I use this same circuit except that my input resistors are 15K, 2W). Note that the H11AA1 has two LEDs on the input; this lets it detect both phases of the AC. I'm betting you're using an opto with just one LED on its input side. What opto are you using?

attachment.php?attachmentid=55176

DynamoBen · 2008-08-17 17:22

Thanks, I had the 15K in by mistake. I threw the 680 in and everything looks better. Nice square wave with the transitions at zero cross.

It must be a timing problem.....

Comments