As I wrote in a recent blog, not knowing all the stuff I don’t know didn’t come easy. I’ve had to read a lot of books to get where I am today. This was in the context of a recently published book by Lawrence M. K. Krauss: The Known Unknowns: A Brief Account of What We Know and What We Don’t Know About the Cosmos. As I said in my blog, I was proud to discover that I already didn’t know pretty much all of Lawrence’s “Known Unknowns.”

The reason I mention this here is that I’m constantly discovering new things I don’t know. For example, I was just made aware about a feature pertaining to oven-controlled oscillators that I’d never really thought about. Furthermore, if I had thought about it, I’d have got it wrong. But I fear I might be in danger of leading us all into the weeds, so let’s come at this from a slightly different direction.

Do you recall my relatively recent column What Is Time, What Time Is It, and Why Do We Care? That column was sparked by my reading the Intel PTP Servo Solution for Time Synchronization Applications whitepaper in which I was introduced to some of the concepts involved in synchronizing packet-based networks. Suffice it to say that this involves the network nodes passing timestamped packets of data back and forth. These timestamps are used to determine and correct any errors between the prime clock (a.k.a. Universal Clock, a.k.a. “Grand Master Clock”) and any downstream clocks.

Consider a 5G radio access network (RAN), for example. Every node (router, server, switch…) in the network must be synchronized to maintain the fastest possible data throughput, reliability, and uptime.

Every infrastructure node must be time-synchronized (Source: SiTime)

What is sometimes overlooked by people like your humble narrator (I pride myself on my humility) is that every node must include its own oscillator that it uses to maintain its local time-of-day (ToD) value. It is this value that the node uses in its timestamps, it is this value that is constantly being reevaluated in the context of the prime clock, and it is this value that the node must rely on should it happen to lose access to its upstream reference clock source for any reason, in which case the node is said to be running in a “holdover mode.”

What sort of holdover accuracy are we talking about here? Well, for 5G base station infrastructure, network operators usually aim for ±1.5µs over 8 hours or more. Wowzers!

Actually, it’s reasonably easy to achieve this level of accuracy; all you need is to incorporate an atomic clock in each node (I didn’t say it was “cheap and easy”). However, if you want to add “affordable” and “realistic” into the equation, then your best choice to achieve a holdover of ±1.5µs over 8 hours is to use an oven-controlled oscillator (OCXO).

So, what exactly is an OXCO? Well, since you ask, this is probably the perfect time to introduce some oscillator-related terminology, which was kindly provided as part of a handy-dandy Epoch Platform MEMS-Based OCXOs FAQ by the nice folks at SiTime.

What is a Crystal? A crystal (X, XTAL) is a passive resonator that vibrates at a fixed frequency. It can be quartz crystal or MEMS-based. These devices are used as external timing references for semiconductor ICs with an integrated oscillator circuit (i.e., on-chip clock generation)

What is a Resonator? A resonator (X, XTAL) is a passive device that vibrates at a fixed frequency. It is sometimes referred to as crystal. It can be quartz crystal or MEMS-based. The resonator (or crystal) devices are used as external timing references for semiconductor ICs with an integrated oscillator circuit (i.e., on-chip clock generation).

What is an Oscillator? An oscillator is an active device that uses a resonator and an oscillation circuit to generate a clock signal. Basic crystal oscillators, XOs, are also known as OSC and SPXO in various geographies. Typical frequency stability variation over temperature of XOs is between ±10 and ±100 parts-per-million (ppm).

What is a TCXO? A TCXO is a temperature-compensated oscillator and is an active device. These devices typically have frequency stability of ±0.05 ppm to ±5 ppm over the operating temperature range. These devices are used in applications where precision timing references are required, such as high-performance telecom and networking equipment, including small cells, synchronous Ethernet, optical transports, and GNSS modules.

What is an OCXO? OCXO stands for oven-controlled oscillator. These devices have very high stability, typically better than ±50 ppb, and more commonly in the range of ±0.5 to ±20 ppb. OCXOs achieve high stability by encasing the crystal along with temperature-sensing and compensation circuits inside a heated metal enclosure to create an oven with a relative constant temperature. A double-oven OCXO (an oven inside another oven) can reach <±0.5 ppb stability.

In my MEMS Oscillators Address Precision Timing Problems column earlier this year, we discussed how MEMS-based TCXOs from SiTime can out-perform quartz-based OXCOs. So, can you imagine how well MEMS-based OCXOs from SiTime can perform? Fortunately, there’s no need for you to imagine because I’m just about to tell you.

