Prototyping has shown you the way to go: through devkits and first versions, proof-of-concepts and tryouts, you've reached the conclusion that your project is possible, both technically and financially. Now is the time to make definitive choices, and prepare for the next step.
Producing a detailed spec
The culmination of your needs assessment phase will become the headlines of your specification phase. This specification phase is a crunch phase for your overall project success.
The Sigfox IoT Agency has written down the most important considerations when writing your solution specification. This is an opportunity to reduce time to market.
Choosing a radio chipset
In order to create a Sigfox-enabled solution, you will need to integrate a Sigfox compatible radio chipset in your device. Thanks to our open approach regarding hardware integration, our semiconductor ecosystem offers a wide variety of solutions to answer all our customer needs.
We have created a page to bring you up to speed with the available technologies
- What types of chipsets exist.
- How to choose the one that fits your needs.
- See suggested chipsets retrieved from the Sigfox Partner Network.
Choosing an antenna
When developing your device, it is important to consider its antenna. This is the one element that connects your hardware to the Sigfox network.
The choice of your antenna will depend on several parameters:
- Environment in which the device will work
It is therefore primordial to choose your antenna and antenna provider wisely. To help you, we have created a page giving all the information there is to know.
Integration of the antenna into the device is a critical part of the device design. Severe degradation of performance may occur if antenna integration is not properly analyzed. In this case, uplink class 0u may not be achieved.
The device maker is responsible for adjusting the device's radio parameters (radiated power, harmonics, etc.) in order to meet performances in the final application environment.
Having a class 0u device does not garantee perfect reception once installed. Only proper field testing can assert that.
Choosing a battery
The Sigfox technology has been optimized in every way possible to be power-efficient, to allow devices to operate independently for a number of years without changing the power source. What does this mean for a device maker?
As the Sigfox network does not use a handshake mechanism (or any other type of power-controlling system) within the protocol, Sigfox is one of the only technologies allowing to precisely analyze and predict how much power you will use during your device's battery life.
2) Which type of battery?
Numerous power sources are available on the market, each with their own benefits. Which source to use depends on your use case, as battery capacity can be impacted by a number of parameters.
The questions to answer before choosing are:
- How long is my device supposed to work?
- How many sensors need power while not sending messages?
- What are my constraints in term of design?
- What temperature will be reached?
Once all parameters have been defined, you will be able to choose the most suitable source for your use case.
Warning: Don't undersize your power source! Whilst having the smallest battery on the market could help with the design aspects, it is also important to consider the amount of power needed during transmission while choosing your battery. On average radio solutions consume between 20 and 50 milliampere in TX mode, which has a great impact on battery life. If your use case requires very small batteries (like coin cells), special attention needs be paid to this aspect.
3) Radio configuration impact
The various Sigfox Radio Configurations across the globe each use different ways of transmitting data. However, the impact on battery life is minimal if the correct approach is taken.
For example, when the speed of transmission is six times higher (in RC2), the power required will be higher during the TX. However, as the time of transmision is six times faster, the impact is minimal on battery consumption in general.
Hence, the target RC has to be considered when designing the board itself, as constraints are a bit different.
4) Radio solutions
Each radio solution (module, System on Chip, transceivers) has its own power consumption, which may vary from one provider to another. You should compare the differences between radio solutions in order to size the battery appropriately. From one module to another, you will see that the power consumption can almost double, depending on the partner.
To make our partners' lives easier, an application note on battery compatibility with the Sigfox technology is available below.
Choosing a casing
Another important part to consider early on is the casing you plan on using for your device. Namely the material of the casing will have a real impact on the radio performance of your final product.
There are at least 3 points to be aware of when choosing a casing.
1) Casing material
For better performances, consider plastic.
Metal casing might look more solid, but will create issues for your device, especially with radio propagation.
2) Casing production
We tend to recommend off-the-shelf casings for most projects. They offer a good quality for the price. They are also great for low-volume orders.
They have the advantage of being quick to buy and inexpensive. Many references are available from your local distributor.
3D-printing can be interesting for very low volumes, because you can design exactly what you need. But it can become expensive once you need more volume, and it requires extra work to adapt to your needs.
Custom casing are to be reserved for high volume orders, as they can get very expensive.
3) Casing protection
Depending on your use case, an IPXX-type casing is worth considering, particularly for outdoor or industrial use cases. It will protect your design from being exposed to water or dust.
Pre-certification network credentials
To communicate on the Sigfox network, Sigfox Network Credentials need to be incorporated into the device. These credentials authenticate the device and ensure secure data transmission.
Note: this section is only about Sigfox Network Credentials provided by Sigfox Build; for Production Sigfox Network Credentials, go to https://build.sigfox.com/industrialization#the-sigfox-credentials.
The development phase is an extension of the prototyping phase. For device makers who build their own modem, the outcome of the development phase is a final device that must pass Sigfox RF & Protocol tests. To qualify for the Sigfox Ready certification, the device must then have its RF radiated performance validated.
In order to allow device makers who want to perform live demonstration of their devices on the Sigfox network, Sigfox can provide Sigfox Network Credentials prior to Sigfox certification, under the following conditions:
- Device makers can ask for up to 20 Sigfox network credentials per device.
- Device-making organizations can ask for up to 100 Sigfox network credentials overall.
- These credentials allow device makers to register devices on Sigfox backend as prototypes only. Additional credentials are provided to registered devices on the Sigfox backend as Sigfox Ready devices
As a device maker building your own modem, it is your responsibility to flash the credentials into your device's memory.
The Sigfox RF & Protocol tests aims at verifying the compliance of modems and devices with Sigfox's requirements, to ensure interoperability with the Sigfox network.
Any demonstration or pilot carried out before achieving certification may result in a negative perception of the quality of the device by the end customer.
To avoid this, it is highly recommended that device makers use available tools such as the RSA in combination with the SDR Dongle to run their own pre-qualification tests.
What are the Sigfox Network Credentials?
There are three credentials to be flashed into your device's memory:
- The ID: Each ID is unique on the global Sigfox network and is independent from the Sigfox subscription.
- The key: The key is only known to your providers (modem maker, Secure Elements maker, or System on Chip maker).
- The PAC: The Porting Authorization Code is a one-time code, used to register your device in a specific group on the Sigfox Cloud. Its aim is to prevent someone from attaching their device to the device's own group without having ownership of the device.
How to obtain and activate the ‘pre-Sigfox Certification’ credentials?
- Register on Sigfox Build
Simply create a user account.
- Create a product
You can choose to create one device, a batch of devices, or a modular design.
- Request credentials for the created product
This is free of charge.
- Download the credentials
This is done directly from Sigfox Build.
Two files are to be downloaded: ID/Key encrypted file and ID/PAC clear text ASCII file
The AES key, necessary to decrypt the credentials, is also provided through Sigfox Build.
- Decrypt the credentials
See the procedure below.
- Purchase connectivity through Sigfox Buy or your local SO
A Sigfox Backend account will automatically be created for the connectivity purchased.
- Activate the device as a prototype on the Sigfox Backend
ID / KEY encrypted file - How to decrypt the Sigfox credentials
To decrypt the Sigfox credentials, you will need to use a software decryption tool based on CBC-128, along with your private encryption key (16 bytes). The key is unique for each manufacturer.
Both the key and the software ("AESd") are provided by Sigfox. AESd is a decryption tool that manufacturers can modify to match their flashing bench constraints. Sigfox provides the C code, which you need to compile into an executable for your machine.
To build your own AESd tool, use GCC (or G++) and call it from the command line:
gcc AES_Decrypt.cpp -o AESd.exe
To use AESd, call it from the command line:
AESd.exe <encryption private key> <encrypted file input name> <decrypted file output name>
AESd.exe 00112233445566778899AABBCCDDEEFF id_key_encrypted.bin id_key.bin
AESd prints the ID and NAK (Network Access Key) for each device from the list in clear format, to the standard output (stdout). It also puts into a binary file ("id_key.bin" in the above example) the decrypted binary data, which must be flashed into the device.
ID and keys are stored alternatively on 16 bytes blocks to be decrypted on-the-fly by AESd. This allows you to decrypt only the ID/KEY pair of data without decrypting the whole file, for security reasons.
ID / PAC clear text ASCII files
This file contains the ID and associated initial PAC for a specific device. Once the PAC is used for registration, its initial value is obsolete: a new PAC is generated by the backend.
The file uses this format:
Preparing for Sigfox RF & Protocol testing
This section is for you if you have decided to go for a full approach for your device. This can have benefits, but please be aware that your completed device will require a Sigfox RF & protocol testing, as you will have to integrate the Sigfox stack.
The SDR Dongle can help you prepare for that certification, thanks to its Radio Signal Analyzer (RSA) tool.
About the Radio Signal Analyzer
The Radio Signal Analyzer is a software built to test radio compliance with Sigfox essential requirements in terms of radiofrequencies. It works together with the Sigfox SDR Dongle. By delivering analysis and automatic results, it provides verification output to prepare for Sigfox RF & Protocol tests.
- CONFIGURE: Device ID, Key and Radio configuration for any Sigfox country worldwide
- TEST: Modulation, Demodulation, Ultra Narrow Band Spectrum shaping occupation, Datarate accuracy, Phase accuracy, Frequency dynamic drift
- VISUALIZE RF measurement results
- GET result overviews in the certification verdict window
- EXPORT verdicts, results and pictures
A specific laptop is required to run the Radio Signal Analyzer:
- Can boot from a USB device.
- Has at least 2 USB ports (one for the RSA drive, one for the SDR Dongle)
- Has a 64-bit compatible processor.
- Has at least 2 GB of RAM.
- Download the latest software package (ISO file).
- Install it on a USB flash drive to use it as a bootable option.
- Check the video below for a complete tutorial.
If you have any further question, go to support.sigfox.com!
Now that you are deep in development mode, definitive decisions have to be made concerning the design of your device.
We already wrote about naming rules in the Qualification step (in short: don't give your product a name that might bring confusion with the Sigfox name).
Likewise, we ask you that you do not use Sigfox's name or its butterfly logo for your product (design, casing, manual, box, etc.).
Sigfox Verified logo for certified modules
The “Sigfox Verified” label is dedicated to partner products that meet the requirements of the Sigfox Verified modular design (module or dev solution) certification.
This means that the product must first obtain the Sigfox Verified certification before it can display the logo.
Sigfox Ready logo for certified devices
The “Sigfox Ready” label is dedicated to Sigfox partner products that meet the requirements of the Sigfox Ready certification.
The "Sigfox Ready" label is also dedicated to web platforms that meet the requirement of the Sigfox PaaS program.
Logo for Partners
The "Sigfox Partner" logo can be used by any entity which has signed a partnership agreement with Unabiz or a Sigfox technology 0G Operator, and/or engaged in a Sigfox Ready/Verified certification.