Why You Should Follow These Best Practices In Real Time Clock Design

Created: July 31, 2017
Updated: March 16, 2020

Electrical components on a PCB


Have you ever been late for school because your alarm clock decided to stop at 3.15 AM? In high school, my alarm clock wasn’t very pleasant sounding, but the sound of my mom shouting at me was worse. I knew that my clock had stopped because its battery was dead. However, had I paid closer attention, I would have noticed that my clock ran slower as the battery drained off. That way I could have changed it in time and avoided rising to my mom’s shrill voice. Now that I’m all grown up, I’m more focused on Real Time Clock (RTC) design, instead of school days alarm clocks. RTCs are usually integrated circuits (IC) that keep track of the current time against a set standard. RTCs are generally designed to continue running after the main system is powered down and consume minimal power. If your system’s RTC fails, the consequences are higher than a harsh scolding from your mom. Let’s look at why they are important and what best practices can keep you out of detention.


Why RTCs are important in embedded systems

Hand using keycard to open digital lock

Your HR Will Hate It When The Time Got Messed Up


Almost any data-driven and time sensitive embedded system features an RTC. They rely on the accuracy of the date and time to perform specific actions. For example, a door security system may activate different access priorities based on the time configured. A fault in the RTC can result in doors that refuse to open when activated at the right time zone.


Besides that, an RTC is critical in embedded systems that record events and alarms that are intended to be a reliable audit trail. For example, an attendance management system where HR departments track the employees on their reported date and time, or a fire alarm system that needs to keep a record of alarm events.


Failing to implement good practices in RTC design can be expensive, especially if the controllers have been deployed in the field. In one of my previous job, a batch of standalone payment controllers for a parking system developed a problem with their RTC. It gradually ran slower than the actual time. This lead to angry customers who had received the wrong parking rates.


Common RTC Design Mistakes You Should Avoid

Designing an RTC circuitry may seem like a simple task since it usually involves 5 components. You’ll have a dedicated RTC chip or a built in RTC on a microcontroller, a crystal, a couple of capacitors and a coin cell battery. I’ve made it a best practice to always follow these design guidelines:


1. Keep the crystal as close as possible to the RTC and keep the trace as short as you can. It will reduce the possibility of noise coupling.


2. Do not route any other trace in between or under the trace between RTC and the crystal. This will prevent unwanted interference being coupled into the clocking signal.


3. Do not route any high-speed signals within the vicinity of the RTC circuitry. It is recommended to keep a distance of 200 mil in between.


4.Place a ground plane beneath and surrounding the RTC circuitry and keep it isolated from other ground planes for at least 40 mil.


5. Make sure that you are using the correct value for the crystal load capacitors as specified in the datasheet for the crystal.


Why Some RTC Design Mistakes Escape Lab Testing

Making mistakes in RTC design can result in symptoms like the time ticking slower or faster than the actual time. In some cases, the symptoms are very obvious in the design stage and can be immediately fixed in the prototype. But sometimes these problems escape lab testing and only show up in the live application.


This was the case with the payment controllers, they functioned well in our lab. However, when we were woken up by the shouts of angry customers, we did some troubleshooting on the devices. In our lab, we have close to an ideal electrical environment, and at sites, it is common to have a noisy power network. This can be electrical noises coupled from other equipment or improper grounding on the building itself. Once our controllers were deployed, this noise was channeled through a lesser grade power supply, through a voltage trace on the PCB that runs between the traces connecting the crystal to the RTC, and into the RTC clocking signal. This signal is typically a square wave that oscillates at 32.768 kHz, and a disruption to it will skew the accuracy of the RTC, which is exactly what we saw.


PCB being repaired
You wouldn’t want to go through manual rework for hundreds of PCBs.


What Can You Do If You Have Post Deployment RTC Problems

Unfortunately, there are no elegant quick fixed when you have messed up your RTC design and the products are already deployed on the field. In some cases, you can design a small RTC module and manually rewire the controller to the new working module.


In situations where your devices are tightly fitted into enclosures or are mass produced consumer products. These reworks are impossible to perform. In this case, you will have to produce a new batch of replacement units that have a functional RTC.


Either situation is going to cost your company time, money and reputation. It is better to be safe than sorry when it comes to designing RTC circuitry. One thing that will save you money long term is good PCB design software, like Altium’s CircuitStudio. Also, you can check out our other best practices in PCB design to prevent post deployment issues on our blog.

Have any more questions about RTC design? Contact an expert at Altium.

most recent articles

Back to Home