Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Weird (And very annoying) uC problem

Status
Not open for further replies.

things

New Member
Hey guys, I built a temperature controller to switch on and off an airconditioner condenser unit (Compressor and fan). I am using an ATMega168. Attached is a LM335 temperature sensor, 2 switches, and LCD and a relay (Thru a MOSFET)

I have the circuitry mounted inside the condenser unit.

Now, I am having a problem with the microcontroller "glitching" when it fires the relay. I have a video of it here: YouTube - Temp controlled oversized water cooler problem

I have tried many things to fix the problem, but nothing seems to help. Things I have tried:

Diode and capacitors on relay, both on the relay itself and on the control PCB.
Adding a heap of capacitors to the power supply.
Moving the wires coming off the PCB away from the mains wires.
Triggering the relay from a seperate PSU.
Powering the whole circuit from a seperate PSU.

And so far, nothing stops it glitching.

The ONLY other thing I can think of, is an EMP radiating from the compressor and fan wiring, and entering my circuit thru the LCD wires, or even just directly on the PCB.

**broken link removed**

Nothing I have tried helps. About the only thing I haven't tried is shielding all the circuitry, which is going to be very annoying.

Is there anything else you suggest I try? I'm completely out of idea's and theories as to why this keeps glitching like that.

Cheers,
Dan :)
 
Last edited:
I'll draw one up and post it in a little while :)
 
Ok, here it is. Sorry about the inefficient diagram and huge image :(

**broken link removed**

Transformer outputs 10VAC 200mA.

First capacitor totals about 3000uF, one after the 7805 totals about 3000uF as well.

Capacitor right on the relay is a 100uF electrolytic, capacitor on MOSFET is a ceramic type, something like 100nF.

Resistors on the switches are for pulldown. Resistor on reset for pull up.

Capacitor on temp sensor is another ceramic type.

Capacitor infront of transformer is 2 of those little yellow brick types, 33.uF and .1uF.
 
Last edited:
hi,
I dont think thats a PIC glitch problem, the video shows character corruption on the LCD, but the PIC seems to maintain control.???
I would decouple the power lines to the LCD and if possible screen the LCD leads them.
 
So, put a capacitor right on the power lines right at the LCD? As for shielding, not really sure what I can use. Aluminium foil wrapped around the wires and grounded maybe?

Cheers,
Dan
 
A battery in this case is unpractical. Besides, I tried a completely separate PSU and it still glitched ...
 
You have to find out how the pulse is getting into the microcontroller. If you don't isolate the supply and put resistors and capacitors on each of the outputs, you will never be able to home in on the problem.
 
I tried flipping the lid upside down (The one the PCB is sitting on), grounded it. So there was a peice of grounded sheet metal between the compressor/fan etc and the PCB, and it STILL glitched. Something else is going on here :(
 
Last edited:
You are not isolating the microcontroller sufficiently. You need to keep isolating it more. You really want to know if the wiring of the PC board is picking up the pulse or if the in/out connections to micro are transferring the glitch.
 
I don't know how I can isolate it any more than using a seperate PSU, and it still glitched.

How any kind of EMI is still making it thru the panel of grounded sheet metal is whats confusing me. If a sheet of grounded metal isn't stopping the interference, nothing will :(
 
If you say you can connect another power supply, why don't you make me happy and put a battery on the micro.
I have absolutely no faith in power supplies.
 
Since the LCD glitch doesn't seem to be having a detrimental effect on anything, I'm going to try coding it so that it re-init's the LCD after switching the relay. If that doesn't work, I may be able to use a transistor to power cycle the LCD.

EDIT: Did up the code and it all seems to work OK now (Although hackily) :)

Thanks guys :)
 
Last edited:
Do you have LVP enabled?

Did you leave any LCD pins floating, maybe an Enable pin?
 
Last edited:
Hi,

I may be reading the diagram wrong....it's a bit haphazard (as you've already noted), but here's how I read the problem, I reckon it's a case of back EMF.

Please don't consider me an expert, I'd be interested in wiser heads than me chiming in with any corrections. It's an interesting problem.

You're switching the relay with a mosfet on the lower side, with your back EMF diode dumping EMF current to the positive supply side. After switching consider the relay is a momentary battery of maybe a hundred volts (depending on the current and number of relay turns) in reverse to the switching voltage. From this assumption...
Several things could go wrong here.
- your tracks might not be thick enough to handle the current, thus leading to a voltage spike or droop due to the resistance in the tracks themselves. Remember stripboard tracks have little holes all along them, so you need to think of them as lots of thin tracks (around the holes) joined by thick tracks (between the holes).
- capacitance on the gates of the mosfet may inject a signal into the micro. See below comment on a mosfet driver/additional protection.
- the 1n4004 might not be able to handle the EMF voltage or current.
- the extra current dumped into the high side supply line may be affecting the regulator.
- possibly the mosfet is being driven too hard to switch the relay, leading it to suck too much current from the micro thence the supply rail.

I would change to a high side switch and route EMF current to ground, widen the tracks (use several lines if you're using stripboard) and move the back EMF diode as close to the relay as possible. I'd also keep the logic circuitry and tracks well away from the relay stuff, that is have effectively two circuits physically and electrically isolated as possible.

You could also try driving the mosfet with a mosfet driver rather than direct off the micro. I'm not sure about how to do this. There might also be some EMF protection issues required on the mosfet.

If you can get an oscilloscope on the unit, you should be able to see if there is a spike or droop on the supply lines. Remember you'll need to measure at different physical points, even on the same electrical connection as the current will make the tracks little resistors on the relay switch moment.

To solution to reinit the lcd after switching may get it functional....but I bet the spike or droop or whatever the original problem is still underneath. I wouldn't bet on the micro being totally reliable even if it is more resistant than the LCD. Also if there are high voltage spikes, or large current spikes happening to the micro output pins or the regulator, eventually it will die.


Phil
 
I can tell you this- SHIELDING is not the issue. It's highly implausible that enough EMI is radiating out through the air and induces a current in a trace to confuse the PIC.
You either:
1. Have a floating input that the code is responding erratically to (IIRC, leaving LVP enabled causes the chip on-board programming hardware to freak out when the LVP pins are left floating)
2. You've got a voltage + spike on a signal wire or Vdd, but this usually causes complete latchup- which can only be recovered by cycling the power.
3. You've got a drop in Vdd that can cause a brownout, which should be detected by BOR if you have that sort of feature and have it enabled.

Your reg might not have sufficient capacitance, or the wrong type of capacitance. You need a 0.1uF ceramic right by the controller's Vdd/Vss pins.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top