• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 769 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Spurious negative temperature readings with LM95071

Graeme Fraser
Prodigy 30 points
Other Parts Discussed in Thread: LM95071, LM95071-Q1

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?

Regards,

Graeme

  • 0
    TI__Expert 7220 points
    Hi Graeme,

    Do these errors pop up when you slow down the read time of the LM95071 to at least 130ms?

    -Michael Wong
  • 0 in reply to Michael Wong
    Prodigy 30 points

    Hi Michael,

    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.

    Regards,

    Graeme

  • 0 in reply to Graeme Fraser
    TI__Expert 7220 points
    Hi Graeme,

    Think of it like time blocks of 130ms. In the first time block, no matter how many times you read that block it will always give you the same temperature until the first block has ended and the second block comes up. A read in the second time block will yield a different temperature (if it changed).

    Right now the you are sampling the part at 4ms and 300us which is way too fast for the part to do conversions and may in fact be causing the errors you are seeing. We recommend following the recommended datasheet values of waiting at least 130ms between samples.

    To create a robust system we do not recommend just reading the raw temperature values from the LM95071. Instead we recommend to take a series of samples and check if they are within a few LSBs or within a range of each other. Occurrences such as voltage transients on the VDD line or noise on the SPI bus could cause the conversion to create weird results. In essence, don't rely on a single temperature reading, take a few readings and judge if the output is truely the correct temperature.

    -Michael Wong
  • 0 in reply to Michael Wong
    Prodigy 30 points
    Hi Michael,

    Thanks for your response and we will take your guidance in terms of checking multiple reads before determined the "final" value.

    However, regarding the operation of the device from the datasheet 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.

    Regards,

    Graeme