• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 4 answers
  • Subscribers 30 subscribers
  • Views 373 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.

TMP144: Response rate of Digital Temperature Sensors for Remote Temperature Monitoring

Neet
Intellectual 462 points
Part Number: TMP144
Other Parts Discussed in Thread: TMP61-Q1, TMP1075, , TMP1827, TMP61, TCA9544A, TMP107, TMP1826, SN74HCS125, BOOSTXL-TMP107

Hello E2E Community,

We are exploring different Analog & Digital Temperature sensors for our use case where we have to monitor the temperature of the machine components like Bearing Housing, Lubricating Oil temperature across pipe, Motor casing etc. So far we have planned to use TMP61-Q1 with 170'C range. However, we are now planning to explore a more integrated solution in the Digital Temperature Sensor portfolio.

  1. TMP1075
  2. TMP144
  3. TMP1827

Among these shortlisted sensors, can you share with us what is the response rate to changes in temperature? The use case requires a temperature response rate of about 1 second at most, not more than this.

Further, we have to install these sensors at least 3m away from the MCU/ADC, we plan to use STP CAT6e cables for the sensor interfacing, can you suggest any suitable reference for any additional consideration to be implemented in such cases of longer cables?

Regards.

  • 0
    TI__Mastermind 38035 points

    All of these devices can make a temperature measurement in less than 30ms. This is called Conversion Time in the datasheet. The devices can be commanded to do this as often as you'd like.

    They can all be configured to make temperature measurements automatically at 8Hz or greater. You simply poll the sensor to find out the most recent temperature result.

    In summary, there's no limitation in the ADC or logic preventing you from reaching your goal with digital temperature sensors. There is, however, a practical problem of thermal transfer into the sensor itself. Generally speaking, temperature sensors with the least mass will be able to change temperature faster due to environment changes. If the sensor is mounted on a large PCB with power planes in it, the PCB can represent significant mass slowing down temperature change. This can also be an issue when mounting the TMP61.

    Here is a plot of response time for a typical local digital temperature sensor. Please note the plot is in log scale on the x axis to be able to view the differences between the 3 tests. Immersion in stirred oil shows that the sensor is capable of settling within 0.1s and reporting several steps along the way. 

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 462 points

    Thank you for your response, my concern stemmed from a application note where it was mentioned TMP144 took 15+ seconds to record 3’C temperature difference.

    I know understand a clear relationship between thermal transfer, which we can try to optimize at our end.

    can you also kindly confirm/comment on use of these sensors for remote temperature measurement ie sensors installed 3-4m away from the MCU with a STP cable connection.

    Thanks.

  • 0 in reply to Neet
    TI__Mastermind 38035 points

    TMP144's push-pull UART interface is the most desirable for driving the cable. TMP144 automatically adjusts to a range of baud rates that would enable you to slow down the communication if needed.

    TMP1075's open-drain I2C bus is less desirable for cabling due to the relatively weak logic high drive. It should still be possible to operate over 2-3m cable. I2C frequency can vary, but generally only 100kHz or 400kHz are used.

    TMP1827's open-drain 1-Wire is proven on cabling, but has the same weak logic high drive as I2C. However, the 1-Wire protocol is very slow relative to the other buses. The low speed helps it to tolerate cabling's capacitance.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 462 points

    Hello Ran,

    So we are now inclined towards using TMP1075, which so far seems suitable from all other use case perspectives, except a caution to be practised for I2C & Cabling with TMP1075. Said that, for robustness:

    1. We plan to operate the I2C at 2-5kHz maximum.
    2. With a dedicated I2C Master channel only for TMP1075
    3. Connecting upto 4 x TMP1075
    4. TCA9544A on master end
    5. Star configuration in terms of physical connection, however only one out of 4 I2C slaves connected at any given point of time with the MUX

    So overall we do not have any other major design consideration when using such a setup for TMP1075, if any can you guide with your feedback/suggestions?

  • 0 in reply to Neet
    Intellectual 462 points

    And If we plan to use TMP144 -

    1. Can we assume it might further minimize the need for a I2C MUX - TCA9544A
    2. We can simply star connect upto 4 TMP144 sensors, as Diasy chain is not feasible in our use case?

    Looking forward to your feedback & guidance.

    The use demands measuring temperature of 4 different components installed at different locations, and to minimize the cable length, star connection is only layout that fits. In this case, is TMP144 more suitable to drive long cables than TMP1075 can or at low I2C speeds of 2-5kHz both should be same/similar performance?

  • +1 in reply to Neet
    TI__Mastermind 38035 points

    TMP144's low impedance bus is also less susceptible to induced noise. It is sourcing current to create logic high where the other buses rely on the pull-up resistor to create logic high. Technically, the current that TMP144 is capable of sourcing/sinking is lower than what the other devices sink on their logic-low-only outputs. Running SCL/SDA over long cabling will increase cross coupling between them, causing spikes/noise to appear on SDA when SCL changes state. 1-Wire would have no other signal to couple to. UART may be less susceptible to cross-coupling due to low impedance. Cross-coupling may not cause you any trouble, but is a technical consideration. If the data signals can be twisted with another signal (power/ground) instead of each other, it would reduce cross-coupling. 

    Mux is not needed for TMP144 and I2C mux would not be compatible. The TMP144 should survive daisy-chain even through star connection. At the star connection, you could buffer the signal to the next TMP144 with a standard logic buffer if you wanted to. https://www.ti.com/logic-voltage-translation/buffers-drivers-transceivers/noninverting/overview.html If you still wanted to mux TMP144 at the star, you could do so with standard logic devices that may be cheaper than I2C mux. The same is true for isolation, if you needed it.

    We also have TMP107 as another UART device. It has some similarities/differences with TMP144, but may not be more appealing to you than TMP144 unless you really dislike the TMP144's DSBGA package. The TMP107 datasheet has test results for a 300m cable connection between TMP107 devices, and has the same output current specifications as TMP144.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 462 points

    Hello ,

    Thank you for your feedback & comments. So we are now inclined towards using TMP144. & yes I do not like DSBGA package! Can TI make TO-xx package for this!? Slight smile

    For use in industrial environment, what ESD/EOS protection measures should we take care of?

    Can you guide us thorugh this? I did not find any protection devices in the TMP107 application section.

    We have ESD314 that we are using for our other devices, can we use the same?

    Any additional measure we need to take care of?

    CAT6e cables shall be sufficient for these, right?

    Regards

  • 0 in reply to Neet
    TI__Mastermind 38035 points

    We are actively working on a TO-92 version of TMP1826, if you're inclined to wait for that. We previously considered a TO-92 version of TMP107, but did not release it. Currently, we are investing in 1-Wire instead of UART. 

    I'm not an ESD/EOS expert. :) All of these ICs do have integrated ESD features to enable them to pass JEDEC standards as outlined in their datasheets. These standards mainly pertain to handling during assembly. It seems like ESD314 would be acceptable for any of these buses. I expect that you would select an ESD product based on the capacitance it adds to the bus, and how much capacitance the bus can tolerate. http://ti.com/esd

    I don't have anecdotal experience with CAT6 in our lab, but it seems reasonable. It would have more conductors than you need; do you intend to run other interfaces next to the sensor bus?

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 462 points

    Hello @Ren,

    No, not at the moment, we plan to run these cables separately. My primary concern is the potential noise interference in an industrial setting and its impact on device operation. We are incorporating suitable ESD, EFT, and Surge protection using the ESD314 across all lines. & yes, we will pair the signals with power/ground & not with each other to avoid opportunities for crosstalk/coupling.

    Could you provide insights on the extent to which industrial noise might affect our system? Do you recommend installing Low-Pass Filters (LPFs), Ferrite Beads, or other noise mitigation techniques for these signal lines? Do we need STP Cables or will normal cables work too?

    Another aspect we need your feedback on is the UART communication baud rate for the TMP144 setup, we may be connecting 8-9 sensors on a single bus. What baud rate would you suggest to ensure reliable communication under these conditions?

    TMP107 Typical Circuit as given in the datasheet:

    TMP144 Typical Circuit as given in the datasheet:

    Can you guide what else we should consider to make this robust for the industrial environment apart from ESD/EOS protection?

    • Do we need to make provisions for LPF based on RC filters? If so what cutoff shall we aim for? What is the minimum/maximum baud rate these devices need/operate on?
    • Do we need a buffer like SN74HCS125 at the MCU side to help with better drive strength for longer distances? Will this cause any issues with the sensors as the +-7.8mA drive of SN74HCS125 is within the AMR for TMP144)
    • Do we need specialized shielded cables for these devices, the distance shall be about 4-5m between each of them maximum & upto 8-9 devices
    • We would like to oversample the sensor output to make the SNR higher, it seems CR[1:0] allows upto 8Hz, are there any higher sampling rates possible with TMP144? or is 8x sampling sufficient in this context? Our end-use can tolerate upto 4-5 second latency in final temperature readings, accuracy is a priority (+-1 is acceptable, yet the higher the better)
    • Are there sample drivers/codes for interfacing these devices with MCU that can speed up our testing?
    • Any other methods/suggestions/feedback you may have, do share, your inputs shall help us make the designs robust
  • 0 in reply to Neet
    TI__Mastermind 38035 points

    I would always use shielded cable given the option. My customers typically won't consider it. I prefer this to filters. I would avoid adding capacitance to any bus; there is always parasitic capacitance and edges can be slowed with just series resistance. These are my general opinions and may not be appropriate for specific situations.

    TMP144 and TMP107 have min/max baud rate specified in their datasheets. They are just about identical in this regard, coincidentally.

    Buffer is not required but may be helpful. The current capability is not harmful in itself. Hypothetically, the buffer could produce faster edges and more extreme spikes/ringing than what the TMP144 current capability could produce. This could be tamed by series resistance, if necessary.

    I'm skeptical about oversampling providing any real benefit. Our noise is typically an LSB or two at most. I mentioned one-shot mode in my first response, which would allow you to trigger new measurements as fast as you like. You are only hypothetically limited by conversion time spec and the time it takes to send the required commands. Triggering the device like this will increase its current consumption and may present a small self-heating rise in the output temperature.

    There is no source code available for TMP144. I wrote the code for BOOSTXL-TMP107 which has a TMP107 driver. The LibraryTestBench included in that code is useful for learning both the TMP107 and TMP144 interface even if you don't have the hardware. While it is not written for TMP144, I say it is useful for TMP144 because the two devices' interfaces are very similar. TMP1075, TMP1826 and others that we discussed earlier have drivers in ASCStudio. https://dev.ti.com/sysconfig/index.html?product=ascstudio&module=/ti/sensors/tempsensor/TMP1826

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Intellectual 462 points

    Hello,

    I am working on an application where I plan to interface a TMP144 temperature sensor (which operates at 3.3V logic levels & 5kbps baud rate) with a 5V UART logic field bus. I intend to use the SN74LVC07 hex buffer with with 3.3V Vcc & open-drain outputs for level shifting. Power consumption is not a constraint. Here are the key details of the configuration:

    1. Level Shifting from 5V to 3.3V: For the UART Tx line from the 5V field bus to the sensor
    2. Level Shifting from 3.3V to 5V: For the UART Rx line from the sensor to the 5V field bus
    3. Clock Signal Translation: Additionally, translating a 4MHz clock signal from 5V to 3.3V logic level for an MCU (on seprate PCB)

    The SN74LVC07 is powered at 3.3V, and according to the datasheet, it supports input voltages up to 5.5V, making it suitable for interfacing with the 5V logic levels of the field bus. The datasheet also mentions that both input & output are 5.5V tolerant & the device can be used to translate upto 5.5V or down to VCC.

    I have a couple of questions regarding this setup:

    • Is this configuration appropriate for the bidirectional UART communication using two seperate channels as required for interfacing the TMP144 sensor with the 5V bus while the buffer is powered by 3.3V VCC?
    • Can we continue with the assumption based on datasheet that the outputs can be safely pulled up to a voltage higher than VCC ie 5V when powere by 3.3V VCC
    • Are there any additional considerations or potential issues I should be aware of, especially regarding the reliability of the level shifting for the UART communication lines?
    • Is the idea to use one of the channels for level translating 5V & 4Mhz logic signal into 3.3V signal that can be fed to Clock input of MCU? We will take care of the rise time & the fall times by suitable R-Pull up.

    Any insights or recommendations for this type of application would be greatly appreciated.

    Thank you!

  • 0 in reply to Neet
    TI__Mastermind 38035 points

    Are you sure you meant TMP144? We've spoken about a few different devices. The TMP144's communication is unidirectional, and shouldn't be buffered by open-drain drivers. Bidirectional protocols are often implemented with open-drain drivers to prevent conflicts. https://ti.com/lit/gpn/sn74lvc1t45 is an example of a level translator that meets your voltage requirements and would be compatible with TMP144.

    thanks,

    ren