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

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 ?