Keeping time 3: Accuracy

To keep clock in time, there needs to be a timing source. In case of embedded systems, the most typical is 32768 Hz clock crystal (why 32768? For any programmer worth their pay, this is obvious, but that happens to be nice power of 2; 2^15 to be exact. And due to how digital systems work, powers of two use least amount of energy, giving optimal battery life).

The datasheet of the clock chip you're using will specify the required frequency and load capacitance needed for clock functionality. If the frequency is 32768 Hz, you're almost there; there are many different types of crystals to choose from. Then you'll only need to pick one with correct load capacitance and fine tune the circuit.

Furthermore, datasheet of the RTC chip will specify a circuit (something like one below) that should be used and the load capacitance required for proper function. Datasheets of clock crystals specify their load capacitance. So just pick ones that match, right?

Unfortunately that isn't that easy. In some cases this works directly (typically with chips that are specifically tuned for one type of crystal), sometimes they work but are inaccurate, and sometimes oscillator completely fails to oscillate. And only way to find out is to test the circuit in practice.

The arrangement below is just about the most complex one you might encounter, as specified by datasheet of a Microchip PIC24 MCU. The values for resistors and capacitors can be approximated (or even guessed), but for best results, you'll have to test them in practice.

Typically resistor R110 is not needed, and R67 can work as 0 ohm resistor (or short) - if in doubt, you may use above 100k as first guess (try 10k or 1k or even short if oscillator doesn't start). For the capacitors - C109 and C110 here - a good starting value might be around 10pF for both. These are the most critical passives, as they set the accuracy of your clock (and, with some chip/crystal combinations, they're not needed at all as chip and crystal just are tuned well enough already.)

