Wie alles begann

Als Uli mich Anfang September überzeugt hatte, das Projekt mit den vernetzten CO2-Sensoren anzugehen, war das Berliner The Things Network eine naheliegende Lösung zur Anbindung der Sensoren. Ich hatte mich schon länger mal mit LoRaWAN auseinandersetzen wollen, da uns diese Funktechnologie und ähnliche wie z. B. NB-IoT in früheren Projekten mehrfach vorgeschlagen wurden.

Um alle Eigenarten des Systems zu verstehen, fingen wir ganz unten an und bauten einen eigenen Prototyp auf. Nach etwas Recherche entschieden wir uns für eine Kombination aus dem Radiofrüchtchen Feather M0 RFM95 LoRa Radio (900MHz) von Adafruit und dem CO2-Sensor SCD30 von Sensirion.

Breadboard-Aufbau

Wir folgten dem Adafruit TTN-Tutorial, legten unsere erste TTN-Applikation an und waren dank des Gateways auf dem Schöneberger EUREF-Campus tatsächlich innerhalb kürzester Zeit online.

Danach schlossen wir auf unserem simplen Breadboard-Layout den SCD30 per I2C an. Das Ergebnis sah und sieht bis heute so aus:

Clairchen

Zu besseren Übersicht in Draufsicht:

Clairchen Draufsicht

Wir nutzten die SCD30-Arduino-Library von Sparkfun, um den SCD30 anzusprechen und konnten mit Freude nachvollziehen, wie die CO2-Messwerte in die Höhe schossen, wenn man den SCD30 anhauchte.

Software

Bis hierher hatten wir im Wesentlichen Arduino-Beispiel-Sketches der verschiedenen Librarys zusammenkopiert. Nun ging es darum, unserem Aufbau etwas mehr Intelligenz zu gönnen.

Die größte Herausforderung war es dabei, die Anforderungen unserer Anwendung mit der Fair Access Policy des TTN in Einklang zu bringen. Unser Ziel war und ist es, Messdaten (zumindest zu relevanten Tageszeiten) mit ausreichend hoher Auflösung und möglichest geringer Latenz zur Verfügung zu stellen. Um z. B. die Entwicklung der CO2-Konzentration in einem Klassenraum während einer Schulstunde nachvollziehen zu können, reicht es nicht, drei Messwerte pro Stunde zu übertragen, und wenn im richtigen Moment darauf aufmerksam gemacht werden soll, dass das Fenster geöffnet werden sollte, sollten die Daten nicht mit einer halben Stunde Verzögerung eintrudeln.

Die Fair Access Policy des TTN schreibt vor, dass jedes Gerät max. 30 s Airtime pro 24 Stunden im Uplink belegen sollte. Die Herausforderung besteht nun darin, dass ein Gerät, das relativ weit von einem Gateway entfernt ist, einen hohen Spreading Factor verwenden muss, damit seine Nachrichten vom Gateway empfangen werden. Solcherart kodierte Nachrichten können aber leider über eine Sekunde lang werden, so dass das tägliche Airtime-Kontingent schnell verbraucht ist. Deshalb haben wir für unseren Prototyp die Mess- und die Übertragungsfrequenz vom jeweils aktuellen Modulation and Coding Scheme abhängig gemacht. Die Details unseres so entworfenen Übertragungsschemas sind in einem Design-Dokument beschrieben.

Leider lassen sich für viele kommerziell verfügbaren Sensoren die Übertragungschemata nicht in ähnlicher Weise anpassen, was sie, sofern nicht ausreichend Gateways zur Verfügung stehen, für das TTN in unseren Augen schnell unattraktiv macht.

Der Quellcode für unseren ersten Prototyp ist auf GitHub verfügbar und die Aufbauanleitung für Bastler haben wir hier nochmal etwas strukturierter zusammengefasst.

Diesen Beitrag teilen: