This was 2 years ago during the first Sigfox connect event: Christophe Fourtet was on stage opening a letter and this action was firing a Sigfox message. He was announcing Admiral Ivory service. He was announcing $0.20 solution able to communicate on the Sigfox network. Since this date, the Admiral Ivory service has just been a strategic vision proposed by Sigfox for a future low cost IoT, far from the device maker day to day reality. Far from the minimum $10-$15 devices we currently produce coming with its $2-$5 yearly subscription fee.

Could we imagine, this two years old vision will be the next semester reality ?

Being in relation with the Sigfox lab, I’m back with some really good news about making this vision becoming a reality, let see how it is going to be possible.

What are we talking about ?

The Sigfox vision proposed by Ludovic Le Moan two years ago was a really low cost hardware solution ($0.20) supported by a more complacent network with the emitted radio signal.

The idea behind was to make the Sigfox network able to accept lower radio quality signal, coming from ultra low cost chip. This is the strength of the Sigfox network: its asymmetric design allows to move the complexity on the network side to simplify, again and again, the device side design.

Basically, the idea was to use radio design coming from large public solutions like remote control for garage door. This domains has radio solution around the $0.25 targeted price allowing $1 finished device creation. The challenge is to make these devices able to generate a Sigfox compatible radio signal and to make the Sigfox network able to support communication coming from such devices.

Today, these are challenges that are a few weeks away from being raised.

Use cases

Making a $1 Sigfox certified device, all included, MCU, Radio, antenna, battery, casing is going to be possible in the next months. For real !

Even if the $1 target still correspond to large volume, it means you can make small quantities under $2… A full finished object for today module’s price.

It’s now time to imagine all the new use-case we can make with it… and rush on them !

Supply chain as an immediate target

Making a $1 IoT device able to report 1 or 2 different messages is an enabler for supply chain applications: The Altas solution is well working with low cost devices to get a location, like a city, a facility in association with bubbles or Micro-basestations. A second type of message can report a status: open/close, vertical/horizontal, correct/incorrect temperature.

As a consequence you can track goods flow, monitor stock level even on client side for reordering.

Traceability chain as a derivative market

Directly derived from the Supply chain use-cases, the traceability use-cases are becoming possible for low value goods, individually. It can support different status, register location, associated timestamp, identify operation on product.

Goods usage as an innovation area

Tracking any existing goods industry product to have information on its status (produced, stocked, distributed, locally stocked, installed at customer) becomes possible.

Tracking good usage by final user by reporting action on it, transparently, is now possible.

What else ?

Many use cases are not listed here, the limit is your imagination. This is just a “no cost” solution able to communicate all over a zone like Europe on its own with no configuration, no power source…This is a demonstration of what the technology can deliver just tweaking some network parameters.

Sigfox, with a such evolution, wants to demonstrate its network ability to be tolerant and evolutionary. Christophe Fourtet would add Cognitive.

What hardware can be used for a such challenge ?

It’s now time to understand where this new capability is coming from and why it is accessible right now.

A really low-cost micro-controler

The Sigfox lab team retained a really low cost MCU integrating a radio module. This integrated solution, used in garage remote controller, is a CMOSTEK CMT2189C. This device only costs $0.28 per 2500 pieces / $0.25 per 25K pieces according to the quotation I’ve obtained. It does not need expensive side components as you can see on the following the circuit. This circuit is just what you need to do to fire a Sigfox message.

This chip contains a MCU based on a 8b PIC-like. It has 2KB flash, 256B EEPROM and 128B SRAM. It can run up to 16MHz but Sigfox is only requiring a 2MHz rate for energy saving. Its sleep current is about 0.8uA. How to support Sigfox protocol with a such solution is an interesting challenge we are going to discuss in the coming chapters.

The MCU has 4 GPIO, no ADC, not I2C…. this solution is basic, really basic according to its cost.

This chip also contains a radio chip, able to manage OOK, GFSK and FSK radio transmission on 240Mhz to 960MHz. Hum…. Sigfox is BPSK so here is a second challenge to be managed ! Nothing impossible for someone who wants to drastically reduce their costs.

This solution will impose a first compromise: the device will only be able to uplink data.

How to hack it to create a Sigfox compatible signal ?

This low-cost chip is able to modulate OOK, FSK and GFSK, but Sigfox modulation is BPSK. This is a challenge but not a big challenge. In fact this challenge has been already managed in the Telecom Design module with one of the best radio quality for Sigfox transmission I’ve seen.

