EMI from Cell Phone Triggering IRQs in QG4!

[PatrickW]

Hi All,

I am using a QG4 in a new product that we have already produced a few thousand of.  The device is a battery-powered LED lamp with three brightness settings.  We've already gone through lots of field trials and months of testing.  But today I was just brushing my teeth, with one of these lamps sitting in the bathroom (where I had been using it in my own high-humidity "field trial").  The lamp was off, but all of a sudden, it turned on to mode one... then mode two... then mode three... all over the course of 10 seconds!  It was acting as if a ghost were pushing the button and turning the lamp on.  

I about freaked when I saw this as I thought it was a code malfunction that I had just randomly been present for.  But then I realized that I had set down my cell phone right next to the lamp.  After some investigation, I find that if I put my phone right next to the device, I can occasionally activate the lamp just by calling my phone.  Afterwards, even after many tries, the code is still running fine, and I can tell that no reset has occurred.

I use an IRQ with subsequent switch debounce polling to wake the device from sleep and then switch lighting modes.  I am really surprised that EMI from a cell phone could even trigger the IRQ to begin with, much less get through the debounce routine.  I do not have a cap on the IRQ pin, but it is not like I have a long antenna going into that pin - just a 5 cm wire going to a tactile switch.  

Can I prevent this IRQ triggering by just adding a 100 nF cap across the IRQ pin?

Beyond fixing the IRQ line itself, I am quite worried because I assume that if a cell phone can trigger the IRQ, it could also screw up the code execution completely.   Can anybody point me to comprehensive advice on this?  I have used QD4 for years and never experienced anything like this.  I have not yet checked whether this is just one device that is susceptible or all of the devices.

Thanks,

Patrick

[PatrickW]

Update:  It is indeed a common problem for all of the devices.  Basically if I put a phone right up against the board and call somebody, occasionally (like 1/3 times) the lamp will turn on.  It seems to be legitimately cycling through the modes without having any detrimental effect like a device reset, but this is still a pretty big problem that I need to fix.  

I presume I could fix this somewhat in software by just doing more polling of the IRQ pin (currently I poll only once to confirm the IRQ button press, around 10 ms after the ISR is triggered).  But I would much prefer a solid hardware fix.

Patrick

[kef]

What do you have connected to IRQ pin? Any resistor (what value), or just weak internal pullup device?

Connecting just capacitor is not right. You need series resistance between cap and switch to limit capacitor discharge current through closed switch contacts.

[PatrickW]

If you have any specific EMI filtering/shielding references/ideas, please let me know - I know that is a huge topic for RF-intensive applications, but it seems like overkill for such a simple device to get into wrapping this in foil or whatever, on account of cell phone interference.  

I just have the weak internal pullup - it's not that weak though, 25 kOhm or so - I'm kind of amazed that is getting overcome by a nearby cell phone.  I could strengthen that pullup.  If the capacitor is small, eg. 100 nF, is a resistor in series necessary?

[bigmac]

Hello Patrick,

Does your board layout provide an effective low inductance  "ground plane"?  If using a leaded component for the additional bypass capacitor, I would suggest that a lower value may be more effective at the frequencies involved, say 100p or 1n.  Whatever capacitor type you choose must have a self-resonant frequency that is above the frequency of interest., which is another way of saying that it must have very low self inductance.  And this assumes that the leads can be kept very short, and the return path to ground is of low inductance.

Using a smaller value capacitor, it is unlikely that there would be sufficient discharge energy to damage the switch contacts.  However, a series resistance (or inductance) may help the RF filtering process.  If the switch itself uses a flying lead to connect to the board, maybe a ferrite bead on one or both leads may help to reduce the effectiveness of the "antenna".

Note that the normal purpose of the debounce code associated with the input, is to lockout any bounce that may occur after the first closure is detected, so would unlikely affect the current problem.  What might help depending on the nature of the interference, is to modify the code so that each closure, following a short debounce delay, must remain continuously active for a minimum period for the required action to occur.  Maybe a debounce period of 5-20ms, and a minimum closure period of 100-200ms would be appropriate.

