What can be achieved using just 12 Bytes in uplink and 8 Bytes in downlink? Why are there 60 different modes (business cases) programmed in SimplePack? How to choose the proper one? Watch the recording: https://www.youtube.com/watch?v=R88P3GvLRj4 Register for more: https://simplehw.eu/webinars/

1. API 6
introduction
Webinar Insight 2
Hosted by: Pavel Sodomka
6.6.2019

2. About this webinar
Who is this webinar insight for?
Sales, technical pre-sales, sales, support SO’s and integrators, IoT platforms.
Technical level:
intermediate
Format:
30 mins presentation + 15 mins Questions & Answers session
Speaker:
Pavel Sodomka, Founder & CEO at SimpleHW

3. Why API 6 ?
Sigfox limitations of 12 bytes in upload and 8 bytes in download
Normal way of device control in non-Sigfox solutions
What documentation is available where right now:
Everything over at ask.simplehw.eu with links to various documents
Very important is the API 6 table found there as well
All documentation is currently being rewritten and moved to Confluence, will be published soon

4. 4 major issues
1. Data/uplink interpretation
2. Getting business logic to the devices
3. Data coding/compression
4. Device control - downlink

5. 1. Data interpretation/uplink
1. Using always 1st Byte to report which mode/business logic the device is at
2. Using always 2nd Byte to send of the predefined Type of event
3. Depending on mode
a. Using Appended payload and the 3rd Byte as as mask defining following data
b. Using all 10 Bytes as mode specific data
Button press in Press me mode: 0130
Temperature monitoring with pipeline: 11855345584A5C4560435C41

6. Appended payload
Can be added to:
1. any event that does not have event specific payload (1-128)
2. heartbeats 1,2
1 Bytes is used as mask for interpretation
Appended can be the following data: voltage, temperature, accelerometer, magnetometer, MAC
address, boolean & humidity
Example: 01304076 (single button press in Press me mode that sends you the temperature around the
device - 18°C (0x76) in this case)

7. 1. Data interpretation
Advantages:
● Human readable uplink in most cases
● Stateless data interpretation
● Clearly predefined events for further processing
● As small payload as possible

8. 1. Data interpretation
Exceptions:
1. Stupid mode1 - sending only 2 MAC addresses at predefined time for localisation
2. Stupid mode2 - sending null payload at predefined time for localisation
3. WiFi Atlas modes - sending 2 messages and second message is just 2 MAC addresses
4. Monitor me - once you change sampling period it is not stateless, you must keep the period in
platform for proper data interpretation

9. 2. Getting business logic to the devices
Stupid vs. smart devices
Why Sigfox needs smart devices
Influence on number of messages/message size/battery life
Mode is a combination of:
● What is measured, when and how long
● Measurement evaluation
● What is sent and when
Modes are crucial for integrators but end customer should never switch modes

10. 2. Getting business logic to the devices
Modes - currently around 60 implemented
Examples:
Press me
Trace me
Monitor me
Put me back

11. 2. Getting business logic to the devices
More modes added at customer request
Examples:
WiFi High precision mode
Reed counter mode
Blink till switched off

12. 3. Data coding/compression
Sigfox downlink payload is limited to 12 Bytes
Unique coding for Time (values from one second to 63 days)
Unique coding for Temperature (values from -40°C to +87,5°C; 0,5°C precision)
Unique coding for Voltage (values from 0 to 9,9V; 0,1V precision)

13. Data coding/compression - Time
Values from one second to 63 days
First 2 bits define seconds (00), minutes (01), hours (10) or days (11)
The remaining 6 define the number 1-63 (000001-111111)
Example:
01001111
-01: minutes
-001111: 15
-15 minutes in one byte (hex is 0x4F)

14. Data coding/compression - Temperature
Predefined values from -40°C to +87,5°C found in the API 6 table
0,5°C precision)
Total of 256 values (one byte)
Examples:
0xC1 - 56,5°C
0xC2 - 57°C
0xC3 - 57,5°C and so on

15. Data coding/compression - Voltage
Values from 0 to 9,9V; 0,1V precision
Bits 7-4 define the whole number
Bits 3-0 define the decimal number
Example:
00110001
-0011: 3
-0001: 1
-the result is 3,1V (hex is 0x31)

16. 4.Device control
You have only 8 Bytes so you cannot control a lot right? Not at all.
API 6 is a unique way of controlling thousand of parameters using only 8 bytes
The trick is only a few need to be changed, not hundreds at a time
We use Predefined registers in the device
Downlink contains only a pointer address to the register and value
Using 4 pairs of addresses/values you can change 4 one byte values

