FSK Configuration#

For more detailed information about FSK and its power profiles, see the Amazon Sidewalk specification

Typical Behavior#

FSK is a synchronous protocol, which means the endpoint keeps the connection with the gateway alive using beacons. Beacons are sent by the gateway every 10 seconds. Messages can be sent and received in between beacons.

By default the connection is kept alive and there are 3 RX opportunities every 10 seconds. Transmissions are preceded by a Clear Channel Assessment (CCA) and followed by an Acknowledgment message (ACK). See the figure below for an example:

Amazon Sidewalk - FSK

When the endpoint boots, it connects to the gateway using discovery; the endpoint listens on every channel to detect the gateway preamble. Upon detection of the preamble, the endpoint retrieves its first beacon and starts communicating with the gateway (touchless registration, configuration negotiation, and time synchronization).

Power Consumption and Energy Modes#

FSK Power Profiles#

Power profile 1 consists of smaller messages exchanged during synchronization with the gateway. Protocol parameters are chosen by the gateway. Power profile 2 is a full synchronization with parameters chosen by the endpoint and negotiated with the gateway. In both power profiles it is possible to choose the time separation between two RX windows.

In the sub-GHz Hello Neighbor application, power profile 2 is the default, with an RX window every 3150 ms.

Possible Parameters#

The FSK power profile can be modified by the sid_option API call using option SID_OPTION_900MHZ_SET_DEVICE_PROFILE. Then the structure sid_device_profile_unicast_params can be updated with the following values:

  • The device profile ID possible values SID_LINK2_PROFILE_1 and SID_LINK2_PROFILE_2 contained in sid_device_profile_id enum.

  • The number of RX windows is always SID_RX_WINDOW_CNT_INFINITE for both power profiles.

  • The windows separation can be any of the values of enum sid_link2_rx_window_separation_ms.

  • The type of event for which the device wakes up values are contained in enum sid_unicast_wakeup_type.

Finally, while Profile 1 has infinite windows, the application can still turn the protocol off shortly after transmitting a packet to achieve similar operating characteristics of limited number of RX windows. When the protocol is turned off, the wakeups for beacon and data will not be executed. Whenever uplink data needs to be sent, the application can turn the protocol back on, re-establish the Sidewalk connectivity, transmit its data, and turn it back off. Hence, even though the protocol does not automate this process for the application, similar operating characteristics are still achievable.