---

I think because the outputs are interrupt driven. At every AC zero cross an interrupt is triggered, which I guess doesn't rely on the instruction pointer to execute its code?

Jim

EDIT: This might be a good application for a watchdog timer, I think. Set it up to shut things down if the main program code doesn't kick it every so often.

---

Power supply lines is my best guess.

Jim

---

OK let us know how the EMI filter goes.

I found these docs which I thought were interesting and relevant.

http://www.ti.com...lup100.pdf
http://www.vishay...accaps.pdf

Would I be ok having the Arduino powered from the DC jack as well as having a USB cable connected to a laptop?

---

Would a choke on the power supply line(s) be useful in this application?

---

Dan -

This is a very interesting question. I've noticed that the commercial PID controllers I've autopsied all have common mode chokes on board between line power input and their AC-DC converters -- and that they do not suffer from this problem. I have a few common mode chokes here, but haven't gotten around to doing any testing.

It doesn't help that the problem occurs so infrequently that testing is very difficult.

Jim

---

Yes, this is OK. The Arduino's and the TC4C have circuitry that automatically switches the V+ input from USB to the DC jack when a DC voltage above around 7V is detected on the jack.

But .... ground (V-) will remain connected to both the USB and DC jack in this configuration. It is only the V+ that is switched over to external.

Jim

---

I think I have fixed my freezing/reseting problem. I did the following.
- Powered the arduino from a 7.5V DC power supply rather than USB
- Putting ferrite beads on most of the inputs to the Arduino/TC4
- Adding an X2 suppression capacitor across the 240V AC fan supply.

But I have now been having another strange problem!

I noticed that if I touched the metal braid on my thermocouples or my macbook case if the usb cable was connected then the power to the fan got mucked up with the waveform becoming weird. I checked the waveform on my scope but didn't get a screen shot. It was only happening with the fan power at 65% or lower. And this only happens when my bare feet were touching the concrete floor!

The controller is wired the same as Jim's example except I have two separate power circuits. One for the fan and TC4 and the other for the heater. http://www.mlgp-l...111120.jpg

I completely disconnected the heater power and disconnected the heater and touching the neutral power wire on the heater circuit causes the same issue. The neutral line goes through the zero cross SSR.

I then disconnected the 5V power I had going to the zero cross detector (I think Jim said this 5V connection wasn't necessary) and the problem became worse. I could now just move my hand near the control box (without touching it) and the fan power would by mucked up.

Any ideas? I'm a bit baffled by this one. Maybe I could try replacing the zero cross SSR?

---

Brad -

Good to know that you solved the freeze-up problem. Perhaps the X2 capacitor is acting as a snubber?

Regarding the weird waveform, my guess is that the problem lies with noise in the signal coming from the ZCD board to the TC4.

Can you put a scope on the ZCD output signal? Measure the voltage between the ZCD output pin and GND. It should be constant 5V except when the AC crosses zero every 10ms. At the zero crosses the signal should drop to 0V for 1ms or thereabouts.

The software on the ATmega watches for a falling voltage and interprets this as the zero cross. If there is noise then the processor will be tricked into thinking a zero cross has occurred when in fact it has not. This would cause the timing to get really messed up for the fan control signals.

Jim

---

I've checked the pulses coming from the ZCD and it looks ok even when the fan output is weird. I have attached some of the waveforms I recorded.

I can create the problem when I probe the positive pin on OT1 and OT2. And also by just touching the insulation on the leads going from the TC4 to the SSRs. And in some circumstances it occurs by just putting my hand near the leads.

I mentioned in my previous post that the problem only occurs when the fan power is set to 65% or less. And I also noticed that having the heater set at 100% stops the problem and at 0% it is at its worst.

Also attached are waveforms for the fan output at 50% with and without the weird waveform. I was probing the output of a 15VAC wall-wart connected in parallel with the fan.

I'm thinking of trying the following when I get a chance.
- connecting mains earth to the TC4 ground. Any reason I shouldn't do this?
- load an old version of the arduino code to see if that helps?
- replacing my SSR
- ???

---

What I can offer is that something is messing with the timing of the TRIAC (i.e. SSR) firing. I'm not sure what it is, though.

Here's what I see:

1. In the "good" trace, there is still voltage present after the zero cross. This is probably because the fan load has enough inductance so that the line voltage and fan current are out of phase. TRIAC's switch off when the current is zero, but the ZCD detects when the voltage crosses zero. The Arduino is sending "on" signals to the gate based on voltage, and relies on the TRIAC to turn itself off at the end of each half-wave.

2. In the "bad" trace, the firing of the TRIAC is delayed, and then there is a very odd-looking voltage still present after the zero cross. I'm not sure what is causing the delay in switching on the TRIAC. But I suspect the weird trace after the zero cross might be coming from voltage stored in the wall wart?

3. Unfortunately, there's no way to be sure that the AC wave coming from the wall wart is in phase with the line AC, is there? I suppose it is possible that your measurements have a phase delay in them as the result of the wall wart (I am speculating here).

There are two timing parameters you can play with in the code (note that the values are in "counts", not in uS).

First, there is ZC_LEAD, the presumed delay between when the ZCD signal goes low and the "real" zero cross of the AC current. The default value would be around 500uS for a purely resistive load. This is based on the observation that the pulse width coming from the ZCD is around 1000uS in width and is centered about the true voltage zero cross. You can try larger values of this zero offset parameter to try and compensate for the fact that the current and voltage may be out of phase.

Second, you can adjust the width of the TRIAC firing pulse (TRIAC_PULSE_WIDTH). The pulse to the gate of the TRIAC only needs to be long enough to latch the TRIAC. If this pulse is too short then the TRIAC may not get fired. For my popper motor I found (by trial and error) that this width needed to be no less than 2mS.

If this pulse is too long then it may overlap into the next half wave (although I think the code automatically turns off the gate signal at each zero cross regardless of whether the TRIAC pulse is done).

You might try different approaches to this. One approach would be to simply leave the gate signal high until the next zero cross. This wastes a little power, but otherwise shouldn't be a problem. The other approach might be to shorten the pulse width to the minimum required to latch the TRIAC.

In a perfect world, you would set up your scope to simultaneously measure the current to the fan and the signal coming from the ZCD to see if there is a phase shift.

You might also track the ZCD signal against the gate signal to the TRIAC, both with the fan connected and with it disconnected.

Try and determine which of these 3 possibilities is the culprit:

1) phase shift of AC line voltage versus fan current
2) incorrect timing/width of the TRIAC firing pulse
3) noise on the gate signal to the TRIAC

