feature article
Subscribe Now

Network Timing in Your Car

Of Oscillators and IEEE 1588

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:

SiTime Automotive Oscillators

 

Leave a Reply

featured blogs
Jun 5, 2020
'€œYou'€™ll know it when you see it.'€ Have you had that moment where you know what you want but don'€™t know what it is? So you start looking around the store, the internet, or your house to find it. To help you find those '€œknow it when you see it'€ solutions...
Jun 4, 2020
[From the last episode: We started this new with a broad introduction to machine learning.] While neuromorphic neural networks '€“ that is, ones that work the way our brains work '€“ may still be off in the future a ways, someone came up with a different way to emulate th...
Jun 2, 2020
It just struck me that I have only 37 years remaining to complete my Countdown Timer project before it becomes superfluous to requirements....

Featured Video

DesignWare 112G Ethernet PHY IP Insertion Loss Capabilities

Sponsored by Synopsys

This video shows the performance results of the Synopsys 112G PHY receiver to varying amounts of channel insertion loss. The IP meets the standards requirements. With leading power, performance, and area, the IP is available in a range of FinFET processes for high-performance.

Click here for more information

Featured Paper

Why Does It Take a Pandemic to Realize the Value of Remote Patient Monitoring?

Sponsored by Maxim Integrated

The headlines that COVID-19 are bringing to us each day serve to highlight the promise of remote patient monitoring. According to the U.S. Centers for Disease Control and Prevention, 6 in 10 American adults live with at least one chronic disease and 4 in 10 adults have two or more. The time is now to embrace and accelerate the deployment of remote patient monitoring to ensure that chronic conditions are managed in a way that can improve outcomes and reduce the need for regular healthcare facility visits.

Click here to download the whitepaper

Featured Chalk Talk

Selecting the Right MOSFET: BLDC Motor Control in Battery Applications

Sponsored by Mouser Electronics and Nexperia

An increasing number of applications today rely on brushless motors, and that means we need smooth, efficient motor control. Choosing the right MOSFET can have a significant impact on the performance of your design. In this episode of Chalk Talk, Amelia Dalton chats with Tom Wolf of Nexperia about MOSFET requirements for brushless motor control, and how to chooser the right MOSFET for your design.

More information about Nexperia PSMN N-Channel MOSFETs