After having tested different LoRaWan gateway like Kerlink iFemToCell, TheThingsGateway and Kerlink Wirnet, in the past two years, I was looking for a new low cost indoor gateway for deploying TheThingsNetwork (the global crowd-sourced LoRaWan network) in my city.
Gateway are not all easy to shop, Kerlink at first. As one of my iFemToCell has burned into the hell this summer with no reason after only 3 months powered-on I was not looking for the same. TheThingsGateway has different semiconductor provider reseller but myne suffer of certain instabilities actually and I need to reboot on regular basis. So that’s the reason of this new try.
In the real life you need to create a specific setup once your prototype is transformed into a custom board. This setup redefines the pin mapping, the target MCU and needs to refine the firmware transfer method as you will use and external STLINK programmer.
In this post we are going to see the different step for doing this.
I want to start a new category of posts about IoT, not focus on the technology itself but on the use-cases. That said, for sure my words will be on the technological aspects of this use-case. The objective is to let you understand what are the solution but also what are the challenges behind that use-case. To start I’ve selected the Tracking use-case, reviewing all the GPS, WiFi and operator technics.
Regarding my experience in IoT from the past 5 years, one of the biggest market for LPWAn is actually assets tracking. In number I assume alarm backup is a little bit behind but thanks to one uniq actor. Tracking is far away first regarding the number of actors already having implemented a solution in production. This is also where we find the largest number of objects on the market for a single use-case.
That’s why I decided to start with this use case. I also know it really well for being the founder of one of these solution : Foxtrackr and I’ve already implemented all the technics described below.
This IoT class is an introduction to IoT and LPWAN, it has been made to be a 2x2h teaching session for engineer school students. This class has been given to I.S.I.M.A. school in Clermont-Ferrand in 2017. This class has been completed by 2 more hours on the backend part for IoT by Daniel Petisme. It has been followed by three industrial conferences.
The content of my class had the following slides (in French):
Introduce why IoT is a revolution compared to M2M and why service matter. Introduce the different phases of a connected object design and the involved technologies. Introduce the challenge, from the technical stand point to the business model considerations.
LPWA networks needs antennas and gateway to receive the device communication and transfer them to a network kernel. You can take a look to my post on the LPWA network architecture for more details.
In the LoRaWan ecosystem we call the first part of this network architecture a gateway. There are different kind of gateway : The network operator gateway with a big and efficient antenna, capable to support external weather like the Kerlink IoT Station and some low costs solution you can deploy at home or within a building (indoor) to cover a local device fleet.
The Kerlink Wirenet iFemtoCell device is a such type of gateway. this post will review how to get start with it and what we can expect in term of coverage.
IoT design a usually a matter of antenna as already seen in different previous blog post. Antenna performance is the assurance of your capacity to deploy your object in larger zone and a way to save energy by reducing transmission power.
As we will see, if you get a hardware component and simply put it in a box its radio behavior will be totally different as the box is impacting the transmission.
This post will practically show you the impact of a box on a device radio quality.
This last monday I had the chance to meet the two Sigfox founders Ludovic Le-Moan and Christophe Fourtet during a really nice day at Labege (SigFox headquarter) with other Sigfox ambassadors.
From the meeting we had with the founders I retained some of the Sigfox strategical guide line:
Scalability – this is the major point raised during our discussions : the network must be able to scale and all what has been designed in the radio protocol & technology, as in the cloud architecture was for scalability.
Thanks to this initial design no big change are expected in the radio solution in the coming years. It has already been designed for future.
In regard to this scalability strategy we have also meet the team operating the network. I’ve seen a really nice Network Operation Center, well equiped and with about 40 people involved. It has been fun for me as in my daily job I’m managing internal inter-application communication of a large company. The volume of data we are proceeding every day is quite similar as of now but Sigfox is well more equiped than I am and better prepared for scaling 😉
Reliability – The ISM band will continue to have more and more noise on it coming from all the coming radio device using it. Sigfox design has been made to ensure a long term capacity to support this evolution. Ultra narrow band is actually the best and secure way to continue to communicate over noisy environment also protecting this common good by limiting the spectral usage.
Simplicity – Sigfox has been made to be simple to use with no parameters to tune the radio or the protocol. Everything is defined to ensure a good quality in the communications. This spirit will be kept in the future but potentially we will have the capability to tweak some of the parameters. We could imagine to limit the repetition time for frame with lower criticality. This will save power or send more frame per hour. We could imagine to get higher speed. Why not having more downlink ? Larger payload ?