There are four startup scenarios that requires synchronization between the Host and Module:
...
The diagrams in this section illustrate the Startup Synchronization sequence.
First Time Startup Configuration Sequence
Figure (1) illustrates the expected Startup Synchronization sequence following the first power up of the Module from its factory default state. In this diagram, the Configuration and Updates phase from the previous figure has been expanded to show key operations performed by the Host.
...
Startup Synchronization Request Retries
Figure (2) illustrates the sequence when the Module initializes before the Host (described in scenario (2)). In this scenario the Module starts sending Startup Sync Request periodically(every 5 seconds) to ensure that the Host receives the message even if the Host starts up slower than the Module. You can see in the figure, the Host Startup Ready command is sent after the Startup Sync Request. The Module is required to send a final Startup Sync Request after receiving the Host Startup Ready command. The Host can now start the Configuration sequence.
...
The first byte of the Startup Sync Request Command(see payload /wiki/spaces/SPRHA17/pages/37093548for Startup Sync Request ) indicate the current running state of the module i.e., Running State indicates whether the Module has just powered up or is already running. If the Running State indicates the latter, it signifies that the Host experienced a unilateral reset. In this case, the Module will have retained all its application cache and attribute values, but will suspend network operations and return to the Startup Synchronization phase. The module will go through the following phases:
...