Tinkering with Time

Protocols and Programming

Many embedded systems need to make use of synchronized time information. In this article, Jeff explores the history of time measurement and how it has led to NTP and other modern technologies for coordinating universal date and time. Using Arduino and the Espressif System’s ESP32, Jeff then goes through the steps needed to enable an embedded system to request, retrieve and display the synchronized date and time to a display.
(Caption for lead image Figure 1: Time zone boundaries are flexible, shifted locally to keep territories from being divided wherever possible..

By Jeff Bachiochi

It’s been said that ”If you are on time, you’re late,” or, “To be early is to be on time.” It’s all relative. If you go to a meeting and people are already there, you feel as if you are late. If you are the first to arrive, you wonder if you’ve got the schedule wrong, and then you check your watch or phone for the time. Time can be troublesome for us, because the present is an ever-changing instant where the past meets the future. We cruise through life when all players reference the same moment, but should we become out of sync, the ride gets bumpy.

We can imagine that in humanity’s early times the first concepts of time were cyclic periods—like day/night, seasons and life/death. Our fundamental measurement of a day directly relates to our life and history, and seems to tie all nature together. But what about those activities that occur within the confines of each day? Some way of defining the parts of a day were needed. At the time, we had one division—day/night—with most considering the start of a day to be daybreak or sunrise, and the start of night to be sunset.

Since daytime was directly related to the sun’s position, the day could be divided into two parts based on whether the sun was rising in the sky or falling back toward the horizon. Observing the sun’s shadow gave way to the first sundials, which provided a visual indication of time relative to sunrise and sunset without physical divisions. One such division of the day was religious in origin: canonical hours or periods of fixed prayer at regular intervals were defined in monastic communities. At that time, our understanding of the sky was astrological and not astronomical. The latter would eventually define the breakdown of a day into hours, minutes and seconds.

For the most part, the hour was a variable concept. Around the 14th century, 12 was chosen as a practical division of the day (and the night) into equal parts. It was the most convenient number for dividing into fractions because it’s divisible by 2, 3 and 4—thus giving us the 24-hour day we use today. Without the sun, sundials were worthless, so other means of recording the passage of time were invented, including water, candles and weights. These and early mechanical clocks of the 16th century were not accurate, because their mechanisms were essentially unregulated. It wasn’t until the next century that the pendulum gave the mechanical clock accuracy to within 1 minute a day. Today, we have access to extremely accurate clocks. Atomic clocks measure an atom’s fluctuating energy levels to produce an accuracy of ± 1 second in over a billion years.

Time Keeper

The International Bureau of Weights and Measures (called Bureau International des Poids et Mesures or BIPM in France) is an intergovernmental organization that was established to oversee measurement science and measurement standards. One important role for the BIPM is maintaining the accuracy of worldwide time of day. It combines, analyzes and averages the official atomic time standards of member nations around the world, to create a single, official Coordinated Universal Time (UTC). The Royal Observatory, Greenwich, England was chosen as the reference point to define the Universal day, counted from 0 hours at mean midnight, as used on the island since 1847. By 1884, the Greenwich Meridian was used for two-thirds of all charts and maps as their Prime Meridian. The world is divided into 24 time zones, each 15 degrees in width (24 hr/360 degrees). However, as shown in Figure 1, time zone boundaries are shifted to prevent a country from being needlessly split into separate zones.

All time on earth is related to the official time in Greenwich, England by denoting a time zone offset. Current civil time can be determined by adding or subtracting the UTC offset (number of hours and minutes). This ranges from UTC−12:00 in the west to UTC+14:00 in the east. Table 1 lists those offsets that relate to the United States.
The US spans seven time zones. When a time zone uses daylight saving time, the ST for Standard Time is replaced by DT indicating Daylight Saving Time. Daylight Saving Time increases the regional offset by 1:00, and was implemented to shift daylight activities during the longer summer hours. Daylight Saving Time is a local shift that must be handled locally, and as such does not affect the UTC in any way.

Table 1
Time zone offsets are listed here for the US daylight saving times have an additional offset of 1 hour and must be accounted for locally.

In my youth I recall the phone company providing a number you could to call to hear the current time. The first radio station, WWV in Colorado, morphed into National Institute of Standards and Technology (NIST), whose broadcast focused on developing frequency standards and eventually broadcasting time and frequency information on the 2.5-, 5-, 10-, 15- and 20-MHz shortwave bands. Today, the time is available almost everywhere, and that time is synchronized to the UTC, all thanks to the Internet.

National Standard Time

The Network Time Protocol (NTP) is used to synchronize our clocks via the Internet. The NTP architecture, protocol and algorithms provide a nominal accuracy of tens of milliseconds on WANs, sub-milliseconds on LANs, and sub-microseconds using a precision time source such as a cesium oscillator or GPS receiver. Reliability is assured by redundant tiered servers and diverse network paths. The “NTP pool” is a dynamic collection of networked computers that volunteer to provide highly accurate time via the NTP to clients (like us) worldwide. We can use one of the NTP pool servers to get UTC information. Although using the NTP protocol will assure the accuracies listed above, this is often unnecessary and overly complicated for those applications that are only interested in whole-second times for RTC (Real Time Clocks). SNTP, a simplified subset of the NTP protocol, generally is sufficient for our needs.

Figure 2
This is the format of the 48 byte packet sent to and from NTP servers. We can get away with sending a packet of “zero” data, except for the first byte as a request. A received packet will contain the total seconds since the Epoch located in the first four bytes of the Transmit Timestamp.

SNTP uses a UDP connection to send a datagram or packet, as opposed to a TCP connection. The basic transaction is simple. We send an SNTP data structure as a UDP packet using port 123 to the server. The time server (one of the NTP pool) then sends back an SNTP data structure as a UDP packet. That’s it! The structure of the datagram consists of four 32-bit words (4 × 32 bits = 128 bits or 16 bytes), followed by four 64-bit time stamps (4 × 64 bits = 256 b or 32 bytes) as shown in Figure 2. There can be optional data, but we won’t need it. In fact, we need only to worry about the first byte of the (16 bytes + 32 bytes = 48 bytes) datagram to make a request.

This is set according to RFC 4330:

LeapsecondInformation 2 bits = “00” disregarded
             VersionNumber 3 bits = “100” 4
                        MODE 3 bits = “011” Client
First Byte = “00100011” or 0x23

The returned datagram will be in the same format. The time stamps we sent as zeros could have been used to determine the actual propagation delay in the message trip, to calculate an accurate sub-second synchronized time. We are not concerned with that level of accuracy. However, we do want to get the time from the server, and that will be populated in the last of the four time stamps in the reply. So how does this time stamp relate to the present second, minute, hour, day, month and year? Sad to say, it does not specify any of those. This time stamp gives the number of seconds from 0:00 on 1 January 1900. …

Read the full article in the February 343 issue of Circuit Cellar
(Full article word count: 3269 words; Figure count: 5 Figures.)

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

ARM-based SoC Targets Net Acceleration

NXP Semiconductors has announced the highest performance member of its Layerscape family, the LX2160A SoC. The LX2160A is specifically designed to enable challenging high-performance network applications, network edge compute, and data center offloads. Trusted and secure execution of virtualized cloud workloads at the edge is driving new distributed computing paradigms.

LX2160AThe LX2160A features sixteen high-performance Arm Cortex-A72 cores running at over 2 GHz in a sub 30 W power envelope, supporting both the 100 Gbit/s Ethernet and PCIe Gen4 interconnect standards. In addition, it provides L2 switching at wire rate and includes acceleration for data compression and 50 Gbit/s IPSec cryptography.

NXP supports and drives the rich ARM ecosystem for virtualization, building on the foundations of open source projects for cloud and network function virtualization including Open Daylight, OpenStack, and OP-NFV. NXP Arm processors incorporate hardware for virtualization technologies such as KVM and Linux containers and hardware acceleration of network virtualization. NXP also supports industry-standard APIs for virtualization, including DPDK, OVS, and Virtio, and standard enterprise Linux distributions, such as Debian and Ubuntu. Silicon samples and a reference board will be available in Q1 2018.

NXP Semiconductors | www.nxp.com

High-Speed RS-485 Transceivers Target IIoT Networks

Intersil, a subsidiary of Renesas Electronics, has announced two new high-speed, isolated RS-485 differential bus transceivers that provide 40 Mbps bidirectional data communication for Industrial Internet of Things (IIoT) networks. The ISL32741E offers 1,000 VRMS working voltage and 6 kV of reinforced isolation, more than 2x higher than Intersil isl32740e-41e-transceiver-promocompetitive solutions. The higher working voltage and reinforced isolation is required for today’s most rigorous medical and high-speed motor control applications. The ISL32740E with 2.5kV of isolation and 600VRMS working voltage comes in a small package, enabling high channel density for programmable logic controllers (PLCs) in factory automation applications.

The ISL3274xE transceivers provide additional advantages over other isolation technologies, including ultra-low radiated emission and EMI susceptibility, support for up to 160 devices on the bus, and an extended 125°C temperature range. These devices leverage giant magneto-resistance (GMR) technology that provides galvanic isolation to keep the communication bus free from common-mode noise generated in electrically noisy factory and building automation environments. The ISL32740E and ISL32741E 40 Mbps RS-485 transceivers are available now with prices ranging from $3.79 to $4.79 depending on package type and temperature range. Evaluation boards are available for $99.

Intersil | www.intersil.com

Q&A: Networking Expert Dru Lavigne

Dru Lavigne wasn’t always interested in networking applications. I recently interviewed her about how she discovered UNIX and launched her career as an OS specialist and technical writer. She also described her “to-do” list, which includes more writing, and her hopes for the future of the BSD OS.—Nan Price, Associate Editor


Dru LavigneNAN: What is your current occupation?

DRU: I’m the lead tech writer for iXsystems, a hardware solutions provider and corporate sponsor of the FreeNAS and PC-BSD open-source projects. Since both of these projects publish a comprehensive user’s guide with each software release, most of my time is spent making sure each guide is kept up to date as changes are made to these OSes. I’m also involved in the FreeBSD Documentation Project and I am currently assisting in updating and preparing the FreeBSD Handbook for publication in a two-volume format.

NAN: What is the FreeBSD Foundation?

DRU: The FreeBSD Foundation is a 501.c3 nonprofit that provides financial support and a legal entity for the FreeBSD Project.

The FreeBSD Foundation provides grants so developers can attend conferences and developer summits, sponsors developers to work on specific software projects that would benefit the FreeBSD community, interacts with companies that use FreeBSD to determine their needs, and assists in introducing developers to the community. As a director, I assist in fundraising and advocacy, reviewing project proposals, and developing relationships.

NAN: What is BSD? What is the difference between BSD and Linux?

DRU: BSD is a UNIX-like OS that was originally developed at the University of California Berkeley in the 1970s. When the university stopped developing the OS, several open-source projects began to continue development.

Its lineage differs from Linux as Linux is derived from a different UNIX branch known as SysV. Traditionally, the most noticeable difference is that SysV systems use run levels whereas BSD systems do not. The release engineering process also differs between BSD and Linux. BSD projects release an entire OS with a set of base tools included in the OS’s userland. The entire OS has a release engineering team that is responsible for the release and a security team that is responsible for security advisories until a release reaches its end-of-life (EOL). In contrast, Linux itself is only the kernel. Each distro integrates that kernel into its installer, package management system, and userland to create a complete OS.

NAN: How long have you been using BSD? When and how did you become interested?

DRU: I started using FreeBSD in 1997. I went “cold turkey” by installing it on my only computer and learned how to do what I needed to do as I needed to do it. Once I was comfortable with FreeBSD, I ventured into learning how to use NetBSD and OpenBSD, and when PC-BSD came along, I switched to that as my main desktop system.

NAN: Describe your involvement with the BSD Certification Group.

DRU: I founded the BSD Certification Group to create a community-based and psychometrically valid certification exam for system administrators of BSD OSes. The group is composed of volunteers who have been involved in BSD for quite some time as educators, authors, and/or system administrators. We have worked hard to provide a globally affordable examination that provides real value to employers.

NAN: You’ve written several books, including BSD Hacks, The Best of FreeBSD Basics and The Definitive Guide to PC-BSD. What can readers expect to learn from the books?

DRU: How to be comfortable on a UNIX system and how to think using the logic of a UNIX system.

NAN: Do you consider your books introductory or are they written for more experienced engineers?

DRU: These books are written in the style: “Now that you have BSD, did you know that you can do these cool things?” I’m a hands-on person and I like to know what I can do and to understand what I’m seeing when something I do acts differently than I expected it to.

The great thing about UNIX is that you can learn how to do something useful now, even if you have never seen a UNIX command line before. And, even if you’ve been around forever, there is always something you haven’t come across before or a cool new way to do something that you haven’t thought of before. So, these books can appeal to both the introductory user (the main target audience) as well as the advanced user (who will still pick up a trick or two before passing the book along to an introductory user).

NAN: Are you currently working on or planning any books or projects?

DRU: I do have a to-do list, book-wise. It’s interesting that I currently write the equivalent of three 300ish page books per year, but these are available for free online at doc.freenas.org  and wiki.pcbsd.org.

In addition, my current big project is the two-volume set for the FreeBSD Handbook, which will be a good 900 pages when it is complete. Once that project is finished, next in line is modernizing The Best of FreeBSD Basics for FreeBSD 10.x. Then, I’d like to write a second BSD Hacks-type book.

NAN: What do you consider to be the “next big thing” in the industry?

DRU: Since my expertise is in BSD, I’ll frame my answer from that perspective.
The first is creating usable frameworks for securing/sandboxing existing non-secure applications. FreeBSD is leading the development and research in this area in its Capsicum framework (see the article “Capsicum: Practical Capabilities for UNIX” on the University of Cambridge website).

The second is modern file systems that aren’t limited by the hardware restrictions that were around when most file systems were created. Examples include the OpenZFS storage platform and DragonFly BSD’s HAMMER file system.

NAN: Give us some background information. Where are you located? Where and what did you study?

DRU: I’m a recent transplant to Northwest Arkansas, having lived in Canada for many years. I went back to school in my early 30s to get a technical diploma in Networking and Telecommunications. I also earned the following certifications: MCSE, CNE, CCNA, CCSA, Security+, and probably others, which I have since forgotten.

NAN: How did you become interested in OSes and IT?

DRU: I was working in a dead-end position for a municipal department (low pay, very low glass ceiling) and wanted to expand my horizons. Many of our clients were being referred to a technical college for a networking program at a time when networking was a “hot” topic.

I had no idea what networking was, but figured it couldn’t be any worse than what I was doing, so I negotiated half days with my employer so I could attend classes. I quickly found that the course interested me and I seemed to be good at it.

Toward the end of the program, when I was researching employment opportunities, I noticed that the interesting and well-paying positions wanted UNIX experience. Having no idea what that was, and having no money as a poor student, I did an Internet search for “free UNIX.” The first hit was freebsd.org. I went to the website and my gut told me “this is it.” The rest, as they say, is history.