Regards,

Mac

[PatrickW]

So I tried monitoring the IRQ pin to see if I could spot the noise on my 100 Mhz scope.  I was expecting to see random noise if anything, but low and behold, this is the waveform I get when I place a call on my phone with the antenna right next to the switch wire:

No wonder this thing is triggering the IRQ... I am getting 1 ms solidly negative pulses.

I was thinking about putting a filter on the line, but main concern now is that no amount of filtering is necessarily going to solve this problem, because if the pulses happen just a little bit more often, then even the filtered DC component of this waveform would trigger the IRQ (active low).

I am really surprised that I can get this large of a signal out of a switch wire.  The signal is managing to pull the IRQ line nearly down to ground through a 25-50 kOhm pullup resistor.  So I don't think adding a 5 kOhm pullup is going to do the trick either.  I can mitigate this somewhat by twisting the pair of wires together, but not completely.  

[bigmac]

Hello Patrick,

Here is my best guess of the phenomenon you are observing:

The input pin to the MCU has an intrinsic diode connected between the pin (anode) and Vdd (cathode), and there is also a pullup between these two points.  You are coupling the RF signal into the pin, and the diode is rectifying the RF signal, which produces a negative DC component that is filtered by stray and input capacitance.  This is why you are observing a solid negative impulse.

There are two possibilities - decrease the shunt impedance to RF ground, or increase the series coupling impedance to the input pin, or some of both.  Reducing the pullup value and providing a low inductance shunt capacitance at the pin should decrease the shunt impedance.  To increase the coupling impedance, the best way would be to use shielded/coaxial cable to the switch, but other series inductance or resistance may help.  The twisting of the wires might help to some degree because you are increasing the distributed  shunt capacitance.  You might also try an additional capacitor (say 100p) between the wires, at the switch end.  But be aware that the connection of the oscilloscope probe may also affect the results obtained.

The ease of implementing a solution is likely to depend on the detail of you circuit board layout, and its grounding provisions.

I am not familiar with the details of GSM transmissions, but my presumption is that the phone produces RF bursts of 1 ms duration during ringing, and that these are at maximum power level.  When the phone is subsequently answered, I assume that the power level is decreased under most circumstances.

I think that the input monitoring I previously suggested was also quite similar to Rocco's suggestion.  However, I would probably suggest to test for an unbroken switch closure over a period of at least 100ms.  If you were sampling at 1ms intervals, you would expect to see 100 sequential samples with low state, before a switch event would be registered.  If any sample was high state, the count would be restarted.

Regards,

Mac

[TurboBob]

the best solution is double-overkill.

Fix it in software,  so that it works 100%,  fix it in hardware so that it works 100% (independent of the software fix).  Then implement both in production.

Is your power supply pin properly bypassed?  Any other long I/O traces or wires?

Single sided board or double?   SMT or thru-hole?

Since you have such a clean trace on the scope,  a software fix should be do-able,  even if you write something that specifically ignores this type of periodic signal.

Bob

[PeterHouse]

If you can mitigate this by twisting the wires, try 5K the pullup.  You may be surprised.

What shielding do you have in place for static surpression at the switch?  Does the switch have a static shield connected to circuit ground ?

[PatrickW]

The tactile switch that this connects to is behind a hermetically sealed silicone cover - I don't have any ESD protection on it.

I added the 5k pullup - this has some but not enough effect on the resulting signal.  As you can see, the interference can pull a 25k pull-up resistor nearly down to about 0.4V.  With a 5k pulllup, the line still gets pulled down to 1.2 V.  This depends a little on where I put the phone, so there may be no difference at all actually.

