Arduino GPS PPS: Syncing to Atomic Time with Hardware Interrupts

The PPS (Pulse Per Second) pin on a high-quality GPS module outputs a highly precise 1Hz square wave synchronized to UTC atomic time. While standard NMEA sentences give you time down to the millisecond, they suffer from serial transmission latency. To achieve sub-millisecond timing accuracy for data logging, sensor synchronization, or building a Stratum 1 NTP server, you must use the hardware PPS signal. This guide details exactly how to wire, code, and debug an Arduino GPS PPS setup using hardware interrupts, avoiding the common serial-timing traps that ruin accuracy.

Hardware Spec Sheet & Pin Mapping

This build specifically targets the Arduino Pro Mini 3.3V (8MHz). We use the 3.3V variant because the u-blox NEO-M8N operates at 3.3V logic. Using a 5V Arduino Uno requires level shifters on the TX and PPS lines to prevent frying the GPS module's internal clamping diodes over time. The code relies on AltSoftSerial rather than the standard SoftwareSerial library to prevent interrupt masking.

Pin Mapping Table

The Circuit: Why Logic Levels and Interrupts Matter

The most common point of failure in DIY GPS timing projects is signal degradation and interrupt latency. The NEO-M8N PPS pin outputs a 3.3V HIGH signal. On a 5V Arduino Uno, the V_IH (minimum voltage guaranteed to be read as HIGH) is typically 0.6 × VCC, which equals 3.0V. While 3.3V technically crosses this threshold, it leaves almost zero noise margin. A slight voltage drop from the active antenna's current draw can cause the Arduino to miss the PPS edge entirely. Using the 3.3V Pro Mini guarantees a rock-solid logic HIGH.

Furthermore, the PPS signal must be routed to a hardware interrupt pin (Pin 2 or Pin 3 on the ATmega328P). Polling the pin in the loop() function will result in missed pulses whenever the microcontroller is busy parsing NMEA strings or writing to an SD card.

Complete Compilable Code (Interrupt-Driven PPS)

This code targets the Arduino Pro Mini 3.3V. It requires the TinyGPS++ and AltSoftSerial libraries. We use AltSoftSerial because the standard SoftwareSerial library disables global interrupts while receiving bytes, which will cause you to miss the PPS hardware interrupt entirely.

#include <AltSoftSerial.h>
#include <TinyGPSPlus.h>

// --- PIN DEFINITIONS ---
#define GPS_RX_PIN 8    // AltSoftSerial RX (connect to GPS TX)
#define GPS_TX_PIN 9    // AltSoftSerial TX (connect to GPS RX)
#define PPS_PIN 2       // Hardware Interrupt 0 (connect to GPS PPS)
#define LED_PIN 13      // Onboard LED for PPS visual feedback

// --- OBJECTS ---
AltSoftSerial gpsSerial;
TinyGPSPlus gps;

// --- VOLATILE VARIABLES FOR ISR ---
volatile bool pps_triggered = false;
volatile unsigned long pps_timestamp = 0;

// --- STATE TRACKING ---
unsigned long last_pps_time = 0;
const unsigned long PPS_TIMEOUT_MS = 2500; // Expect pulse every 1000ms

// --- INTERRUPT SERVICE ROUTINE ---
void ppsISR() {
  pps_timestamp = micros(); // Capture exact microsecond of the rising edge
  pps_triggered = true;
}

void setup() {
  Serial.begin(115200); // Debug serial
  gpsSerial.begin(9600); // NEO-M8N default baud rate
  
  pinMode(PPS_PIN, INPUT);
  pinMode(LED_PIN, OUTPUT);
  
  // Attach hardware interrupt on RISING edge
  attachInterrupt(digitalPinToInterrupt(PPS_PIN), ppsISR, RISING);
  
  Serial.println(F("Arduino GPS PPS Sync Initialized."));
  Serial.println(F("Waiting for 3D Fix and PPS signal..."));
}

void loop() {
  // 1. Parse incoming NMEA data
  while (gpsSerial.available() > 0) {
    if (gps.encode(gpsSerial.read())) {
      // Valid NMEA sentence parsed
    }
  }
  
  // 2. Handle PPS Interrupt Flag
  if (pps_triggered) {
    pps_triggered = false; // Reset flag immediately
    last_pps_time = millis();
    
    // Toggle LED to visualize the 1Hz pulse
    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
    
    // Output synchronized time
    if (gps.time.isValid() && gps.date.isValid()) {
      Serial.print(F("[PPS SYNC] "));
      Serial.print(gps.time.hour());
      Serial.print(F(":"));
      Serial.print(gps.time.minute());
      Serial.print(F(":"));
      Serial.println(gps.time.second());
      Serial.print(F("  Microsecond offset: "));
      Serial.println(pps_timestamp);
    } else {
      Serial.println(F("[PPS PULSE] No valid UTC fix yet."));
    }
  }
  
  // 3. Error Handling: PPS Timeout
  if (millis() - last_pps_time > PPS_TIMEOUT_MS && last_pps_time != 0) {
    Serial.println(F("ERR: PPS_TIMEOUT - No interrupt fired in 2500ms"));
    last_pps_time = millis(); // Reset to prevent serial flooding
  }
  
  // 4. Error Handling: NMEA Buffer Overflow
  if (gps.charsProcessed() > 0 && gps.charsProcessed() < 10 && millis() > 5000) {
    Serial.println(F("ERR: NMEA_BUFFER_OVERFLOW - Serial buffer dropped bytes"));
  }
}

