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.

  • TI Thinks Resolved

LM73: Incorrect temperature readings from LM73

Prodigy 110 points

Replies: 20

Views: 491

Part Number: LM73

Hi,

As the title suggests, I am seeing abnormal temperature readings with the LM73:

- The abnormal readings are not directly after power-on, but after a certain amount of time of valid readings. I have 10 different units and they all exhibit the failure within about 2 hours of run time, but the exact time varies.

- The abnormal readings of the Temperature Data Register are usually around the same value: 0xF5XX or 0xF6XX, which corresponds with a negative temperature (around -20 degrees C). The temperature readings before the incorrect ones were around 35 degrees C. Once an incorrect value is read from the LM73, the temperature readings return to the valid range (~35degC) again.

- The problem is not I2C noise, because the microcontroller is interfacing with other I2C peripherals on the same I2C lines with no corrupted data at all. Any I2C noise would be expected to affect all devices on the same bus. The microcontroller is not seeing any problems with the I2C protocol itself (misplaced start/stop conditions, bus arbitration or NACKs).

- The VDD ramp rate is faster than the minimum of 0.7V/ms specified in Section 9 of the LM73 datasheet. The VDD takes about 400us to rise from 0V to 3V3, corresponding to a ramp rate of about 8V/ms. The microcontroller software is also performing the software reset sequence in Section 9 of the datasheet, to prevent any problems with corrupted data due to POR ramp-rate.

This problem appears to be very similar to that experienced by others on this forum, however I've not been able to find a definitive answer in those posts as to why the LM73 behaves in this way.

Kind regards,

Tom

  • In reply to TomW:

    Hello Tom.

    I have left the WA running on a weekend and it has not failed 2 days of the read cycles.

    Regards,

    Amit Ashara

  • In reply to Amit Ashara:

    Hi Amit,

    Ok. That's very strange, I can't explain why I'm seeing the issue and you aren't. I'm still unclear as to why the poll rate should affect the temperature reading. The datasheet clearly says I can read the Data Register at any time. Is the Data Register not double-buffered in the LM73?

    I am now trying a software build with a 1000ms poll rate to see if that makes any difference. I suspect it will be tomorrow before I can verify whether that has failed or passed.

    Meanwhile, our hardware engineer has suggested that we should try to induce the problem by introducing some ripple on the VDD, to see if that makes the problem occur. Do you have any data on what is the lowest that VDD can go without causing bad readings, or how much VDD ripple is acceptable?

    Thanks,
    Tom
  • In reply to TomW:

    Hello Tom

    As I mentioned earlier, the read transaction seems to be causing the issue when a temperature conversion happens at the same time. Even though the datasheet mentions that the temperature can be read at any time, I believe that reading it at over 2x the conversion time will prevent the issue from occurring. Let me know what results you get from your tests. Ideally I would like to have the parts which does not seem to follow the 2x solution, to figure out what is happening, since I cannot reproduce it at 2x read time.

    Regards,

    Amit Ashara

  • In reply to Amit Ashara:

    Hi Amit,

    But surely, polling the data register at any periodic rate is eventually going to align with when the sensor is performing the temperature conversion, because the host software's clock and the LM73 clock are not synchronized. So I don't understand why the 2x polling rate would prevent this from happening?

    I will see if we can return a sensor that is exhibiting the fault to you, so you can do some more diagnostics.

    Thanks,

    Tom

  • In reply to TomW:

    Hello Tom,

    The working hypothesis is that if a read corrupts the data, the next conversion will correct the same. By reading at 2x the conversion time, if the current read corrupts the data, then the next read shall occur after the conversion by which time a correct conversion would have corrected the reading.

    Regards,

    Amit Ashara

  • In reply to Amit Ashara:

    Hi Amit,

    Right, in that case I think I misunderstood the whole idea. You're saying that the 225ms poll rate doesn't prevent me from getting a corrupted reading in the first place, it just means that after a single bad reading I can guarantee that the next reading is a good one, correct?

    So could you confirm, when you said you ran it on your end with a 225ms poll rate over the weekend and saw no errors - did you see *any* corrupted readings, or did you mean that you did see single occurrences of bad readings, but they were corrected upon the next read?

    On my end, I am definitely still seeing single occurrences of corrupted readings with a 225ms poll rate.

    Thanks,

    Tom

  • In reply to TomW:

    Hello Tom,

    TomW
    Right, in that case I think I misunderstood the whole idea. You're saying that the 225ms poll rate doesn't prevent me from getting a corrupted reading in the first place, it just means that after a single bad reading I can guarantee that the next reading is a good one, correct?

    No. What I am saying is when a read corrupts the conversion data, the corrupted value gets loaded into the temperature register for the next read cycle. Howvever when the next conversion happens the corrupted value gets "corrected", subsequently to which the read is always correct.

    Yes, I can confirm that the reads were no longer corrupted with ~225 ms of read interval.

    On your side, is there any timing variation you see on the 225 ms? I.e. it is sometimes 224 and sometimes 226 ms?

    Regards,

    Amit Ashara

  • In reply to Amit Ashara:

    Hi Amit,

    Right, I see what you are saying now. That makes sense.

    Yes, it's possible that the timing of the software is not that accurate. I will try increasing the software timeout to something like 230ms and see if that makes a difference...

    Thanks,
    Tom
  • In reply to TomW:

    Hello Tom,

    Were you able to test the device with the 230 ms software timeout between reads?

    Regards,

    Amit Ashara

  • In reply to Amit Ashara:

    Hi Amit,

    Yes, I did manage to test with a longer interval between polling. Due to the design of my scheduler, the easiest for me is to pick multiples of 6.25ms, so I tried both 231.25ms and 237.5ms. I saw occasional invalid readings with both of them, so no difference from the 100ms default rate.

    However, since then I have managed to implement a software workaround where I store the previously known good reading, and if the new reading differs by more than 0.5 degrees C from the previous reading, I reject the new reading and use the old one instead. I do this a maximum of 3 times and then I flag a downstream fault. This appears to work perfectly in "riding through" these occasional bad readings from the sensor. Since we know that under normal operating conditions, the PCB temperature can never change by more than 0.5 degC within 100ms, we are satisfied that this solution will work for our needs.

    I think we can go ahead and close this thread. Many thanks for your time and effort in trying to debug this.

    Kind regards,

    Tom

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.