Another thought: Keep in mind that OT1 and OT2 are both open collector outputs. So OT2(+) will be at +5V and and OT2(-) will be floating until the processor puts a voltage on the base of the transistor to pull OT2(-) to GND. Anything that allows OT2(-) to go to GND will fire the TRIAC. Maybe an open collector is not the ideal arrangement here and going directly to the MCU pin for OT2 would work better? You might also try a 10K resistor across the OT2 pins to keep OT2(-) pulled up when OT2 should be off?

Finally, you might try putting the heater on OT2 and the fan on OT1. Phase angle control should work flawlessly on the heater since it is a resistive load. And the ICC control on OT1 worked pretty well on my popper motor. In my test setup, all I had to do was connect the output from SSR1 to the fan and from SSR2 to the heater to give it a try.

Jim

---

Thanks Jim, that's given me a few things to try.

I also like the idea of driving the SSR directly from an Arduino output pin but will try the pullup resistor on OT1(-) and OT2(-) first.

Yes. I'll definitely try to scope the ZCD pulse and the base of the OT1 transistor at the same time to see if the timing is changing.

Yes, I wondered if probing the wall-wart output was showing my true waveform for the fan.

---

Jim

Here's some more waveforms showing the ZCD pulse combined with the output on the Arduino's digital outputs for OT1 and OT2.

The ZCD pulse looks stable in all cases.

When the fan is going weird it seems that OT2 is only triggering every second half cycle. And the majority (7 of 8?) of OT1 pulses seem to reduce in width to about 5ms instead of 10ms.

AND this all still happens with both the fan and heater disconnected!

I haven't yet tried any of the your other suggestion. Should I start a new thread instead of clogging this one up?

---

And here's the waveforms showing the ZCD pulse and OT2.

---

And some good news is that I have a cheap ebay bluetooth module working well for wireless logging and roaster control.

---

Sorry that should read OT1 not OT2. Sometimes the edit post option is not available??

---

That information is very helpful to understand what is happening. Now to try and figure out why!

What sketch was running when you made these graphs? I would like to try and reproduce the problem here.

Jim

---

Yes that's right. But working out why is the hard part.

I've attached the code I currently have loaded. It's a slight variation of what's in the aArtisan_PID trunk directory in the repository.

---

I tried the 10K resistors across OT1 and OT2 and also connecting mains earth to the TC4 but this didn't help. In fact it was worse with the ground connected.

I then noticed that lifting the cables from OT1 and OT2 up out of the project box made the problem go away. So I hot glued some of the the cables into position and it's working fine at the moment! But I'm still don't really have any idea what was happening.

I'll keep you posted if it plays up again. I still haven't had any more freezes or resets yet either.

---

I got some chokes by accident in a shipment of magnets last year. They are 30mm x 5mm. Pictured is one wrapped with #14 wire, and two rolls with about fifty in each roll. I have about 20 rolls. I'd be happy to mail some these to any experimenters. Just PM me with your mailing address. If they deal with the RF issue, the developers might want a couple of rolls to ship with every TC4 board.

---

I have no idea how many turns you need on the coil to create the inductance you want. Here are some resources.

http://www.physic...p?t=616605
http://en.wikiped...i/Inductor