Debugging: First Three Things to Check When It Fails

When your serial monitor stays blank or throws errors, do not start rewriting the code. GPS modules are highly sensitive to environmental and wiring variables. Here are the first three things to check, ranked by likelihood.

1. The GPS lacks a 3D Fix (The "Indoor Trap")

Symptom: NMEA sentences are printing, but the PPS pin is either dead or pulsing erratically at the wrong frequency.
Cause: According to the u-blox NEO-M8 integration manual, the Timepulse (PPS) pin will not output a reliable 1Hz signal until the receiver achieves a valid 3D navigation fix. If you are testing on your workbench indoors without an active antenna near a window, the PPS pin will remain LOW.
Fix: Move the active antenna outdoors or directly against a single-pane window. Wait for the gps.satellites.value() to read ≥ 4.

2. SoftwareSerial is Masking the Interrupt

Symptom: You see ERR: PPS_TIMEOUT in the console, even though a multimeter shows the PPS pin pulsing at 1Hz.
Cause: You swapped AltSoftSerial for the standard SoftwareSerial library. SoftwareSerial disables global interrupts (cli()) while bit-banging the serial receive pin. If the PPS rising edge occurs while a serial byte is arriving, the hardware interrupt is ignored.
Fix: Revert to AltSoftSerial or NeoSWSerial, or move the GPS TX line to the hardware RX pin (Pin 0) and use Serial1 / HardwareSerial.

3. Baud Rate Mismatch on the I2C/UART Bridge

Symptom: The serial monitor prints endless ERR: NMEA_BUFFER_OVERFLOW or garbled text, and gps.charsProcessed() remains low.
Cause: While u-blox modules default to 9600 baud, many third-party breakout boards flash custom firmware that defaults to 115200 or 38400 baud.
Fix: Change gpsSerial.begin(9600); to 115200. If that fails, connect the module to a PC via a USB-to-Serial adapter and use the u-blox U-Center software to verify and reset the UART baud rate.

Extending and Simplifying the Build

Depending on your end goal, you may not need the full complexity of hardware interrupts, or you may need to scale this up for network synchronization.

• To Simplify (Wall Clock / Basic Logger): If your application only needs time accuracy down to ~50 milliseconds, drop the PPS wire entirely. Rely solely on the TinyGPSPlus gps.time objects parsed from the NMEA $GPRMC sentences. This frees up Pin 2 and removes the need for interrupt-safe coding practices.
• To Extend (Stratum 1 NTP Server): Replace the Pro Mini with an ESP32 and add an Ethernet shield (like the W5500). Use the PPS interrupt to discipline a local software PLL (Phase-Locked Loop). You can then serve time to your local network via NTP with sub-millisecond accuracy, completely independent of internet connectivity.
• To Extend (High-Speed Data Logging): Use the pps_timestamp variable captured in the ISR to tag high-frequency sensor data (like accelerometer readings). Instead of relying on millis(), which drifts and blocks during I2C transactions, buffer your sensor data and stamp it with the microsecond offset relative to the last PPS edge.

Frequently Asked Questions (FAQ)

Why is my Arduino GPS PPS pin not pulsing?

The most common reason is that the GPS module has not achieved a 3D satellite fix. The u-blox firmware intentionally suppresses the Timepulse output if the positional accuracy is outside acceptable bounds. Another frequent hardware issue is using a passive antenna instead of an active one; without the 3.3V power feed from the GPS module to an active LNA (Low Noise Amplifier), the receiver will never lock onto satellites indoors, and thus the PPS pin will stay LOW.

Can I use SoftwareSerial with a GPS PPS interrupt on Arduino?

Technically yes, but practically no. The standard SoftwareSerial library relies on pin-change interrupts and disables global interrupts to accurately time the incoming serial bits. If a GPS NMEA character arrives at the exact millisecond the PPS pin goes HIGH, the Arduino will miss the PPS hardware interrupt. Always use AltSoftSerial, NeoSWSerial, or hardware UART pins when working with PPS signals.

How accurate is the Arduino GPS PPS signal compared to a DS3231 RTC?

A high-quality DS3231 Temperature Compensated Crystal Oscillator (TCXO) RTC is accurate to about ±2 parts per million (ppm), which translates to roughly ±1 minute of drift per year. The PPS signal from a GPS module locked to the atomic clocks on the GPS satellites is accurate to within ±15 nanoseconds (0.000015 milliseconds) of UTC time. For any application requiring long-term synchronization without manual adjustment, the GPS PPS signal is vastly superior to any standalone I2C RTC.