Downlink Information
Downlink Introduction
Last updated
Downlink Introduction
Last updated
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.
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.
On the IOFrog platform, downlink payload is configured automatically by changing the settings, but can be manually adjusted in the New downlink payload section at the top of the Downlink section.
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:
0x15 - sent when downlink was received, this event will request another downlink
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
REGISTER
VALUE
REGISTER
VALUE
REGISTER
VALUE
REGISTER
VALUE
0x09
0xC0
0x07
0x81
0x03
0x45
0x01
0x03
Method/event (hex)
Additional information
Extra long press (0x81)
Button press (magnet present) longer than 6 seconds. Default way to request downlink in SimplePack, SimpleMeter, SimpleIndustry.
Heartbeat 1 and 2 (0x00 and 0x01)
Heartbeats can be configured to request downlink by setting bit 5 of registers 0x08 and 0x0B to 1 (default for Heartbeat 2).
Start of arming (0x10)
This event will request downlink with bit 0 of register 0x0F set to 1. Default way to request downlink in the SimpleLeak.
Alerts 1, 2 and 3 (various hex)
Every mode-specific event defined as an alert can request downlink with bit 6 of registers 0x23, 0x26 and 0x29 set to 1.
Downlink confirmation with a downlink request (0x15)
There are two downlink confirmation events - 0x15 and 0x16. This one requests downlink (chaining). Read more below.