Qualification

While being the perfect technology for a lot of use cases, Sigfox is not adapted to all the needs of customers today. This page will take you through the possibilities and limitations of the technology. 


How to start a Sigfox project?

At Sigfox, our main objective is to provide our customers with the best network possible. We don't develop or sell end-to-end solutions, but we rely on our ecosystem to deploy them. 

Because an IoT project involves many different types of companies and skills, you can get help from specialists on every topic you need to focus on. Take a look at our partners website to find the best partners for you. 


The right technology?

While Sigfox is a very good technology for numerous projects, some use cases may not be feasible as of today. 

1) Message size limitations

The Sigfox protocol is designed to be extremely efficient and allow devices running over our network to have many years of battery life. The 12 bytes payload (maximum, but flexible) of a Sigfox message is also perfectly suited for the vast majority of IoT use cases we see today, allowing devices to transmit interesting data to the cloud.

However, this technology is optimized for a specific kind of use case, meaning that some projects requiring high bandwith and constant connection are not really adapted for the Sigfox technology today.

2) Legal limitations 

As the current version of Sigfox uses public radio frequencies (aka ISM bands), we have to comply with the sharing rules in place in the different regions of the world to keep these bands available for everybody.  

For instance, in Europe, the ETSI regulation allows devices on these frequencies to send messages for 1% of the time per hour. Devices can only send a defined number of message per day to be compliant with the rule, and our commercial contracts were designed to match this limitation.

It is a direct application of the European ETSI regulation: 

  • There are 3,600 seconds in one hour.
  • 1% of 3,600 is 36 seconds, so a device can emit for 36 seconds per hour .
  • A Sigfox messages takes 6 seconds to send (for RC1 devices).
  • Therefore, you can send 36/6 = 6 messages / hour, which makes 24x6 = 144 messages a day. We keep 4 messages for protocol use, which allows for 140 messages per day for your device.

NB: This calculation is just an example of what is done in EMEA region (Europe, Middle east, Africa). Depending on the location, limitations can be very different.

To get more details on the Sigfox technology, you can download the Technical Overview available below.

General technical overview

What can 12 bytes be used for?

Sigfox messages are small and optimized for sensors, as they require only a small amount of power. The Sigfox payload is limited to 12 bytes (excluding the payload headers). Although this might seem to be a very restricted payload size, there's actually a lot that can be done with 12 bytes.

The example below shows how you could structure 12 bytes to send a set of GPS coordinates along with speed, acquistion time and the battery voltage.

Direct cost

The Sigfox network has been designed and optimized to be very cost-effective for our customers. From the hardware you need to create a device, to the cost of network deployment, all the details have been cautiously taken care of to offer the most optimal IoT solution on the market. 

1) Hardware costs

Because the technology is free for semiconductor companies to implement in their solutions, the cost of modules and all the other radio solutions is low in comparison to competing technologies. Starting at less than 2€ for certified modules, you will be able to create connected devices for a relatively small investment. 

Since electrical consumption is very low, battery costs are also lowered compared to other solutions, which impacts greatly the overall cost of material costs. 

2) Network costs

The total cost of ownership of your solution also integrates the network subscriptions. Our business model is based on yearly subscriptions paid by customers to connect to our service. 

As the the technology itself is very long range, we have optimized our deployment costs by lowering the number of antennas needed to cover entire areas, impacting directly the price of the solution we offer to our customers. 

Today, the price of the connectivity depends on two major factors: the number of messages you need to send every day, and the number of devices you want to connect. 

You can get subscriptions to our network on buy.sigfox.com or by contacting your local Sigfox operator for prototyping needs. 

Geolocation

Geolocation is one of the most interesting use-case deployed with the Sigfox technology. It can be achieved through a number of different methods. Let's look at the 3 most common ones, from the least precise to the most precise: 

1) Sigfox Location  