Unfortunately this cannot be tested on bread- or prototyping board; it has to be the circuit board you are going to use in production. This is because the capacitances in circuit are so small; different board layout, with its stray capacitances will be enough to throw testing way off. But worry not; just make room for the components, make educated initial guess and start testing. (just be aware that even if you find out that you don't need some of the components there - resistors most likely - the capacitance of circuit will be changed just by removing the pads for them. Re-test with every change of board layout!)

Set time on your chip (careful! you'll need very good reference time here for this to work. Fortunately web is full of those these days). Let it run and come back few days later. Check how badly clocks had drifted, and correct circuit accordingly. If it runs fast, make capacitors bigger (10pF -> 12pF or 15pF). If it runs slow, make then smaller (10pF -> 8pF or 6pF). Repeat and adapt, until you get close enough.

The problem is that unless you have very, very good way of setting and getting time out of the chip, this takes time. Typical crystals - and thus your target accuracy - are 10 or 20 ppm range; in practice, this means 12 seconds of drift per week - or less than 2 seconds per day. Accurately timing this kind of short time periods with manual methods is practically impossible. Thus, when you get close enough, you'll need to let system run for long periods before checking the results.

This will take some time. Even many, many weeks of trial and error before you zero on correct capacitances. Unfortunately, there really isn't much better way to do this, especially for your first attempt.

Good hunting.

Keeping time 2: Capacitors?

In previous post I talked about ways how you can make your embedded design to keep time, even when not powered.

Mostly I spoke of coin cell batteries as backup source. There is also other options, most common being capacitors and super- or ultracapacitors, and possibly some others. I'll just ignore bigger lithium- and other larger batteries here, since those generally imply that your device is primarily powered from that battery and thus the same battery will be used to keep time when device is "off", or minimal power drain mode.

There are pros and cons with each type of energy storage. The short list, as I see it;

• Large batteries (Li-ion and others): large, expensive, require charging circuitry. Not great for backup supply (these usually have tendency to self-discharge at certain rate), but this is the choice when you want your design to operate fully without external power.
• Lithium coin cells and equivalents: relatively small and inexpensive and they carry lots of energy to keep your clock ticking, up to several years without external powers. Bad side is that they are expensive (if you use them wrong, i.e. waste their power), must be replaced (if you allow them to run empty) and can't really power up your entire design - unless it's very - no, ultra-low power (like TI's MSP430-series)
• Super/ultracapacitors. Compact ones (in millifarad range) can keep your clock running for several days or up to a week or so, and are essentially infinitely rechargeable. So if you expect your product to encounter few days of power outage (but not much longer) occasionally, these might be enough.
• Electrolytic capacitors, few hundreds of microfarads or so. The can keep your clock running for several hours, so useful for common, but short breaks, and they are also very cheap.
• MLCCs - that is, ceramic multilayer caps; tens of microfarads. Now we are down to tens of minutes, but for common but short breaks they will be enough - and they're very cheap too.
• None at all. If your design is connected, you might be able to get away with device fetching current time on startup from internet or other such place. This means that it will take a while (connection latency) before your clock is in time again, and this is assuming that your device can fetch the time when it powers back up immediately.

The times I mention above are very rough estimates, and depend highly on the energy capacity of the power source you are using and power drain of your clock. For your design, you'll just have to read the datasheets (very carefully, as the most important information tends to be hidden away - again, a topic for another day) and do the energy math for yourself.

Keeping time 1: Keep it running

Having an accurate clock is one of the potentially most annoying problems you can have with embedded electronics. Not least because of the inaccuracy of typical oscillators you might want to use, but there is also the issue with powering the clock all the time.

I do remember the first time I thought of this. It was something like this, thoughts in my head;
"Clock sure would be useful here, but what of power outages... Oh, I know! I'll store the time in the EEPROM and when the power resumes... Oh, wait, damn..."

But back to this day. Let's start with the oscillator first, and with assumption you want to do the device on a budget - fairly minimal BOM cost. Mind you, unless you are expecting production runs in millions of units, you really should not aim for minimum-cost BOM. The minimum monetary cost will cost you dearly in other fronts. But that is completely different topic so I'll just ignore it here.

I'll skip a bit. I'll assume that you've worked out that you want to have a clock, and it would be really nice if it kept time when when device itself is unpowered (meaning, without mains or whatever your primary power source is) too.

So right, here is, for example, a PIC24 processor, let's say PIC24FJ64GB106 (because I happened to have a few). Faily cheap 16-bit MCU with pretty nice peripheral devices in it. Comes with RTC (Real-time clock) and everything. Except this one isn't really built for this kind of use. The RTC doesn't run without power, and there is no back-up battery supply possibility. Meaning that the MCU must be fully powered from some kind of battery all the time when not connected to mains. Not exactly great if you want to clock to run from, say, small coin-cell battery for months and months.

Mind you, there are plenty of power saving options on the MCU, bringing the quiescent current draw to fairly low levels, but from design point of view, this isn't greatest option, and you'll need to take care of all the other circuitry too when in low-power mode, including safe and uninterrupted switch between mains and battery power.

So let's go for next best option. There are external RTC chips available - let's just mention MCP79400 as an example, because it is from Microchip too and was first item listen on their RTC page. This makes things somewhat easier. Separate Vsupply and Vbat lines - meaning that you can just connect battery to Vbat and essentially forget about it - chip will take care of those nasty power switching issues when mains goes off and on again. You'll only need to add clock crystal there and communicate with it via I2C bus. Simple and easy design, although it'll raise your BOM cost slightly. And these chips are designed to be low-power, meaning that simple 3v coil-cell battery will keep it running for a year - or ten, depending on chip you'll choose. Simply great if your device may be disconnected for extended periods between uses.

Or, in case you are already planning to have a bit beefier MCU, you could pick for example STM32F4-series MCU, which has RTC and external battery supply included. This MCU will consume a bit more power than dedicated clock chip, but in practice this means mostly that instead of 5 years of running with small coin cell battery, you get "only" 2-3 years. Whether this is an issue depends on your design, naturally.

There is really no single superior strategy, it's all about balancing your design constraints.

Next time: Capacitors?