I'm having a weird problem using the TMP102 sensor.
Basically, I cannot use floating-point operations with my application, so what I do to get the right temperature is this:
1) Interpret the 8 MSB as the integer part
2) Interpret the remaining 4 bits as the fraction portion of the number.
I just handle everything in the fraction portion as integers, and then print them accordingly (the decimal point is just part of the
print format; the numbers are integers)
So, I read the 2 bytes that the sensor sends, and print them in a hyperterminal.
The first byte is working fine (I have a thermometer to compare results). However, the remaining byte is acting strangely: it only prints values between 0 and 127.
Considering 127 = 0b01111111, I am losing part of my fraction portion (the range from 128 to 255).
Has something like this happening to anyone? Maybe I'm doing something wrong while reading?
Thanks in advance
It sounds like you have the right idea when reading the two bytes. My concern is that you are reading 127 = 0b01111111 in byte 2. As you stated this byte is used for the decimal value of the temperature reading. In 12-bit mode only the first four bits are used for the temperature reading while the last four bits are all zero. In 13-bit mode only the first five bits are used for the temperature reading while the last three bits are all zero.
If I understand correctly you are reading the last byte as follows:
Is it possible that this byte has been misinterpreted in software? Is it possible that the most significant byte and least significant byte have been mixed up? The first byte will be the most significant while the second byte will be the least significant.
Linear Applications Engineer
High Performance Linear and Sensing Products
Phone: (520) 750-2432
Best Regards,Chris FeatherstoneLinear Characterization EngineerHigh Performance Linear Products
Thanks for your fast reply.
I think I'm not quite getting what you're saying. As far as I understood, in 12-bit config I have data in D7-D4 in byte 2, while in 13-bit I also have D3; however, you
said that in 12-bit I only have D7, D6 and D5. Maybe I'm understanding the datasheet wrong?
However, let me explain the issue a little bit more.
Let's say the measured temperature is 36.000 celsius. Then it starts rising (the fraction portion rises in multiples of 0.0625). I only print 3 decimal digits, so I get something like this:
36.437 -> This one is the problem. I get this 437 when the byte I'm reading is 127
36.437... (this value continues for a while)
Basically, it rises normally until I get to a fraction portion of 0.437, which is represented by 0111 (I just care about the 4 most significant bits from byte 2),
but then it's stuck there, until it jumps to the next integer, which has a 0000 in that part.
I don't really think I'm mixing the two bytes up, because the integer part is always right (as I said in my first question, I have a thermometer to compare results), and the
fraction portion is also always right until that value I mentioned.
As a side note, the only writing operation I'm doing to the sensor is writing the 00 address so that I read from the temperature sensor. Other than that I'm not
messing with any other register.
Thank you for the clarification, as well as the correction. Note that I modified my response above, and sorry for the confusion. I haven't seen this happen before. If I understand correctly the issue isn't that you are reading 127 like I previously thought it is that the reading of the device is getting hung up at the fraction portion 0.437.
Does this happen all the time? Let's say the temperature is 38oC and rises. Do you see this happening again at different temperatures consistently such as:
I will continue to investigate this issue.
That's precisely what happens: the temperature hangs at 0.437 (which is equivalent to 0111xxx in byte 2. In my case I always get
01111111 - the 127 I mentioned earlier - which still decodes to 0.437). And, indeed, it happens with every temperature I've measured.
So, yeah, after many measurements with 0.437 in the fraction portion it jumps to the next integer, like this:
38.437, 38.437... 39.000.
Thanks again for the fast reply, and let's hope we can figure this out =D
Perhaps you are losing the top most bit in each byte read somewhere in the I2C stack. Maybe try test with cold spray to cause a negative temp to see if most significant bit of byte 1 gets set. Or read the config register. Byte 2 should have the MSBit set.
I have checked the device with our EVM. Below is a screen shot of the Temperature Register.
This results in 27.9375 (above are bits D15-D4). As shown above you can see that bits D3-D0 are zeros. This is in 12-bit mode. Is it possible to capture a screen shot of the I2C lines? This would be helpful to determine any noise on the lines, if the data is valid, or if the microcontroller is not handling the bits appropriately etc.
Unfortunately I don't have the EVM, since I only bought the sensor, not a whole development kit.
To debug, I'm printing the second byte to a hyperterminal, and when I get to a temperature of 0.437 or greater in the fraction portion, I always read a 0111 1111.
I find it strange that I'm getting a 1 in the unused bits, since the datasheet says:
"The unused bits in the Temperature Register always read '0' "
Thanks for the support and for the fast replies.
Although you are getting ones in the unused bits I would still treat these as "don't care bits", as you have been doing. My check with the EVM was to see if I was able to replicate the issue. This sounds like a possible communication issue. If possible I would analyze the communication on an oscilloscope and look at the data when the temperature is above lets say
T = 27.437oC. If we can rule out a communication error, then we can also look at the program flow. If you would like to post any scope shots I will be happy to analyze the data.
Sorry for not answering sooner, I have been really busy this week.
This weekend I'm going to make some tests using and oscilloscope, as well as some other device that uses I2C, to see
if the problem is the communication.
Thank you very much for your help. I have already solved the problem =D
For some reason, my I2C protocol was having a problem when reading the second byte (the first one was indeed fine, but from the second
onward it was doing it wrong), that's why the integer part was fine, but the fraction portion was incorrect. I already made the changes to my I2C, and it
is working just fine.
Thanks again for all your help.
I am glad it is now working. Let me know if I can help with anything else.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.