Time Card: an open hardware reference for datacenter time synchronization

Time Card's role in PTP-enabled datacenter networks

Time Card addresses the hardware layer of time distribution. The README describes a time server as a critical component of a PTP-enabled network: it receives time from GNSS, serves accurate time to other systems, and continues operating during a GNSS outage through a stable holdover oscillator. Time Card packages those ideas into a standard, single-slot, passive-cooled PCIe card described as the heart of the Open Time Server project.

The intended audience is narrower than that of an NTP server package or a general-purpose clock daemon. The project concerns hardware architects, firmware and driver developers, network timing engineers, and organizations building datacenter timing systems where the behavior of the time source itself matters. It is also relevant to researchers working from an open reference rather than reverse-engineering a proprietary timing appliance.

The repository presents this as a hypothetical reference model rather than only a finished consumer product. Its top-level directories cover hardware, FPGA, oscillator, GNSS, driver, software, documentation, system modules, and tests. Based on that layout, the goal extends beyond a board schematic. It includes supporting implementation and reference material intended to describe a complete timing card. The IEEE publication and the ongoing IEEE P3335 work add a standards-oriented context, but the README does not claim that the card is itself an IEEE P3335-certified product.

GNSS, oscillator, and bridge signal flow

The central signal path begins with a GNSS receiver and continues through a bridge that disciplines a local clock. The receiver can come from u-blox or another vendor, provided that it supplies PPS output and time-of-day data in a suitable format. The README identifies the u-blox RCB-F9T GNSS time module as the recommended receiver.

The oscillator supplies the frequency reference during normal operation and provides holdover when GNSS is unavailable or cannot be trusted. The README specifically recommends an atomic clock with holdover accuracy of plus or minus 1 microsecond or a high-quality OCXO with holdover accuracy of plus or minus 22 microseconds. It also lists AC, OCXO, and TCXO as possible clock categories, while naming SA5X, LN CSAC, mRO-50, and SA.45s as atomic-clock examples. These are design examples, not dependencies installed by the project.

The preferred bridge implementation is hardware. The README assigns most of the functionality to an FPGA. Software and hardware bridge alternatives are discussed, but hardware is identified as the end goal. The design also exposes Linux character-device interfaces, including /dev/phc and /dev/pps, for use with open source software such as ptp4l and chronyd. In practical terms, GNSS supplies external time and timing information, the bridge reconciles it with the local oscillator, and the resulting disciplined time is made available to host software through timing interfaces.

Acquiring or fabricating the PCIe timing hardware

The README does not provide a software installation command, package-manager invocation, or application deployment tutorial. Time Card is physical PCIe hardware, so its first adoption step is acquisition or fabrication rather than installing a program.

One documented option is to purchase a card with the OCXO daughter card and NEO-M9N RCB, fully programmed and assembled from Makerfabs. A second option is to use the source code, bill of materials, Gerber files, and binaries in the repository and follow the linked PCBWay fabrication, assembly, and accessory videos. A third option is to source and produce the design with another manufacturer. These options differ in effort. Buying an assembled card avoids board production, while self-fabrication requires access to the listed design outputs and assembly parts.

After acquisition, the installer must confirm that the card fits the system as a standard stand-up PCIe card and that the platform can support its single-slot passive cooling arrangement. The README does not document operating-system drivers for Linux, a Windows installation procedure, BIOS settings, pin assignments, or a first-boot diagnostic sequence. The repository contains DRV, Software, SOM, and TEST directories, but the README does not explain their individual contents. It would therefore be unsafe to invent driver installation steps or configuration commands.

For a first functional use, the host interface is the part to verify first. An integrated card is intended to make its PPS and precision hardware clock facilities available to compatible software through /dev/pps and /dev/phc. The README names ptp4l and chronyd as possible consumers, but it does not provide their configuration files or startup commands for Time Card.

GNSS attack resistance and holdover boundaries

The design directly addresses two attack paths against a GNSS-based time source: jamming and spoofing. Jamming suppresses usable GNSS signals. The README states that long-run holdover is the most reliable way to keep operations going during such an attack. That makes the quality and tuning of the local oscillator central to service continuity rather than an optional detail.

