Wiznet makers

A satellite clock for the local network

Clock 2 is a GNSS-disciplined Network Time Protocol (NTP) server published by GitHub maker HouseOfBeck in August 2026. The project combines an ESP32-S3, a satellite receiver and W5500 Ethernet to give computers on a local network a common time reference. Its August 28 update added a browser console, reception diagnostics and local firmware updates. The repository includes firmware, assembly notes, working-device photographs and a measured client session.

GNSS means global navigation satellite system. A receiver supplies both a date-and-time message and an electrical pulse marking each second. Clock 2 associates those signals, maintains a validated UTC timebase and answers NTP requests over Ethernet. An OLED panel and browser pages show whether the appliance has usable time.

Architecture illustration: satellite timing becomes a time service on the wired LAN.

Why the second needs both a label and an edge

A serial message tells Clock 2 which second the receiver means. The separate one pulse per second, or PPS, edge marks when that second began. Treating message arrival as the second boundary would include the time taken to transmit and process the message.

Clock 2 accepts checksum-valid NMEA sentences, the text records emitted by its receiver. The timebase implementation prefers a ZDA date/time sentence and falls back to a valid RMC navigation sentence. For the documented receiver output order, the label belongs to the most recent PPS edge. Clock 2 accepts that association only within a 50–950 ms window after the edge, then advances time using subsequent PPS counts.

Stratum describes distance from the reference clock in the NTP hierarchy. Clock 2 advertises Stratum 1 because its reference is directly attached; a computer synchronized to Clock 2 is Stratum 2. The number describes the relationship between clocks. NTPv4 defines this hierarchy and the exchange of timestamped packets that lets a client estimate its clock offset.

Timing diagram: the pulse provides the boundary and the NMEA sentence supplies its UTC label.

Three modules, with two important signal routes

Clock 2 uses the Waveshare ESP32-S3-ETH, Pico-GPS-L76B and Pico-OLED-1.3. The Ethernet board carries W5500 and a Pico-compatible expansion header. A separate PoE module supplies power from an Ethernet connection, so the completed stack can run from one network cable plus its external GNSS antenna. PoE means Power over Ethernet; it requires the appropriate power module and a compatible supply.

The GNSS board needs solder configuration before stacking. H1 and H2 move to position B to select the alternate UART route, and R20 connects PPS to the expansion header. Waveshare independently documents both choices in the Pico-GPS-L76B guide. Clock 2 receives NMEA on GPIO45 and PPS on GPIO43. A receiver can send readable messages while its separate PPS connection is still absent, making both routes essential to check.

An optional rechargeable backup cell preserves only the GNSS backup domain. The cell does not power the complete server after the main supply is removed. The original assembly photographs are linked in the Documents panel.

Where W5500 carries the time service

The Ethernet implementation connects the ESP32-S3 to W5500 on SPI2 at 20 MHz, with an interrupt input and reset control. Clock 2 uses Espressif's W5500 Ethernet driver and the ESP-IDF network stack. W5500 supplies the wired Ethernet interface, while firmware maintains UTC and constructs the NTP reply.

The NTP server receives client requests on UDP port 123 and returns timestamped responses through lwIP. The reply carries reference ID GPS and Stratum 1. Ethernet also carries DHCP address assignment, local hostname discovery and the browser service. The Espressif driver documentation describes the MAC/PHY integration used by this path.

The OLED uses a separate SPI3 bus. Display and web code consume status snapshots outside the timing callbacks, keeping presentation work separate from the code that associates satellite seconds and forms timestamps.

When the server stops answering

Clock 2 checks the age of both timing inputs. Its timebase becomes invalid when the newest PPS is more than 2.5 seconds old, or no accepted GNSS label has arrived for more than 10 seconds. The NTP handler then ignores requests until the timebase is valid again. This behavior prevents clients from continuing to receive time after the configured freshness limits expire.

Reception messages answer a different question: how the receiver is doing. The reception state machine distinguishes initial acquisition, degraded reception and signal loss. Startup without a fix remains acquisition; a signal-loss warning requires earlier healthy reception. These browser states help explain the antenna or reception condition without replacing the timebase checks.

Validity map: two input-age checks govern whether NTP replies continue.

Operating and checking Clock 2

The web server provides status, diagnostics, hostname settings, a bounded RAM console and local firmware upload. The /api/status endpoint exposes time validity and NTP counters for another monitoring application. The update code writes an uploaded application to the inactive firmware slot and supports bootloader rollback. Browser configuration and upload are intended for a trusted LAN and have no login protection.

Firmware builds target ESP32-S3 using ESP-IDF 6.0.2. Five host-side test suites cover supporting logic such as hostname validation, display formatting and reception states; idf.py build remains the integration build. After assembly, the useful checks are visible NMEA reception, advancing PPS counts, valid UTC, an Ethernet address and increasing NTP response counters.

Service map: local status and maintenance tools support the timing appliance.

HouseOfBeck reports a Debian 13 chrony client session on August 5 with a 2.1 µs RMS tracking offset. The accompanying source sample showed about −128 µs offset with an estimated ±1.835 ms error. These are different measurements: chrony documents tracking values as client clock statistics and source samples as measurements of an individual time source. The recorded session is a useful operational example, with accuracy dependent on the complete clock and network setup.

Related reading

GPS-Disciplined Stratum-1 NTP Server with W5500 Hardware Timestamping offers another approach to the Ethernet timestamp path. GNSSTimeServer provides a separate GNSS time-server build. Clock 2 adds a compact module stack and a clear connection between timing validity, front-panel information and browser maintenance.

FAQ

Q. What does W5500 do in Clock 2? W5500 provides the Ethernet connection for NTP requests and replies, address configuration and the local web service. The ESP32-S3 firmware derives UTC from the GNSS receiver and PPS input.

Q. Does the GNSS serial connection provide everything needed? Clock 2 also requires a separate PPS signal. The documented assembly routes the serial signals through H1/H2 and connects PPS through R20.

Q. What happens when timing input becomes stale? Clock 2 stops replying to NTP requests once either configured input-age limit invalidates its timebase. Replies resume when valid timing is available again.

Q. Can the display change the timing reference? The OLED reads status snapshots and uses its own SPI bus. UTC association and NTP timestamp generation run through separate firmware paths.

Q. Where can I inspect the actual build? HouseOfBeck publishes assembly photographs, source files and build instructions in the repository. No project-wide reuse license is declared.