I don't want to use a 1k pullup because the 3 mA current draw may confuse other parts of my circuit.   Anyway I feel like there has to be a better solution here... some way to dampen the signal?  But the problem is that the signal being created is nearly binary DC in nature, rather than the fast noise I was expecting.  I don't understand why I'm getting 1 ms long pulses instead of noise.  I can filter noise, but how does one filter out a 200 hz full-amplitude square wave??  And how am I getting such a signal from RF interference in the first place?  Really weird.

[rocco]

Hi Patrick,

Twisting the wires probably wont help, as the signal is not differential. The input pin has a high impedance, while the ground pin has a very low impedance.

Maybe you can fix this in firmware.

The debounce algorithm that I have been using for 20 years would be immune to a 1 millisecond pulse (I usually set it to 5ms or 10ms, depending on the switch specs). It is not a simple delay, which can be tricked by multiple pulses.

I sample the signal at a fixed rate at some fraction of the debounce period, usually 10 to 50 times. As an example, if I wanted 5 milliseconds, I might sample every 100 microseconds. When I detect a transition, I start a debounce counter counting down from 50 to zero at each sample. If I see any transitions, I reset the counter to 50. I only accept a switch change when the counter hits zero.

In effect, a switch closure or open is only accepted after it has been solidly high or low for the entire 5 milliseconds. This would filter out your 1 millisecond "noise".

BTW: Have you tried lengthening the wire? Probably won't help, but might show if the wire-length happens to be "tuned" to the cellphone's frequency.

[PatrickW]

Rocco:  I was thinking the same thing:  Twisting the wire shouldn't help because this is not a differential signal.  Our EE told me to twist the wire and I thought he was nuts... but for some reason it seem to reduce the interference.  Difficult to see on the scope but I get far, far fewer switch detections - maybe it's all in my head.

Anyway with twisting and a 5 kOhm pullup, the interference on the scope and in practice is pretty minimal - I can't imagine it would ever be a problem in a normal situation.  A 1 kOhm pullup resistor is even better, nearly dampening the signal completely on the scope.  But I don't want that much current draw during switch presses, so I am going to stick to 5 kOhm and take your suggestion on modifying the debounce routine.  I have used the routine you describe before, but in this software I only implemented one-time polling.

I am concerned that this is not really going to fix the problem though under all conditions.  Of course it will be impervious to the cell phone signal I posted a screenshot of, but what if some phone puts out a square wave where the negative pulses last for a full 5 ms or 10 ms?

I can't shorten or lengthen the wire for assembly reasons.  My only option might be a coax wire, but that seems like a real pain - if that's really what's required, I'm surprised I haven't heard of this before even for consumer-grade applications (of course I wouldn't be surprised if coax and shielding were used in critical applications). 

Thanks,

Patrick

[PatrickW]

Surprisingly again, I can still get switch-press triggers even with your counter-based debounce routine ( have it polling 35 times!).

Patrick

[JimDon]

The fix is to provide adequate EMI shielding/filtering on the board.

[rocco]

---

JimDon wrote:

The fix is to provide adequate EMI shielding/filtering on the board.

---

As an alternative, you can have marketing add it on to the list of features . . .

A 5cm wire is equal to a half-wave antenna at approximately 250mHz, or a full-wave antenna at 500mHz. You could try lengthening the wire to a non-multiple of 5cm to see how that affects it. If it is the wire, a simple solution might be to use a shielded wire.

[PeterHouse]

I would like to have a flashlight with a built in cell phone ring detector !!!

If you are susceptible to cell phone rings, you are probably also susceptible to nearby lightning strikes and other EMI - it does not sound like a good feature.  If it is not crashing your software, then it is most likely transferring enough charge into your IO pin to make the QG4 see an IO transition.  The problem is - you do not know how much charge is being transferred and if it has any chance of IO pin damage from more powerful / different band radios. 

A stiffer external pullup may be part of the answer as it will shunt more of the unwanted current away from the IO pin.  An ingress filter in the form of a series R and C to ground would also help.

Good Luck,

Peter