Author Topic: Freq Vs. Temperature Update  (Read 50859 times)

john k2ox

  • Full Member
  • ***
  • Posts: 111
Freq Vs. Temperature Update
« on: March 01, 2014, 04:52:37 PM »
Last fall I posted some data that described how the RX/TX frequency drifted with temperature.  At that time I used the internal RFM69 temp sensor.  What I didn't realize at that time was that the chips temperature changes dozens of degrees depending on what the chip is doing.  Since the frequency is derived from an external  crystal and not the chip, I couldn't rely on the internal sensor.

In November I added an 18B20 to track the ambient temperature and correct for frequency drift.  The results have been outstanding.  I have a Moteino about 1200 ft from my house setting in a snow covered field.  RXBW set to 12KHz.

It has worked flawless from -12F to 65F degrees. 

I just added 18b20s to a couple more Moteinos.  This time I used a little heat sink compound and arranged the sensor to be in contact with the crystal.  The close coupling allows for even better compensation.

In the attachment you can see that an uncorrected Moteino drifts more than 14,000 Hz over -5C to 60C degrees.  With compensation less than 488Hz, usually within +/-122Hz.  Blue is uncorrected measurement data, Black is the error equation(curve fit), and Red is the corrected measurement results.

To apply this technique to your Moteino take the polynomial on the graph and put it in your sketch. 'x' is the temperature you get from your sensor in Celsius and 'y' is the resultant  error in Hz.

So, Freq(corrected) = Freq(wanted) - y;  Then set Moteino to Freq(corrected).

Bottom Line:  You should only care about this if you want to change BR, Deviation, and RXBW to small values that increase the radio's sensitivity. Say for long distance experimentation. Or if you have two or more Moteinos in vastly different environments where the temperatures don't track. 


Cheers,
john

 



 

KanyonKris

  • Full Member
  • ***
  • Posts: 113
Re: Freq Vs. Temperature Update
« Reply #1 on: March 02, 2014, 02:28:39 AM »
John, excellent work. Eye-opening that the frequency can shift 14kHz.

I know you said the internal RFM69 temp sensor didn't work for you, but do you think there could be any case in which it could be used for frequency correction?
For instance, if the Moteino and radio were asleep for 10 minutes, then woke up and immediately took a temperature reading from the RFM69 (before it had a chance to heat up), do you think the reading would be accurate enough for frequency compensation?

john k2ox

  • Full Member
  • ***
  • Posts: 111
Re: Freq Vs. Temperature Update
« Reply #2 on: March 02, 2014, 09:31:04 AM »
Hi KanyonKris,

Thanks.   Yes, I believe that is the only way to use the internal temp sensor.

That would be a worthwhile project.  Connect an 18b20 and capture the readings from it and the internal sensor. 

There is one other issue. If the crystal oscillator is also sleeping, the crystal will heat up when it wakes up.  In the first 30 seconds it's  +0.7C, about -183Hz. In five minutes it goes up +3C and -305Hz.   Not that bad, but it does happen.

If it were sleeping long enough so that everything was at ambient temp, it woke, measured its temp, corrected its freq, and sent its payload the correction should be very accurate.  In this case the chip and the crystal would have little time to self heat.

Using this correction and the narrowest RBW I'm going for a distance record of more than 2 miles. :)

john

KanyonKris

  • Full Member
  • ***
  • Posts: 113
Re: Freq Vs. Temperature Update
« Reply #3 on: March 02, 2014, 07:58:54 PM »
John, thank you for the informative reply.

I'm surprised the oscillator warms up that much, and so quickly.

2 miles? Astounding. Well done.

One other thing I've been wanting to ask you. In your work making frequency corrections, do you use a frequency analyzer to measure frequency or another Moteino? Certainly an analyzer would be best. But I imagine a pair of Moteinos, TX and RX could tune themselves by having the TX vary the sending frequency and the RX report back the RSSI so TX can look for the peak.

john k2ox

  • Full Member
  • ***
  • Posts: 111
Re: Freq Vs. Temperature Update
« Reply #4 on: March 03, 2014, 10:11:57 AM »
I used an Agilent MXG Signal Generator to produce a known stable CW signal.  It uses an oven to keep its crystal on frequency.  My Moteino code then triggers the RFM69 to do an FEI measurement that sends the freq error result to the serial port.

