LM35 Temp sensor spikes

@zander

Posted by: @zander

I see English is your second language so I hope I am clear. It helps if you leave out useless and null statements to reduce the code volume (like beep and empty #include's) also if you can eliminate any code not directly involved in the perceived problem that also helps to reduce code volume. One last thing, statements like

if (beta == gamma){

  doSomething;

}

Occupy much less code space when written as 

if (beta == gamma) doSomething;

3 lines down to 1

Hope this is of some assistance.

Each to their own, but I personally do not like that kind of code reduction... it specifically causes more problems in debugging code/compiler errors, as you don't know which part of the line was in error (you might, and you might not), so why make it harder for you and the compiler?

However, I don't see a problem with: count2 = count2 = 0;

Cheers

@davee, et, al...

Posted by: @davee

The only clue as to why they might be different is the second sentence starts "When mounted" ... which you will be able to visualise and understand, but as I cannot see your equipment, I can only guess what you mean.

Spot on, and this is the key question... What does "mounted" mean?

Cheers

@frogandtoad Divide and conquer is a standard debugging technique. Since you are not bothered by his volume, find and fix his problem.

@fungreenfox

I've noticed that analog temperature sensors like this one can be extremely sensitive to fluctuations or noise in the supply voltage.  My first thought was adding a capacitor to try to filter out the spikes/noise.  But if that doesn't help, there are several things you can try in software to reduce the issue (not specific to the LM35, but can be helpful with sensors in general).

Basically, they involve some sort of filtering of the raw values you get from the sensor. Note that any filtering you do will impact your ability to detect real changes from the sensor. They will generally delay the response, and may affect the magnitude of the reading.

One approach is to simply ignore a reading that is too different from the last known good reading (an outlier). For example, you might ignore a reading that is more than 10% above or below the last (good) reading. You can obviously pick a different percentage. A risk is that the value you are sensing really has changed that much, but you ignore it because you assume it is a bad reading. Another risk is that you get a bad reading when you first start up, and then subsequent good readings get ignored.

Most of the other ways of filtering end up combining multiple readings to come up with some kind of average reading. You'll want some sort of delay between readings so that a spike or noise doesn't affect all of the readings you are using for the average. The length of that delay depends on how quickly you expect the sensed value to change, and how quickly you need to react. In your case, you might start with something like a tenth of a second or a small number of seconds. If you're just monitoring the temperature in a room, you might choose several seconds or minutes between readings. Ideally, a spike should only affect one or two readings out of several.

You can keep track of the last several readings and average them (add up the values and divide by the number of readings). Every time you make a new reading, you replace the oldest reading with the newest one. This is a moving average.

Another approach is exponential decay. For example, every time you take a new reading, you calculate 0.9 times the old filtered value plus 0.1 times the new reading. Those 0.9 and 0.1 can be changed, but need to add up to 1. The smaller (closer to zero) that 0.1 value is, the slower the filter will react to a change in value, and the less effect there will be from a brief spike. Note that you don't need to keep track of multiple past readings: just your most recent filtered value.

You can also change how you react to a change in sensor value. If you have the ability to control the fan speed (for example, with PWM), you might not bring the fan to full speed the first time the temperature reading is above your threshold. For example, using typical Arduino PWM with a range of 0-255, you might choose to increase the PWM value by 15 every time the temperature reading is high, and decrease the PWM value by 15 every time the temperature reading is low. Don't forget to constrain the PWM value to stay in its allowable range. Since 17 * 15 = 255, it would take 17 consecutive high temperature readings to make the PWM value go from 0 to 255. Again, you will need some delay between readings and adjustments to the PWM value. It should be more than one full period of the PWM (ideally several periods); that would typically be several milliseconds to tens or even hundreds of milliseconds.

You could do something simpler and wait for several high temperature readings in a row before turning on the fan (and several low temperature readings before turning the fan off). This is similar to ignoring big changes in the sensor reading, but will respond to a sustained change in readings.

When you are using a sensor to control something else that would affect the sensor reading (like a temperature sensor controlling a fan or heater), there are more complex solutions you can use. Look into "PID controllers." (This is really just more sophisticated software to decide how to react to a change in sensor reading.) In your case, a PID controller may be more complicated than you need (the added complexity might not produce a better result).

Good luck,

-Mark

Hi @fungreenfox,

In addition to all the other questions and suggestions, I have just looked at the TI data sheet for the LM35 and note it includes a filter on the suggested circuit for driving an analogue-digital converter, consisting of a capacitor and resistor in series, across the output to ground. An unusual approach, but as they make the chip, they are probably suggesting it with good reason.

From https://www.ti.com/document-viewer/LM35/datasheet/application-and-implementation#SNIS1595333

Best wishes, Dave

Hi Dave. I have read another article about a guy investigating something close to this. He is asking how to eliminate the noise on the line, and one suggestion is, to add a resistor and a diode, which would be a trick way of work around, but would with luck work.  Suggestion isnt for the LM35, but the main Q is still present. I have some Evisun B1205s 1w, that might help some on this, but they can not persist with a MaH at 230.
The Esp32 with relay turned on, can reach 230 MaH. 
The LM35's are performing within a range of one degree celcius when on USB and ranging from 25 to 40 and even sometimes up to 70c. Noise at the pwr supplier. There is a LM2596 stepdown on the wire also, making 24 into 5 volt. 
The sensors are also connected to allaround grounding, and positive, so if those are inside the LM35, they should be active already?
There might be something about, that the LM35 work best from 4V and up, they are getting 5v directly from the stepdown module.

Hi @fungreenfox,

   Sorry, you seem to be describing some different configurations and results, but I am struggling to comprehend the meaning.

I haven't used an LM35, but the data sheet implies 5V is the 'normal' minimum supply voltage, but the introduction says it will operate down to 4V, so this should not be too critical. However, that doesn't give guidance as to  how it will behave if its supply has lots of noise.

Noting it is a 10mV/deg Celsius output device, then temperature spikes of say 50 Celsius, suggests 500mV peaks ... which is perhaps 10 times more than I might have expected ...

I think you are saying the LM35 works normally when supplied from a USB source, but produces 'spikey' data when supplied with an LM2596 that has been set up for 5V output (and a 24 V battery source). If that is the case, it suggests the LM2596 output could be noisy ... it is a switch mode supply, that is widely sold as a very low cost module, often with a minimum of 'quality control' because of the very low cost. IF this is the case, you might try increasing the voltage from the LM2596 to about 7V, and then use a linear regulator, such as an LM1117 to convert the 7V  (from th eLM2596) to 5V for the LM35 supply, adding extra capacitors to filter at the same time.

Also, I am not clear about your ESP processor supply ... it needs to be 3.3V, but there is probably a linear regulator with an input of 5V or so input on the ESP board. In addition ESP chips can take a lot of current, especially when when doing WiFI or Bluetooth comms, and that might be causing problems.

In addition, earthing paths need to be carefully thought through ... sorry, this is tricky subject at best, and trying to diagnose over a forum is nearly impossible.

I think you need to try to do it all a small piece at a time, possibly using a known 'good power supply' options, and trying to track down the 'problem ones. It is necessary to become a detective, looking for clues!

e.g. power the LM35 from a small battery .. e.g. 3 x AA 1.5V cells .... does it work then?

Similarly with the ESP ... you may need 4 x AA 1.5V cells to drive the onboard regulator.

If it works with small batteries, then at least you know you have some wiring and supply issues to deal with, rather than software etc.

-------------

Note when power is coming from two sources, the 0V or 'earth' wires from each should only join at one point. Look up 'star point earthing' if you are not familiar with the concept.

Beware of making an 'earth loop', in which the 0V line has two paths between two points ... if (say) you are using one battery, to feed two power supplies, then it is very easy to make this mistake. Again, look up 'earth loop' if it is not familiar to you to find out about it.

----------

And remember the ESP chip is strictly a 3.3V device .. it may be damaged if the voltage on the analogue inputs exceeds this, even if it is only a momentary peak.

-----------------------

Sorry, I don't know any 'instant fixes', but hopefully this and the guidance from others above may combine for a good result.

Best wishes, Dave

@zander

Posted by: @zander

@frogandtoad Divide and conquer is a standard debugging technique. Since you are not bothered by his volume, find and fix his problem.

I understand the divide and conquer troubleshooting technique, and agree... my concern was putting if statements on one line, making it harder to read and debug.

Cheers

@frogandtoad Do you mean if (a > b) c = d; OR if (a > b) {c = d;}

Since the screen is so small (wrong orientation really) and we only get about 30 lines of code visible at one time I find it wasteful to use as much as 3 lines for what is conceptually one idea. I thought the entire idea of {} was to group several related lines together. Several means MORE than 1. In the past I would grab their code, run it through the formatter then start tidying up the code, even rewriting parts that made the code more readable but now I don't have time so ............... you can figure out the rest.

@zander

Posted by: @zander

@frogandtoad Divide and conquer is a standard debugging technique. Since you are not bothered by his volume, find and fix his problem.

Posted by: @frogandtoad
I understand the divide and conquer troubleshooting technique, and agree... my concern was putting if statements on one line, making it harder to read and debug.

Posted by: @zander

@frogandtoad Do you mean if (a > b) c = d; OR if (a > b) {c = d;}

Since the screen is so small (wrong orientation really) and we only get about 30 lines of code visible at one time I find it wasteful to use as much as 3 lines for what is conceptually one idea. I thought the entire idea of {} was to group several related lines together. Several means MORE than 1. In the past I would grab their code, run it through the formatter then start tidying up the code, even rewriting parts that made the code more readable but now I don't have time so ............... you can figure out the rest.

Yes to either of your examples.

The brackets "{}" introduce and define a scope, whether it be an if statement or a function, etc..., but that doesn't mean that you place statements on the same line just to save space over clarity - Generally speaking, it's just not a well accepted style of programming for reasons I have already highlighted.

Cheers