Protocols, Interfaces and Communication
Follow a Sigfox Message from Warefab ESP32 Devkit to Google Cloud’s BigQuery
The journey begins with the ESP32-S SoC Module establishing communication with the Temperature and Humidity sensor on the Warefab ESP32 devkit.
Protocol
Usually sensors and microcontrollers speak several languages. To enable them exchange information, they need to agree on a common way of communication, a protocol.
This is analogous to having Person A who only speaks in Taita and Swahili and a second Person, B who speaks in Luo and Swahili. For them to understand each other, they could agree to speak using a common protocol, Swahili.
I2C communication protocol
The Temperature and Humidity sensor uses Inter-integrated Circuit (I2C) communication protocol to send and receive messages. The Protocol is intended to allow multiple “slave” digital integrated circuits (“chips”) to communicate with one or more “master” chips.
The temperature sensor has 8 pins including Serial Clock, SCL, Serial Data, SDA and address pin, ADDR Pin. The default I2C address for this sensor is 0x44. Nonetheless, address 0x45 can also be selected by connecting the ADDR pin to a high voltage signal.
Reading binary temperature data
ESP32 MCU, the Master, initiates the communication to reads data from the temperature register ( a bunch of Transistors ) by pulling the SDA line low while maintaining the SCL line high — Start condition. This tells all the devices on the bus that someone is starting to communicate. The Master then sends out the address of the device that it wishes to talk to, 1000100 (0x44).
Few exchanges and acknowledgements takes place and eventually 6 bytes Temp and Hum data is read from the sensor’s register at a particular address and transmitted to ESP32 one byte at a time.
The temperature value is sent first and then the relative humidity value. The Data and commands are protected with a CRC checksum to increases communication reliability.
After having received the checksum for the humidity value a NACK and Stop Condition is sent.
Interpreting the binary temperature data
Once in the ESP32 MCU, the temperature and humidity data is processed and manipulated by the ESP32-S SoC’s Arithmetic and logical unit using the following formulas:
SRH and ST denote the raw sensor output for humidity and temperature, respectively.
Sigfox Protocol
After the raw temperature data has been converted to raw readable string, the firmware instructs the MCU to send the data (in Hex) to the Wisol Radio Module via UART interfaces.
The wisol Module contains a software, SIGFOX protocol stack, that generates radio frames and therefore transmit SIGFOX messages. The protocol stack is composed of frame, medium access control, and physical layers covering layers 1 to 4 of the OSI model.
SIGFOX provides the protocol stack FREE of charge to modem manufacturers. It is embedded in millions of chipsets, system on chips or modules with No royalties charged.
Frame Layer
The Frame layer gets the payload data provided by the application layer and generates a radio frame. A sequence number is subsequently systematically attached to the frame.
MAC Layer
In this layer, fields for device identification/authentication (HMAC) as well as other standard parameters such as the error correcting code (CRC) are added.
The packet structure is shown above; a preamble (4 bytes), a frame synchronization part of 2 bytes, a device identifier of 4 bytes, a payload of up to 12 bytes, a Hash code to authenticate the packet in Sigfox network (variable length), a Cyclic Redundancy Check (CRC) syndromes of 2 bytes for security and error detection
For a 12-byte data payload, a Sigfox frame will use 26 bytes in total.
PHY Layer
The data is then used to change the phase of the carrier wave, a modulation technique called D-BPSK, and transmitted wirelessly with Tx Output power of 25mW (14 dBm) to the Sigfox Base Stations, BTS within the 200 kHz of the publicly available 868 MHz band.
Why change the wave of the data Signal?
The famous story goes that — if we try to throw a piece of paper away from us,the piece of paper would not go too far even if we throw it very hard. It is however very simple to get the piece of paper go a further distance if we wrap a rock with it and throw them together.
In our case, the data signal is analogous to the the piece of paper while the rock, the carrier wave. The data signal is imposed on a high frequency carrier wave changing its Phase.
Two copies of the uplink message together with the original, each 100 Hz, are transmitted at 100 bps on three unique random frequencies with various time delays, with the aim of improving reliability.
The uplink message takes an average 2s over the air to reach the base stations which monitors the 200 kHz spectrum looking for UNB Sigfox signals to demodulate.
The minimum power level at which the Sigfox BTS is able to clearly receive the frames, Receiver Sensitivity, is -142 dBm.
In an ideal situation, the device can radiate up to 16.15 dBm EIRP. At the base station, the antenna gain is 5.15 dBm.
In this case, the link budget, an account for all gains and losses from the transmitter to the receiver over the air-interface could theoretically reach 163.3 dB.
The Signals with the Temperature and Humidity data eventually gets to the base station. They are detected, demodulated and message is retrieved.
IP
They are checked further and backhauled via the Liquid Telecom backbone Network to Sigfox Cloud in a point to point link over IP protocols.
Session Layer
Sending encoded data to Google Cloud
The warefab Sigfox data automatically triggers Cloud Functions as soon as it reaches SIGFOX Cloud and the sender is authenticated. These Cloud Functions are registered as callback functions in the Sigfox backend system and are associated with the Warefab ESP32 device ID.
They authenticate the Sigfox backend over HTTPS, authorize and manage the connections between Sigfox and Google Cloud.
Presentation & Application Layer
Translation, decryption and storage of data in Google Cloud
Eventually the cloud functions forwards and publishes the encoded temperature and humidity data to a Cloud Pub/Sub topic e.g warefab-data
The data in the Pub/Sub topic triggers a second Cloud Function, warefab-pubsub-bigquery that decodes (parses) the data payloads using the Warefab ESP32 payload specification before writing them as standard columns and rows to Google Cloud’s data warehouse, BigQuery.
In the Warehouse, each bit of The Temperature & Humidity data finally lays somewhere (Google Servers) in a microscopic Transistor, having travelled from the Transistors of the Warefab Sensirion SHT — 30 (Humidity and Temperature Sensor) register, address 0x44, in just SECONDS.
Well, if this doesn’t blow your mind, nothing will!
Found this helpful? Click the 👏. Follow this publication for more tutorials on The Internet of Things.
NB-If you have any IoT concepts you’d like explained in a post, any question, comment, or suggestions, please let me know. I’ll get back to as many as I can.
Want to get supported in your IoT journey? Register
