Zero crossing phase noise?

[miceuz]

Hi,

I'm building yet another mains dimmer module and have stumbled on this phenomena - the length to ZC pulse varies quite a lot. Down below is my zero crossing detection schematics and a graph of ZC pulse lengths measured by a microcontroller running on 16MHz - looks like a white noise.

Can anyone explain to me what is causing it? Is it some ripple riding on top of AC mains sine? I'm aware that probably this graph is aliased as I'm sampling at only 100Hz (recording a lenght of a pulse after every ZC).

Any idea how to deal with it? In terms of filtering I only have a 120nF cap across my mains input.

I know that I can just make my conduction periods shorter than the edge of "problematic area" and that probably will be totally ok, but I'm curious about the basic stuff.

[SeanB]

Probably a mix of mains harmonics and power line transmitters, along with all the local AM and FM transmitters picked up on the line. Try adding a capacitor across pins 3,4 of the optocoupler to filter it a little, suggest 10n to start. As well add the same to the input across the LED.

[AlfBaz]

It's difficult, for me, to understand the data you have provided via the graph. Clearly there's some kind of variance but not knowing what the units are the extent of difference is hard to see.

Presumably the mcu starts timing when "Zero Crossing" goes high and stops timing when it goes low?

If this is the case I can see several potential sources of error. First and foremost is software latency. Are you using an interrupt, if so is it high priority? Is the time from the signal going low/high to the timer starting/stopping fixed? if the interrupt is doing context saving, perhaps the size of the context changes depending on what else the software is doing.

On the electrical front the opto's transfer characteristic needs to be looked at. The amount of current flowing through the LED's and the output photo transistor all affect the Current transfer ratio, as does the temperature, so at what point the AC turns the output on/off may have something to do with it.

Altering LED current and output transistor collector current may change the "sensitivity" of the OPTO

[Rufus]

The rise and fall times of that optocoupler are about 100us and 50us with 10k collector pull up when driven with a square input.

You have 47k pull up and are driving it with some unstated part of a sine wave which will make them significantly slower.

The switching threshold of a digital input is affected by noise on the signal, the supplies, and within the chip. When you you feed it a signal with slow edges that switching threshold uncertainty is translated into uncertainty of the time when the signal reached the threshold. I guess you have a Schmidt trigger input, if not you would likely see multiple digital transitions as noise on those slow edges takes the signal above and below the switching threshold as it passes. 

You need a lower value pull up, and probably need to drive the LEDS harder to increase the rate of change of current around the zero crossing point.

[miceuz]

Thanks to all, for the suggestions. I've spent a day experimenting with the thing, but really didn't go far.

Regarding my measurement setup - I perform measurements using 16 bit timer input capture interrupt of ATmega 328. MCU is running at 16MHz on a crystal. This is the code of the interrupt:

ISR(TIMER1_CAPT_vect){
  if(HIGH == digitalRead(){
    TCNT1 = 0;
    TCCR1B &= ~_BV(ICES1);
  } else {
    pulseLength = ICR1;
    semaphore = 1;
    TCCR1B |= _BV(ICES1);
  }
}


As fas as I understood the variation in ZC pulse length is caused by a mains sine crossing zero at steeper or more shallow angle and this is caused by mains sine peaks being higher or lower, OR by a smaller ripple riding on the mains sine that gets aliased by sampling it at 100Hz AND this might be partially caused by mains frequency instability (is it something like 0.2%? If so, it contributes 20uS difference in period length)

I get different rise/fall times than specified in a datasheet, probably due to different input conditions, as you can see below, decreasing the value of pullup does not increase the rise time. I've checked the signal on the scope - with decreased pullup values, I get more triangle-like pulse with long edges. I've tried varying the led drive current - this shortens the pulse and decreases the amount of noise, but not significantly.



I've meda mesurements in 5 different combinations of AC mains input resistors and pullups. Below are my results. I'm very eager to hear your comments on them.

At first - just plain recording of adjacent pulse lengths.






Then the FFTs. I've used a rectangular window, so it might be showing bananas here, but anyway, some low frequency components can be noted.





In the final graph I try to show how different are lenghts of adjacent pulses.

[DRT]

You might try rewriting your ISR to sample ICR1 on both edges (then diff them) rather than zeroing TCNT1 on the first edge. At the moment, you have the variable interrupt latency of the AVR architecture built into your timings.

[miceuz]

You might try rewriting your ISR to sample ICR1 on both edges (then diff them) rather than zeroing TCNT1 on the first edge. At the moment, you have the variable interrupt latency of the AVR architecture built into your timings.

good point, but alas, I've changed it and made another round of measurements - it's the same. My MCU program currently just measures ZC period length and sends it via serial, so there was no different interrupt entry point delays, just the first entry overhead that should be constant for every interrupt.

[ejeffrey]

I don't really understand why this 'zero crossing pulse duration' is a meaningful quantity, or what information you are trying to extract.  It isn't clear to me that it even has anything to do with the mains waveform at all.  Even if it is, I can't see what the physical significance of that number is.  Have you tried driving with a clean 60 Hz signal from a function generator?  You can use a small transformer to generate a 120 VAC signal from a function generator.

If you want to analyze phase noise on the mains, measure the time interval between successive zero crossings, not the pulse width that comes from your zero-crossing detector.  If you want to analyze harmonic content, digitize the waveform directly with an ADC  or use a notch filter to separate the harmonics from the fundamental.

[Rufus]

I don't really understand why this 'zero crossing pulse duration' is a meaningful quantity, or what information you are trying to extract.

He is making a phase control dimmer. Jitter in zero cross time detection directly produces jitter in his triac/thyristor trigger timing and so power control.

[miceuz]

I don't really understand why this 'zero crossing pulse duration' is a meaningful quantity, or what information you are trying to extract.

Lets say I want to know exactly when the zerrocrossing will happen. I get zerro crossing interrupt before the real zerocrossing. I Imagine, I get the pulse that is symmetric around zc point (oops, 5% resistors , then count a half of it. When pulse width varies, so varies point, when I trigger the triac.

I'm interested in understanding the nature of the noise. Does it look like a mains noise to anyone?

One thing I see is that probably I want a pulse as narrow as possible, so higher CTR optocoupler would be appropriate and I'd need to burn more power in resistors (those are already toasty hot in 16.4k mode)

But really now I hope I will be able to find a digital solution - at least keeping track of zc pulse length would help a bit - half of near pulses differ less than 50us from one another.

On another hand - does a 2% power jitter matter for lighting and motor controll applications? I wander when switching is done at the peak of the mains sine, 2% of firing angle might create substantial fluctation in power delivered - somewhat 4% -- am I right about this?   

Is this problem common for all the zc detection circuits or is it culprint of this particular solution (cheap, dumb) or is it my design?

[DRT]

You might try rewriting your ISR to sample ICR1 on both edges (then diff them) rather than zeroing TCNT1 on the first edge. At the moment, you have the variable interrupt latency of the AVR architecture built into your timings.

good point, but alas, I've changed it and made another round of measurements - it's the same. My MCU program currently just measures ZC period length and sends it via serial, so there was no different interrupt entry point delays, just the first entry overhead that should be constant for every interrupt.

It doesn't matter what your code is doing (unless it's sleeping), you'll get either 1, 2 or 3 clocks latency variation depending on which particular instruction was executing at the moment of the interrupt trigger.

[AlfBaz]

If I'm reading your charts correctly the trend shown in the one titled "Zero crossing pulse length, r input = 16.4k R pullup = 1k" is interesting.

Is that exhibiting a rise and then flattening of the pulse width variances? If so does it correlate with the "Relative CTR change with temperature" graph in the data sheet for your opto?

The chart in question seems to indicate a cold start, followed by warming, probably due to LED's IF and outputs Ic, and then it looks as though its heading for a relatively flat temperature equilibrium.

[codeboy2k]

Why do you even care about the pulse width at all, if all you want to detect is the start of the zero-crossing??

You should ensure the leading edge of your pulse is coincident with the zero-crossing and should not care about the length of the pulse, and usually a zero cross pulse should be as narrow as possible.  Use an edge-triggered interrupt pin not a level-triggered interrupt.

If you are getting HF line noise triggering your detector early, before the zero cross, then you need to low pass filter all that HF line noise out, before you send it to the zero crossing detector and onto your interrupt pin.

And as was posted already, the actual interrupt will have 1, 2, or 3 cycles of latency, depending on where in the instruction cycle you were when the interrupt comes in to the micro.  So the max jitter would be 3 clock cycles at your specific clock speed.

If you need more accuracy then this, then you need to use a free-running timer where the edge of the zero cross pulse causes a timer snapshot but does not stop the timer.  When the ISR is finally entered (after a max 3 clock cycle delay) you can read the timer snapshot from it's register. This will give you a relative time of the zero crossing from the previous time... if you need that. I don't know exactly what you really need, but I am just throwing out ideas here.

[AlfBaz]

And as was posted already, the actual interrupt will have 1, 2, or 3 cycles of latency, depending on where in the instruction cycle you were when the interrupt comes in to the micro.  So the max jitter would be 3 clock cycles at your specific clock speed.

I have doubts about that, even though I mentioned it earlier. If its a decent timer capture module, the timer value should be shifted into a register on the chosen edge by hardware, the interrupt generated and the "frozen" timer value retrieved. If that's the case, interrupt latency should be irrelevant.

As for why, I think the opening post said he was curious

[Kremmen]

I have doubts about that, even though I mentioned it earlier. If its a decent timer capture module, the timer value should be shifted into a register on the chosen edge by hardware, the interrupt generated and the "frozen" timer value retrieved. If that's the case, interrupt latency should be irrelevant.

As for why, I think the opening post said he was curious

The MCU that the OP is using does exactly that. The interrupt latency affects the counter reset operation, but not the timing capture that is hardware assisted. The reset is done in the ISR so the 1-3 clock latency will impact that operation but it is not enough to explain the large variation in timing results (the latency is max ~200 ns).

The root cause of the large jitter is not immediately obvious but i suspect something that is not directly visible from the schematic or ISR code.

[codeboy2k]

And as was posted already, the actual interrupt will have 1, 2, or 3 cycles of latency, depending on where in the instruction cycle you were when the interrupt comes in to the micro.  So the max jitter would be 3 clock cycles at your specific clock speed.

I have doubts about that, even though I mentioned it earlier. If its a decent timer capture module, the timer value should be shifted into a register on the chosen edge by hardware, the interrupt generated and the "frozen" timer value retrieved. If that's the case, interrupt latency should be irrelevant.

That's exactly what I said in the last paragraph of my post. Maybe I wasn't clear.  He should use a free running timer to capture the time value at the moment of the interrupt; yes, then there will be no latency. I thought I said that.

The paragraph you quoted of mine where I indicated there would be latency was referring to a situation if the OP was just using a regular interrupt and assuming his ISR would run at each zero crossing.. it won't.  That's where the latency would be *IF* OP was doing it this way..

If OP is externally interrupting a (decent) timer, then the timer value would be stored at the time of the interrupt, even though the ISR might be entered with some latency, but the stored value would be read from the register. 

[AlfBaz]

That's exactly what I said in the last paragraph of my post. Maybe I wasn't clear.

My apologies, reading it again, it's perfectly clear. Selective reading on my part 

[DRT]

The OP said he changed the ISR to use the ICR properly (he was initially resetting the TCNT in the interrupt, which is flawed as discussed).

Any chance of some scope traces?

[ejeffrey]

Lets say I want to know exactly when the zerrocrossing will happen. I get zerro crossing interrupt before the real zerocrossing. I Imagine, I get the pulse that is symmetric around zc point (oops, 5% resistors , then count a half of it. When pulse width varies, so varies point, when I trigger the triac.

OK, between this and looking back at your schematic this makes sense.  The pulse is high whenever the AC waveform is too low a voltage to turn on the LEDs in the optocoupler, so you have to find the middle of the pulse for the true zero crossing.  I don't see any fundamental reason this circuit shouldn't work, but it doesn't surprise me that it has problems.  You will be sensitive to the matching and temperature coefficients of the LEDs, the relatively slow-going cutoff of the drive current, and the slow pull up on the phototransistor.

I agree with DRT, at this point some scope traces would be useful -- both of the mains waveform and the zero-crossing output.

If you want a different circuit topology that is intrinsically more precise, look to detect the zero-crossing directly.  You could do that with a comparator to generate a clean logic signal for the opto-coupler, or you could use a small isolation transformer to couple the AC waveform directly to the micro controller side and forgo the opto-coupler altogether. 

[miceuz]

I agree with DRT, at this point some scope traces would be useful -- both of the mains waveform and the zero-crossing output.

If you want a different circuit topology that is intrinsically more precise, look to detect the zero-crossing directly.  You could do that with a comparator to generate a clean logic signal for the opto-coupler, or you could use a small isolation transformer to couple the AC waveform directly to the micro controller side and forgo the opto-coupler altogether.

unfortunately I don't have an access to a two channel scope, and the one I have is a crusty old small soviet scope, the zc peak looks like a normal peak - symmetric, 400us at the bottom. the scope has a hard time to trigger on it and when it does - it's jittering, before, I thought it's due to problems in the trigger circuitry of the scope, but now I suspect that i'm seeing exactly that i'm measuring. it's 1 volt / 100us per division

Somehow I was unable to find small isolation transfmers on digikey and decided to give a shot at this design - it seemed temptingly cheap. Fortunatelly the main thing this will be driving is a heater, not a light or a motor, but since I have an MCU on board, I thought I could use it as a I2C controllable dimmer module too. I wander how will it react to it's own noise that it will create on the power line, when I will give some decent load to it

[mamalala]

Be aware that AC from the mains is a really dirty thing. Everyting that is hooked up to the mains induces some noise. Then, there is a chance that there is some stuff modulated on it for remote control purposes. That is, not just locally by some neighbour, but by the electricity company itself.

All the wiring acts as a capacitive and inductive element. Whatever you plug in to (or switch on) a socket somehwere else on the same circuit will skew that further.

Keep in mind that you have a _really_ long cable run going into your home. Inside your home, you have even more cabling, and spread out over several rooms. The best you can do is to filter the mains to eliminate "higher" frequency stuff. Best would be a peaking filter at exactly the mains frequency you expect (well, plus/minus a bit to allow for variances in the mains supply itself). Then feed that into your ZC circuitry. In case of the optocoupler, give it a lower pull-up/down resistor, 47k looks a bit high.

Then, check your microcontrollers datasheet. There might be additional latencies involved. On a PIC micro, you have a low and a high level interrupt. Latency to enter any of them is always the same (from a purely µC viewpoint). The low level can be interruptet from the high level, but not the other way aroud. Of course, if you use C (or any other compiler) it may be that you have some extra code on entering/leaving the IRQ that adds additional latency.

Of course, if you use some filtering to get a clean waveform for detection, it will already have a shifted phase at that point. So you have to account for that accordingly by using a proper (timer-) delay.

Greetings,

Chris

[miceuz]

I think I've solved it - on the photo of the scope there are as if TWO peaks clearly visible and thats because when using lower value resistors there are TWO peaks in the histogram. There are two modes of zc pulse, because there are two modes of led switching. Leds alternate every second zerocrossing while composing leading and falling edges. This explains why the noise graph is so jaggy - near pulses are always away from each other. Thanks for making me to do a photo