Quicksand micro-electronics / Mbed 2 deprecated QW-Downlink

This software example demonstrates the downlink capabilities of the SIGFOX network.

Dependencies:   QW_Sensors mbed

Fork of QW-Downlink by Quicksand

Information

This example demonstrates how you can use SIGFOX downlinks on your QW development kit.

When the device boots, all leds are turned on. After successful initialization the LEDs are turned off again. A bidirectional message is sent to the SIGFOX cloud when the user pushes either SW1 or SW2. All the leds light up during SIGFOX transmission.

The Downstream messages are, in fact, frame acknowledgment. It means that to receive a message on the device, you have to send one indicating the SIGFOX network you are expecting an acknowledgement.

The device is sending a message with ack flag activated and then turns into receive mode during 25 seconds, looking for the network acknowledgment. Between the end of the send and the begin of the receive you have about 15 seconds of sleep.

A moving LED animation is displayed while the modem waits to begin listening for its downlink packet. The first LED and the last LED start burning continuously when the modem is listening for a downlink packet.

When reception is complete, the signal strength (RSSI) of your SIGFOX device is displayed on the led's.

• 1 LEDs = maximum -130dBm or lower
• 2 LEDs = maximum -110dBm or lower
• 3 LEDs = maximum -90dBm or lower
• 4 LEDs = higher than -90dBm

This is the RSSI at which the original uplink transmission was received on the basestation. You can also read what basestation received the uplink message if you connect to the virtual com-port of your QW development kit (9600 baud, 8-N-1)

If something goes wrong, all leds will blink together for 5 seconds. If no downlink message was received you will get the following notification in your terminal window:

SIGFOX Backend settings

This example makes use of the "default downlink settings" when you create a device type. This is a static "direct" message, no calls to an external server are used when using this type of downlink callback. The first 4 bytes of the downlink message contains the tap id that received your message, the next 2 bytes are user-payload, in this case 0x0000, the last 2 bytes contain the RSSI.

SIGFOX downlink messages are always limited to 8 bytes total!

You can alter this example to send your own type of payload back to the device. The sent back data can also be the result of a callback to your own server.

Your own server as downlink data provider

You can find more information about setting callbacks here: https://lpwan.be/wp/faq/#toggle-id-6 Basically you will need to create a BIDIR callback if you want to send data to your server and receive a response to send back to the device, from the same server.

The backend server will receive a new parameter : ack. The value will be “false” or “true”. When true is set, an acknowledgment is expected.

Then you have two choices :

• You can refuse to respond to the ack, for this you have two ways:

The first one is to respond with a HTTP 204 (no Content) ; this can be done in php simply executing

<?php
header("HTTP/1.0 204 No Content");
?>

The second way is to use the standard json way indicating you do not want to ack. For this you can use something like this :

<?php
   $_id = $_GET["id"];
   $_time = $_GET["time"];
   $_ack = $_GET["ack"];
   $_data = $_GET["data"];

   if ( $_ack == "true" ) {
     echo "{";
     echo "\"". $_id ."\" : { \"noData\" : true }";
     echo "}";
   }
?>

• You can answer to the acknowledgment by a 8 byte message like this

<?php
   $_id = $_GET["id"];
   $_time = $_GET["time"];
   $_ack = $_GET["ack"];
   $_data = $_GET["data"];

   if ( $_ack == "true" ) {
     echo "{";
     echo "\"". $_id ."\" : { \"downlinkData\" : \"0102030405060708\" }";
     echo "}";
   } 
   header("HTTP/1.0 200 OK");
   header("Content-Type : application/json");
?>

Battery consumption

During the RX period, the device is consuming 15mA until the message is received. This has to be added to the device consumption and it reduce the battery life if you are expecting potential acknowledgment on every message.

If no ack is sent, the system will listen for 25 seconds. If an ack is sent, the device will transmit again and consume an extra 45mA during less than a second.

The number of downlink messages is limited

The number of message in downlink depends on your contract, it can be up to 4 on platinum contract. You can send more than that but it will be transferred on best effort – meaning you have no insurance it will be transmitted or not. In the future there might be penalties involved.

Nothing however limits the number of downlink requests. This can be every SIGFOX message, but you would only be allowed to reply 4 times per day.

Added header byte (0x01) to the sigfox packets that indicates this example.