Feature Request: Authoritative Time Servers (GPS-Based Time Synchronization) #2132
Description
Dear MeshCore Developers,
I’m proposing a new feature to improve time synchronization across the mesh network by introducing authoritative time servers based on GPS-enabled nodes.
Current Challenge
Accurate and consistent time across nodes is important for logging, coordination, and potential future features. In the current setup:
- Nodes may have unsynchronised, drifting clocks or clocks that are years out due to no RTC being present on node hardware.
- There is no standardized way to distribute accurate time
- GPS-equipped nodes already have access to highly accurate time, but this is not shared across the mesh
This leads to inconsistencies that can affect reliability and coordination between nodes.
Proposed Solution: Authoritative Time Server Nodes
Introduce a feature allowing any node (Client, Room Server, or Router) to be configured as an authoritative time server when equipped with a GPS module.
Server Behavior
-
A node with GPS hardware enabled can be configured as a Time Server
-
The node responds to time requests from other nodes with its current GPS-derived time
-
The node must validate GPS quality before responding:
-
Minimum satellite count (configurable threshold)
-
Valid GPS fix (e.g., 2D/3D fix)
-
Nodes with time server capability should include availability and status flags in existing flood and zero-hop advertisements
This avoids creating additional data transmissions on the network -
Advertisements indicate whether the time server is enabled and GPS fix is valid
If GPS quality is insufficient:
The node responds with a “time unavailable” status instead of inaccurate data to allow a client to move on to another node quicker than waiting for a timeout to expire.
Client Behavior
Client nodes should support configurable time synchronization:
- Ability to enable/disable time synchronization
- Ability to define a priority list of time servers (e.g., up to 5 nodes)
- Ability to auto-populate from discovered nodes advertising time capability
- Clients may automatically build or update their time server list based on these advertisements, removing the need for manual configuration unless desired;
This minimizes transport of timing messages across the wider network
Reduces latency in clock synchronization caused by long-distance transmission
Optimizes overall network efficiency and reduces congestion
Time request logic:
- Attempt to query the closest (fewest hops) time server
- If no response or invalid response → move to next server in the priority list
- Continue until a valid time is received or list is exhausted
Optional enhancements:
- Configurable retry intervals (If the node has previously received a good time update there is probably no need to update the time more than every 12 hours)
- Caching last known good time source
- Timeout thresholds per server
Startup Behavior
To improve initial synchronization and network awareness:
On boot, a client node should:
- Perform a network flood/announcement (standard behavior)
- Wait for a short delay to allow routing tables and capability advertisements to propagate
- Discover nodes advertising time server capability
- Query the closest available time server (by hop count) first
- If no configured or discovered time servers respond:
The node may:
Retry after a delay, or
Fall back to other discovered time servers
This ensures nodes obtain accurate time as early as possible after joining the network, while avoiding unnecessary traffic during network convergence.
Why This is Important
- Improved Network Consistency
- Ensures all nodes operate on a shared, accurate time reference
- Multiple time servers provide redundancy in challenging environments
- Uses existing advertisements to broadcast capability and status
- Minimizes additional network load and avoids unnecessary transmissions
- Makes effective use of GPS modules already present in some nodes
- Foundation for Future Features
Summary
This feature introduces a lightweight, resilient method of distributing accurate time across the mesh network by:
- Promoting GPS-enabled nodes to authoritative time servers
- Advertising time capability and status in existing network advertisements
- Allowing clients to discover and query multiple fallback sources
- Preferring closest servers to minimize latency and network load
- Synchronizing time at startup after network stabilization
It’s a practical enhancement that strengthens the overall robustness, visibility, and coordination of the MeshCore ecosystem.