OOK has one frequency to transmit or not to get a 1 or a 0. FSK has two different frequencies each of them is encoding a 1 or a 0. But in BPSK we have one frequency and the phase of this frequency is encoding the 1 or the 0 indirectly. A radio chip able to create OOK and FSK has not been made to switch the signal phase as BPSK is requiring it.

The solution to hack this issue is simply to jump from the desired frequency to a lower or higher frequency. This change with low down or accelerated the signal generation, so once you come back to the original frequency, the phase will be shifted compared to the initial point. The code is basically easy to write to obtain a such result, the main point is to precisely manage the timing to ensure getting the 180° phase shift.

In a normal Sigfox modulation, during the phase shift change, the Sigfox signal is reduced to limit the impact on the spectrum footprint. This is the reason why we can receive Sigfox communication with an AM demodulation short range. But in a really low cost implementation the power reduction is too complex to implement. As a consequence, the spectral occupation will be larger for a such low cost product. As a side effect, the current version of the Radio Sigfox Analyzer, based on AM demodulation will not be able to decode the frames.

How to manage the Sigfox protocol in a such small MCU ?

Last challenge is to manage the Sigfox protocol with a really small MCU only having 37 assembly instructions. It has no MUL no DIV operations, only 1 bit barrel shifter… Also considering the 128B ram, calculating an AES128 value for managing the HMAC is just impossible.

The HMAC computation challenge

How to deal with it ? Like we did with 3d rotations when I was 14: coding realtime 3d on 16bits intels… pre-computation. It means the way to solve the problem is to precompute all the possible frame to be transmitted and store it in the Flash.

It has a lot on consequence on the use case but efficient. Imagine you just need to send a signal to report an action like Ludovic did on stage. You fire a message when the letter has been opened. There is no data to transport. So the only changing element in the frame is the sequence Id, reserving 1 KB of the flash for this storage, you can store 512 different precomputed HMAC (2byte each). As the sequence number number is modulo 4096 you will have to generate a sequence ID incremented by 8 on every communication to make it working as a normal object.

Imagine you now have to manage 2 different states: open / close. You have 1bit change + seqNum. So for each of the combination you need to manage HMAC. It means you will have to increment the seqNum by 16 and to store 2 tables of 256 precomputed HMAC values for each of the bit value.

Ok, so why not having 256 different values to report temperature ? This means 4×256 precomputed HMAC with a seqNum increment by 1024. Simple no ? In fact it is not, in this case, the seqNum protection on the sigfox backend will be armed and the messages after the second one may be trashed. Ok… let’s disengage the sequence number after each messages and it works !

The security deal

Ok, that’s working, but nothing is totally free: by reducing the number of possible HMAC/seqNum you directly expose your device to replay attack. It it a real problem … good question, it depends of your use case and the potential financial stakes. It’s on your own.

We also agree, if you are not able to compute a AES128 locally, if you do not transport data and your data is 1 bit to 1 byte limited… encryption is not a real question.

What else ?

Nothing in fact, the other protocol parts are locally generated. Most of the frame structure can be hardcoded as ID, Size are fixed. CRC as the repeat scrambling can be dynamically computed. You need nothing more.

The EEPROM is large enough to store the ID and the seqNum. You do not need to store the Private Key as all the HMAC are precomputed. The PAC has no reason to be stored in the chip other than on modules.

Once the device reach the industrialization phase you will have to manage the Flash content dynamic generation as all the devices will have different HMAC stream. This is not a challenge, just something to think about.

Ok, if you are not satisfied by this solution, you can also take a look to the standalone radio chip CMT2119A ($0.15 / 100k pces) and coupling it with a stronger MCU adding some cents.

How to deal with Quartz based clock ?

The second challenge to deal with is the clock drift. Sigfox is ultra narrow band with a 100Hz bandwidth. The precision of the frequency is not really important as much as the signal stays in the 200KHz listen by the gateways. What is important is to not have a frequency drift during the communication. A variation higher than 20Hz/s to 30Hz/s will not be supported, this is corresponding to 0.034ppm at 868MHz. That’s really strong requirement.

Making a <$1 device is possible when using a crystal clock, not a TCXO. A crystal clock is subject to frequency drift as soon as the environment is changing. The wait to hack this challenge is to protect the Quartz against the environment. As an example, a quartz located in a couple of mm near the MCU will be impacted by the MCU temperature increase al along the transmission. The solution is to move it far away and to isolate it from the ground plan. It also need to be protected against air, wind, anything that can have an impact during the 1 repeat transmission time.

The second quartz design particularity is to limit the injected power to reduce warming and drift.

Battery challenge

