Project Logs

Collapse

• MQTT is much better

  Détourner • 11/07/2025 at 15:34 • 0 comments

  MQTT is much better than WebSocket.
  I updated the GitHub repositories:
  

  • Electric time (ESP32): https://github.com/detourner/electime
  • Grid frequency monitor (Rasberry Pi): https://github.com/detourner/GridFreqMonitor

• Switching from WebSocket to MQTT for Reliable Frequency Streaming

  Détourner • 11/05/2025 at 14:07 • 0 comments

  The first implementation of The Electric Time used a WebSocket connection between the Raspberry Pi and the display device to stream the measured mains frequency in real time.

  While this worked fine for short sessions, I started to experience unstable communication after several hours  / days of uptime: dropped connections, frozen values, and occasional buffering delays.

  WebSockets are great for browser-based communication, but in this project the Raspberry Pi acts more like a data source, and the display device (an ESP32) behaves like an IoT client.
  That’s why I decided to migrate the data exchange to MQTT, which is far better suited for this kind of setup.

  Architecture Overview

  • The Raspberry Pi runs the frequency measurement script and publishes the measured frequency (in Hz, with 3 decimal precision) to an MQTT topic, for example:

    topic: grid/frequency
    payload:
        time_stamp: 1690000000.123456
        last_update_time: 1690000000.123456
        frequency: 50.480A lightweight MQTT broker (Mosquitto) runs locally on the same Raspberry Pi.

  • The ESP32 connects as an MQTT client, subscribes to the same topic, and updates the display in real time.

  This new setup offers several advantages:

  • Automatic reconnection handled natively by MQTT libraries (no custom retry logic needed).

  • Message persistence and guaranteed delivery, even if the Wi-Fi connection briefly drops.

  • Decoupled architecture: measurement, messaging, and display are now independent and can evolve separately.

  • Scalability: any additional device can subscribe to the topic to monitor the frequency remotely.

• Measuring Mains Frequency (Software) — Raspberry Pi + pigpio + WebSocket

  Détourner • 10/31/2025 at 08:55 • 0 comments

  In a previous log, I covered the hardware part of measuring mains frequency — this time it’s all about the software.

  The goal: measure the local 50 Hz mains frequency in near real time, using a Raspberry Pi, a zero-crossing detector, and the pigpio library for precise timing. The Pi counts the signal edges, keeps timestamps in a circular buffer, corrects time drift using a 1 Hz PPS reference from a GPS receiver, and streams the calculated frequency over WebSocket.

  The source code is on Github

  How It Works

  The core idea is simple:

  1. Each zero-crossing from the mains signal generates an interrupt on a GPIO pin.
  2. pigpio gives us a timestamp (in microseconds) for every edge.
  3. We store the last N timestamps (e.g. 1000 samples).
  4. Once per second (triggered by the GPS PPS), we compute:

  • DeltaT : elapsed time between first and last samples
  • base_time: correction from the 1 Hz PPS reference
  • Division by 2 → because the zero-crossing detector triggers twice per cycle (positive + negative)
  1. The result (current_frequency) is broadcast as JSON via a WebSocket server.

  
  

  Core Components

  • pigpio handles GPIO interrupts and timestamps (run sudo pigpiod before the script).
  • Two GPIO inputs:
    • GPIO_INPUT_SIGNAL = 24: the grid frequency signal (from your sensor)
    • GPIO_1HZ = 21: the GPS PPS (Pulse-Per-Second) reference
  • Circular buffer (deque) keeps the most recent timestamps.
  • Callbacks process incoming edges:
    • cb_grid_signal: filters noise (debounce ~8 ms) and stores timestamps.
    • cb_1Hz: triggered once per second → computes the average frequency using all samples in the buffer.

  Key Details

  • Debounce filtering on 50Hz input. The callback ignores edges that arrive too close together (less than 8 ms). That prevents false triggers from electrical noise.
  • Reference correction (GPS PPS) The 1 Hz signal comes from the GPS receiver’s PPS output, which is accurate to better than one microsecond. This makes the Pi’s local clock drift essentially irrelevant — every second is locked to GPS time, giving you sub-ppm stability for the frequency measurement. 

  
  

  Real-Time Streaming

  The script starts a WebSocket server (ws://0.0.0.0:8765) and sends an update once per second:

  {

    "time_stamp": 1730362540.12,

    "last_update_time": 1730362539.89,

    "frequency": "50.013"

  }

  Any WebSocket client (Python, Node.js, browser dashboard, etc.) can subscribe to display or log the frequency over time.

  Example Console Output

  Base time: 1.000001 seconds (from GPS PPS)

  Frequency: 50.012345 Hz (at 1730362540.123456 seconds) [1000 samples; Measured: 100.024690 Hz]

  WebSocket server started at ws://0.0.0.0:8765

  Client connected from IP: 192.168.1.42

  (Measured: 100 Hz = zero-crossings/sec → divide by 2 → ~50 Hz mains frequency.)

  
  

  Summary

  This small Python script combines hardware-level timing from pigpio with a GPS-disciplined PPS reference and asynchronous streaming via WebSocket. It’s a neat way to visualize how the power grid frequency fluctuates in real time — and a solid foundation for any GPS-synchronized power-quality or IoT monitoring setup.

• Measuring Mains Frequency with a Raspberry Pi (MQTT / WebSocket) — Zero-Crossing and Safety Notes

  Détourner • 10/29/2025 at 12:33 • 0 comments

  Principle

  The idea is simple: detect every zero crossing of the AC waveform, count how many occur during a time interval T, and compute the frequency.
  If all crossings are counted (both rising and falling), there are two per cycle:

  I use a 10-second interval with a moving average to stabilize readings. The frequency value is updated every second.

  Two Key Challenges

  1. Accurate Time Reference

  The accuracy of the frequency measurement is directly tied to the accuracy of your time base.

  To see why, consider that the frequency is inversely proportional to the period:

  If the real period of a 50 Hz signal is:

  and we want to resolve a difference of 0.01 Hz (i.e. 50.00 Hz vs 50.01 Hz), the corresponding change in period is:

  So, to detect a 0.01 Hz difference at 50 Hz, our timing precision must be on the order of a few microseconds. To obtain a stable result over several cycles, a base clock or timestamp resolution around 1 µs is typically required.

  With this expected resolution, NTP synchronization is not sufficient — it usually offers millisecond accuracy. To achieve microsecond-level precision, I used a GPS PPS (Pulse-Per-Second) signal as a reference clock.

  2. Bringing 230 V (or 120 V) to a GPIO Safely ⚡

  Never connect the mains directly to a GPIO or use a resistor divider — that’s lethal and will destroy your Raspberry Pi.

  A safe option is to use an optocoupler for AC detection. For this project, I used a mains sensing module from AliExpress that provides galvanic isolation and outputs a 3.3 V logic signal compatible with the Pi.

• How to Measure the 50 Hz Mains Frequency

  Détourner • 10/28/2025 at 07:55 • 0 comments

  Before diving into direct measurement, I first explored the possibility of using an online service that provides the mains frequency (50 Hz in Europe) in real time.

  There are indeed a few websites that publish this information — mostly in Germany and Switzerland — but:

  • some only offer limited-time access,

  • others don’t provide any public API,

  • and most of them introduce several seconds or even minutes of delay, making the data unsuitable for true real-time use.

  In short: it’s nearly impossible to find a reliable, open, real-time source for the 50 Hz mains frequency in France or across Europe.

  👉 So, I decided to measure the mains frequency myself, using a local reference signal — a more independent and definitely more maker-style approach!

  The next log will describe the measurement principle and the hardware setup in detail.

View all 5 project logs