Anyone have a readTemperature calibration table for the RFM69?

[WhiteHare]

At best the on-chip sensor would report the temperature to the nearest degree C, but that might be just fine for a lot of things, provided it stays within 1 degree C of the true temperature.  Has anyone here checked it for accuracy over a wider temperature range than just ambient?

For instance, our refrigerator failed recently due to a defrost problem, but it's not the sort of thing you tend to notice right away.  If there had been a Moteino in there... even without a fancy temperature sensor, if it has a reliable and repeatable 1 degree C accuracy, it might have sent us a wireless alert earlier.

Is a calibration table even needed, or is it pretty much bang on for a wide range if you calibrate it only at ambient?

I read that John K2ox "gave up" trying to do it and instead decided to add a DS18b20, but he didn't explain why it was that he gave up. 

[jra]

You need to calibrate each chip individually to get anywhere close to +/- 1C.  Quoting from http://www.avdweb.nl/arduino/hardware-interfacing/temperature-measurement.html

One-point calibration. Offset removal using room temperature as reference gives +/-5°C accuracy from -30°C to 100°C and +/-3°C accuracy between 0°C and 85°C.
Two-point calibration. Here, +/-1°C accuracy from 5°C to 95°C can be achieved.

[WhiteHare]

You need to calibrate each chip individually to get anywhere close to +/- 1C.  Quoting from http://www.avdweb.nl/arduino/hardware-interfacing/temperature-measurement.html

One-point calibration. Offset removal using room temperature as reference gives +/-5°C accuracy from -30°C to 100°C and +/-3°C accuracy between 0°C and 85°C.
Two-point calibration. Here, +/-1°C accuracy from 5°C to 95°C can be achieved.

That's interesting.  What you referenced is for the atmega328 rather than the rfm69, although  I guess for my purposes it doesn't really matter which temperature sensor gets read.  Thanks!

[jra]

My bad, saw RFM69, read 328.  Where the radio is soldered to the underside of the Moteino I suspect the two temperatures may track fairly closely.  That would be an interesting experiment in itself to perform as you slowly raised or lowered the ambient temperature while you read the temperature from:

• The radio
• The MCU
• Some more accurate/precise temperature sensor

[WhiteHare]

I suppose one advantage of the RFM69, versus some of the dedicated temp chips, is that "It takes less than 100 microseconds for the RFM69W to evaluate the temperature (from setting TempMeasStart to 1 to
TempMeasRunning reset). "

A DS18B20 requires a minimum of 3v, which is bad news if it's everything is running direct from just 2x AA's.

An Si7053 only requires 1.9v, but it can take up to 80ms just to power up, plus another 10.8ms before it can produce a temperature reading.  It's $2.

The STSC1 is fairly quick: it can power-up and take a measurement all within 1ms, and it's accurate to within 0.3C, but it's $4.23 each and has a very narrow operating voltage range of 1.62-1.98v, so I guess it might require it's own LDO to power it.

For nearly the same price, there's the TSYS02P, which is insanely accurate to within 0.2C, and a resolution to 0.01C, and has a better operating voltage range of 1.5-3.6v.  However, it can take up to 150ms to reach an idle state after power up.  I suppose it would be a good reference standard for calibrating other sensors.

I suppose the figure of merit will be total system amps per temperature measurement, because impact on battery life will be a significant consideration to weigh in the trade-offs.

[john4444]

Hi WhiteHare,
An issue to keep in mind is the RFM69's self heating.
This also applies to the 328 but to a lesser extent.
I found the 328's internal temp-sensor useable but not +/- 1°F.
Also, it increased several °F depending on how busy the processer is.
RFM69/328 operating at low power are practically at ambient and it
takes a second or two before self heating begins to push the numbers up.
Reading the die-temp before doing anything else can give repeatable results.
But, I never tried to "calibrate" the numbers generated to a temperature.

John AE5HQ

[joelucid]

WhiteHare,

