Forums

Ricardo,

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.

Best Regards,

Chris Featherstone

Linear Applications Engineer

High Performance Linear and Sensing Products

Phone: (520) 750-2432

Chris

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.000

36.062

36.125

36.187

36.250

36.312

36.375

36.437  -> This one is the problem. I get this 437 when the byte I'm reading is 127

36.437

36.437... (this value continues for a while)

37.000

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.

Ricardo,

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 38^oC and rises. Do you see this happening again at different temperatures consistently such as:

38.312

38.375

38.437 

38.437

38.437...

38.000

I will continue to investigate this issue.

Chris

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

- Rick

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.

Rick,

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.

Chris

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.

- Rick

Chris

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.

Thanks!

- Rick

Chris

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.

- Rick

Rick,

I am glad it is now working. Let me know if I can help with anything else.