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.

Lock-up of LM92 temp sensors

Other Parts Discussed in Thread: LM92, LOG101

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

  • 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

  • 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

  • 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!

  • 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

  • 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.

  • 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

  • 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

  • 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

  • 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?

  • 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

  • Hi Andy and John,

    Thank you so much for the great suggestion. I apologize for any inconvenience this may have caused you, and I really appreciate the troubles you have gone through to troubleshoot our product.


    I have brought this issue to the attention of my manager and to the designer manager about a month ago.  They suggested that I duplicate this test to find the root cause. At this moment, I’m currently designing a schematic for the LM92 evaluation board (we don’t have any more board in stock).  However, it will take a couple of months to finish the board.  After we have boards, then I will investigate this issue further and will inform you of my findings.  If you guys have a board that you can spare, then please send it to me so I can take a look at this issue sooner.  If not, then I can give you my report in a couple of months when I am done. Once again, thank you for your patience and your help to find the root cause of this issue.

    Regards,

    Aaron Heng

  • Aaron,

    Do not hesitate to contact me for further information on my experiences with the LM92 if you want to.

    I just have one handcrafted prototype system/board at present, so unfortunately cannot send you any useful hardware.

    Kind Regards,

    John O'Connor

  • Update: I implemented a pure software I2C port in the PIC 18F4620 and was able to successfully read the ambient temperature every 2s. Then I breathed on the LM92 and it behaved as when used with the hardware I2C in the 18F4620 - reading climbed up a few degrees then reading went up to maximum number, all 1's, and stayed there.

    I think this helps a little in that it exonerates the PIC substantially, maybe completely, I reckon.

    John O'C

  • Thanks lot to all of you for your posts. They helped me a lot. I was thinking to use this temperature sensor into a new project for natural gas application, where reliable operation is paramount. Now I changed my mind completely, of NOT ever using it. I will stay with a very reliable operation using a NTC resistor, LOG101 and ADC12 of MSP430. It is more expensive, but NO FAILURES.

  • You have made the right decision.

  • Aaron, are you still monitoring this thread? Or someone else at TI?  I'm still interested in an update on the LM92, it's lock up problem, and if a revision or replacement is scheduled.  As you can tell from the recent post, you would have a larger market for the part if you made it robust.

    Best

    Andrew

  • Is there any action on TI on this, after more than 1 year?

    Can we return our LM92s?

  • Hi Lu,

    We are sorry you are having issues with the LM92.  We have a formal process for handling customer returns. I'm sorry but I cannot help you directly. Please contact the distributor you purchased your LM92s from for returning the parts.

    I would also like to say that we working diligently on new temp sensors. I'm not at liberty at the moment to disclose exactly what we are working on - all I can say is stay tuned. (Hopefully you will!)

    You are replying to a post that was started some time ago, so I am assuming that you are also having issues with lock up. If you would like further help to debug the issue on E2E, please describe your problem in more detail. Scope photos of the communication before the lock up and a schematic would help us understand your problem further. Not all problems have the same root cause, I always learn something new…

     Take care,

  • Hi Emmy,

    I have a problem with writing Thyst, Tcrit, and Tlow of LM92. I've tried to writing values to the three register, but default value can be read. I2C data scope showed right writing bit stream.

    I need your help.

    Best,

  • Hello Shinwoo Kang,

    The only thing I can think of immediately to help you is:  Check out the pullup resistors on the SCL and SDA lines of the I2C bus to the LM92. Some found that reducing these from 10k to 2k2 improved the behaviour of the LM92.

    I never got as far as programming Thyst, Tcrit and Tlow. I had problems with temperature register locking up

    and reading too high.

    Regards,

    John O'Connor

  • Specifically, the parameter that I have tested is as below,

    - clock : 400kHz

    - Thyst : 5 deg. C

    - Tcrit : 130 deg. C

    - Tlow : -55 deg. C

    - Thi : 80 deg. C

  • Hi Shinwoo,

    Are you getting an ACK after you send the I2C address? It almost sounds like you don't have the I2C address sent correctly. Check for the ACK and make sure the protocol is correct.

    In addition, the LM92 is best used with 100kHz clocks or slower. This is especialy true if your bus capacitance is at the higher end. Check to make sure your data hold and setup times are being met appropriatly for the micro and LM92.

    Take care,

  • Hi Emmy,

    Back to the original topic of this thread, does TI have a replacement for the LM92 or any plans to address the the horrible lock up problems that plague this sensor in response to certain types of electrical noise?

    Best,

    Andrew

  • Hi Andrew,

    I can only re-iterate what I posted earlier to Lu:

    We are sorry you are having issues with the LM92.  I would also like to say that we working diligently on new temp sensors. I'm not at liberty at the moment to disclose exactly what we are working on - all I can say is stay tuned. (Hopefully you will!)'

    Take care,

  • Yes, I'm very interested, but the sooner the better. Please have someone from the design team contact me directly. I'd like to discuss the features / specs that we need so they can consider them in the new sensors. You or they can call me at 310-441-3767 from 1pm Pacific Time onward.

    We need something to use as an accurate temperature probe so it needs to be more robust than it would if its only application was to sit next to a CPU and turn on and off a cooling fan. Compared to the LM92, a replacement should have more robust communications:  less sensitive to moisture and to electrical noise. It is absolutely critical that failure modes do not include locking up and repeatedly returning the same temperature value.  The LM92 has good accuracy specs, but some of its bugs/features make it problematic to use, for example only being able to ask it the temperature about once per second or it will keep giving you the previous temperature and not sampling a new one, with no error signal regarding that.... not good (and the distinct from the lock-up we've complained about where it keeps getting the same temperature value regardless of how long you wait in between requests.