DS18B20 Oversampling and Decimation??

[Gabriel]

Hi All,

I have a lot of DS18b20 temperature loggers deployed and over the last 2 years I've been playing with different Filter methods, averages, etc.

I'm up to a point where I can resolve down to the 0.0625°C as per the datasheet(at least i think so), with surprising stability, using a simple median filter: take 9 readings into a buffer, Sort, take the median.
Its the best method I've found with this sensor, with no "Averaging Delay".
The DS18B20 takes AGES to provide a reading... somewhere in the 500 to 700ms range.. i know.

My temperature curves look nice except for the 0.0625 steps, which I would like to eliminate as it looks and probably is quantization error of the Sensors ADC.
much like this: https://i.stack.imgur.com/AvOf6.png

I would like to gain a few bits more of resolution via oversampling and decimation of the readings but all I've read involves injecting triangular wave noise to get those LSB's flipping and I cant wrap my head around how to inject noise to a DS18B20.


At this point you ask: "But why?"... to which i answer: "For Science!" and basically a learning exercise.

I'm logging refrigerators with very slow cycles with less than 1°C peak to peak.

as an example this is 1 hour of data:

[temtronic]

hmm...
1 reading per second is 60 per minute, 3600 per hour so why not just sample 1 per second? I recall that'd give 12bit reading. The way I rememeber that is I read the sensor when the DS1307 gave an interrupt at 1Hz rate.

[Gabriel]

That would result in signal full of 0.0625C jitter....and averaging merely rounds off the steps.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

There is a balancing act between how much you average, lag, and oversampling.
By not averaging, you don't have any oversampling.
To get oversampling and so smooth the steps, you have to average.
The more you average, the greater the lag.
I'd suggest using a combination of Olympic, and cumulative filters. This will give you lag, but also smooth the steps:

[newguy]

http://www.atmel.com/images/doc8003.pdf

I used the technique in the app note to squeeze another 2 bits of resolution from a dsPIC's 12 bit A/D converter. You can do the same thing to increase your temperature resolution from its current 1/16th of a degree C to a 32nd or probably even a 64th.

The biggest issue is time, as you mentioned, since the temperature sensor is relatively slow to convert. To get a 32nd C resolution you'll need 4 samples, and to get 64th, you'll need 16 samples.

[Gabriel]

HA!
Newguy seems we are reading the same stuff... that is precisely what im trying to achieve.

My noodle is noodled because i have no control over the DS18B20 ADC raw bits so i dont know how to perform the Decimation procedure.

All the DS18B20 give me is the temperature converted to a Celsius value represented in binary which i doubt i can just add 4 samples and shift. even worse I convert my results to float which might not be so cool to shift either.

if i was using the ADC on the chip directly the solution in the document is clear.

how do i implement this App note using the temperature values only since i dont have the raw ADC values to add and shift?



G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

The raw value from the chip is a binary ADC reading. It is just 12bits, with each count representing 0.0625 degrees.
Look at what I posted. This expects to receive the raw value from the chip. It then rejects the high and low readings from each group of three (to get rid of noise), and averages these using a rolling average, giving a result that is 8* the reading.

Feed it with the raw reading, and try it.

[temtronic]

I had a glance at that Atmel info and you need 4x the samples for every extra bit. If you went '9 bit ' mode for the sensor, you'll need 12x the samples which overall is longer than just one 12bit sample.
Frankly 1 reading a second is overkill for most temperature controllers or alarms. I did remote energy control and sampling was once per 15 seconds,never had a complaint about 'too hot or too cold'.
If you want 'finer' readings you'll need another sensor,probably analog(thermister or pt) but that opens up a HUGE can of worms.I used LM34s (that was in 1985),well filtered to kill EMI. I didn't care if it was 70.1 or 70.15 as long as the customer was happy.
Going analog means being real careful of board layout, 'balance' between filter vs precise readings, glitch removal, ultra clean power and super stable references,yeesh..it can get ugly.....

jay

[Gabriel]

I want finer readings for prettier graphs... sounds stupid but i learned something this week due to this here topic.

For my loggers the 0.0625 is more than enough but one day i might meet "that one customer" and the lesson here might save me.

I have had another project in my head for a while that hit a mental technical wall... this topic made it possible again!


Ttelmah do i call your function in a loop? How many calls do i need before i can trust the reading... i havent yet fully understood how the function works.... i know what it does... just not how yet.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Gabriel]

"have_sampled" is always false.... it becomes true in the first else but then the function exits?? What?

Im guessing the static declaration might be the trick here right?
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

The static means it will still have the last value, when the function is called the second time.

It is set 'FALSE' at the start, so the first time the routine is called it 'pre-loads' the sum used for the rolling average, otherwise it'll take several minutes for this to catch up. It is then set 'TRUE', so this part of the code is never called again.

[Mike Walne]

[temtronic]

Ok, I just got a dumb idea... seeing how these things are '1-wire'. Why not add say 3 more sensors then take the average of all 4.

or

Better yet, stagger the reading of the sensors by 1/4 second? 1st sensor on the second, 2nd, 1/4 sec later, 3rd 1/2 sec, later, 4th 3/4 sec later

If you do this, you effectively quadruple your 'reading rate' thus smoothing out the data.

If you have 3 extra pins left over, each sensor connects to its own 1-wire bus. You'll need to copy the driver 3x so it takes some code space BUT it saves the hassle of coding for 'looking for devices, ID's, checksums, etc.

Just thinking 'outside the box'...
Jay

[Mike Walne]

A second thought on the Peltier option.
Make the temperature go up and down quickly.
That way you'll get sort of random noise in the readings.
Just be careful to avoid locking between the readings and the noise.

Mike

[Gabriel]

Hi All,

I will give Mr. Ttelmah's code a whirl and see how it goes, now that i actually understand the code flow.. (hard to test something i didn't quite get myself)

I will also, try writing my own oversampling and decimation code now that some of my doubts have been cleared here.

Temtronic: great minds think alike!
I've already have 3 loggers deployed with 3 sensors each.I however take 3 readings from each into a 9 space buffer, sort and take the median.

The results are similar as the single sensor, hitting that 0.0625 wall as well, but it "looks" cleaner but that's just cause the cooler has a faster compressor cycle.

This is an hour of that 3 sensor logger data: