Offline Software controlled lamps malfunction when plugged in near to power tools

[treez]

Hello,
We have designed some 40W, offline 230VAC, non isolated LED lamps which have no AC input filter. (-because they are based on linear current regulators). They can be dimmed up and down by a microcontroller which receives DALI input signals. We had some builders in to our factor to do some work, and whenever they operated their heavy machinery such as drills and angle grinders, our LED lamps began to turn ON and OFF , -ie malfunction.
The micro in the lamp is PIC16F18856.
The ones that malfunctioned had software in them which is written by our remote software contractor. We actually loaded some of our own simple software into the lamps, and this software did not malfunction. Our simple software simply repeatedly dims the lamp up and down.
Why did our software work fine, when our contractor’s software malfunctioned?
Our simple software actually declares the ports to inputs or outputs in just the same way as the contractor’s software…..the difference was that our software does not actually read from the ports declared as inputs.
There aren’t that many inputs to the microcontroller….just the DALI RX signal, the MCP9700 temperature sensor signal, and the SFH5711 light sensor signal.
Why did our contractors software malfunction, but our software did not malfunction?
Is there something about the universally available DALI software libraries which is overly noise sensitive? Maybe the DALI software libraries just read the DALI signal with one read per bit….instead of taking multiple reads during a bit to really check that a bit is high or low…..ie, to check that a “high” or low input isn’t just a noise-spike input.

Also, the builders have gone now, but we want to buy something that will cause the problem again, so that we can see how we can solve the problem….what equipment would you recommend to get this kind of interference?…what about a laptop SMPS with its AC input filter removed?

 

[betwixt]

DALI shouldn't be particularly prone to noise. I would guess the builders used motorized power tools that injected significant amounts of interference close to the DALI signaling frequency and it was misinterpreted as a real command. I can see that happening if their tools had brushes arcing as the commutator turned at particular speeds. The real problem is their tools weren't suppressed.

Brian.

 

[treez]

Thanks, and form what you say i think we need a ragged old DC motor because it will give this contactor arcing which will inject as muuch noise as possible, so we can see if we can overcome it.

 

[betwixt]

Easier to buy a cheap power tool and remove the interference filters. However, I doubt random noise is the culprit, I would expect the frequency of the arcing conflicted with the DALI bit rate and was interpreted as real data.

Brian.

 

[treez]

Thanks, we have a 10k pullup on the micro DALI RX pin.....this is pulled down by the opto...but at this time the DALI bus wasnt connected.....so the 10k resistor was just pulling up to the micro's 3V rail. -Its hard to see how noise could afflict this.....ie, how could noise pull down the micro pin below the logic low threshold, when there is a 10k pullup?

 

[betwixt]

If the DALI input wasn't connected it clearly wasn't mis-interpreting the bus signals. Without seeing the product and software it is difficult to know what caused it then.
If I had to make a guess, and that's all it is, it probably crashed and the lighting changes you saw were from random start-up. The crash could be from floating inputs as you suggested before or it could be from poor line filtering. The PIC has a way of telling you where it's last reset came from (PCON0 register) but unless you have some kind of diagnostic that can be run without needing another reset it is difficult to read.

Brian.