868 Mhz communication based on CC1310 and thermal issues

[faithware]

Hello everyone,

I have designed a wireless star network based on the CC1310. The way this network operates is based on time synchronization between the gateway(master node) and the end devices. The gateway sends a synchronization signal to all the nodes in a broadcast message once a minute. When the synchronization message is received, all the devices go to sleep and operate on the RTC crystal oscillator for low power consumption and they wakeup each second to check any RF activity.
After each wakeup , the devices shut down the main 48mhz oscillator and operate only on the RTC 32.768Khz oscillator.
At the room temperature everything works ok until I place these devices in the field where they are subject to higher temperature and the drift of the oscillator will cause the devices to wake up in the wrong timeslots. The enclosure that I use are plastic waterproof standard enclosures and I can't find a way to keep the RTC oscillator cool enough so that the devices and the gateway are still synchronized.
Do you have any suggestion how to keep the devices cool when the are placed in the field, maybe putting a resin coating on top can help?
Thank you in advance for any suggestion.

Cheers

[ataradov]

Usually it is done the other way around. Gateway transmits multiple frames carrying current time for long enough to accommodate possible time variations on the end nodes. End nodes wake up on their old clock and receive one of the messages. By subtracting the local time from the remote time, they know how off their clock is, and they can make corresponding adjustments to the next wake up cycle.

And in 1 minute the temperature will not drift too much, so the transmit window from the master could be very short.

You could actually get creative and implement the adaptive window. If gateway knows that all devices responded in the time slot, it can start transmitting close to the target slot the next time, since all end node timers are accurate.

[faithware]

you are right but the drift at any time is not fixed amount, for example a +-20ppm oscillator can get over a minute +15µs drift or -15µs drift that means we have to stay awake for 30µs to  be sure that we can catch the synchronization signal. But because this is a low power application, I cannot afford to do that.
the drift can be positive or negative and that is purely random.

Cheers

[mayor]

Can you confirm whether the collector is mains powered?

[faithware]

yes the gateway is mains powered

[ataradov]

No, devices wake up for a short time at their scheduled interval. The gateway will send multiple frames in a row for a longer time to accommodate all possible drifts of the end nodes. Although +/-15 us seems like a short enough window already. Even without temperature there will be drift over time. How long is your data frame?

[faithware]

No, devices wake up for a short time at their scheduled interval. The gateway will send multiple frames in a row for a longer time to accommodate all possible drifts of the end nodes. Although +/-15 us seems like a short enough window already. Even without temperature there will be drift over time. How long is your data frame?

So 15µs on every wakeup which is in around 2 seconds over time we  have 648ms of listening wasted over a day which means that the battery will be drained two times faster.
my packet is 30bytes wide at 2.5KB/s.

Thanks for the help

[ataradov]

So 15µs on every wakeup which is in around 2 seconds over time we  have 648ms of listening wasted over a day which means that the battery will be drained two times faster.

It is not a waste if things don't work otherwise. Stabilizing the internal oscillator is not  the best idea, your options are to either use a more stable clock, or a better algorithm.

my packet is 30bytes wide at 2.5KB/s.

How long is this is this in terms of time? Modulation matters as well.

15 us window can be minimized over time if device knows the time it receives the frame. So you starts the receive with a wide window, then you know the time the frame was actually received relative to that window. The next time you shrink the window and center it around the previous time. For small variations this would auto adjust to the sender. If you start missing the frames due to frequency drift, you widen the window again.

Transmitter should have as stable clock as possible in this case, of course.

[mayor]

yes the gateway is mains powered

In that case, is it absolutely necessary to use beacon mode? In non-beacon mode, sensors are free to wake up whenever they like and send to/receive from the collector.

[faithware]

Transmitter should have as stable clock as possible in this case, of course.

It is absolutely true, what I found is that I have to use a tuning fork instead of a normal crystal.
In this case the clock drift can be calculated due to the fact that tuning fork have a known behaviour.

Cheers