Simple HW device settings are stored in downlink registers as values in hex and changing these values will change the settings and also device behavior.
In one downlink payload, up to 4 registers can be changed - 4 bytes are register pointers from 0x00 to 0xFF and 4 bytes are register values from 0x00 to 0xFF for a total of 8 bytes - Sigfox downlink limit.
Downlink payload: 09C0078103450103, register pointers are in bold and their settings (values) follow them.
value of register 0x09 = 0xC0
//Heartbeat 1 message will contain Battery Voltage and Temperature data
value of register 0x07 = 0x81
//Heartbeat 1 message will come every 1 hour
value of register 0x03 = 0x45
//Departure delay is 5 minutes
value of register 0x01 = 0x03
//Mode of the device is Track me
- 1.On the Sigfox backend, you can input your downlink payload to the Downlink section when you click on Edit in the Information section of Device type.
If you’re not working with the Sigfox backend directly, you need to set up callbacks!
The devices are NOT listening to respective Sigfox radio frequencies 24/7 in order to save the battery life. This means downlink has to be requested, otherwise it wouldn’t be expected/received. After the request is sent, the device will listen to the respective frequencies and expect to receive the downlink for a set amount of time (40 seconds).
The only way to request a downlink is through an event (uplink message). Here are all the possibilities:
The device can send you a downlink confirmation alert that will let you know that the device received the downlink payload properly. This is useful if you need to know that device settings really changed.
In the Sigfox backend, the ACKED downlink status will be shown when the downlink payload was sent to the device - NOT when the device received the payload. Watch out for this!
Downlink confirmation messages are turned on in default settings, it is controlled by bit 3 of downlink register 0x0F (til FW version 6.0.228 the confirmation message was turned off). There are two events you will then receive:
- 1.0x15 - sent when downlink was received, this event will request another downlink
- 2.0x16 - sent when downlink was received and no more downlinks will be requested
Downlink sequence has an effect on how the device behaves. If the received register bytes are ascending from left to right, the device will automatically request another downlink - we call this feature chaining. If the register bytes are descending, no downlink request is sent.
If the device requests another downlink based on the payload sequence and the next received downlink is the same as the one before it, chaining ends and no more downlinks are requested.
- 01030345078109C0 – 01030709 is ascending, another downlink is automatically requested
- 09C0078103450103 – 09070301 is descending, no downlink is automatically requested after this one