The FEI measurement compares the received signal with its own and saves it in the FEI register.  It has a resolution of 61 Hz.

If you do this with two Moteinos you can keep them within a couple hundred Hz of each other.  You have to do it often enough though so that they don't get 'lost'.   I haven't had an issue when syncing once every 15 minutes.  Once an hour should be OK.

With T vs F correction the FEI correction isn't necessary. 

john

hdphilip

  • NewMember
  • *
  • Posts: 17
Re: Freq Vs. Temperature Update
« Reply #5 on: May 18, 2014, 01:24:52 AM »
Quote
In the attachment you can see that an uncorrected Moteino drifts more than 14,000 Hz over -5C to 60C degrees.  With compensation less than 488Hz, usually within +/-122Hz.  Blue is uncorrected measurement data, Black is the error equation(curve fit), and Red is the corrected measurement results

would this frequency drift be for the 900 MHz radios?

Philip


Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Freq Vs. Temperature Update
« Reply #6 on: October 22, 2014, 08:49:45 AM »
I found this Semtech document which outlines some of the techniques to adjust the frequency drift of the oscillator, adding it here for posterity and as extra reference:
http://www.semtech.com/images/datasheet/xo_precision_std.pdf

The temperature compensation section is similar to what john has done, except they suggest keeping compensation tables at each frequency used, which might eat a lot of memory.

john k2ox

  • Full Member
  • ***
  • Posts: 111
Re: Freq Vs. Temperature Update
« Reply #7 on: November 09, 2014, 10:31:31 PM »
Yes.  All my experiments are with 900MHz radios as of 11/2014.

maxim

  • NewMember
  • *
  • Posts: 1
Re: Freq Vs. Temperature Update
« Reply #8 on: February 17, 2015, 11:54:09 AM »
Hi,

New to this board and just wanted to share another type of fix to ensure that these radios can communicate while exposed to very cold temperatures. Right now it's -24C and the radios are communicating with rarely a retry and an RSSI of ~ -70dBm for the last month with a transmission at least every hour with the RFM sleeping between transmissions.

This tweak is applied to the RFM's AFC algorithm and gives it more time to analyze the incoming transmission's preamble to perform the usual frequency correction. Since the likelihood that these radios will transmit "bang on" is handicapped by a relatively low quality xtal, one solution is to adapt each receiver to the incoming transmission's frequency (acceptable under an unlicensed band scenario).

Steps:
1) Reduce the AFC feedback loop gain.
2) Increase the wait period between AFC corrections.
3) Increase the Preamble length.

The net effect is to increase the number of AFC corrections (by reducing the weight of each correction), and to increase the delay between corrections to allow the VCO to stabilize before a new correction is applied.

In code (using the RADIOHEAD library by Mike McCauley - Version 1.39) it looks like this:

rf22.setFrequency(923.0,0.1);  // Increase FM capture range from default 0.05 to 0.1.
rf22.spiWrite(0x1D, 0x50);  // Reduce AFC gain (Default is 0x44).
rf22.spiWrite(0x1E, 0x1A);  // Increase wait time between AFC corrections (Default 0x0A).
rf22.setPreambleLength(25);  // Increase Preamble to 100 bits (25 x 4bits).

Once I confirmed that the settings were useful I switched to a narrower & Gaussian-smoothed modulation using:
rf22.setModemConfig(RH_RF22::GFSK_Rb2_4Fd36);

The radio used was an RFM22B in the 900 MHz band. I've attached snapshots of the register descriptions.

-- Max


« Last Edit: February 17, 2015, 11:23:24 PM by maxim »

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #9 on: March 10, 2015, 09:56:02 AM »
Hi! I'm well out of my feet on this subject, but sure would like to try to understand it a bit more.

I have installed a moteino with a 433mhz RFM69HW inside the bonnet of my car that is used to open the outer gate and garage door of my house.
I'm sure the temperature inside the bonnet will shoot to 80ºC or even more.
The moteino works flawlessly in this environment. But looking at your post it is obvious that the transmitting frequency will drift a lot thus reducing the range. Also, because of all the metal around it, the signal is further attenuated.

