# Downlink Information

## Introduction

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.

### Example:

**Downlink payload: 09**C0**07**81**03**45**01**03, register pointers are in **bold** and their settings (values) follow them.

| REGISTER | VALUE | REGISTER | VALUE | REGISTER | VALUE | REGISTER | VALUE |
| :------: | :---: | :------: | :---: | :------: | :---: | :------: | :---: |
| **0x09** |  0xC0 | **0x07** |  0x81 | **0x03** |  0x45 | **0x01** |  0x03 |

```
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
```

#### [HERE you can find our API 6 table where every register and values are explained!](https://docs.google.com/spreadsheets/d/1hGcSu_Wcld7ZAccNz29Ni4D3gWtkkKHsiGtZQLGJE6g/)

## **Where to input the downlink payload**

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.**
2. On the [*IOFrog platform*](https://www.iofrog.com/), 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.

{% hint style="warning" %}
If you’re not working with the Sigfox backend directly, you need to set up **callbacks!**
{% endhint %}

## **Downlink request**

{% hint style="info" %}
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).
{% endhint %}

The only way to request a downlink is through an event (uplink message). Here are all the possibilities:

| **Method/event (hex)**                                         | **Additional information**                                                                                                                                                                                      |
| -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Extra long press (0x81)                                        | <p>Button press (magnet present) longer than 6 seconds.<br><strong>Default way to request downlink in SimplePack, SimpleMeter, SimpleIndustry.</strong></p>                                                     |
| <p>Heartbeat 1 and 2<br>(0x00 and 0x01)</p>                    | <p>Heartbeats can be configured to request downlink by setting <strong>bit 5</strong> of<br>registers <strong>0x08</strong> and <strong>0x0B</strong> to 1 (default for Heartbeat 2).</p>                       |
| Start of arming (0x10)                                         | <p>This event will request downlink with <strong>bit 0</strong> of register <strong>0x0F</strong> set to 1.<br><strong>Default way to request downlink in the SimpleLeak.</strong></p>                          |
| <p>Alerts 1, 2 and 3<br>(various hex)</p>                      | <p>Every mode-specific event defined as an <em>alert</em> can request<br>downlink with <strong>bit 6</strong> of registers <strong>0x23</strong>, <strong>0x26</strong> and <strong>0x29</strong> set to 1.</p> |
| <p>Downlink confirmation with<br>a downlink request (0x15)</p> | <p>There are two downlink confirmation events - 0x15 and 0x16.<br>This one requests downlink (<strong>chaining</strong>). Read more below.</p>                                                                  |

## **Downlink confirmation**

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.

{% hint style="warning" %}
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!
{% endhint %}

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

## **Chaining multiple downlink payloads**

**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.

### Examples:

* **01**03**03**45**07**81**09**C0 – **01030709** *is ascending, another downlink is automatically requested*
* **09**C0**07**81**03**45**01**03 *–* **09070301** *is descending, no downlink is automatically requested after this one*