• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 496 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

tmp121 problem / confirmation bit question

Rolando Calla Zalles
Prodigy 60 points
Other Parts Discussed in Thread: TMP121, TMP122, TMP123, TMP124

I'm using a TMP121 in a few boards, which seems to work well, except that logs show that every few 1000s to a few 100000s readings, a single temperature sample is read wrong, mostly twice or half the value that it should be, others read as zero

Now I'm looking into ways to try to validate the reading before marking it as valid, all I do now is range checking.

Looking in the datasheet, I can read that in page 6 there says something about a "confirmation bit", but there is no detailed information about this bit. Sample codes in table 2 show it as always zero, but figure 3 shows it as 1 and the curve shows that it can be any value. Is it parity or something? My code is ignoring the last 3 bits right now.

Are there other ways to validate or re-read several times the output bytes ensuring that I'm reading from the first bit?

Also, what is the largest change that the TMP121 will be able to output sample to sample? (So that I can reject an impossibly large change.)

The part of the system that reads the TMP121 works at 26.7 kHz, so I never worried about reading too fast.

Right now I don't have easy access to a test setup, and it takes months to years to get a wrong reading.

Thanks in advance

  • 0
    TI__Expert 7945 points

    Hello Rolando,

    Thanks for posting some interesting questions on TMP121.

    Sorry about the confusion in the datasheet. TMP121/122/123/124/125 are based out of the same silicon die and confirmation bit on Page 6 of the data sheet refers to device confirmation. I checked the design files and when this bit is '0' it refers to TMP121/TMP123 ('1' refers to TMP122/TMP124) . It doesn't signify data valid or data ready functionality. So in your case you should be able to read this bit as '0'.

    Table 2 deals with the binary equivalence of the temperature value for the customer to decode. It's not describing the register values it is only dealing with the binary equivalent temperature and hence doesn't include the confirmation bit. 

    The largest change from sample to sample really depends on the temperature range and its rate of change in your application. Once I understand the range, I would add a guard band of max accuracy error (2deg C) + an additional 1-2degree just to be on the safe side while filtering out the unwanted invalid values.

    I would also check and make sure the code that decodes the temperature register is correct  because you are getting double or half of  the actual temperature values some time. Speed should not be an issue in your case and data output from the internal shift-register is also buffered so this cannot be a synchronization issue with SPI click and internal oscillator clock.

    I hope this help and do let me know how it goes.

    Best Regards,

    Abhi Muppiri

    Applications Engineer

    MHR- Sensing Products

    Texas Instruments

    -----------------------------------------------------------------------------------------------------------------------------------

    Search for answers, Ask a question, click  Verify  when complete, In the process, Help others, Learn more...

  • 0 in reply to Abhishek Muppiri
    Prodigy 60 points

    Thanks for your reply.

    Code indeed looked a bit messy, and even though couldn't be proved to be wrong it was rewritten and the band guards have been implemented. The process is very slow to change temperature, so this should work well.

    About getting to understand the actual cause of the problem, nobody is worried about it because it doesn't cause the system to misoperate, and its been working, more than 2 years. I'll try to experiment when possible.

    Regards