• Not Answered

Lock-up of LM92 temp sensors

We use the LM92 to report the temperature to a PIC microcontroller via I2C once per second. Sometimes, in some environments, the LM92 will go crazy and report a very high temperature, and lock in that state. For example, after working correctly reporting temperatures around 37 degrees C every second for 2 weeks, it will report a temperature such as 216.9 degrees C and then lock in that state, reporting 216.9 for all subsequent requests.  When the device is powered off and back on, normal operation resumes.

Is this a known phenomenon with spikes of too much electrical noise? We'd like to find a robust solution. Yes, the sensor has a 0.1uF cap on its 5vdc power supply right next to it. We are using the LM92 in a non-standard way (via a wire to it's own PCB), and if it would be possible for a LM92 expert to call me by telephone to discuss this, I would be happy to update this forum with the results of the discussion, but I think trying to describe everything else and answer all of your questions will be time consuming and laborious in the forum and we can make a lot more progress in a 5 minute phone call. I can be reached at 310-441-3767 after noon, Pacific time.

I think this is an important issue because it can cause critical device failures.

Thanks,

Andrew

25 Replies

  • Hi Andrew,

    Before I call you, I need additional information from you. Do you mind if you can share the schematic with us? Please capture the waveform snapshot when the device in normal operation, and the temperature reached to 216.9 degree C. Please probe the clock and data signals.  You can send directly to me at aaron.heng@ti.com. Thanks.

    Aaron

  • In reply to Aaron Heng:

    Hello Aaron Heng,

    I have similar lock-up problem with LM92 temperature sensor. Reads temperature OK, then I breathed on IC a few times to take the ambient temperature up. Temperature reads as 0x1 FFF - i.e. ALL bits are 1's. Stays locked reading this max value all the time until powered off and on again. This is similar to AndyZappa's problem - did you reach a solution there ? I found a TI Application Note entitled: "AN-2113 AN-2113 Applying LM92 I2C Compatible Temperature Sensor in Systems with Slow Clock Edges".

    This states that SDA should wait at least 300ns before changing state, after SCL goes low. Looking at SDA and SCL from the 18F4620 on the oscilloscope does not  look good in this respect - SDA changes about 60ns or thereabouts after SCL goes low. This seems far too soon. I would be getting close to saying the PIC is not going to work with the LM92 .... ?

    I am using PIC 18F4620 MCU to interface to LM92. I2C bus clock is about 50kHz.

    Thanking You,

    Kind Regards,

    John O'Connor

  • In reply to JohnO47112:

    I can tell you a little about my experience in case it helps. We use the 18F4520 w/ 100kHz I2C. I have never looked at the timing issues you mentioned, so Aaron will have to address that. I can tell you that the LM92 is surprisingly sensitive to moisture. If you get enough condensation to coat the part, it will freak out. However, my guess is that it's not your breath but the fact that you are handling near the connections that is causing the problem, because your body is acting like a source of increased electrical noise. The best way we found to induce the lock up was to plug a 120VAC power drill into the same outlet as our PIC power supply and get the drill and its cord near the LM92. (This works good because the brushes on the drill make sparks which is the right kind of electrical noise.)

    We looked at the clock and data lines using a scope, and we could see that the pulses were not very square (they had a rounded leading edge). We were using 10k ohm pull up resistors, as was recommended in several places.  We were able to clean up the pulses substantially by lowering the value of the pull ups to 2.7k ohms.  I checked and this value is perfectly acceptable for both the LM92 and the PIC.  After this substitution, the LM92 became much more resistant to the lock up problem and also to spurious read errors that didn't cause a lock up.  See if any of that applies to your problem and let us all know what you find!

  • In reply to Andy Zappa:

    Andy Zappa,

    Many many thanks for your time and such a pertinent and helpful reply ! It could well be the moisture issue with my setup here - I do not handle the LM92 or its leads, it is in-situ on its PCB and I just lean over and breathe over the general vicinity of the IC a few times.

    I have 4k7 pullup resistors on SDA and SCL, and yes, I agree with you, at around 100kHz SCL frequency, the rising edges of both SDA and SCL signals are very slow, very rounded. I will take these 4k7s down to 2k7s. I took I2C bus clock speed down to around 50kHz but of course this did not square the rising edges - the exponential rise on these edges is essentially a dc phenomenon. I tried lowering the bus speed to cure whatever ills might be there but it made no difference.

    My environment here is very benign as regards electrical noise, if my product is susceptible to EMI where it is now, sitting on bench beside me here, I shudder to think what might happen when it goes industrial, sitting not far from induction motors et al.

    Regarding the moisture issue - this is quite serious and quite worrying for industrial etc deployment. I reckon one should consider some source of heat close to the LM92 IC - a 2W resistor allowed to get "quite hot" - this might maintain surface and space in vicinity of LM92 at slightly elevated temperature and discourage condensation on the device. But on the downside, if product is battery powered, cannot use up the battery heating the temperature sensor IC !!

    Kind Regards,

    John O'Connor

  • In reply to JohnO47112:

    I'd like to add that this lock up problem is extremely undesirable as it can cause catastrophic failure in devices that rely on the LM92 for temperature regulation. I would imagine that the device could be made to detect this state and reset itself? That would be better.

  • In reply to Andy Zappa:

    Hi John,

    Last conversation with Andrew Papp, I supposed to get a board ship to me to investigate this issue; however, I have never received one. Could you provide the following items below when the device is reading a bad temperature?

    1. A plot of I2C probe as close to the LM92.
    2. A plot of V+ and at start up.

    Aaron

  • In reply to Aaron Heng:

    Hello Aaron,

    And many thanks for reply. I will try and get the plots of the waveforms you request to you, but I am struggling a bit as my instrumentation setup and data acquisition capabilities here are a bit limited. I have been working on the LM92 over the weekend and have discovered that only the first byte of the temperature register is being read ! I must correct this first of course. 

    Best regards,

    John O'Connor

  • In reply to JohnO47112:

    Update: I now have the LM92 functioning very well, reading room temperature around every second or so(not exactly a second, a bit longer). BUT, if I breathe gently over the LM92 IC the temperature starts correctly to rise gently then freezes. It is the I2C bus which is frozen, majority of cases due to a lack of ACK from the LM92 slave, but sometimes waiting for Master ACK to complete. So, breathing gently over the LM92 IC really upsets the I2C bus ................... ??? If I put a hot air gun gently over the LM92 I can drive temperature away up to 80C+, with no such problems. It must be moisture in exhaled air that is causing the problem - is this moisture altering the impedance between adjacent SDA and SCL pins so as to cause I2C to malcommunicate ? To me at moment the answer to this is yes.

    I also noted though that similar freeze occurred when delay between reads was shorter at closer to 1s exactly. The internal conversion time of the LM92 is around 1s - I was pondering then if there could be some "problem" with trying to read "too much in synchronism" with the internal conversions.

    Andrew Zappa: All I can offer you at present is above observations and thoughts. There does seem a very probable condensation issue - you would need to hermetically seal the LM92 in some way. Also, ensure the software implementing the I2C communications is "thorough" => check for all ACKs, etc. And finally, maybe stretch your temperature sampling out to once per 2 seconds and see if this decreases freeze-ups.

    John O'Connor

  • In reply to JohnO47112:

    Regarding the moisture, we dip the PCB and cable in some waterproof, thermally-conductive, electrically insulating epoxy. which works pretty well.

    Regarding using a resistor to heat up the area to keep it dry... that kind of defeats the purpose of having an accurate temp sensor... we are using it to get a high accuracy temperature measurement in our application.

    Regarding the 1-second thing, it is clearly documented in the data sheet that if you read more than once per second, it will abort the next conversion and give you the previous value, but that is a bit different than locking up, in which case it doesn't matter how long you wait. One way we detect lockup is by reading the T-crit value, which we know. When it's locked up, you can't even do that, which has nothing to do with the conversion-abort-pseudo-lockup.

    For us, lock ups in the lab and field were infrequent with the 10k pullups and we haven't seen any since we switched to 2.7k.

    But... TI.... that does not excuse the bad behavior or the device, or the super-moisture-sensitvity. Users should not have to struggle to debug and deploy what should be a simple IC.  It really should never lock up, unless you really abuse it, like cooking it or something like that.  Can you guys work on making it more robust?

  • In reply to Andy Zappa:

    Yes, heat a temperature sensing IC to keep it dry .................... NOT one of my better ideas, .......if only there was a Nobel prize for stupidity .......!

    I now have the LM92 working adequately good enough in my application prototype, but it was a lengthy and troublesome struggle.

    Now I am agonising over whether to source another adequate device, so TI, if working on an update for the LM92 based a lot on the

    LM92, your Product Development manager for the device would probably appreciate being aware of the issues discussed in this post.

    Yours,

    John O'Connor