Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

LM35 reading sometimes stuck with 2-degree offset


  • Please log in to reply
5 replies to this topic

#1 dbinger

dbinger
  • Members
  • 2 posts

Posted 22 August 2013 - 08:09 PM

I've been using LM35s for temperature readings with labjack and I like them, but I have

noticed a new problem.

 

Sometimes, one of several LM35s on my T7 returns a reading that is off by exactly 2 degrees.

Sometimes it gets "stuck" in this off-by-2 mode for either a few seconds or all day.

The only way I've been able to make the problem go away is to move the wires to a different

input on the T7. The LM35 itself seems to be fine.

Any ideas about how I can really solve this?

 

 



#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 23 August 2013 - 07:06 AM

I would start by using a DVM to measure the voltage from AINx to GND.  Look at the DVM voltage and the voltage reported by the T7 at the same time, to see if they are the same or differ by 20mV.



#3 dbinger

dbinger
  • Members
  • 2 posts

Posted 28 September 2013 - 04:40 AM

This problem was solved by increasing the settling time.

 

Because the settling time was too low, the voltage readings

were influenced by the current value on the previous input,

and that explains the unpredictable results.



#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 16 October 2013 - 01:09 PM

We have always notice that micropower temperature sensors have a somewhat weak drive, so not a total surprise.  We have previously notice problems with how close to 0.0 volts the sensor can drive its output:

 

I did some testing to look at the settling time for an LM34 sensor.

 

Note that ScanRate does not really affect the interchannel delay within each stream scan.  A sample from each channel is acquired as fast as possible, and the time between each sample is affected by ResolutionIndex, StreamSettlingFactor, and the highest gain (smallest range) of any channel in the scan.

 

U6-Pro with firmware V1.39.  UD library V3.39.  LabVIEW example "U6 easy Stream Full.vi".  Range = +/-10V. ScanRate=100.  AIN0 <=> LM34CAZ.  AIN3 <=> VS.

 

First, I used the automatic settling time and varied resolution.

 

StreamSettlingFactor = 0 = Auto:

 

Channel List, ResolutionIndex, Voltage error of last 3 channels

15/0/0/0,        Res=1,                +0.018/0/0    (+1.8 degree error)

15/0/0/0,        Res=2,                +0.01/0/0    (+1 degree error)

15/0/0/0,        Res=3,                +0.004/0/0    (+0.4 degree error)

15/0/0/0,        Res=4,                +0.002/0/0    (+0.2 degree error)

15/0/0/0,        Res=5,                +0.001/0/0    (+0.1 degree error)

15/0/0/0,        Res=6,                +0/0/0    (no noticeable error)

 

So from the first row, I scanned channel 15 (internal ground), then 0, then 0, and then 0 again.  4 channels.  Note that after the 4th channel is sampled, the mux is immediately changed to the 1st channel.  Thus the 1st channel usually has more settling time, whereas the other channels have the same settling time (auto or specified).  For example, if settling time is 10us, and scan interval is 10000us (100 Hz), the settling before the 2nd, 3rd, and 4th channels is 10us, but the settling before the 1st channel winds up being 9970us.

 

Still looking at the 1st row, ResolutionIndex was set to 1.  The results were that the 1st reading of the LM34 on AIN0 (2nd channel in the scan list), had a settling error of +0.018 volts which corresponds to +1.8 degrees F.  The 2nd and 3rd readings were both fully settled with no noticeable error.

 

Next I tried settling in the negative direction rather than positive.  With the previous data, the system had to settle a change from 0V to about 0.7V, whereas now the system will settle a change from 5V to about 0.7V.

 

Channel List, ResolutionIndex, Voltage error of last 3 channels

3/0/0/0,          Res=1,                -0.2/-0.2/-0.16    (-20 degree error)

3/0/0/0,          Res=4,                +0.06/+0.005/0    (+6 degree error)

3/0/0/0,          Res=6,                +0.017/0/0    (+1.7 degree error)

3/0/0/0,          Res=7,                +0.006/0/0    (+0.6 degree error)

3/0/0/0,          Res=8,                +0.002/0/0    (+0.2 degree error)

 

You can see that a higher resolution settling was required to see the same results, and even at the max stream resolution index of 8 I could still notice a slight error.  This tells us that settling is tougher in the negative direction for this setup, so we will stick with the negative direction to know the worst case.

 

Now I tried with resolution index fixed to the minimum of 1, and varied settling time.

 

ResolutionIndex = 1:

 

Channel List, StreamSettlingFactor, Voltage error of last 3 channels

3/0/0/0,          Sett=1 (10us),             -0.17/-0.24/-0.16    (-17 degree error)

3/0/0/0,          Sett=5 (50us),             +0.33/+0.08/0    (+33 degree error)

3/0/0/0,          Sett=10 (100us),         Osc/0/0    (Oscillation noticeable, +/-10 degree error)

3/0/0/0,          Sett=16 (160us),         0/0/0    (no noticeable error)

 

What is apparent from this data, is that it takes about 150us for the LM34 signal to settle.  We can see that in the Sett=5 row, where only the 3rd reading was settled, and in the last row where the 1st reading was settled.

 

A settling time of 150us tells us the max sample rate we could expect to use without settling errors on an LM34, is about 6.7 ksamples/second.  So if you had 7 channels you needed to scan, the max scan rate would be about 1 kscans/second.

 

 

So what if you want to stream faster but have an LM34 as one of the signals?  The hardware fix is to add a buffer to the LM34 signal.  An LJTick-InAmp would work, or pretty much any op-amp circuit.

 

If you are doing a bunch of channels, a trick is to use duplicates of the LM34 channel.  For example, say you had the LM34 with 13 other channels for 14 total.  If you set the settling time to 150us, the max scan rate will be about 6.7k/14 = 480 scans/second.  Instead, though, you could stream 16 channels, where 3 of them are sequential samples of the LM34, and then use a settling time of 50us.  That means your max sample rate is 1/50us = 20k samples/second and the max scan rate is 1250 scans/second.



#5 ARDUINEM

ARDUINEM
  • Members
  • 6 posts

Posted 19 February 2014 - 01:00 AM

I wires my ue9 GND to GND lm35 --- Vs to Vcc lm35 and AIN0 to midle of sensor . now how can i do for read and show the outputs ? im using python ubuntu



#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 19 February 2014 - 12:36 PM

ARDUINEM,

 

This was answered here:

 

https://forums.labja...?showtopic=6643




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users