Since I decided to make a new PCB for the car moteino, I will insert a ds18B20 temp sensor directly under the radio but now I'm  completely lost on what to do next in order to implement a pratical solution for temperature compensation.

Do I need to log the temperature and determine the polinomial function to correct the frequency? Is it possible to create a turn key solution that could be applied to any situation, cold or hot that would depend of the type of radio?
« Last Edit: March 10, 2015, 09:59:46 AM by luisr320 »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #10 on: March 10, 2015, 01:50:16 PM »
May I ask why you put the moteino near the engine? My 868 MHz gate opener RC is working just fine from inside the car. You gain nothing from putting it under the bonnet, on the contrary, you need to deal with other sorts of problems like heat as you mentioned.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Freq Vs. Temperature Update
« Reply #11 on: March 10, 2015, 03:20:15 PM »
And dust and water/humidity ...

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #12 on: March 10, 2015, 03:20:38 PM »
My car is an Audi TT and I can't find any holes that allow me to pass a wire to the inside of the car. I guess its a question of being practical.
I have waterproofed the box. And with all that heat there will be no humidity there. Ever.

« Last Edit: March 10, 2015, 04:01:27 PM by luisr320 »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #13 on: March 10, 2015, 03:27:29 PM »
I don't know the Audi TT's internals but in that case I'd ask for suggestions from a professional. They know all the places you can mount and hide your stuff. Though I'd imagine it'd be practical to mount it under the dash on either side of the console. There are usually conveniently sized compartments there. Or you can just hide it in or behind the glove box (remove the door to have a look). I've seen many onboard DIY electronics there in a wide variety of cars.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #14 on: March 10, 2015, 08:57:54 PM »
Thank you for your advice.
All that makes sense and at the end I will probably look for a way to install it inside the car.
But at the present time I would like to try to understand a bit more on how temperature affects the frequency stability on these radios and for that I really want it to be where it is.

