Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Webinar 2: SimpleHW API 6 Why is it revolutionary?


Published on

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:

Register for more:

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Webinar 2: SimpleHW API 6 Why is it revolutionary?

  1. 1. API 6 introduction Webinar Insight 2 Hosted by: Pavel Sodomka 6.6.2019
  2. 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. 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 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. 4 major issues 1. Data/uplink interpretation 2. Getting business logic to the devices 3. Data coding/compression 4. Device control - downlink
  5. 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. 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. 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. 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. 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. 10. 2. Getting business logic to the devices Modes - currently around 60 implemented Examples: Press me Trace me Monitor me Put me back
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. Changelog and FW releases Found here: 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. 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. 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 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. 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. 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. 31. Now it is time for your questions!
  32. 32. Thank you for your time!