atmega328p + RFM69: now a precision thermometer

[joelucid]

Just noticed something curious: measure the radio's temp sensor 100x and the average value has a much higher resolution than the 1 per C you get from the register. You'll get repeatable measures down to 1/10 C - pretty cool.

I think for once noise is helping us: the thermal noise gives you a gaussian distribution of measurements around the true value. Average a large number of measurements and you increase the resolution by a factor of 10!

328p + RFM69 = now a precision thermometer. After calibration ...

Joe

[TomWS]

Just noticed something curious: measure the radio's temp sensor 100x and the average value has a much higher resolution than the 1 per C you get from the register. You'll get repeatable measures down to 1/10 C - pretty cool.

I think for once noise is helping us: the thermal noise gives you a gaussian distribution of measurements around the true value. Average a large number of measurements and you increase the resolution by a factor of 10!

328p + RFM69 = now a precision thermometer. After calibration ...

Joe

Good Work, I guess...

Gotta hurt your power budget however...

Tom

[perky]

I suspect you might get a good set of coefficients for your particular crystal with a one-off measurement. If the accuracy of the internal temp sensor is that good with averaging then just heating it up while locking the receiver to a known fixed transmit frequency might suffice (assuming the crystal temperature and radio are well matched, and any absolute temperature offset calibrated).
Mark.

[joelucid]

If the accuracy of the internal temp sensor is that good with averaging then just heating it up while locking the receiver to a known fixed transmit frequency might suffice (assuming the crystal temperature and radio are well matched, and any absolute temperature offset calibrated).

I think so, yes. Check out the attached where I used the radio to heat up my gateway by 20 C and then let it cool off. While it's cooling I ping a Moteino at constant temperature and do AFC during reception of the ACKs. Ignore the first couple of points which are off due to non constant temps between crystal and radio, do a linear regression and you're done.

This will likely work well form 5 to 50 C or so. Colder or hotter and you get into the non-linear areas where you need to know what kind of crystal you have.

[joelucid]

Gotta hurt your power budget however...

One measurement takes 100us so 100x that's 10ms, not that bad. I don't know what the radio draws while measuring, but assuming total power as 5mA and one measurement every 10 minutes then this thermometer will cost you 83 nA. Not too bad ...

[WhiteHare]

Sounds great.  Is the measured temperature affected at all by the applied voltage?  i.e. will that need to be part of the correction formula?

[ChemE]

Sorry to necro a thread but I just now got around to playing with this notion and I noticed something interesting.  Starting from standby mode, it takes around 140uS to get a temperature reading.  Starting from synthesizer mode, it only takes 100uS as stated in the datasheet.  If I do 100 measurements from standby, it takes 14,000uS using my absolutely no-frills SPI code.  If I change the function to put the radio in synthesizer mode instead before starting the loop of measurements I don't save 40uS, I save around 2,400uS!  I'll take 2.4ms back for free anytime!

This function takes 14,000uS to call and return

Code: [Select]

// Return the temperature x 100 in C. Leaves the radio in sleep mode once done to save power
static inline uint16_t RadioGetTemp(void) {
  uint16_t total;
  CHANGE_OP_MODE(STANDBY_MODE);                     // Radio must be in standby or synthesizer to measure
  for ( uint8_t i = 0; i<100; i++) {                // Take 100 temperature readings
    writeReg( REG_TEMP1, RF_TEMP1_MEAS_START );     // Initiate a temperature conversion
    while ( readReg( REG_TEMP1 ));                  // Wait for the result to be ready
    total += (uint8_t) ~readReg( REG_TEMP2) - 91;   // Add the current result to the running total
  }
  CHANGE_OP_MODE(SLEEP_MODE);                       // Place radio in sleep mode to save power
  return( total);                                   // Return temp x 100 in C
}

This function takes 11,600uS to call and return

Code: [Select]

// Return the temperature x 100 in C. Leaves the radio in sleep mode once done to save power
static inline uint16_t RadioGetTemp(void) {
  uint16_t total;
  CHANGE_OP_MODE(SYNTHESIZER_MODE);                 // Radio must be in standby or synthesizer to measure
  for ( uint8_t i = 0; i<100; i++) {                // Take 100 temperature readings
    writeReg( REG_TEMP1, RF_TEMP1_MEAS_START );     // Initiate a temperature conversion
    while ( readReg( REG_TEMP1 ));                  // Wait for the result to be ready
    total += (uint8_t) ~readReg( REG_TEMP2) - 91;   // Add the current result to the running total
  }
  CHANGE_OP_MODE(SLEEP_MODE);                       // Place radio in sleep mode to save power
  return( total);                                   // Return temp x 100 in C
}

[steve v]

I like the idea of using the temperature to adjust the frequency offset.  Can I use this same routine for the RFM95 Moteino ?  I am running a spreading factor of SF9 = 512 and that requires significant accuracy.

And in this latest California heat wave,  I need to temperature compensate the Moteino on board crystal.

[ChemE]

I'm pretty sure the 95 and 96 already do this automatically to some extent.  Register 0x3c contains the temperature on the 95 but there isn't a way to trigger it to measure temperature so far as I can tell.