It’s a quaint tradition, born out of decades of action thrillers summoning teams of protagonists to execute some very precise (and unlikely) plan. As the caper commences, before they disperse, they execute the final ritual: synchronizing watches.
Seems silly these days; quartz and electronics have long ago given us watches that keep excellent time, with no need for constant resetting. What with cell phones doubling as watches, our timing is even better coordinated.
But that last step isn’t simply one of better electronics: for most of us, it represents the availability of a master clock. Anybody here remember dialing POP-CORN? Why back in my day, that was the master clock. Today, we can get the time from our cell phone network. All the adventure is gone…
As it turns out, however, we still have situations where different nodes in a network will operate mostly independently of each other, but will need to share a sense of what time it is. They may not lead a dramatic Mission Impossible life, and they darn sure won’t attract an audience to watch them operate, but a lot of what we take for granted depends on this ability to synchronize systems.
The high-level issue here is one of automata (for lack of a better hundred-dollar word) that work independently of each other, and yet need to coordinate time without the benefit of a precise central master clock. Or so it would seem until you ask a few questions and learn that it’s not quite as simple as all that. So let’s back up and set some context.
This all came up in a conversation with SiTime about new oscillator offerings addressing the rather demanding needs of automotive applications. The discussion touched on a network timing standard, IEEE 1588, and its potential appearance in automotive applications.
This standard, to oversimplify things, is what gets different points on a network to agree on what time it is. So, obviously, as a timing issue, it seems relevant to a discussion about oscillators and such. Except for this: the adjustments made on any node to synch up with the rest of the nodes are going to be large jumps as compared to the minute phase perturbations of an oscillator. So why in the heck would tight oscillator specs have anything to do with supporting 1588?
I posed the question to SiTime, and the response from their Jeff Gao took me far afield from cars. In fact, cellular folks will find this to be familiar territory, even if it is newer to automotive. The big-picture context would be this: each node’s local clock, on its own, will have a tendency to drift. In fact, more than a tendency: it will drift, guaranteed, when compared to any other independent clock, no matter how accurate. It’s just a question of how fast it will drift.
When drift takes the local clock too far afield, then IEEE 1588 lets you make a quick adjustment to get back into spec. So you can think of each node as noodling along, but, every now and then, needing to “slip a notch,” giving up or gaining an extra cycle to stay in synch.
For this to work, you need a reference of some sort so that you know if you’ve drifted. Ideally, every node should work on that same reference. In practice, it’s not quite so simple. Using the mobile network as an example, a given cell would look to GPS for very high accuracy – but poor reliability. So a second source could be a Synchronous Ethernet (SyncE) signal, which provides a backup reference that’s more reliable but less accurate.
Locally, you have an oscillator that provides good phase stability. And phase stability holds a prominent position in this whole timing scheme. So you can use that oscillator both as the local clock and to recover the GPS or SyncE clock.
But there’s a second part to this: what if you lose the reference signals for some reason? Are you dead in the water? If you’ve played with PLLs before, you know that you treat them like a flywheel; an occasional nudge will keep the thing spinning merrily along. If you stop nudging, it will keep spinning – for a while, until it “loses lock.”
So here we have a higher-level flywheel – and the question is, if you lose the reference, how long can you keep going before you drift out of spec? Turns out this has a name: holdover. And there are specs that establish what grade of oscillator is required for a given level of holdover. We’re not talking milliseconds here; we’re talking human time – a half hour, an hour, even as long as a month.
Using quartz, the only way to get to the level of stability required for cellular timing is to take control of the temperature using oven-controlled oscillators. These guys are fussy and expensive and require a 24-hour temperature soak before they’re good to go. This is an area where SiTime says their 100 ppb MEMS oscillators can compete with the oven-controlled quartz units on select critical parameters, if not across the board.
So what happens if we end up with 1588 running the timing on our in-car network? This is a newer application – especially car-to-car – so it’s an active area of work. Are we going to need precision at the level of the cellular network? I sure hope not, because I don’t want to have to do a 24-hour soak before I can drive. And we don’t need ECUs to keep running independently for a month. Looking at the stability specs for the oscillators that SiTime has offered up for automotive shows stability in the 10s of ppm rather than ppb levels, so that’s encouraging.
As it turns out, I received a last-minute (or later-than-last-minute) clarification that, our discussion notwithstanding, the announced automotive devices can’t, in fact, manage 1588 – because they don’t have that elevated level of precision. Automotive versions of the Elite family would be needed, which haven’t been announced. So… yeah, that was unexpected. The just-announced devices are intended only for the more mundane tasks of ADAS, ECUs, and infotainment.
High precision or not, what distinguishes an automotive oscillator, of course, is the need to withstand the rigors of the road. Depending on where a unit is located, temperatures could be high, and they may change quickly. Same goes for vibrations and shock.
And the package? If it has leads, your mechanic can see and probe the connections. With a leadless package, you need an X-ray unit to check the connections. You can guess which one your mechanic is going to prefer.
So yes, the same standard that helps keep the cell system humming along may well keep the engine humming as well [edit: sometime in the future]. Minus the dropped calls, presumably.
More info:
