All devices in your cluster must agree on the current time and date. Technically the time/date doesn’t even have to be correct, they just have to agree on it.
Each device in your cluster makes best use of whatever components and sources it has to arrive, and keep current, the time.
Sources of Time
| Secure Pings | These are the most trusted sources of time. They are signed by any trusted on-cluster device, and utilize that other device’s onboard components and cluster knowledge to share that device’s belief of the current time. |
| High Precision Realtime Clock | If your device is equipped with a realtime clock, this will be considered a good source of time, and your device should immediately power up, regardless of GPS connectivity. The RTC’s time will continue to be updated regularly as part of the device’s regular functioning. The T-Beam Supreme has a decent realtime clock, although it’s more for holding current time while powered and during short gaps between powerups. On the other hand, the DS3231 onboard the SAMD51-based ChatterBox is extremely accurate, temperature compensated, and can maintain time for quite a while (> 1 year) without external power. |
| GPS/GNSS | If your device is equipped with GPS/GNSS, this will be considered a secondary source of time, unless that is the only external time source your device has at startup. If that’s the only onboard source of time your device has, your device will wait during startup until it has a good GPS signal, which can be problematic if you don’t have a view of the sky. There is a workaround for this. |
| Other Nearby ChatterBoxes | Unless disabled, all ChatterBoxes broadcast time about every 120 seconds. Using this is a time source is considered a last resort, but it can be done. You can force any startup-stuck device to listen for nearby time broadcasts instead of using GPS or onboard RTC. If the stuck device is a communicator, tap the time sync icon on the startup screen. If the stuck device is a node, tap the button farthest from the reset button once. You can instantly broadcast time from any ChatterBox by touching the clock on the home screen. |
Functions Dependent on Time
| Current Channel | Unless you have locked your cluster to a single channel, it is regularly hopping to different frequencies. Each device in your cluster uses knowledge of the current time, as well as one of the cluster’s symmetric keys to determine which frequency the cluster is using during any given second. |
| Signing Messages and Pings | All messages you send/receive and all pings and other automated traffic within your cluster is signed. The signatures expire, and the signing device sets the message expiry, using its knowledge of the current time. |
| Validating Signed Messages | All devices validate the signature of messages and pings. As part of this validation, they also check the signature’s declared expiry versus the current time. |
| Mesh Packet Delivery | Mesh packets have limited life to help ensure good performance. If packets are in the cluster’s mesh cache, but don’t get to the final destination before expiry, the expired packets are removed from the mesh cache. |
| Location Staleness | As location data is securely shared throughout your cluster (if enabled), the time is used to determine if one location ping should be replaced by a newer one. It also helps you see on a communicator how old the location is. |
| Identifying Neighbors | If one device’s timestamp is out of sync with others, that device will be invisible to other cluster devices, and even if they are near one another, they’ll constantly be on different channels. |
| Interpreting Mesh Graph Data | The distributed mesh graph is each device’s view of the cluster’s interconnectedness. It is kept current through watching pings, frequent pruning, and other functions that are highly time dependent. In order for meshing to perform well, time needs to be fairly consistent throughout the cluster. |