LM75B weird behavior.

[IAmBack]

I've noticed weird behavior on LM75B (11-bit version). Temperature measure result is transmitted in 2 bytes, while first byte is integer part, and the second is fractional part.
When I heat up sensor slowly (or while it is cooling slowly) i observe something like "delay" between integer and fractional part, and resultant measurement series looks like (case of increasing the sensor's temperature):

...26.0, 26.25, 26.75, 26.125, 27.25, 27.375...

Temperature 26.125 (bolded in given series) has integer part "26" from "earlier" series, while fractional part is "actual". It looks like "older" byte is modified one readout after the "younger" byte.

This kind of behavior can be observed with a scope, directly on I2C bus as well as with my software (due with FreeRtos).

Readouts are done once every second.

Any ideas? My error? Fake chip (from Ebay)?

Regards.

[rs20]

Just to double check, what order are the bytes appearing on the wire? Is it possible that the data is coming LSB first, i.e.,

"26", ".0", "26", ".25", "26", ".75", "26", ".125", "27", ".25", "27", ".375"

And that the correct pairings are like follows:

"26", ".0", "26", ".25", "26", ".75", "26", ".125", "27", ".25", "27", ".375"

Alternatively, are you choosing which bytes you read out & when? Because some chips will enforce a particular byte read order on you by way of a clause that the next value is loaded on, e.g., the read of the least significant byte. So if you read LSB first, and then MSB, the first LSB read will trigger an update of the register and causes a subsequent MSB read to get a non-matching value.

[rs20]

Also, are you performing 2-byte reads as required by the datasheet, or are you collecting the two bytes as two separate 1-byte reads (explicitly disallowed by the datasheet)? What does your reading code look like?

[IAmBack]

Code looks like (some weirdness possible due too extensive urge to find the bug   )

   uint8_t wordRXBuffer[2] = {0,0}; //array filled with zeroes for debug purposes
   uint16_t wordReceived;
   bool negativeTempValue;
   
   TWIRXPacket.chip = actParams->TWIAddress;
   TWIRXPacket.addr[0] = 0;
   TWIRXPacket.addr[1] = 0;
   TWIRXPacket.addr_length = 0;
   TWIRXPacket.buffer = (uint8_t *)  wordRXBuffer;
   TWIRXPacket.length = sizeof(wordRXBuffer)/sizeof(uint8_t);
   
   freertos_twi_read_packet_async(actParams->FreeRTOS_TEMP_twi_params,&TWIRXPacket,max_block_time_ticks,actParams->LCD_sync_semaphore);
   xSemaphoreTake( actParams->LCD_sync_semaphore, 40/portTICK_RATE_MS );

   wordReceived =  ((uint16_t)wordRXBuffer[0] << + (uint16_t)wordRXBuffer[1];
   
   if( (wordReceived & 0x8000) == 0 ) negativeTempValue = false; else negativeTempValue = true; //checking MSB
      
   wordReceived = wordReceived >> 5; //unused bits removal   
      
   if (negativeTempValue){
         actParams->tempReadout = (float)((~ wordReceived) + 1) * -0.125f;
      } else {
         actParams->tempReadout = (float)(wordReceived) * 0.125f;
      }
      
   actParams->tmpReady = true; // for sync purposes (no big deal)

As I've mentioned in mu post, conversion weirdness is consistent with what I see on the scope (later I'll try to make movie and extract "key frames". Therefore I don't think, that the problem is with data reading. When temperature rises, the lower portion of data grows, then integral part does it's trick...

[IAmBack]

I did a video of scope screen showing temp changes. LM75B was slowly heated by hand. Weird, isn't it.