Timer that supports microseconds for Yun

Is there a timer library compatible with this board that supports microseconds? And one that I can create multiple timers at the same time and have them run in parallel?

Thanks

i8flan:
Is there a timer library compatible with this board that supports microseconds? And one that I can create multiple timers at the same time and have them run in parallel?

Thanks

@i8flan,
interesting request. Yun has microsecond resolution, if you can access a NTP server. So unlike other Arudino boards, the Yun supports a microsecond timer and since the Wifi part is actually a Linux router you can have multiple software timers. However, the since it has been noted to drift (several seconds per day), this may not be of sufficient quality. As such, could you go into more about your requirements.

TIA
Jesse

(NOTE: Yun has several undocumented bugs causing issues, if the Time of Day is incorrect).

Hi Jesse, thanks for your reply. It's a long-ish story, but what I'm trying to do is get 2 (or more) TRIACs to fire and turn off at zero cross detection; for the purpose of dimming two lights independently. This means I need to have each TRIAC wait for a period of microseconds after zero cross is detected and then shut them both off 8.33 microseconds later and wait for the next zero cross and then do the whole thing over again.

I need to have each bulb be at a different dim level and be able to control that dim level in the loop.

I have a sense that if I can start two independent timers in parallel at zero cross, one for each TRIAC, and fire them after different delays I may be able to accomplish this. But not sure how to create a timer for each that has microsecond resolution, use it for that zero cross instance to turn the TRIAC on and off and then use it again at the next zero cross.

Let me know if you have any thoughts on it. I have 5 different code samples with interrupts and without and can dim both at the same time using a bunch of methods. But dimming them independently seems to be where the challenge is.

Thanks
Matt

i8flan:
::::SNIP::::
Let me know if you have any thoughts on it.
::::SNIP::::

Yep. I think someone else will be online soon that can help you. Maybe SonnyYu or ShapeShifter or Matt or Russ.

My thoughts are you definitely need hardware for this. I'm thinking this is for a light show of more than 10 minutes. I'm thinking in the long term you could live with drift in the software clocks. However, since you are doing a zero cross detection, you might get one in a thousands misses. And while that might be acceptable over time, I think occasionally you might get a "blink" instead of a "dim". And I'm sure after a while you could fix that, but then some other software bug will appear.

My sense is you need a good hardware solution, with predictable drift.

Someone will be along soon.

Good Luck
Jesse

i8flan:
It's a long-ish story, but what I'm trying to do is get 2 (or more) TRIACs to fire and turn off at zero cross detection; for the purpose of dimming two lights independently..

How stable does the light level need to be? Are small fluctuations acceptable? What else will the processor be doing during that time? The answers will have a bearing on how complicated the solution needs to be.

I've done several circuits like that to control the speed of a motor. In that case, absolute stability was not as critical, as slight variations were smoothed out by the rotational inertia of the motor/blower assembly. What I did was have an AC zero cross detection circuit trigger an interrupt on the processor. When the interrupt fired, it triggered a hardware timer to delay for the desired phase angle. When the time elapsed, it fired an interrupt, and the handler for that interrupt turned on the TRIAC trigger output, started a second hardware timer for the pulse width, and programmed in a new phase angle to the first timer. When the second hardware timer expired, its interrupt handler turned off the TRIAC trigger output. Everything was done in interrupts since the processor had many other tasks to perform. Using interrupts sped up the response time, but did bring in some slight jitter to the outputs as the ISR response time could vary slightly due to other interrupts and other software variances.

On another project, involving a large manufacturer of commercial and industrial lighting controls, absolute stability of the output was a prime requirement: even partial cycle or phase fluctuations were simply not acceptable, they wanted absolutely no flicker or variation in the output. For that project, the zero cross signal went through a software phase locked loop to accurately track the line frequency and make it immune to any jitter or noise pulses. The output of the PLL was used to synchronize a hardware timer to the line frequency, and the hardware output of the timer went directly to the TRIAC, eliminating software variances.

So there are medium and complex solutions to the problem. A simple solution, if the processor is not doing anything else time consuming, would be to have a spin loop waiting for the zero cross detection, then keep checking micros() until the phase delay has passed, set the output, delay a few more microseconds before turning the output off. micros() typically has a resolution of 4 uS.

For the hardware timer method, there is timer hardware available on the Arduino processor. I've not used it (the above projects were on vastly different processors) but it should be able to run at the processor's clock speed, giving you plenty of speed and resolution. I see several libraries for dealing with the hardware timers, but they all seem to be set up to generate PWM or periodic interrupts. That's not really what you want, you want to trigger them as one-shots when a zero crossing occurs. It may take some searching to find a suitable library, or you can just use the processor datasheet to figure out how to control the timer directly. If you are experienced with accessing registers to program processor peripherals, programming the timers shouldn't be too difficult; but if you don't have such experience they can be daunting.

and then shut them both off 8.33 microseconds later

Might you be off a few orders of magnitude? 8.33 us is 120 kHz. Did you mean 8.33 ms, which is 120 Hz, the frequency of the zero crossings?

Your entire loop (detect zero cross, turn on TRIAC, turn off TRIAC) must complete every 8.33 ms. But you don't necessarily need 8.33 us resolution to run the dimmer.

If you want to control your triac from your AtMega, maybe the following code can be of help; this (old) code of mine can control a triac in 256 steps; here’s the zero crossing interrupt:

void dimInterrupt() {

	uint8_t d= dim;

	if (d < THRESHOLD)
		digitalWrite(PINDIMOUT, HIGH); 	// pulse on to triac
	else if (++d) {
		OCR1A  = SLICE*dim;
		TCCR1B|= 1<<WGM12; 		// turn on CTC mode
		TCCR1B|= 1<<CS11; 		// set CS11 bit for /8 prescaler
 		TIMSK1|= 1<<OCIE1A;		// enable timer compare interrupt
	}
	else
		digitalWrite(PINDIMOUT, LOW); 	// pulse off to triac
}

Variable ‘dim’ always has a value in the range 0 … 255; A value lower than THRESHOLD always turns on the triac immediately because a lot of triacs won’t properly switch on if the current is still too low.

Here’s the timer interrupt routine:

ISR(TIMER1_COMPA_vect) {
 
	TCCR1A= 0;				// disable timer for triac
 	TCCR1B= 0;

	digitalWrite(PINDIMOUT, HIGH);		// pulse to triac
	delayMicroseconds(10);
	digitalWrite(PINDIMOUT, LOW);
}

As you can see from the code, this routine simply sends a 10us pulse to the triac; this is done after SLICE*dim timer ticks; for 50Hz AC, a proper value of SLICE is 75 and a reasonable value of THRESHOLD is 15 (triac dependent). PINDIMOUT is the output pin the controls the TRIAC. The interrupt routine needs to be hooked up to an input pin that can detect zero crossings.

kind regards,

Jos