• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 138 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.

TMP106: Temp sensor that does NOT respond to general call

Zach Kimble
Intellectual 1075 points
Part Number: TMP106

Tool/software:

Hello,

I am looking for a temperature sensor similar to TMP106 that does not respond to the I2C general call. All of the sensors that I have found that meet my requirements respond to the general call. Below are my required specs:

1. 1.8V supply

2. Less than or equal to 2°C accuracy over -5-85°C

3. As small as possible

4. No response to general call

Please let me know what device you would recommend for my application.

Thank you!

Best regards,

Zach Kimble

  • 0
    TI__Mastermind 38695 points

    Hi Zach,

    All of our I2C temperature sensors respond to general call. Can you share why you want to avoid this feature? 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    TI__Intellectual 1075 points

    Hi Ren,

    Thank you for letting me know. I want to avoid this feature because another component on the bus will respond to the general call and I do not want the two responses to interfere with one another. Is it common to have multiple devices responding to the general call on the same bus? Can that cause issues with my I2C communication?

    Best regards,

    Zach Kimble

  • 0 in reply to Zach Kimble
    TI__Mastermind 38695 points

    This is how the general call is meant to work. General call is a reserved address that can be used to send common commands to all devices. More than one device can ACK at the same time without causing an issue due to the open drain nature of the bus. Often, General Call Reset is the only general call command supported by our devices. If the second byte is not the reset command, our device will take no action in response to the general call. Are you looking to repeatedly General Call Reset the other device? How are you making use of the general call address with the other device? 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    TI__Intellectual 1075 points

    Hi Ren,

    Thank you for this info, this makes sense. I am not sure how exactly I will use the general call with the other device yet, I am waiting for more information from my team. 

    My one remaining question is what will happen if one device responds to the general call with a NACK. If the bus is open drain, is there any way to tell if a device did not acknowledge the general call? Do I just need to poll the devices afterward to ensure the command was received and executed?

    Best regards,

    Zach Kimble

  • +1 in reply to Zach Kimble
    TI__Mastermind 38695 points

    No, there's no way to know which device(s) respond to general call with NACK or ACK. All you can know is if one device ACK or all devices NACK. This concept is called wired OR. 

    On a somewhat related note, the SMBus standard has Alert Query. This is a way for devices sharing an open-drain interrupt to communicate their address to the host when they are asserting alert. Many of our sensors support SMBus Alert Query, but it only applies to the Alert/interrupt use case.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    TI__Intellectual 1075 points

    Hi Ren,

    Thank you for your explanation. I have let the customer know that there is no way to know if an individual device NACKs. I do not believe that they can use SMBus here but I will let them know about that as well just in case.

    Thank you for your help with this issue!

    Best regards,

    Zach Kimble