Crystal/Resonator observations and ways to compensate over time

Added by Disca over 6 years ago

Hi All.

I’m currently in the midst of programming a sensor/home monitoring application using multiple Jeenode SMDs, a Jeelink and a raspberry Pi acting as the central node. My aim is to implement a primitive TDMA protocol to avoid the issues/complexity surrounding packet collisions and retries. The best solution for battery life also appears to be with the remote node initiating all communications.

The Jeelink acts as USB/Serial interface between the raspberry pi and the sensor network. It sends out a clock sync packet every 1000ms which nodes joining the network use to get initial sync (this prevents them transmitting over another node).
Each node has a pre-programmed transmission offset which they attempt to hit for each transmission (0-1000ms - representing the offset from the clock sync packet). I intend to use 32ms transmit windows which will give me around 31 transmission windows per second which will be shared between nodes. The node initiates a transmission and the central node responds with its offset from 0ms sync in the ACK packet.
Each node has a target transmission interval time of between 1-240 seconds. A PI (Proportional/Integral) algorithm is used to keep the clocks in sync and the target transmission interval is reached by slowly increasing the interval by 16ms each time to prevent a large deviation occurring.

My observations are as follows (all at the same room temperature and relative to the clock of the Jeelink) :-

The two Jeelinks I have are very closely in sync. 1ms drift over 120 seconds. 0.001% clock drift. Pretty impressive!
The two Jeenode SMD’s have clock drifts of 0.03%. One is positive, one negative. So about +35ms over 120 seconds.
Logs below show the results of the PI compensation (Overall deviation from power up is never more than 8ms, when properly compensated it remains within 1ms).
Master Logs (128 Second interval between transmissions. The node is aiming for a 240ms transmission offset.):

I>Offset 246ms Correction 6ms
I>Offset 244ms Correction 4ms
I>Offset 244ms Correction 4ms
I>Offset 242ms Correction 2ms
I>Offset 241ms Correction 1ms
I>Offset 242ms Correction 2ms
I>Offset 240ms Correction 0ms
I>Offset 240ms Correction 0ms
I>Offset 241ms Correction 1ms
I>Offset 240ms Correction 0ms
I>Offset 241ms Correction 1ms

Node Logs:-
I>PI Correction –39.00ms
I>PI Correction –38.00ms
I>PI Correction –39.00ms
I>PI Correction –37.50ms
I>PI Correction –36.75ms
I>PI Correction –38.25ms
I>PI Correction –36.25ms
I>PI Correction –36.25ms
I>PI Correction –37.50ms
I>PI Correction –36.50ms
I>PI Correction –37.75ms

I’m still tuning the PI algorithm but in its current non-aggressive state it hits its offset target pretty quickly and should provide good compensation to drift over time caused by temperature changes etc.

Hopefully the info might be of use to someone else trying to do the same thing and thinking of ways to do it.

Interested to hear of ways other people have approached this issue.

Replies (2)

RE: Crystal/Resonator observations and ways to compensate over time - Added by padvinder95 over 6 years ago

How do you handle the assignment of time slots? Do you program that into each node, or is the desired offset distributed by the master node?

I think I would partition the short interval (1000 ms in your case) as follows:

000-100  ms -> reserved for new nodes
100-500  ms -> reserved for 1 Hz transmissions
500-1000 ms -> reserved for <1 Hz transmissions

The master node sends a synch every second at t=0 ms; then new nodes can respond immediately (or with a random delay of 0..80 ms to lessen the chance of collisions when multiple new nodes are added within one second—not very likely) with a request for a timeslot, indicating their required transmission rate. Based on this, they will be divided into the proper slots.

The reason I would distinguish between 1 Hz and <1 Hz transmissions is that I don’t have a lot of nodes that need to send their state every second. When distributing them over a larger time period, say T=10 s, they have more time to send their messages (namely, the entire second half of the short interval -> 500 ms) so the clock doesn’t have to be that accurate (but have more time to drift as well). The master node then has to include the current second (1..T) in the synch message as well.

Using this setup, all the nodes have to know initially is their required update rate. They’ll wait for a synch packet to notify the master within 100 ms; then the master will find a free slot based on their need. If necessary, the master can change assignments later on.

Of course, the boundaries (100,500 ms) and periods (1000 ms and 10 s) can be modified based on the number of transmissions that have to take place in each category.

RE: Crystal/Resonator observations and ways to compensate over time - Added by Disca over 6 years ago

The time slot is hard coded at the moment as my development to this date has focussed on offsetting the clock drift over a time period of < 5 minutes (realistically the majority of nodes will be at about this interval - although I want to incorporate some alarm related nodes that need to transmit on very low intervals should they be triggered). Its very stable now to less than 1ms out in 2 minutes - I have yet to try any greater time period’s but if it was +–3ms over 5 minutes then that would still very easily fit into a 32ms transmission window.

I like your idea of assigning a timeslot for new nodes as they come online rather than it be hardcoded. If I do this immediately after the clock sync it will also reduce the power needed by the node as it can get the sync and slot allocation done in one transmission session. Maybe with a delay algorithm based on assigned nodeID to reduce risk of collisions in the 0-32ms time slot.

My intention was to assign them an offset after 0ms but to then subdivide this so that for instance node 1,2,3,4,5 could talk in the same 32ms slot in seconds 1,2,3,4,5 respectively as they would know there would be no traffic from the other nodes. So based on the amount of data needing to be sent it should be possible to fit an awful lot of low frequency transmissions into the same segment.

mmm more things to think about. Thanks for the feedback I will definitely incorporate some of your ideas next.

Striking the balance between lots of features and simple design is very tricky IMHO!