... | ... | @@ -36,6 +36,90 @@ Sync precision is measured on every synchronization. If a minimum value of 10 ms |
|
|
|
|
|
After network is synchronized accurately the number of required messages to maintain same precision is 1 or 2.
|
|
|
|
|
|
### Time Sync JSON messages
|
|
|
|
|
|
After a node is first connected to mesh or connected to a new AP node it calculates the need to adopt other node's time as explained above.
|
|
|
|
|
|
If it has not to adopt time, then it asks the other party to request time using this message.
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"dest": 887034362,
|
|
|
"from": 37418,
|
|
|
"type":4,
|
|
|
"timestamp": 448543984,
|
|
|
"msg":{
|
|
|
"type":0
|
|
|
}
|
|
|
}
|
|
|
```
|
|
|
|
|
|
The recipient will start a Time Sync procedure as follows.
|
|
|
|
|
|
On the other hand if it has to adopt time it send a time request like this:
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"dest": 887034362,
|
|
|
"from": 37418,
|
|
|
"type":4,
|
|
|
"timestamp": 32990,
|
|
|
"msg":{
|
|
|
"type":1,
|
|
|
"t0":32990
|
|
|
}
|
|
|
}
|
|
|
```
|
|
|
|
|
|
`t0` is internal clock value when the packet was generated in time sync adopter,
|
|
|
|
|
|
The recipient, then fills the response with other 2 timestams, `t1` and `t2`.
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"dest": 37418,
|
|
|
"from": 887034362,
|
|
|
"type":4,
|
|
|
"timestamp": 448596056,
|
|
|
"msg":{
|
|
|
"type":2,
|
|
|
"t0":32990,
|
|
|
"t1":448585896,
|
|
|
"t2":448596056,
|
|
|
}
|
|
|
}
|
|
|
```
|
|
|
|
|
|
`t1` is timestamp when request was received
|
|
|
`t2` is timestamp when response is generated
|
|
|
|
|
|
Adopter calculates `t3`as timestamp when response is received. In this example it can be **`63221`**.
|
|
|
|
|
|
Time **offset** and **round trip delay** in adopter are calculated like
|
|
|
|
|
|
``` math
|
|
|
offset = ((t1 - t0) / 2) + ((t2 - t3) / 2)
|
|
|
tripDelay = (t3 - t0) - (t2 - t1)
|
|
|
```
|
|
|
|
|
|
In this example:
|
|
|
|
|
|
``` math
|
|
|
t0 = 32990, t1 = 448585896, t2 = 448596056, t3 = 63221
|
|
|
|
|
|
```
|
|
|
|
|
|
Then calculated values would be
|
|
|
|
|
|
``` math
|
|
|
offset = ((448585896 - 32990) / 2) + ((448596056 - 63221) / 2) = 448542871 us
|
|
|
tripDelay = (63221 - 32990) - (448596056 - 448585896) = 20071 us
|
|
|
```
|
|
|
|
|
|
Process is repeated the required number of times until calculated offset is less than 10 us. Normally, first sync takes 2 to 4 iterations.
|
|
|
|
|
|
This process is then repeated every 10 minutes +- 35%
|
|
|
|
|
|
## Routing information
|
|
|
|
|
|
Routing information is shared in form of node synchronization messages. Every node inform its neighbors about all other nodes it is connected directly to and all their respective subconnections. In this way every node has a real time picture of the whole mesh and knows which nodes are connected to the mesh. This information is refreshed every 6 seconds. Synchronization consists of a pair of message. First the node sends a `NODE_SYNC_REQUEST` to its neighbors. This message is of type 5 (`"type": 5`). Secondly, the neigbors reply with a `NODE_SYNC_REPLY` (`"type": 6`). Both messages have the following schema:
|
... | ... | |