After looking a bit around the Forum I can't find a clear description on how to implement temperature compensation. It looks like I have to address some bits on the radio but I'm not sure how.
I'll dig a bit into the radio datasheet to see if I get some epiphany but I'm guessing I just be wasting time without any guru guidance.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #15 on: March 10, 2015, 09:06:38 PM »
John gave us the polynomial he calculated (it's on the image). I think it's just the simple matter of applying it to your desired frequency value, as a function of ambient temperature. Though he measured the error with a 915 MHz module IIRC. But since the xtal is the same on all modules, I think it's safe to assume the same corrections need to be applied on all of them, if you scale the error relative to 915 MHz.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #16 on: March 10, 2015, 10:09:22 PM »
But where and how would I implement that polinomial function as a correction?
There must be some obscure instruction that I must call to enter a corrective value on the frequency as a function of the temperature.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #17 on: March 11, 2015, 03:25:13 AM »
No, there isn't. You calculate the coefficient based on the formula, subtract it from the desired frequency, then set the result on the module via a simple call.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #18 on: March 11, 2015, 07:18:32 AM »
Ah, thank you for your reply.
And what would that call be? And where would you insert it? In the loop() on in setup()?
« Last Edit: March 11, 2015, 07:20:08 AM by luisr320 »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #19 on: March 11, 2015, 07:32:08 AM »
It depends on your code, but most probably in your init() function, with a call to RFM69::setFrequency(). There are several tutorials for Moteino, I'm sure you can easily find them. They will guide you through the basics.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #20 on: March 11, 2015, 03:31:08 PM »
I hope you meant setup() function.

But since the temperature will vary as a function of time, frequency correction must be cyclical and as such, I think it should be inserted in the main loop().

Something like this:
Code: [Select]
void loop() {
float x = getTemp();//a call to the usual getTemp function
float adjFreq = ((123*x^3)+(123*x^2)+(123*x)+123); //our polynomial function
float newFreq = (433 - adjFreq);//Being 433 the expected frequency of 433 Mhz
RFM69::setFrequency(newFreq);

Serial.print(temp); Serial.print (" - "); Serial.println(adjFreq);
delay(100);
}


This, of course, bring in a new problem. How do I get the polynomial function for my 433 Mhz radio? For that I would need a Spectrum Analizer, something I don't have.

If I mail a moteino with a 433Mhz radio, could someone with the right gear be willing to produce the curve related to a similar temp variation presented in the posted graph?

Do you think that the above sketch would work as is?
« Last Edit: March 11, 2015, 03:33:02 PM by luisr320 »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #21 on: March 11, 2015, 03:35:56 PM »
Disregard what I wrote about where to apply the EC. Yes, for continuous operation, you need to apply the EC value periodically. I've already hinted how I suggest calculating the values for 433 MHz. Please see in one of my previous posts. Most probably that will work, but it'd be nice to hear John's suggestions too.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #22 on: March 11, 2015, 04:02:36 PM »
Are you talking about measuring the RSSI on a second Moteino? I think I read that one. I'll take a look at it again. Its not very "scientific" but if it works, it sure is a good idea.
Thank you for hanging in there with me on this one

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #23 on: March 11, 2015, 04:05:21 PM »
No, sorry, I don't even know what RSSI measurement you're talking about.

This is my post I was referring to.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #24 on: March 11, 2015, 04:24:01 PM »
OOOHHH  :o

So I just use the same function for the 433Mhz radio?
And subtract the error from 433 to scale it to 433.
Nice!

I'll make some tests during the weekend to try the RSSI readings on a moteino with and without the other having its freq corrected.

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #25 on: March 11, 2015, 04:53:36 PM »
I'm adding an Excel file with the polynomial function applied to a temperature range from -20ºC to 90ºC and the respective frequency correction and final frequency for 433MHz and 915Mhz.
It is the same data as the one that produces the posted graph but coming from an editable Exel file.
« Last Edit: March 11, 2015, 05:07:33 PM by luisr320 »

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #26 on: March 12, 2015, 03:12:31 PM »
So I just use the same function for the 433Mhz radio?
And subtract the error from 433 to scale it to 433.

My idea is to calculate the error based on temperature, scale it according to the used frequency range and then apply it. So a calculated value of E915 for 915 MHz is scaled for 433 MHz as E433 = 433 / 915 * E915

luisr320

  • Sr. Member
  • ****
  • Posts: 255
  • Country: pt
Re: Freq Vs. Temperature Update
« Reply #27 on: March 12, 2015, 05:37:29 PM »
Hummm, that's interesting. You are assuming that there is a linear correlation between the difference in frequency and the difference in error caused by the temperature. I guess the only way to be sure would be trough testing with a spectrum analyzer.
How sure are you that that correlation is linear?
« Last Edit: March 12, 2015, 05:39:31 PM by luisr320 »

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: Freq Vs. Temperature Update
« Reply #28 on: November 13, 2015, 05:03:45 AM »
I fully agree with kobuki's approach. XO's have same frequency vs. temperature error in all RF frequency variants (when XO's are similar) but RF frequencies are generated by multiplying XO frequency which leads to larger absolute error for higher RF frequencies.

Corrected luisr320 excel and attached it here (btw. there was typo on polynomial coefficient).






Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: Freq Vs. Temperature Update
« Reply #29 on: November 25, 2015, 03:27:40 PM »
Finally had some time to wrote recent findings what I made with RF69HCW on temperature chamber.

So I tested one RF69HCW assembled on small PCB together with ATMEGA328P (comparable to Moteinos) on temperature chamber to see how frequency drifts over temperature. My setup was SDR for frequency sniffing, K-type thermocouple for crystal temperature and DS18B20 for chamber temperature (altought it has internal sensor). Swept was made from 20 to -30 celsius and back from -30 to 70 celsius with ~20min settling time for each step. RX was continuously on which caused radio & crystal to have higher temperature than chamber. Controlling TX, requesting internal & DS18B20 temperature was done via serial commands. Frequency was measured with "pre-heated" SDR so that its own frequency shift due self heating could be minimized.

First figure represents the correlation between internal, K-type and DS18B20 temperatures to ambient temperature. Naturally DS18B20 measures quite nicely 1:1 what chamber was set. Also it seems that radio is ~10 celsius hotter than ambient over the range. Crystal temperature behavior is not 100% clear to me, as it seems to run hotter than radio in cold but vice versa in hot. Could be also measurement error as K-type sensor is attached on top of the crystal and measured with multimeter.. Anyway, my point was to run tests and see if I could use internal sensor to read temperature and make frequency corrections according that information when I have somewhat stable case (eg. RX continuously on, just after wakeup etc...).

Second figure shows the frequency drift over internal temperature. S-type curve seems quite familiar from Johns post but the swing of frequency shift have huge difference when comparing to first post of this topic. John has measured ~14kHz swing and I did measure "only" ~8kHz. This cannot be explained by the fact that I have 868MHz and John have 915MHz radio (see the previous post) or that John has measured crystal temperature with DS18B20 and I use radios internal temperature (using different temperature doesn't have impact on swing). It could be explained by different or broken crystal or some measurement error.

In addition to this, when comparing to first freq vs. temp results by John, it seems that my results have clear correlation to those measurements (https://lowpowerlab.com/forum/index.php/topic,135.msg453.html#msg453). I did convert my results to 915MHz and shifted it to same temperature, see the figure 3.

I'm going to implement simple temperature compensation and re-test this with few radios in temperature chamber to see how it works. Any thought/ideas on this?

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Freq Vs. Temperature Update
« Reply #30 on: November 27, 2015, 05:21:39 AM »
@Nuudeli,

It is worth thinking about where the self heating comes from.  In Rx, for the radio module die, it is mostly gate switching losses + some leakage from 'off' gates. The important internal clocks are derived from the crystal, so essentially constant frequency; the leakage is negligible at room temp and rises exponentially. You could get a good estimate of this by measuring the module current drain - with a constant Vdd, the "smoothed" mA from a DVM reading x Vdd is the mW almost all dissipated as heat when in idle or Rx state.

The crystal self-heating is somewhat different. It is basically the mechanical losses of the crystal slice as it changes shape at the fundamental oscillating frequency.  The driving circuit aims for a loop gain of ~1, just enough to sustain a constant level of vibration. This however would take forever to build up from zero, so the drivers tend to overdrive the crystal to reduce starting time. On some RF modules this overdrive level is adjustable, but AFIAK, there is no programmatic way to do that on the RFM69 family. Just to complicate the issue, the gain of the op amps in the driver circuit are also die temperature dependent. You can expect the amount of crystal self heating to vary over the temperature band, curve shape unknown.

If I understand your aim well (correct the temperature offset of the crystal by estimating the die temperature rather than the crystal temperature) the Achilles heel is the loose coupling between the two temperatures. There are boundary conditions where the error is small - e.g. with both crystal off and the radio module sleeping, the temperatures will drift down at different rates to ambient.


« Last Edit: November 27, 2015, 06:57:59 PM by emjay »

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: Freq Vs. Temperature Update
« Reply #31 on: November 27, 2015, 06:17:58 PM »
Thanks for reply. Please see my comments below.

It is worth thinking about where the self heating comes from.  In Rx, for the radio module die, it is mostly gate switching losses + some leakage from 'off' gates. The important internal clocks are derived from the crystal, so essentially constant frequency; the leakage is negligible at room temp and rises exponentially. You could get a good estimate of this by measuring the module current drain - with a constant Vdd, the "smoothed" mA from a DVM reading x Vdd is the mW almost all dissipated as heat when in idle or Rx state.

Don’t understand what you are meaning with “the leakage is negligible at room temp and rises exponentially”, what leakage? And how calculating power dissipated as heat relates to this one? I know it’s easy to calculate dissipated power, but quite difficult to turn it to temperature for RFM69 module. 

The crystal self-heating is somewhat different. It is basically the mechanical losses of the crystal slice as it changes shape at the fundamental oscillating frequency.  The driving circuit aims for a loop gain of -1, just enough to sustain a constant level of vibration. This however would take forever to build up from zero, so the drivers tend to overdrive the crystal to reduce starting time. On some RF modules this overdrive level is adjustable, but AFIAK, there is no programmatic way to do that on the RFM69 family. Just to complicate the issue, the gain of the op amps in the driver circuit are also die temperature dependent. You can expect the amount of crystal self heating to vary over the temperature band, curve shape unknown.

Thanks for pointing that crystal self-heating for me, didn’t think it so deeply previously. You probably meant loop gain of 1, not minus 1. Could you explain how startup time affects to crystal temperature or RFM temperature as it’s typically only 250usec (datasheet p.12), I would guess it’s negligible?

Well actually I don’t care much about the crystal temperature as I can measure the radio temperature and calculate frequency drift for that temperature, with assumption that I’m using RF69 similar way (RX continuously on and ambient temperature has been stable for a while) as the situation was when doing those previous measurements.

If I understand your aim well (correct the temperature offset of the crystal by estimating the die temperature rather than the crystal temperature) the Achilles heel is the loose coupling between the two temperatures. There are boundary conditions where the error is small - e.g. with both crystal off and the radio module sleeping, the temperatures will drift down at different rates to ambient.

Let me clarify my targets. I would like to use RFM69 internal temperature sensor to compensate frequency drift of crystal when RFM69 is on stable environment (might change with 1h interval). I’m planning to use RX continuously on for server and node will be in deep sleep if button is not pressed --> so both have predictable temperature difference between crystal and RFM69. For server, it’s measured as shown in previous post and for node it’s considered to be near 0 as startup is quite fast and self-heating of the components is negligible. In my opinion the coupling between the components is not so loose. I measured 1.6mm between the edges of the components on RFM69HCW.

Let’s see what kind of results my approach yields when I make re-measurements with compensated HW.

Cheers,
Tommi

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Freq Vs. Temperature Update
« Reply #32 on: November 28, 2015, 01:39:49 AM »
@Nuudeli,

Quote
what leakage?

In Rx, for the radio module die, it is mostly gate switching losses + some leakage from 'off' gates. (The important internal clocks are ... constant frequency); this leakage is negligible at room temp and rises exponentially.

Quote
it’s easy to calculate dissipated power, but quite difficult to turn it to temperature for RFM69 module.

The standard approximation is to assume a constant die to ambient (die to lead frame, lead frame to PCB, PCB to air etc) thermal impedance (∆ºC/W).  So at equilibrium, you have W, Tambient and Tchip estimate - plot and best fit line on these observed data points gives you an estimate of the thermal impedance.

Quote
how startup time affects to crystal temperature

To get short crystal start up times, the crystal is overdriven. The crystal drive circuit is not very sophisticated - the overdrive continues to some extent after the crystal is running.  Overdrive implies larger crystal contortions which maps to higher self heating.

Quote
Let’s see what kind of results my approach yields

Exactly - you were puzzled by the crystal temperature behaviour, the comments were aimed at better understanding what is happening there.  The proof of the pudding is in the real-world measurements.   
One suggestion to help repeatability is to transmit with and without compensation in rapid succession at each temperature stage, then both "raw" and "compensated" curves are generated in parallel.

 



DotMackay

  • NewMember
  • *
  • Posts: 1
Re: Freq Vs. Temperature Update
« Reply #33 on: December 03, 2015, 01:37:28 PM »
It is a nice thing that the frequency can shift 14kHz.
you mentioned the internal RFM69 temp sensor didn't work for you, but do you think there could be any case in which it could be used for frequency correction?
For instance, if the Moteino and radio were asleep for 10 minutes, then woke up and immediately took a temperature reading from the RFM69, do you think the reading would be accurate enough for frequency compensation?

prototype pcb assembly services
« Last Edit: December 09, 2015, 04:14:40 PM by DotMackay »

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: Freq Vs. Temperature Update
« Reply #34 on: December 16, 2015, 05:46:56 PM »
Did more measurements some time ago and finally have time to write those here. So I tested 3 units on temperature chamber on temperature range of -27 to 63 celsius to see how accurately polynomial compensation works. Units were controller over the air to send temperature and value of correction applied within two consecutive TX burst, one with and second without correction. Frequency drift were captured with SDR. Measurements were done from 23 celsius to -27, back to 23 and then to 63, with step of 10 degrees. Also hysteresis was measured from  23-->-27-->23 and assumed to be similar when going from hot to room temperature. Hysteresis was quite negligible, only few hundred Hz at maximum. Results shown later are averaged over hysteresis.

Unit #1 was the same I used previously (board size 3cm*3.5cm),  #2 has bigger layout (7.5cm*10cm) and #3 is same as #2 but with different voltage regulator. Units #1 & #3 had power cord and #2 was battery powered. I assumed that if there would be differences, nodes #2 and #3 would have similar behavior and #1 not due board size differences. But, this wasn't actually what happened...

It turned out that # 1 and #2 had somewhat similar behavior and #3 was acting differently. Below figure shows behavior of all units and polynomials for those together with data from first round. After studying what could be the root cause for #3 different behavior I found that it's the same unit I had been playing with (meaning that it's been de-soldered with hot air gun and re-assembled later). So best quess so far is that it's gone thru different stress than others which could have affected crystal behavior. I calibrated all radios to have same temperature value in same conditions, but didn't realize that it should be taken into account when calculating polynomial which caused systematic offset to corrected frequency (as polynomial is zerod to different temperature). Taking that into account I can say that I'm moving forward using internal sensor to read temperature as it seems to work quite nicely with my applications.

ps. If someone is using these polynomials, please calibrate radio temperature to 29-30 degrees when RX is set continuously on and heated for eg. 10min in normal room temperature conditions.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Freq Vs. Temperature Update
« Reply #35 on: December 16, 2015, 05:53:41 PM »
Interesting research. I'd like to have a couple of questions. What temperature chamber are you using for the experiments? And why is it important to apply the corrections in your case? I found that the chip's AFC can adjust to quite large differences, sometimes up to 30-35 kHz.

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: Freq Vs. Temperature Update
« Reply #36 on: December 17, 2015, 04:49:37 AM »
Temperature chamber is older version of this: http://www.arctest.fi/en/products/environmental-testing/environmental-test-chambers, without humidity control. Range of -40 to 100 celsius. I need frequency correction as I want to use as low RXBW as possible to increase sensitivity which yields maximum range. Currently the application where I need this is remote control for Webasto auxiliary heater which should work over wide range of temperatures (it can be even -35 celsius degrees in Oulu where I live) and it should have maximum range available.

I think AFC is not suitable for my project, as there is only occasional communication between remote control and car unit and between those communications temperature can change ten of degrees. It could work if I set RXBW for AFC routine to be larger than actual transmission, but I would lose range. Currently I use 5.2kHz RXBW and it produces range of 400m with NLOS conditions (forest between) and ~200m when there was some concrete walls and partially line of sight.

LukaQ

  • Sr. Member
  • ****
  • Posts: 302
  • Country: si
Re: Freq Vs. Temperature Update
« Reply #37 on: February 19, 2018, 08:38:07 AM »
There was no correction code released for this, temp compensation for freq. drift

juan3211

  • NewMember
  • *
  • Posts: 19
Re: Freq Vs. Temperature Update
« Reply #38 on: June 02, 2020, 03:21:42 PM »
Hi, could anyone post any example about how to make this in the loop code? ( I mean, I will control when to change the freq by saving last temperature an only call "calibrate_freq" function after a change for X degrees.

But what is the "callibrate_freq" function?

I have a problem with a node that is outside, inside a box. I can't put in shadows, so it gets up to 50ºC or more inside the box. I doesn't recieve any data from it when temperature is soo high (I send data each 5-10 minutes, so it is sleeping all time).
The reciever node is inside the house with "constant" temperature.

I will be very happy if anyone could put here anyexample, and If you have also to change registers to reduce baud rate and increase range, it will help me also. I haven't got any frecuncy measurement tool. Please help US.

Do you think this function will help me? (Remember that I can't check any freq. only "trial and error")
Does ATC solve this? After reading this post, I think no, but I could be missunderstanding something.

Thanks.
« Last Edit: June 02, 2020, 03:28:04 PM by juan3211 »

juan3211

  • NewMember
  • *
  • Posts: 19
Re: Freq Vs. Temperature Update
« Reply #39 on: July 20, 2020, 01:04:58 AM »
Hi, anybody ?