In a previous post, I was complaining a bit about the Sigfox API. At this time Sigfox was already working on a new version of the APIs.
Today Sigfox released the API version 2 for managing devices, subscriptions, messages… And this new version based on REST and JSON standards is a really positive rupture compared to the previous one.
More than a new version of the API set it’s also the full deployment of some of the new backend components now accessible by the API deployment. As part of this the 2018 deployed new Group entity, the asynchronous device creation/edition processing and the coming replacement of the callback duplicates to the equivalent with API.
As part of this APIs also some coming features like different level of geolocation precision, payload encryption and many more…
Posted in Sigfox
Tagged API, SigFox
This was the more expected announcement for Sigfox Connect event: the availability of the micro-gateway: a Sigfox gateway you can buy, own and deploy on your own location.
This was expected to be introduce has it has already been disclosed once FCC certification made it public as it has been noticed by Nestor Ayuso on twitter some days ago.
This model is standard for LoRaWan ecosystem running on private network as on public network. For Sigfox it has always been possible to expend the network but it was a little bit complex because you had to rent the basestation from Sigfox and the basestation itself was an operator equipment: something made for being installed on a roof, not in your office.
Sigfox is now proposing the micro-gateway !
As part of the R&D announcement during Sigfox Connect 2018 a passive Sigfox tag has been introduced. I’ve seen the demo made by Christophe Fourtet and the technology is really promising.
Basically a passive tag is a tag with no battery. The one actually seen it really near to be a passive tag. This tag is receiving power from a radio signal and with this power respond with a radio message. In the Sigfox context this radio message is a Sigfox message. What is really strong with this technology is the low level of power to be provided to get it working. I’ve seen it working with less than a watt and a distance larger than 10 meters with not any radio optimization on the prototypes. The radio message, thanks to the Sigfox communication technology can reach a distant basestation getting benefit of the large Sigfox radio range. The use in conjunction of a micro-gateway sounds a good idea. The global solution looks to be a low cost and easy to deploy solution for asset management & tracking.
Posted in Sigfox
Tagged rfid, SigFox
As a coming soon produit, widely available as an open design, Sigfox has introduce during the Sigfox Connect conference the Bubbles: They are basically a Sigfox Beacon.
Working on the technological basis of the Monarch technology the bubble allows a device to identify the zone where it is. This is basically a kind of solution existing on bluetooth, LoRa but Sigfox was not positioned on it. This is now fixed with the Sigfox Bubble technology.
Compared to bluetooth the Sigfox solution is offering a large range of operations: thanks to the long range communication capability, you can imagine to cover a zone like a complete building or a parking as a single cell ; this is for future as the current technical offering is covering 10 meters max. Like on bluetooth you can manage the beacon power to reduce the cell (bubble) size to 1 or 2 meters and get your device position on this range. On top of this with no technology addition, you get access to the Atlas service locating your device on public area with the usual 1km precision.
The main difference with other technologies comes with the service proposal. Bubble is not just a technology ! Following the Sigfox business model, Bubble is a manage service: you have your bubble devices managed by Sigfox, you are able to share positions with business partner across the bubble global network and you get benefits of the public Bubble network operating on different point of interest.
This service is where the disruption starts !
GNURadio is an open-source software for making Software Defined Radio. It can be used to model a radio transmission or the process a real radio communication.
Scapy is a python tool set able to interact with GNURadio. Basically GNURadio will receive an signal from a SDR key and process it to get a digital sequence. Scapy will process this sequence and potentially generate a new sequence to be process by GNURadio to be transmitted.
There are plenty of example of GNURadio/Scappy usage to hack, simulate, learn many radio protocols like WiFi, GSM, Bluetooth… I want to play a little with Sigfox also so that’s why I started to investigate on this tool.
As this tool is a bit complicated, this post details the key element having helped me to getting started with this tool.
This is a Frequent question I received from many hackers or companies: How can I get a Sigfox subscription for my IoT device?
We need to start saying a Sigfox subscription is a right to have its device data to be proceeded for a year. In the LPWA technology there is no SIM cards or any physical things attached to the subscription. You buy a device from a semiconductor company, when this device is compatible with Sigfox you have an ID attached to this device. This ID is uniq and used to identify the device on the Sigfox network. So once you have a subscription, you attach this subscription to this device ID then you will be able to access your device data from the Sigfox backend.
That’s clarified we can address the question of this post: what are the way to access a subscription?
Posted in Sigfox
Tagged LPWA, SigFox
Since I’m using Sigfox backend there are a lot of operations I’m regularly manually doing. Thanks to the Sigfox API, it is possible to automate these manual operations to gain in productivity and save time.
The most consuming operation were for me to manage the device type because each of them have multiple callback and every callback uses many parameters. The callback replication is for me a recurrent operation when adding a new contract, when creating a new version of application, when instancing for dev, prod… It’s also a complex operation when you have to ask a third party ( like a client ) to configure a device-type for connecting to your service. As a consequence these operations are the first one I’ve automated thanks to the Sigfox Api.
I’ve decided to publish this usefull code to let you saves time on these operation with a new set of API accessible on IngeniousThings Sigfox Api portal and available on GitHub as OpenSource.
In this set of API (actually 3, will grow) you will find operation to export/import a full deviceType configuration and to duplicate a DeviceType.
Have fun !
Posted in Sigfox
Tagged API, backend, SigFox
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.
Posted in IoT
Tagged gps, IoT, LoRaWAN, LPWA, SigFox