Time synchronization importance in the IoT world

gal brandwine
Machines talk, we tech.
5 min readNov 1, 2021

I work at Augury, a machine health company that predicts the health of machines.

But behind this excellent title, we have lots of hardware and sensors installed on the client’s machines. These sensors (named EP’s) send raw data to the cloud, where our AI engine kicks in. The AI engine extracts specific features related to our domain and sends them further down the pipeline.

So yeah, basically, it’s an IoT company.
We have thousands of thousands of edge devices installed all over the world. We are sending data to the cloud 24/7 consitsts of a timestamp which is essential for keeping track of the feature’s time sequence.

You see, I’m also a maker; I love making cool stuff.
While at it, I always try to solve/learn/overcome challenges I meet during day-to-day life.

So I’ve built this cool color-changing-by-time-of-day LED lamp.

My smart lamp

To do so, I used:

For the project’s code, see my GitHub — SimpleSmartLamp

This smart lamp is an excellent example for today’s challenge — time synchronization

For the rest of this post, I’ll use my cool color-changing-by-time-of-day LED lamp to demonstrate the importance of time synchronization between edge devices.

Mostly Time synchronization use NTP servers

According to Wikipedia:
The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.

Using NTP, you can assure that your connected devices are time-synchronized up to a couple of milisecconds. No matter where they the distance between them!

Why should we care?

That’s an excellent question :)

You see, In my cool color-changing-by-time-of-day LED lamp, I’ve implemented an HourToHue mapping function that takes current time and returns the corresponding HUE value.

A note about HUE:
HUE represents the angle in the HSV color space.

HSV color space parameters
Mapping an hour to [-1,1]
I am using the mappedHour in the Gaussian curve function, with normal distribution parameters.

Step 3
I got a normalized value HUEnormalized in [0,1] that correlates to an hour in the day. All that is left is to calculate HUE:

HUE = HUEnormalized * 360

The Overall

I composed a HourToHue mapping function that receives hr in range [0,24] and return hue in range [0,360]:

HUE <- HourToHue(Current_hour)

Now;

let us say that the lamp is an IoT edge device.

I want to light up Ron weasely’s fantastic house with these lamps, which must light in the same HUE value. Thus they must be time-synchronized.

These lamps have no internal battery that helps keep track of time while disconnected from the internet or a power source. Adding such hardware is easy but will raise costs (And I love to get the job done at the lowest price).

So I faced a challenge here, folks:

Synchronizing the lamps to each other, they’ll keep track of the same time, thus making the same color.

I could mesh things up and maintain dynamic primary/secondary assignments between the lamps so that all lamps will synchronize themselves to the currently active primary lamp:

But why?

By design, these lamps are connected to the internet, and we have freely accessible NTP servers. An intelligent, dynamic mesh-like architecture is a design overkill.

Moreover, I like to KISS :)

A better, more agile, easy to maintain, and debug solution will be to use the cloud as a place for shared functionality and heavy calculations. That way, my super-calculation-complexed HourToHue(Current_hour) function will be placed in the cloud, and all the lamp’s left is to call this function with its current timestamp, something like that:

Leaving the heavy calculation elsewhere grants me the opportunity to use an even cheaper yet reliable enough board, lowering, even more, the lamp’s price!. And, using NTP, I can synchronize all the lamps to track the same time; all they have left is to call the HourToHue(myCurrentTime) in the cloud.

Augury EP’s also use this surprisingly straightforward solution, with all of our tens of thousand Edge-devices scattered all over the planet, synchronized using NTP (give or take some milisec’s);

There’s no sea too rough, no muff too tough for these bad boys

So, instead of Ron’s house, we have machines grouping EP’s. We don’t mind at what time a machine’s health started to deteriorate. All we need is that EP’s on the same machine (e.g., Ron weasely’s house) will send data having the same timestamp.

All we need is a synchronized timestamp between EP’s, and well get the job done :)

Counting on correct time serialization, our AI engine will extract features from multiple EP’s (grouped by a machine), resembling its actual physical state. And label events regarding this machine.

And that’s the way the cookie crumbles.
Cheers,
Gal

--

--