Spoofing presents a different problem because a receiver can be fed counterfeit navigation signals. The README recommends receivers capable of verifying packet signatures and says that disciplining logic should reject sudden changes in time and space. For datacenter use, it considers a jump in position potentially unacceptable. This is a system requirement for the bridge and receiver combination, not a claim that any particular receiver or implementation already eliminates spoofing.

There are still boundaries. GNSS requires a usable signal environment, and the README notes that GNSS needs a clear sky. Its security discussion is architectural. It identifies receiver capabilities, holdover, and jump detection as controls, but does not describe a complete authentication scheme, alarm policy, or automatic recovery sequence. A production designer would need to verify how the selected receiver reports bad or missing signals and how the bridge responds. The README does not establish those implementation details.

The listed holdover targets are design targets, not independently demonstrated results in the README. It gives no temperature range, aging data, calibration procedure, measurement interval, or outage-duration curve. Those omissions matter because holdover quality changes with oscillator choice and environmental conditions.

Hardware bridge choices and derivative cards

Time Card is open at the hardware and software reference level, but the architecture still depends on specialized components. The u-blox RCB-F9T is recommended, the card may use an OCXO daughter card, and the oscillator section names atomic references. A team that cannot source these parts will face more procurement and integration work than a buyer of an integrated timing appliance.

The README also identifies two timing cards built by other companies that use different hardware while remaining compatible with the architecture and driver: Safran ART2 and ADVA OSA5400. ART2 is described as fully open source, with its board repository linked separately. These products address the same general time-card role with existing vendor hardware. The README does not compare their accuracy, interface set, pricing, licensing, host compatibility, or holdover performance, so no such comparison can be made here.

A second alternative is a software bridge. The README allows the bridge between the GNSS receiver and atomic clock to be implemented in software, but states that hardware is preferred and is the project's end goal. A software implementation can simplify initial experimentation by using host logic. A hardware bridge shifts timing-critical processing into the FPGA and makes behavior less dependent on general-purpose host scheduling. The repository does not provide comparative timing data, so the choice must be based on the required implementation target rather than a claimed performance winner.

Licensing, maintenance, and adoption cost

The repository is licensed under a custom license that GitHub cannot classify. The README links to LICENSE.md, but does not reproduce its terms. As a result, the project's open description should not be interpreted as a confirmed grant under MIT, GPL, Apache, or another standard license. Engineers must review LICENSE.md for redistribution, modification, hardware production, commercial use, attribution, and patent-related terms before treating the design files as reusable. This is a licensing review requirement, not legal advice.

The repository is not archived, and its last push was on 2026-09-08. The release list also includes windows-driver-v1.13 and windows-driver-v1.9 on 2026-07-15, followed by TimeCard_V28 on 2024-12-04. The driver releases indicate separate packaging or implementation work for Windows, but the README does not explain their installation process or compatibility requirements. The differing release dates also make it important to match the driver, board revision, and oscillator configuration rather than assuming every release applies to every card.

Adoption cost extends beyond the purchase price of an assembled card. Self-fabrication requires manufacturing access, assembly work, component sourcing, host integration, and validation of timing behavior. The PCIe form factor simplifies installation compared with a larger appliance, but it does not remove the need to coordinate hardware, drivers, PTP software, GNSS reception, oscillator holdover, and monitoring. The repository layout suggests organized implementation areas, yet the README does not document release compatibility matrices or an upgrade procedure.

Editorial conclusion

Engineers evaluating the architecture should adopt Time Card when they need an open hardware reference for a GNSS-disciplined PCIe time source with PTP interfaces and holdover. Operators looking for an off-the-shelf server appliance, and projects unable to source specialized clocks or validate timing hardware, should choose a packaged timing product instead. Before adoption, inspect LICENSE.md for the actual grant and restrictions, then verify driver support, hardware revision, oscillator choice, and PCIe integration for the intended platform.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Time-Appliances-Project/Time-Card on GitHub