Technical Quickstart

You can find a wide range of available kits on the Sigfox Partner Network. Devkits generally include Sigfox connectivity service subscriptions and can be activated online.  

As soon as you receive your kit, you can access our network with no extra work, and get an account on the Sigfox Cloud.

There are many devkits and devkit makers to choose from. We cannot recommend one, because it depends on your own particular situation.

What we can do is provide you with a non-exhaustive list of aspects to look for in a devkit.

First and foremost, you must choose a devkit that matches the RC for your project: RC1 in Europe, Middle-East and Africa; RC2 for North America; RC4 for Latin America and Asia-Pacific; etc. If your project must work in more than one zone, you should pick a devkit that supports the Sigfox Monarch feature, such as the UnaMKR. 

Second, you should choose a devkit which uses a development environment that you already know: Arduino, C (for instance ST Micro devkits), Python (for PyCom devkits), etc. You don't want to lose precious time because you didn't check that aspect early on.

Third, assert whether you need a standalone devkit, or a shield/breakboard tied to an MCU (the firmware driving the devkit being in the external MCU). Shield/breakboard devkits are AT-command driven kits.

Fourth, assert which connectivity type(s) you want to support besides Sigfox. BLE, WiFi, GPS, etc.: several existing devkits work with more than one networking technology.

Some off-the-shelf devices can be used as devkits. For instance, both Sens'it 3 and SimplePack have efficient SDKs that allow you to rework their firmware.

While you are connecting your devkit, take the time to learn about the Sigfox Cloud API, including the callback method! 

The Sigfox Cloud allows device makers to see their devices and configure how they want the data to be managed. All this is done through a REST API, which is documented in the page linked below.

By emulating the Sigfox radio network and Cloud main functionalities (callbacks), it facilitates the development of IoT applications, from the connected device itself to the application that processes the data transmitted by the device. 

The SNE is part of the SDR Dongle, which also includes the Radio Signal Analyzer (RSA), which greatly helps down the line once you have to prepare for the Sigfox Verified certification.

Now that you have connected your devkit (or even your device) to the Sigfox network, you're ready to send your first message. You should have instructions available with your product: follow them step by step. 

It's time to learn more about messages in the Sigfox context. 

The Sigfox network is bi-directional. This means that you can send messages: 

• from the device to the cloud (uplink),
• from the cloud the device (downlink).

Uplink messages are the most used, as this is how you connect a device to the cloud. 

There is a set amount of messages you can currently send to the cloud and vice-versa. 

The contractual limit is set at:

• 6 uplinks per hour, meaning 140 per day, not counting the 4 messages that Sigfox keeps for protocol use.
• 4 downlinks per day. In effect you can request as many downlinks as you want, as long as only 4 are sent -- which is determined by your server. If the server has no downlink data to send, Sigfox won't count the request as a downlink.