Next important point to consider is the battery solution related to this solution. For a standard Sigfox objet, you need to have a battery able to support 25-50mA (RC1) during a 7 seconds transmission burst. You target 1-10 years autonomy and for these reasons the battery cost is major.

Considering a $1 device the battery cost limit is about $0.1 – $0.2. For this price you can get CR2032 battery, not much more. Eventually small LiPo if you take the risk to have a higher voltage than spec allows.

The Lithium battery have small capacity but also a small acceptable currant pic. Reducing the transmission power lower than 14dBm is enabling a such battery usage, but works with denser network.

With a such battery you have a 100-200mAh capacity. This capacity is really small but in RC1, it allows (considering the impact of 24mA pulses on battery life) about 100 messages transmission with N=3 (all standard repeat). This is compatible with a lot of rare event use-cases and short life devices. Tracking a postal letter could be 1 message / hour + 1 messages on opening. This is 4 full day autonomy ; good enough.

CMT2189C chip transmission current for 10dBm is 22mA with a single ended antenna but it can be reduced to 15mA with a differential antenna.

The main technical impact coming from battery is the voltage drop during transmission. This one, impacting the internal RC clock, will directly impact the transmission baud-rate. For this reason, a Lithium battery sound better than a LiPo. For this reason the Sigfox network is impacted.

What are the Sigfox network impacts ?

Ok, so, up-to-this point, we have seen nothing new, nothing impossible to be done since the past 2 years. The CMOSTEK chip is old enough. So what’s new in 2019 ?

Radio impact of a such design

Making a such design will have an impact on the Sigfox network. The first reason is regarding the way the BPSK is generated, the use of a Quartz and the ultra-low cost radio chip, the radio template is not respecting the Sigfox requirements. Differently say, this device is not passing the current Sigfox certification process, which should be updated soon with specific requirements for such solution.

The main reason is the device bandwidth is larger and it directly impacts the network scalability.

To accept this kind of low quality Sigfox modulation, there was different thing to do on the Sigfox network: densify, upgrade the radio demodulation for being more tolerant and identify the acceptable conditions to support it. All this has been done. Thanks to its asymmetric approach, the complexity of supporting a such solution has been managed on the network side.

The picture on the left side is the FFT of a message coming from a 1$ device. You can see the frequency drift related to the way the phase shift is generated. This can be compared with the FFT of a message coming from a classical Sigfox device on the right.

Sigfox will soon publish a specific certification for accepting such transmitter. With one constraint : limiting the transmission power to +7dBm instead of +14dBm in Europe. This power reduction have an impact on coverage but is protecting the network scalability and also allows to use smaller batteries.

Baud rate drift

The battery drop coming from the use of small capacity lithium button batteries directly impact the baud rate. The Sigfox network also have to be tolerant to these instabilities. A coming network upgrade will soon offer a better support of baud-rate drift. As a consequence, this will also be part of the coming new specifications.

Coverage

A low cost device have a limited transmission power as we seen previously. As it has a PCB antenna for cost efficiency, its capacity to reach the network is reduced.

As an example we have such indoor difference with a standard Sigfox device (let’s also consider all the basestations updates have not yet been deployed):

standard device indoor

low cost device indoor low cost device outdoor

Even if the antenna matching was not yet done in the test above, it sounds currently safer to consider out-door applications or include Sigfox micro base-station deployment in an indoor project.

It sounds also interesting to invest in a PCB antenna design for a such product to be sure your device will deliver the best of the +7dBm allowed.

What about the radio zone ?

This kind of device, to be really low cost, must be dedicated to a specific use-case. Do not think about making something generic, world-wide, Monarch compatible…

As much as I know, this kind of design supports 100bps as 600bps. It works 868 and 915Mhz. The transmission power constraints over 915Mhz zone is not yet defined. The consequence on batteries could also be a pain point.

Business model impact

The coming new certification specification may be published for Q1 2020 but this is not the only impact on Sigfox offering:

The second impact is related to the Sigfox subscription model. How can you imagine a “trashable” device (ok, that’s bad to think about …) with a $1 cost… running a $5 service per year with a 1 year minium subscription ?

Sigfox need to move to a new subscription model to support this type of devices. Something like a pay-per-use approach, with a message cost ?

I’ve no input about this point, but it will be the key point to get something dedicated really quickly to not kill the potential related use cases. Here could be the real Admiral Ivory offer.

I would like to thank the Sigfox technical team who helped me to get access to the technical details on this technology and answered my numerous questions. Christophe J, Cédric B, Loic H, Nicolas N, Nicolas C, … You rock !