TCP Sync: Theory and Practice
Synchronization Stages
Every anchor goes through several stages until it is fully synchronized and able to correctly receive synchronization messages from masters and blink messages from tags. In these stages anchor detects all masters in range and chooses one that is used as reference master. Reference master has clock that is set as base for synchronization in given time domain.
Synchronization Stages in Practice
State of TCP Sync can be seen in RTLS Manager's status bar:
Everything is correct, all anchors are synchronized
It might take some time until anchors reach the final stage. Until then, you can see in status bar warning message:
TCP Sync is being set up, some anchors are not yet synchronized
Time needed depends on complexity of installation, for demo kits (5 anchors, one master), it should take no longer than 20-30 seconds. In complex installations where visibility is cascaded (e.g. 20 anchors, each master has visibility to around 5 anchors), it might take one minute.
Time Domains
TCP Sync aligns anchors into so called Time Domains. Setup where all masters are reachable through at least one master creates one time domain. However, if some part of installation is separated, system will create another time domain.
All masters are interconnected, therefore there's only one time domain
Impenetrable wall separated anchors into two time domains
Each time domain has own Reference master. Reference master synchronizes other masters in time domain, i.e. clock of other masters is continuously corrected based on Reference master's clock. Time domains are not aligned among themselves. This means that masters in one time domain can transmit in the exact same time as masters in another time domain. This is perfectly correct unless masters in one time domain are suddenly reachable by masters from another time domain. If uncorrected, system might not use full potential of anchors (some master would not synchronize all possible anchors), or in worst case masters would be in collision. Picture illustrating problem:
Impenetrable wall was torn down, but there are still two time domains.
This means that Master B cannot synchronize all slaves in its reach.
Time Domains in Practice
Number of currently created time domains is visible in RTLS Manager's status bar:
Time domains can be reset by resetting synchronization (e.g. setting any anchor to master and back: master no → yes → no). Since RTLS Studio 2.2.0 time domains are merged automatically if possible.
As a rule of thumb, it is better to have as few time domains as possible. If you know that in your installation anchors are placed in a way that there is always at least one anchor in reach of another, you should have one time domain. If you know that in your installation are two localization cells far apart, you should have two time domains.
Bridges
If system detects that there is slave between two time domains that can connect them, it will set him as Bridge master. Slave is set as Bridge master after configuring any master in anchors summary (master no → yes or master yes → no). Whether slave is suitable as Bridge master, is decided using the most recent initialization. Bridge is essentially regular master, however used only for TCP Sync and not for localization.
Thanks to initialization, it is detected that slave S can reach masters from different time domains, so on next
master's configuration it will be set up as Bridge master, effectively merging two time domains into one
Bridge Master in Practice
Initialization should be run again if environment changes (i.e. some obstacles are removed/added, position of anchors is changed, anchor's channel/profile is changed). Otherwise system might not correctly set bridge masters, resulting in partial potential of system. If you explicitly set bridge master as regular master (in anchors summary), it will act as regular master. This means that it will be used both for TCP Sync and for localization. You cannot turn off role of bridge master.
| Used for localization | Used for TCP Synchronization | |
|---|---|---|
| Master |  | |
| Bridge master |  | |
Whether anchor is set up as Bridge master can be seen in Anchor Summary table. Its master role will display "Bridge":
