Interrupt vs. state-change callback function, missed events

I’m getting some undesirable behavior with a zero-cross detector circuit and a callback function in my ac dimmer code. The zero-cross detector is firing at 120 Hz and it’s important that I not miss any of those pulses: missed events show as flickers in the bulb dimmer. I notice that server.show() commands cause the imp to miss zero-cross events. Also, for some very short and very-long chopping intervals (bulb mostly on or mostly off) the imps misses z.c. events. This seems to happen if the imp.sleep() call in the zeroxEvent() extends just past the next zero-cross pulse. The imp misses it.

From what I have read in the documentation, the callback functions are not true interrupts, they are executed after the imp has finished whatever else it is currently working on. Is there any way to attach an actual interrupt to a pin? I need to catch every z.c. event for a flicker-free bulb dimmer.

Thanks in advance!

Robert

acdimmer code: https://gist.github.com/4436501

Any server I/O means it needs to run TCP code, do DMA out to the wifi chip, etc, and as such that will affect accurate timing, which is why we run the networking at a lower priority than the user code.

As the VM isn’t re-entrant, there’s no way to “really” attach it to a hardware interrupt, no, as it might be executing code already. What you probably want is to have a programmable width pulse generator that is automatically triggered from your zero-x input. That way, it doesn’t matter what the user code is doing, the AC dimming part will just continue to grind away in the background.

As AC dimming is a rather common use case, I’ve put in a feature request for this functionality.

Thanks Hugo.

Just FYI there is a good usable range with the software as it stands, with little-flickering in the 0.25-1.0 brightness value range. The bulb brightness isn’t really linear to the value, and 0.25 is nearly off (mostly an orange glow). Below 0.25 I turn the bulb completely off, similar to your example code.

Just out of interest (and as someone who doesn’t know much about hardware), how come this is the imp’s problem? Is the cost of the triac (which you need anyway) really much less than the cost of a device with the tiny number of additional components that it would need to do the wave-slicing itself in hardware?

Peter

Hi Peter. I haven’t tried a hardware only waveform chopper, but I think you’re right. You could use the triggered, voltage-controlled dimmer (like the ‘A more advanced triggering idea’ here http://pcbheaven.com/circuitpages/Voltage_Controlled_AC_Light_Dimmer/), and set the control voltage with an analog out from the imp.

That would be a hardware version of the triggered, programmable width pulse generator Hugo described above.

From my understanding, the wall dimmer you can purchase at a hardware store is also a voltage-controlled light dimmer, see the ‘Minimal Circuit’ here http://www.epanorama.net/documents/lights/lightdimmer.html.

I’m not sure why you’d want to build this type of hardware only circuit with 555 timers and the like in this day and age. You could also use a small, cheap processor like an Atmel ATTiny as a dedicated dimmer and control it from the imp.

Robert, you might to read this as you need know what load type the lamp/transformer is. See Adaptive Dimmers section

http://www.ilight.co.uk/downloads/iLIGHT%20Binder-HowDimmers.pdf

Thanks, that’s a good guide.

I’m trying to dim a specifically ‘Dimmable’ Philip Ambient LED bulb, and am doing leading-edge type dimming as they discuss in this technical note: http://www.lighting.philips.com/pwc_li/main/subsites/dynalite/library_support/assets/led_lamp_compatibility.pdf.

There is a section in that note on the need for ‘Load Correction’ with LED bulbs, which I don’t know anything about.