The location computation is based on the data from the Sigfox infrastructure, coming from several replicas of the same messages sent by a device and received by different base stations. The method used is not based on flight time or signal Doppler shift, but on the signal strength (RSSI - Received Signal Strength Indicator) using a probability model. 

This method is not made to be very precise, but can ensure a quality of service between 1 & 10 km precision, which is already good enough for most tracking use cases. 

Relying on regular Sigfox messages to be calculated, this solution has 2 main advantages:

  • No additional hardware is required.
  • Battery consumption is not impacted.

It is perfect for high volume solutions which don't need extra precision, and where battery life is key. Here is a guide on how to create a geolocation callback on our backend platform.


2) Wi-Fi positionning 

Another common method to find the position of a device is through listening to WiFi networks around it. Through Sigfox, they are then matched to a WiFi hotspot database in order to position the asset. 

How does it work? 

  1. The device (equipped with WiFi hardware) "listens" to the different networks around it and recognizes the two strongest ones,
  2. The device sends the BSSIDs of those WiFi networks through the Sigfox network (a WiFi BSSID is 6 bytes, so 2 BSSIDs are perfect for a Sigfox message),
  3. Once received on your platform, the BSSIDs are sent to a WiFi hotspot database for matching,
  4. The hotspot database server answers with an approximate position (25 to 50 meters). 

This method has numerous advantages: 

  • Works indoor,
  • Energy consumption is average,
  • Extra hardware is not required,
  • Precision: 25 to 50 m.

It also some disadvantages: 

  • WiFi hardware is required,
  • Only works if WiFi networks are available,
  • Access to the WiFi hotspots database is rarely free.

You can see a quick implementation example here on Github.

3) GPS positionning

The most common way of obtaining geolocation is through the GPS method. By adding a GPS module to your hardware, you will know the position of your assets very easily. 

How does it work?

  1. The GPS module listens to the satellites in sight.
  2. Once done, the coordonates are sent through the Sigfox network. A GPS coordinate is usually stored on 6 bytes, so you can send 2 full positions within a Sigfox message.
  3. The data is transmitted to your own server and can then be located on a map.

GPS has multiple advantages: 

  • Highly precise (up to 15 meters).
  • Widely used.
  • Works almost everywhere on the planet.

It has also his disadvantages:

  • High battery consumption.
  • Not very efficient indoor.
  • Expensive hardware.

You can find an example tutorial of Sigfox + GPS here.

You can see all the tracking solutions already available here on the Partners network.

What is the best method for my project? 

Because it involves modules, it's up to the use case you're targeting. While the Sigfox Network Geolocation might be better for some use cases needing high battery life, some will prefer the GPS for its precision, or even WiFi for indoor use. It all depends on what you need to achieve. 

A good solution is sometimes a mix of some of them, and that is why module manufacturers are making available hardware that includes the three technologies on board. 

The Sigfox IoT Agency

In order to help our customers reach their objectives faster, we have created a professional services team called the IoT Agency. 

This team is dedicated to assist companies developing their own solutions. They specialize in hardware, radio, project management, web applications etc. 

If you wish to hier the IoT Agency experets to develop your projects, please contact us

Compatibility

Some of the devices developed for other technologies might already be compatibe with our network out of the box, with just a firmware upgrade. 

If you’re using one of the compatible chipsets for other purposes today (private network, proprietary protocols, etc.), it could be possible to reuse the same hardware and be Sigfox compatible, by adding the Sigfox library and upgrading the firmware.  

As the Sigfox network is quite specific, some limitations exist, meaning that not all devices will work out of the box. 

The compatible chipsets are: 

  • Texas Instruments: CC1120, CC1125, CC1310, CC1350
  • Silicon Labs: EFR32, EZR32
  • Semtech: SX1272, SX1276

If our team validates compatibiity, you will need to go through a compatibility call with our certification team to validate the use case.

If you would like to know whether your device is already compatible with the Sigfox technology, please contact us.