In my previous post I explained how to communicate on LoRaWan with the Murata CMWX1ZZABZ module. This module is capable to support Sigfox communication also and this time we are going to see how to do it !

.

Get Sigfox credentials

As a first step we need to get valid credentials (and other data) to communicate over Sigfox. With a Sigfox classical module these information are provided by the module vendor. In the case of Murata module, the standard communication is LoRa and Sigfox is an option. As a consequence the Sigfox credential are not provided.

There are two ways to get these credentials:

• Following the Murata procedure as described by aurelq
• Using the build.sigfox.com procedure

I’m going to detail this second procedure as I do not like the idea of having a two step procedure, including the loading of a binary file not made for my target circuit and wait a long time to get 1 credential… By-the-way it is also because it sounds a standard procedure we can apply for larger cases than just the ST/Murata devkit.

1. Login on build.sigfox.com

Eventually you need to create an account on the build website to access the credential request.

2. Create a device

Click on Create a device button or go to Dashboard and click on +Product button.

Then indicate you have no certification for your device yet:

And enter a device name. The first time you will have to create an organization.

Now you have a device created.

3. Detail your device specification

Once on the device dashboard you can click on the device name and access the device details. Complete the form as much as you can.

4. Request for Sigfox credentials

Now you can request for the device credentials by clicking in the following menu:

Then you complete your request details

And click on Order credential button. Once done you need to wait for the credential creation.

What are Sigfox credentials

The credentials contains different information:

• The device ID – this is the uniq 32b ID for the Sigfox device. This is the identity of the device on the network.
• The device PAK – this hex-string is an initial value you will use to register your device on the Sigfox network. It prove you own the device you want to register. PAK is changing after every registration so it can’t be reused for transferring the device. The new PAK will be accessible on the Sigfox’s backend.
• The device KEY – this hex-array is the KEY your device will use to sign the communication. This will prove the source of the communication and will be verified on Sigfox backend. From this key are also derived the key used for Sigfox encryption. This KEY is a security key-element for your device, you need to protect it !

Get your Sigfox credential

The process to get your Sigfox credential is taking about a day (this is what it has taken to me (requesting them at 22:00 and getting them next days around 16:00).

You access to them from the Sigfox Network Credential menu on the build dashboard.

When clicking on Access credentials you can download the different files:

• id_pac.txt – it contains the deviceID and associated PAC information. This file is clear text (cvs format)

00X206XX;581XXXXXXCB07DBD;SIGFOX_BUILD_MAKER
00X206XX;F4AC9XXXXXXD48FF;SIGFOX_BUILD_MAKER
00X206XX;2EF8E82XXXXXXB35;SIGFOX_BUILD_MAKER

• id_key.bin – it contains the encryption keys. This file is AES encrypted. The key to be used to decrypt the file is the AES 128b key listed above. To decrypt this file you need to download the Sigfox decryption tool. The file is not directly AES-CBC encoded as apparently the same key is used for 2 consecutive blocs of 16 bytes then the result is used as initialization vector for next 32bytes blocs. Usually an AES-128 file works the same way but it uses 16bytes blocs.

So, as soon as you have decrypted the file you get two things:

• An output file with the binary element decoded : 16 bytes with the device ID, lower byte comes first (little-endian) followed by 16 bytes with the KEY (not big/little-endiand, just keep the order)
• The text version of this printed on the screen

00X206XX 42394XXXXXXXXXX3A7334A12CFFD4A2C
00X206XX 91AE947FFXXXXXXXXXX4E7FA1F4D8CE8
00X206XX B905ACEC2DA0XXXXXXXXXXBEDD948EAE

Let’s make the murata communicated on Sigfox now !

The first preparation steps consist in making some hardware change if you are using a devkit. The reason of these hardware change is the following:

Specific hardware configuration

The use of a sx1276 chip (made for LoRa communications) as a Sigfox transceiver is totally possible but it has not design for it. As a consequence it is a bit a hack to make it working. The signal is not totally generated by the Semtech chip but partially generated by the MCU on the flow. As a consequence during the transmission we need to have a direct & real time communication between the MCU and the Semtech chip. This communication needs to be synchronized: SX1276 and STM32 clocks needs to be the same. This is the reason of the different change made at HW level.

First of all we need to connect the TCXO (semtech clock) connected to the STM32 HSE (External High Speed clock) input. Then we need to control TCXO powering with a GPIO to be able to activate / disable this clock. This is not mandatory but to same energy it’s better to be able to stop it. To finish the configuration.

The Last change is concerning DIO4, this pin is a SX1276 interrupt used during Sigfox transmissions. It needs to be connected to one of the available pins to manage the interrupt. On the devkit, PA5 is selected.

This photo from aureleq will help you to identify the modification to be done on the ST devkit.

What is a bit tricky in the Sx1276 implementation

Update : I recently found a good quality document from ST explaining how the Sigfox libraries works. You can get it here.

In relation with this specificity, the tricky part of the STM32-Semtech communication is related to the real time data transfert between the two components during the transmission. You may not have to care about it as ST did the work and I make it cleaner a bit in my SDK. But for people looking to make their own implementation, you need to know you have to manage a high speed, in sync communication.

For this reason, the ST device will start switching its clock to HSE to be in sync with Semtech, then you have to manage a SPI communication over DMA. This communication is synchronized with a Timer generating the Chip Select signal (NSS) and the DMA triggers. That way the SPI communication will be periodic and stable. The DMA is filled with a complete transmission cycle in a circular mode. When transfer will be half completed an interrupt will load new data from the Sigfox lib to be transmitted.

I’ve spend more than a week to reverse all these settings and make a clean code working. Things done !

Test results

Once implemented and running the Sigfox RSA tool will help to verify the radio compliance with the protocol.

It allows to verify most of the radio characteristics before going for an official radio test:

You can get a synthesis of the different tests with status.

Access to the source code and test yourself

The source code of the Sigfox Murata / sx1276 driver is accessible as a part of the Disk91 IoT Open Source Sdk. This SDK includes different communication drivers for LoRaWan and Sigfox S2LP.

All the production ready feature for an IoT device are included in the SDK, a: debugging, post production configuration, IDs encryption, end-to-end communication encryption, power saving…

For getting started with the Murata CMWXAZZABZ on Sigfox, I have created a dedicated example project you can directly use. The detailed steps to use it are part of the Readme.md file of the project. You can find this Murata / SX1276 Sigfox communication on github.

The project contains credential and a valid device ID. I know it. This will help you to directly do some test with RSA tool. This device registration has not been done. If you want to perform your test up-to-sigfox, you may use your own credential following the first steps of this tuto.