Source: Simple HW
So why is our API 6 truly revolutionary? API 6 is the firmware that controls your devices and interprets messages in a unique way. At the same time, it tells you how the devices communicate between the Sigfox backend and IoT platforms.
Because of the major Sigfox limitation of 12 bytes in upload and 8 bytes in download, it puts hardware producers under a lot of pressure to be smart. So now, we are going to tell you how we do it.
Simple Hardware wants to share our insights with you, so feel free to see our documentation, you can find it right here.
And the very important API 6 table can be found here.
Let’s start with the main advantages of API6:
- Future proof
- Ability to use it for many devices
- Backward and forward compatible
- Ability to do and fine tune settings for PoC within hours
- Ability to use the same device for PoC and field
- Very easily implemented into any IoT platform
- Easy to integrate into Azure, AWS, Google, SAP, Salesforce, Watson and other major platforms
4 major challenges of API6 and how we crack them
Data/uplink interpretation
The data interpretation tells you how to understand and process the data that devices gather and send to you.
- The first Byte always reports which mode (business logic) the device is in
- The second Byte lets you know what type of predefined event was detected and reported
- Depending on the mode:
- Using the third Byte as an Appended payload (additional data sent from the device such as battery voltage) mask defining following data
- Using all remaining 10 Bytes as mode specific data
Advantages:
- Human readable uplink in most cases
- Stateless data interpretation
- Clearly predefined events for further processing
- The payload is as small as possible
Getting business logic to the devices
The IoT world is starving for smart devices. We do not want to waste our battery life on pointless messages that do not provide us valuable information. Therefore, it is crucial to have a logic behind each case and device usage. Plus, Sigfox has a daily limit on sent messages. That is why we should be precise with mode choice.
A mode is a combination of what is measured, when and how long, measurement evaluation and what is sent and when. Modes are crucial for the integrators, but end customers should never switch it on their own.
Here are some modes examples: Press me, Trace me, Monitor me, Put me back, Guard me, Put me back, etc.
Data coding and compression
Our ways to do it:
- Sigfox downlink payload is limited to 8 Bytes
- Unique coding for Time (values from one second to 63 days in just one Byte)
- Unique coding for Temperature (values from -40°C to +87,5°C; 0,5°C precision in just one Byte)
- Unique coding for Voltage (values from 0 to 9,9V; 0,1V precision in just one Byte)
Device control – downlink
You have only 8 bytes, you say impossible to control the device? Not at all! The biggest challenge of device control is to understand how to implement it within Sigfox limitations, but here comes the part why API6 is so revolutionary!
This secret is in using Predefined registers in the device and Predefined database, where downlink has only a pointer address to the register and value. For instance, within 4 pairs of addresses, we can send 4 one byte values. At first sight, it does not seem a lot, but in most of the use cases, it is enough to do important changes.
If you don’t want to play with the Sigfox backend, you can still use 99% of API 6 functionality on the IO Frog platform, which was made for easy data visualization and device management and we are working closely with dev team.
Want to read more details about API 6? Check out our webinar recording and download the slides.
Best wishes,
Simple Hardware Team
