DS18B20 and noise

[BeanieBots]

I have a 28X monitoring the case temperature of a 1kW motor. The 28X is housed in an earthed metal case supplied via a switcmode power supply. The DS18B20 has a 2m twisted 3-core flying lead.
About 1 in 3 times, at the point when the motor is energised, the 28X resets, crashes nad has even lost its program. (there is no problem once the motor is running). So far, I have determined that the cause is solely due to noise comming in via the DS18B20 leads.
I have done the following in attempt to stop it.
DS18B20 supplied via 22R.
10uF tant plus 100nF ceramic across DS18B20 rail.
PICAXE pin to DS18B20 via 330R
4k7 pullup on PICAXE side of 330R.
This reduced crash frequency to about 1 in 5.
Adding 1nF between signal and 0v on DS18B20 side of 330R gives about 1 in 8. Increasing to 10nF causes failure to read.
I am currently using 2n2 and suffering about 1 in 10 crashes. Often the PICAXE is OK but the DS18B20 returns 0 until power is cycled.

Does anyone have suggestions on how to suppress this noise problem further? The motor itself is well suppressed, it seems to be the startup surge that is causing the problem. Slow start is not an option.

 

[hippy]

If the 28X is being zapped bad enough to lose its Flash program there's some seriously heavy noise coming in. Trying to find the nature of that noise is probably the first step to removing it.

Diode clamps to limit over and negative voltages and zeners may all help, along with inductors on the input lines, and maybe even the humble ferrite bead. But unless you know what you are trying to solve, how to will just really be guessing.

 

[Technical]

Have you given the PICAXE any brownout circuitry? Won't prevent the issue but will certainly help the PICAXE restart.

Try using something like a
MCP100 4.35V Brownout IC
on the reset pin
(available from www.tech-supplies.co.uk)

 

[Technical]

You could also try this on the 1-wire line.

http://pdfserv.maxim-ic.com/en/ds/DS9503.pdf

 

[BeanieBots]

Thanks, some useful tips.
Hippy, yes I agree, some really serious noise. So much so that I now question the integrity of the 28X and will replace it once I've solved this. Totally seperating the DS18B20 cables has little effect which to me suggests electrostatic rather than electromagnetic which I don't understand because the problem is at power on and not at power off which is when high voltages would be generated.

Whilst waiting for replies I have actually been playing with ferrite. Wrapping the 3 cores twice around a clamp style core close to but external to the casing has helped a lot but not 100%. I will try adding beads as well.
Technical, there is no brownout issue as far as I can tell (no indication on scope at time of incident) but I have already fitted a watchdog to get around the reseting problem. Interestingly, a DS1307 on the same board also became corrupt on a few occaisions but then that might have been caused by the out of control 28X. Disconnecting the DS18B20 completely leaves the system perfect after many on/offs which very strongly suggests noise comming in on those lines rather than anything comming up through the power supply.
I like the look of your suggested chip from Maxim. It is along the lines of what I was attempting to make decretely but the only fast zeners I have are 36v. I'll order a few and carry on playing with ferrite while I wait for them to arrive.

 

[Jeremy Leach]

How about using optoisolators?

 

[BeanieBots]

The problem with opto-isolators is that besides the bi-directional comms, there is power as well.
I've yet to try an obvious solution which is to use three core screened cable because I don't have any.

Could the flash corruption be caused by the 28X itself? The program has many pokes and a few writes where the address is maintained within SFR. If the SFR became corrupt, it could write/poke to anyware.

 

[hippy]

If the affect is enough to have glitched the 28X and caused the Program Counter to go walkabout it's entirely possible it has overwritten or corrupted the downloaded program held in Flash. There is limited protection in place in the PICmicro to help stop that, but Sod's Law says they won't work when needed.

The Firmware should be unaffected by erroneous code execution because it is write protected. When the PICmicro is put outside it's normal operational envelope, all bets are off.

Edited by - hippy on 1/19/2006 4:33:26 PM

 

[BeanieBots]

Well done Hippy, the humble ferrite bead (plus all the above) seems to have done the trick. Thanks for the pointer. It would suggest that whatever the cause, it's damn fast.
I'll fit screening and a DS9503 as belt and braces.

Posts crossed.
Thanks for the update about 28X flash.
I'll bin that 28X anyway because it's anyones guess what strain has happened internally.

Edited by - beaniebots on 1/19/2006 4:38:23 PM

 

[premelec]

Glad you've solved it - also seems to me to be an argument for using a simpler sense like a thermistor in this application - simpler to filter the 1KW motor crud away from the motor- I'm assuming that you are looking for over temp conditions... thermistors are pretty rugged compared with these clever ICs we use...

 

[BeanieBots]

Actually, it was the long leads and noise that made me take the digital route over analog. I'd not expected that level of noise though. I'm after repeatable accuracy for measuring efficiency rather than a simple "hot" indicator. Still seems to be working so a good learning excersise.

 

[Jeremy Leach]

As an aside re my suggestion on optoisolator... been reading my Forrest Mims book and he shows how two LEDs face to face can offer BI DIRECTIONAL opto decoupling. LED both acts as light source and photovoltaic source. Not saying it would have helped here though.

 

[BeanieBots]

Possibly. I would see the very small current produced by an LED when illuminated only by another LED to be a challenge to make as a retro-fit. None the less, an interesting thought, worthy of further investigation in its own right.