the resolution of the temp sensors in both the 328p and the RFM69 is 1C per LSB. These internal temp sensors need to be calibrated from chip to chip (see http://www.atmel.com/images/doc8108.pdf).

You can use both facts to your advantage: calibrate the sensors on both the 328p and the radio and you will get higher accuracy and resolution results (e.g. say the 328p switches LSB's at 18.6, 19.6, 20.6 C and the radio at 18.1,19.1,20.1 C).

I've done some tests recently to model temperature curves to reduce radio communication and prolong battery life (I still want to build a lifetime TH Mote using a cr2032  ). I found the idea wasn't new (e.g. http://www.vs.inf.ethz.ch/publ/papers/santinis_AMS_07.pdf).

I found that when measuring temps like room temperature of freezer temperature these optimizations can work very, very well, allowing a reduction of >80% in packet frequency while keeping error smaller than 0.1C.

The reason this works so well is that temperature curves are often linear for long times (e.g. when cooling down over night or warming up in the morning, or during the day when they are most often constant).

I mention this because you might be able to measure the temperature slope using the calibrated 328p/rfm69 combination fairly accurately and use it to produce results of much higher resolution than the 1C the sensors provide themselves.

Of course you'd have no way of knowing whether they're correct for any given moment. But on average they'd be better than the non extrapolated values.

Joe

[joelucid]

If I wanted to try anything like this I would probably create two full temp mapping tables rather than one or two point calibrations. You'd want to tease as much info as possible out from the measurements.

Does it make sense? No!

But you could probably milk it for a couple days of fun.

[TomWS]

But you could probably milk it for a couple days of fun.

LOL!

There is an ancient saying: NEVER take TWO chronometers to sea.  Take one, take three, but never two!

Tom

[joelucid]

NEVER take TWO chronometers to sea

Ok, yes, how careless of me ... 

Let me present the third chronometer: measure the radio's rc oscillator frequency against the Moteino's crystal and use its temperature dependence to infer temperature. Problem will be that it automatically calibrates on startup. So you'd have to counter-calibrate your measurements once you know the temp pretty precisely (say when the 328p just flipped one LSB upwards). I think this could be an excellent input to verify your slope assumptions between identical measurements on the 328p/radio front.

I should call out JTC - Joe's Thermometer Challenge: Using only a Moteino build the thermometer with the highest average accuracy, defined as the one with the lowest error integral over time.   

[WhiteHare]

Does it make sense? No!

Why doesn't it make sense? 

Assuming the built-in temperature sensor measurements are highly repeatable (and I don't know that they are), then I would think that with one or two tables you could get measurements accurate to within about plus or minus 1C on the RFM69.

[WhiteHare]

But you could probably milk it for a couple days of fun.

LOL!

There is an ancient saying: NEVER take TWO chronometers to sea.  Take one, take three, but never two!

Tom

If  you average their readings, then you're back to one chronometer.   

[joelucid]

Why doesn't it make sense?

I would guess that if you combine all 4 methods (328p, radio, slope extrapolation and rc frequency deviation) you could get at least to +-0.5 Celsius which would be pretty great.

But the price is measuring these tables - which is probably much more work than putting a DHT22 on a mote. That's where the senselessness comes in.

[WhiteHare]

According to the datasheet, the Energizer Ultimate Lithium AA are actually good for up to 1.7v for a short period of time when the battery first gets used.  So, one could take a hybrid approach, to automatically create a calibration table at the start of deployment, by using a DS18b20 (available from Aliexpress at 50 cents each) to take a temperature reading every time the RFM69 senses a new temperature.  Then, once the two AA batteries fall below the 3.0v minimum, you stop using the DS18b20 altogether.

[joelucid]

Then, once the two AA batteries fall below the 3.0v minimum, you stop using the DS18b20 altogether.

I don't know. For me the beauty of the bare bones approach is (a) no extra components needed and (b) ultra low power consumption. So I think the calibration component shouldn't be on board during deployment.

The challenge for the calibration process is probably to create an environment with very slow temperature change so that you don't get errors due to temperature inertia of the different types of sensors. And so you can measure with low frequency and avoid heating the 328p/radio.

I'm thinking a thick styrofoam container that you first put into a freezer overnight, taking measurements from within as you cool down. then let it warm up in the fridge. Then warm up further to room temperature and finally bring it up to 50 degrees in an oven (hey another use for your reflow toaster :-) ) and let it cool down again.

You want to take measurements on the way up and down to see of there is any hysteresis.

Just put an extra moteino with the best temp sensor money can buy in the same box and have it log in parallel.

One caveat: the temperature curves of the watchdog and internal rc oscillator are also dependent on vcc - though from the datasheet it looks like it's pretty much an offset that's constant across the whole temperature range.

[WhiteHare]

I did it on one prior occasion, when calibrating the temperature measurements given by a waterproof soil moisture sensor whose wireless signals (the raw values) I was able to intercept and decode.  I started it in a container packed with ice water, then put that into a cooler that had thick insulating foam, and then placed that in the attic, where temperatures would gradually rise through the day and slowly bleed into the cooler and raise the water temperature.  To get the full temperature range was a two day process, as the higher temperatures weren't reached until the second day.  So, it's doable, but there is an undeniable hassle factor, as you alluded to.  If one can't generalize the results from one radio to all the others--i.e. every radio has to be calibrated this way--it wouldn't be much fun.

The best temperature sensor I'm aware of at the moment is accurate to 0.1C--I've read that it's sensitive enough to detect the body heat from a hand even without touching it, provided you're within a few inches of it: http://www.mouser.com/ds/2/418/TSYS01_datasheet_rev0_3_20120113-710739.pdf  Digikey doesn't carry it, but Mouser does at $6.80 each.  It only takes 9 milliseconds to do a conversion while drawing 12.5uA, so although it's overkill in accuracy for most things, it's a tempting choice in it's own right, and it would obviously remove any need to do calibrations.  Also, I wouldn't have to worry about degraded performance over time, because of the extreme accuracy it would be starting with.

[joelucid]

That sounds like a reasonable procedure.

If one can't generalize the results from one radio to all the others--i.e. every radio has to be calibrated this way--it wouldn't be much fun.

You'd have to create a batch and measure them all at once for it to make sense - at least once you're in 'production'.

I'm thinking a 328p + rfm69cw + am1805. rtc switches total power off during sleep, 328p switches power to radio on demand. Frequent temp measurements to get precise slope measurements - say once every 10s. Only power radio on when there's a change from extrapolated slope.

Power consumption:

22nA - RTC
31nA - crystal wakeup radio
15nA - temp measurement Radio
18nA - temp measurement 328p
------
86nA - total

Now we also need to send updates. Say about once every 20 minutes (that should work from my experience to get 0.1C max error in rooms). That's about 83nA at 20mA transmit current at 5ms transmit time. Call it 100nA to account for radio startup costs.

For a total of 186nA or 1.63mAh per year. With self discharge of 1% per year a 220mAh CR2032 would last you 86 years. So there you have it: at least a lifetime T Mote.

[joelucid]

Oh I just realized that you have the radio startup costs for each temp measurement. That's clearly too expensive for this setup. So then maybe focusing on the RC oscillator would be more appropriate for ultra low power setups.

[WhiteHare]

Can a battery really last longer than 10 or 20 years?  For something ultra long-lived, I'm thinking energy harvesting might be the way to go, and for that, if you want to keep the small form factor, this chip seems pretty impressive:  http://cds.linear.com/docs/en/datasheet/31081fb.pdf  It can harvest from as little as 20 millivolts and eventually boost it up to 2.5v (well, for those of us still using winbond flash memory).  The atmega itself could run off the integrated 2.2v LDO.  If your electronics were encapsulated in epoxy, and using a capacitor for energy storage, maybe the system would run practically forever?

[joelucid]

Can a battery really last longer than 10 or 20 years?

Well - many of these lithium batteries have stated shelf lives of 10-15 years. An that's to ~90% of original capacity. Then why not use them for a couple of decades afterwards.

Practically speaking though: I have no idea 

[WhiteHare]

Even though the DS18b20 is a comparative power hog, and it can take up to 750ms (!) to take a temperature measurement, what I do like about it is the packaging: 3 long legs let you suspend it in the air, where it can be more attuned to rapid changes without the thermal mass of the main board (especially if encased in epoxy) creating latency and an averaging of fluctuating temperatures.  So, even though it's stated accuracy is +- 0.5C, in a real sense it may  offer a more accurate reading of current temperatures than higher accuracy surface mounted temp chips.

So, it would seem there just isn't a single, obviously "best" solution to incorporate into a general purpose platform.  For that reason, I think I'm trending toward a hybrid, which will avail itself to different trade-offs to fit different circumstances.  The MCP1640 boost converter is pretty cheap ($0.57 on Digikey), and so a  DS18b20 could be powered at 3.3v on-demand at any time, even if running from just a couple AA batteries.  Seems a bit unwieldy though, unless other sensors might (probably?) also need 3.3v  and so could leverage it.