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/NOPB.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,
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/NOPB.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
-
X2(O$J%[QBIG{G1P4I{[email protected]