The reason I’m so flush with information is that I was just chatting with Piyush Sevalia, who is Executive Vice President of Marketing at SiTime. The first thing Piyush told me that I didn’t already know was that legacy quartz OCXOs have been around since 1929. I have to say that I’m amazed to hear that folks were using OCXOs that far back.

Piyush also informed me that quartz OCXOs have a bunch of different issues that the folks at SiTime hear about from their customers. These issues include inconsistencies from batch to batch, poor performance in the presence of environmental disturbances, and the fact that they are power hungry because you’re building an oven inside a big can package. Speaking of these packages, the construction of the quartz-based version is complex, and there are a lot of things that go into building the packages that make these devices prone to failure, especially failure in the field (sad face).

To address these issues, SiTime recently introduced its Epoch Platform. This bodacious beauty is a MEMS-based OCXO that delivers an ultra-stable clock for use in datacenter and network infrastructure equipment.

Epoch Platform MEMS OCXO transforms ultra-stable timing (Source: SiTime)

This is when we ran into the thing I’d never really thought about before. I already understood the concept that one could maintain timing accuracy and stability by presenting the oscillator in its own little oven and by using the oven to maintain a constant temperature. What I hadn’t really thought about was that all an oven can do is heat things up—it can’t cool things down. In turn, this means the oven must be hotter than the surrounding environment if you don’t want your timing to go pear-shaped, as it were. All this was brought home to me when Piyush made mention of the fact that “the Epoch Platform’s oven can maintain a temperature of up to ninety-five degrees.”

“Hmmm,” I thought, “that’s not very reassuring.” I immediately pointed out that we reached well over 100°F several times this summer here in Huntsville, Alabama. Also, if we’re talking about doing this for infrastructure like radio towers for 5G communications, then we’ve been seeing temperatures as high as 118°F in Phoenix, Arizona, this summer. “Ah ha!” Piyush responded, “I was talking about 95°C, not 95°F.”

Well, since 95°C is greater than 200°F, that’s a completely different marmite de poisson (“kettle of fish”). If the temperature around me rises to 200°F, then the timing integrity associated with my 5G phone calls will be the least of my worries.

Let’s take a brief look at the feature set provided by Epoch Platform MEMS OCXOs as summarized below.

Epoch Platform MEMS OCXO feature set (Source: SiTime)

To be honest, a lot of these numbers are over my head, although I have no doubt that the folks implementing timing for things like 5G infrastructure will squeal with delight like… well, things that squeal in high-pitched voices. On the other hand, even though I don’t understand all the numbers per se, I can certainly see the difference when compared to a quartz OCXO using a spider chart (a.k.a. cobweb chart, a.k.a. radar chart).

MEMS vs. Quartz OCXO spider chart comparison (Source: SiTime)

I love this form of presentation, but I’d never thought to wonder who came up with it in the first place… until now. I just had a Google while no one was looking to discover that the inventor of this family of charts was a German Professor of Mathematics and Astronomy called Georg von Mayr. Georg published the first known chart of this ilk in 1877.

Bearing all this in mind, let’s return to the infrastructure example we saw earlier, but this time let’s include all the nodes that would benefit from the use of Epoch Platform MEMS OCXOs.

OCXOs are used as local time sources across network infrastructure (Source: SiTime)

According to SiTime, having MEMS-based OCXOs like the Epoch Platform that can deliver an ultra-stable clock to datacenter and network infrastructure equipment will unlock a cumulative $2 billion served addressable market (SAM) in the next decade. Over time, Epoch technology will be extended to other high-growth electronics markets, such as aerospace and defense, industrial controls, and more.

Well, I for one am very impressed. Meanwhile, you for one can be grateful that I didn’t bombard you with the myriad graphics, tables, and charts comparing legacy quartz OXCOs to SiTime’s Epoch Platform MEMS-based OCXOs with which Piyush cheerfully battered my poor old noggin. I now wake up in the middle of the night muttering things like “Epoch is 2X to 10X better on ΔF/ΔT and 3X to 10X more resistant to airflow, both of which enable better holdover!” On the bright side, this is one of the very few topics my wife (Gina the Gorgeous) doesn’t feel moved to correct me about, especially at three o’clock in the morning. How about you? Do you have any thoughts you’d care to share in the comments below?