IoT Open Platform: Connectivity Solutions

Project Overview

This project is my final bachelor’s thesis. It builds an IoT platform for citizen science, where volunteers deploy sensor nodes to collect environmental data in the field.

The device targets deployments where Wi-Fi is unavailable. It connects via LoRa (Long Range) radio when no internet infrastructure is present, and falls back to Wi-Fi when it is. Configuration happens wirelessly over BLE, and settings persist across power cycles using non-volatile memory. The thesis focuses specifically on the connectivity layer: how nodes discover each other, access the shared radio channel, and deliver data to a gateway within regulatory constraints.

Solution Implemented

The final result is a prototype device configurable via Bluetooth Low Energy (BLE). During setup, the device receives Wi-Fi credentials (SSID and password), which are stored in non-volatile memory (NVS) to persist through deep sleep cycles. If no Wi-Fi is configured or the credentials are invalid, the device automatically falls back to the custom LoRa protocol.

This custom LoRa protocol operates on a 60-second loop, during which each node transmits sensor data in an ordered and optimized manner. The protocol avoids collisions between node transmissions and remains compliant with EU radio frequency regulations.

Design Process

Step 1 — LoRa Foundations

Understanding how LoRa works: modulation basics, spreading factors, and long-range propagation characteristics.

Step 2 — ETSI Regulations

Studying European frequency band restrictions at 868 MHz, duty cycle compliance (≤1%), and Polite Spectrum Access requirements.

Step 3 — Medium Access Protocols

Evaluating CSMA and TDMA approaches to handle multi-node access in a LoRa network without a central synchronization clock.

Step 4 — Optimal SF Calculation

Designing an algorithm to select the optimal Spreading Factor per node based on RSSI and SNR, minimizing Time-on-Air and duty cycle usage.

Step 5 — LoRa Protocol Definition

Designing the message structure and communication flow: Beacon, Request, Schedule, and Data message types.

Step 6 — Slot Negotiation

Implementing a TDMA slot assignment mechanism where the gateway assigns time slots and optimal SF to each node after the initial CSMA-based handshake.

Implementation

Protocol Characteristics

Up to 4 Nodes

Supports up to 4 field nodes and 1 gateway in a single network.

SF Optimization

Optimal Spreading Factor calculated per node based on RSSI and SNR.

Energy Efficient

TDMA-based scheduling enables deep sleep between transmissions.

Data Persistent

Configuration stored in non-volatile memory (NVS) across power cycles.

ETSI Compliant

Duty cycle ≤1% at 868 MHz with Polite Spectrum Access support.

Collision Avoidance

CSMA for initial access, TDMA for scheduled data transmission.

Medium Access Control

Since LoRa does not natively support any medium access control, two complementary approaches were implemented:

CSMA (Carrier Sense Multiple Access) is used during the initial phase of communication. Without a central clock to synchronize all nodes from the start, each node listens to the channel before transmitting. If the channel is busy, the node waits one second and tries again. This mechanism avoids collisions during the bootstrap phase and satisfies the Polite Spectrum Access requirement defined by ETSI.

TDMA (Time Division Multiple Access) is used once the gateway knows how many nodes are present. The gateway assigns a specific time slot to each node, so every node knows exactly when to transmit, eliminating the need to listen before sending. This simplifies node logic (nodes act as slaves, the gateway as master) and allows nodes to sleep between their assigned slots, significantly reducing power consumption. Even in TDMA mode, Polite Spectrum Access is respected before each transmission.

Spreading Factor Selection

To optimize LoRa communication between the gateway and nodes, the optimal Spreading Factor is calculated per node based on the received RSSI and SNR. A lower SF results in a shorter Time-on-Air and lower duty cycle usage for nodes with a strong signal.

uint8_t calculateOptimalSF(float rssi, float snr) {
  const int sensitivitySF[] = { -125, -127, -130, -132, -135, -137 };
  const float snrLimit[] = { -7.5, -10.0, -12.5, -15.0, -17.5, -20.0 };

  for (int i = 0; i < 6; i++) {
    if (rssi >= sensitivitySF[i] && snr >= snrLimit[i]) {
      return 7 + i;
    }
  }
  return 12;
}

Message Types

All messages share a common header with the following fields:

Message type (2 bits): 00 Beacon · 01 Request · 10 Schedule · 11 Data
Gateway flag (1 bit): 0 = node · 1 = gateway
Reserved flags (5 bits): reserved for future use
Transmitter node ID (8 bits)
Receiver node ID (8 bits)

Message	Sender	Purpose
Beacon	Gateway	Announces the gateway on the configured channel
Request	Node	Confirms Beacon reception and requests transmission resources
Schedule	Gateway	Assigns optimal SF and time slot to each responding node
Data	Node	Transmits sensor readings to the gateway

The Schedule message carries per-node assignments: node ID (8 bits), optimal SF (3 bits), and slot index (2 bits). In the worst case with 4 active nodes, the Schedule message reaches 76 bits (10 bytes).

Conclusions

This work builds a low-cost, open-source IoT platform that operates in environments with limited or no Wi-Fi connectivity. BLE configuration, NVS persistence, and a custom LoRa protocol let the device adapt to different deployment scenarios without manual reconfiguration.

The LoRa protocol handles node discovery, medium access control, spreading factor optimization, and data collection within a 60-second cycle, while staying compliant with ETSI duty cycle regulations at 868 MHz. The CSMA-to-TDMA transition provides flexibility at startup and efficiency during steady-state operation.

Future work could extend the platform to support more nodes, additional sensor types, and more robust over-the-air configuration mechanisms.