LM73: Incorrect temperature readings from LM73

Oops, forgot to attach the file. Here it is...

Hi Amit,

I have now obtained a trace of the I2C transaction. See below - this corresponds to a valid temperature reading of 0x0CF4 (25.9 degC). I have now set up my scope to trigger when a negative temperature reading occurs (data byte 1 = 0x0F) to verify that it's not I2C noise, and I'm waiting for the issue to occur.

Regarding your comment "I would suggest modifying the ramp rate to match the specification using additional bulk capacitors" - we have a 100nF bypass capacitor on the VDD signal, which is what Figure 14 in the datasheet specifies. The minimum ramp rate is specified in Section 9 of the datasheet as 0.7V/ms. Is there also a maximum ramp rate?

Here is a snippet from our schematic (there are 4K7 pull-ups on the I2C lines, not shown here):

Also what do you mean by "I am suspecting it has to do something with the read of the temp sensor and the conversion cycle occurring at the same time.". In Section 6.5 of the datasheet it says:

"(3) This specification is provided only to indicate how often temperature data is updated. The LM73 can be read at any time without regard to conversion state (and will yield last conversion result)"

Surely I can read the Temperature Data Register at any time??

Thanks,

Tom

Hi Amit,

I have tried slowing down the polling to once every 225ms as suggested, but the error still occurs. Just for investigation, I also tried a shorter polling periods of 50ms and 25ms, and the error is there. I have managed to capture an I2C trace when the incorrect reading is read:

As you can see, the reading is 0xF5C4, which corresponds to -20.375 degrees C. It's clearly not I2C noise causing this.

At this point I'm not sure what I can do. Seems like the LM73 is intent on giving me incorrect readings occasionally, and I will have to do something clever in software to get around the issue, like disregarding a reading if it is outside a certain 'valid' range and just use the previous reading to "ride through" these incorrect ones.

Thanks,

Tom

Hi Amit,

I've tried it once more with the 225ms polling rate on the 10 devices we have here, and the problem still occurs. I can't explain why you're not seeing it too. Are you sure the issue doesn't occur at all, or it just takes longer to occur? For me the issue can take up to a few hours to occur normally (i.e. with 100ms polling period), so I would expect that with 225ms period the issue would still occur but might just take longer, because there is a lower chance of reading the Data Register at the wrong moment. I had to leave the 10 devices running overnight to see the failure on them with a 225ms polling period.

Sadly returning the part to TI is not something we can easily do as they are surface mounted to our devices. Unless we can find a cause for this, I think I am just going to have to 'ride through' the issue in software. I can detect when the temperature reading is outside of an expected range and ignore the reading (use the last known good reading instead), until the LM73 starts giving me good readings again.

Thanks,

Tom

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

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

Hello Tom,

TomW said:

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?

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