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
Sep 25, 2020
What do you think about earphone-style electroencephalography sensors that would allow your boss to monitor your brainwaves and collect your brain data while you are at work?...
Sep 25, 2020
Weird weather is one the things making 2020 memorable. As I look my home office window (WFH – yet another 2020 “thing”!), it feels like mid-summer in late September. In some places like Key West or Palm Springs, that is normal. In Pennsylvania, it is not. My...
Sep 25, 2020
[From the last episode: We looked at different ways of accessing a single bit in a memory, including the use of multiplexors.] Today we'€™re going to look more specifically at memory cells '€“ these things we'€™ve been calling bit cells. We mentioned that there are many...
Sep 25, 2020
Normally, in May, I'd have been off to Unterschleißheim, a suburb of Munich where historically we've held what used to be called CDNLive EMEA. We renamed this CadenceLIVE Europe and... [[ Click on the title to access the full blog on the Cadence Community site...

Featured Video

Product Update: PVT Monitor IP

Sponsored by Synopsys

Join Rupal Gandhi to learn about silicon-proven process monitors and voltage/temperature sensor IP from Synopsys. PVT monitors provide real-time feedback to SoC designers.

Click here for more information about DesignWare Foundation IP: Embedded Memories, Logic Libraries & GPIO

Featured Paper

The Cryptography Handbook

Sponsored by Maxim Integrated

The Cryptography Handbook is designed to be a quick study guide for a product development engineer, taking an engineering rather than theoretical approach. In this series, we start with a general overview and then define the characteristics of a secure cryptographic system. We then describe various cryptographic concepts and provide an implementation-centric explanation of physically unclonable function (PUF) technology. We hope that this approach will give the busy engineer a quick understanding of the basic concepts of cryptography and provide a relatively fast way to integrate security in his/her design.

Click here to download the whitepaper

featured chalk talk

RF Interconnect for 12G-SDI Broadcast Applications

Sponsored by Mouser Electronics and Amphenol RF

Today’s 4K and emerging 8K video standards require an enormous amount of bandwidth. And, with all that bandwidth, there are new demands on our interconnects. In this episode of Chalk Talk, Amelia Dalton chats with Mike Comer and Ron Orban of Amphenol RF about the evolution of broadcast technology and the latest interconnect solutions that are required to meet these new demands.

Click here for more information about Amphenol RF Adapters & Cable Assemblies for Broadcast