17. 4.Device control
Example:
Switching the device to Temperature monitoring and setting the alert to 0°C takes up only 2 Bytes
1D50 0111
-1D50: set register 0x1D (Temp threshold A) to value 0x50 (0°C in SimpleTemp encoding)
-0111: set register 0x01 (mode) to value 0x11 (Temperature monitoring mode)
This leaves two bytes open for other settings such as appended payload and heartbeats etc.

18. Predefined values
2 sets of values directly predefined in the device:
1. Factory default default registers: circa 100 predefined
Can be changed anytime (with the exception of HW and FW registers) and device keeps the
information
2. Mode specific deltas: each mode has the described in detail in the API 6 table
Erases any customer specific data and replaces some Factory default default registers
Basically gives you a new device when you switch modes

19. Ways how to trigger Downlink request
1. Extra long press
2. Heartbeat
3. Setup by Alerts configuration (beyond scope of webinar)
4. Downlink chaining
Downlink chaining: explanation and example
If the 8 Bytes in the downlink payload are ascending, the device will request another downlink chain
If the 8 Bytes in the downlink payload are descending, no downlink request is sent
Example: 0102044507981107 - No further downlinks are requested
1107079804450102 - Downlink is requested, payload needs to be changed in the meantime in order to
get the second one into the device
If the same message is received chaining ends.

20. Heartbeats
Events that are independent of the modes
Description:
● time-triggered events
● can but don’t have to send additional appended data with the message
● without the data, the message can be used to locate the device
● 2 heartbeats can be defined
● Heartbeat3 serves for Stupid1, Stupid2 and MAC sending modes
● The first two can send different data and can request a downlink with new settings
Example:
Send Heartbeat 1 each 6 hours with temperature
Send Heartbeat 2 each 24 hours with downlink request

21. Some useful registers
Debug (0xFE)
Power (0x55)
HW configuration (0xD3 and 0xD4)
FW revision (0xD1 and 0xD2)
Set RCZ (0x69)
Set RCZ after predefined time (0x68)

22. Physical control
You can totally switch off the LED, button, buzzer
You can control the light periods and button behavior.
Currently you cannot dim the light.

23. Arming and disarming
Switching on/off the measurement/mode (not the device!)
Exception is the Press me mode and its variants
Currently you can’t switch the device off (a kill bit is being prepared)
1. Start of arming (event 0x10)
2. Departure delay (register 0x02)
3. Armed (event 0x11)
4. Disarm (multiple ways how to disarm, long press event is 0x14)

24. Misbehaving registers
Some registers such as general accelerometer or magnetometer sensitivity do not keep their values
but write them through overwriting axes specific values (they work as latches)

25. Light, logistic events, device inclination alert and
temperature threshold working in all modes
All modes support:
● Light on/off alerts (incl. customizing the % of daylight and hysteresis)
● Movement and movement end detection in all modes (logistics alerts)
● Device inclination (measured in degrees, 0-180°)
● Temperature exceeded or fell under a customized threshold

26. Changelog and FW releases
Found here: https://ask.simplehw.eu/knowledge-bases/2/articles/131-api-6-firmware-release-notes
Example: newest 6.0.76 release
New features:
Orientation change alert can be added to almost every mode
Tracking can be added to almost every mode
Temperature alert can be added to almost every mode
New Stupid mode 2 sending empty messages in predefined time periods
Reed counter sends a message only if any change happens
Fixed:
Temperature not working properly introduced in FW 71 fixed
Technical changelog of API6 is on the first tab of API6 spreadsheet.

27. Not covered in this webinar
Alerts - special settings by events
1/3 frames sending
600 bps RC1 encoding
Most of the modes
How to legally send 120 messages per hour in RC1

28. IOFrog platform support
If you don't want to play with Sigfox backend you can use 99% of API6 functionality and do all the
device management and visualisation at www.iofrog.com.
You can even set it up to use your own current connectivity or to act as a middle ware and send all the
data to your data processing and visualisation platform.

29. Advantages of API6
● Future proof
● Ability to use it for many devices
● Backwards and forward compatible
● Ability to do and fine tune settings for PoC within hours
● Ability to use same device for PoC and field
● Very easy to implement it into any IoT platform
● Easy to integrate into Azure, AWS, Google, SAP, Salesforce,Watson and other major platforms

30. Register for more
● Insight 3: IOFrog - not another Sigfox platform?
● Insight 4: Training - 7 biggest mistakes in IoT sales and how to avoid them.
● Insight 5: Why IoT is so important for Insurance companies.
● Insight 6: In LEGO boxes we trust - why we don't do end-to-end solution and the role of
partners in Sigfox ecosystem.
REGISTER HERE

31. Now it is time for your questions!

32. Thank you for your time!