• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Spurious negative temperature readings with LM95071

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

April155

New Member
Joined
Jul 23, 2016
Hello, I hope this is the right place to ask .I have worried a few days.
I am using the LM95071 in a simple application to measure ambient temperature of our product. The normal temperature range is approx 15degC through to 50degC. In general the part is working well, however intermittently I will read a value of -22degC. The spurious values occur around once every 100-200k reads.
Typically a valid read should be 0x0eab, however I am occasionally getting spurious values of 0x0f4b3, 0x0f4a7, 0x0f4a3 or 0x0f4b7
I am reading the LM95071 every 4ms, which is much faster than its conversion time, however the datasheet implies that this should not be a problem as the read doesn't inhibit the conversion process and the temperature register is updated when /CS is high after the conversion is complete. Is it possible that the asynchronous nature of the SPI transactions is causing a problem with the chip or is there another explanation for these spurious and incorrect readings?
I have attached a scope trace of the offending read. My observation of the trace is that the SPI timing and transaction look fine, expect the data coming out of the LM95071 is incorrect given the actual temperature. Note: /CS is Yellow, MISO is blue, CLK is green and our trigger output is pink.
Can you help with information or suggestions as to what the problem may be?
We haven't tried slowing it down yet, however in a effort to try and get more occurences we did speed up the reads and have an image that reads a value every 300us. This does in fact produce more frequent errors and in fact we have found that it is not just a single bad read, but a burst of values that are around the 0xf4b3 point.
What happens at the 130ms point in the LM95071 converter? Can you provide more info as to what might be happening?
We can try reading no greater than once every 130ms however based on the rate of occurances to date that might be a month in between failures and therefore harder to debug.
However, regarding the operation of the device from the datasheet there is the datasheet link http://www.kynix.com/Parts/2540220/LM95071QIMFX%2FNOPB.html I see that the typical conversion time is 130ms (228ms max) and the note that goes with that states:

"(4) This specification is provided only to indicate how often temperature data is updated. The LM95071/LM95071-Q1 can be read at any
time without regard to conversion state (and will yield last conversion result). A conversion in progress will not be interrupted. The output
shift register will be updated at the completion of the read and a new conversion restarted."

I had interpreted that as having the ability for us to read the output of the LM95071 at any time and at any rate with the only penalty for this being that we would get the same answer multiple times. It would appear that if we read the part too soon after a conversion has completed that we can get the invalid outputs.

What worries me is that if this is a purely asynchronous process then even if we do read at 130ms or greater then we may still have an issue if we read too soon after the completion of a transaction. If this is true then it appears the only way to solve the problem is to do multiple reads and throw out any suspect readings.
All the suggestions and every suggestion will be grateful.
Regards,
 

Attachments

LutaWicasa

, Immutable, Administrator
Joined
Dec 22, 2000
Location
Huntsville, AL
Didn't state anything wrong per se.
If power droops low enough it will go to a power down state. When it then transitions to power up state you could be getting those spurious readings.
 

Bobnova

Senior Member
Joined
May 10, 2009
I was thinking maybe there's some ripple in the power supply that is confusing it. Say a little spike or dip that, if timed perfectly, throws off one measurement that you catch every few hundred thousand reads.
Another possibility is a dubious ground that the signalling can cause a fluctuation in.
Do you have all the various bypass caps recommended for everything?
Is this device running on batteries? SMPS? Transformer PSU? Solar? Mice?

I'd be inclined to do three things:

1) Replace the chip, maybe that specific silicon has a defect.
2) Up the bypass caps, have a 0.01µF ceramic, 0.1µF ceramic, and 10µF electrolytic as close to the sensor chip as you can.
3) Have the software/firmware compare the current read against the last two and throw it out if it's too large a difference. In 4ms the temp can't change that much. Even in 140ms it won't change that much unless you're doing something especially interesting.