Seite 3: Software

Inhaltsverzeichnis

Beim Entwickeln der Software gab es zwei Herausforderungen. Zum einen musste maximale Ausfallsicherheit erreicht werden, da die Sensoren beim Transport und Betrieb über Wochen autonom arbeiten sollen. Zum anderen sind die Ressourcen eines normalen Arduino begrenzt, es stehen nur 2 Kilobyte Arbeitsspeicher zur Verfügung. Zahlreiche Speicherprobleme gab es mit der String-Bibliothek, sodass ich, als Hobbyprogrammierer, erstmals auf C-Funktionen ausweichen musste. Am Ende funktionierte alles gut und es war sehr befriedigend zu sehen, wie der Speicherverbrauch Kilobyte um Kilobyte mit jeder Optimierung des Codes (Software siehe Link am Ende des Artikels) nach unten ging. Hier zeigte sich, dass Programmierung für Embedded Devices sehr viel anspruchsvoller sein kann als etwa Web-Programmierung, wo im Vergleich nahezu endlose Ressourcen zur Verfügung stehen. Wenn irgendetwas schiefläuft, kann ein Web-Service neu gestartet werden. Bei einem Arduino, der 3000 Kilometer entfernt in einem Baum hängt, ist das nicht möglich.

Ein Solar-Panel muss her!?

Für das re:publica-Projekt war ein Solar-Panel nicht direkt erforderlich – allerdings für die Vision, die Sensoren dauerhaft autonom zu betreiben. Der erste Gedanke war, das Fona-Modul mit einem Solar-Panel über seine vorhandene Lade-Elektronik mit der angeschlossenen Batterie zu laden. Das funktionierte zunächst, die Lade-Lampe leuchtete selbst bei geringem Lichteinfall auf. Dann wurde klar, dass Lithium-Polymer-Akkus spezielle Elektronik benötigen, um die extrem variierende Spannung des Solarmoduls auszugleichen. Der Akku wurde vom Solar-Panel nur betrieben, nicht aufgeladen. Entsprechende Module gibt es, leider teuer oder kompliziert zu konfigurieren. Für die Installation auf der re:publica haben wir sie nicht verwendet, testen aber derzeit, ob die Sensoren dauerhaft mit Solarenergie betrieben werden können.

Ein passendes Gehäuse

Das Gehäuse sollte wetterfest und lichtdurchlässig sein, genügend Platz für Arduino, Sensor und Batterie bieten sowie gegebenenfalls das Solarpanel aufnehmen können. Wir begannen mit einer speziellen Variante: Weckgläser. Inspiriert von der Firma Seeed, die mit ihrem ArchGPRS-Projekt schon mal einen ähnlichen Ansatz verfolgte. Also wurde der erste Prototyp in ein Weckglas gepackt, verschlossen und draußen an den Baum gehängt. Das konnte nicht gutgehen. Zwar verfügt das klassische Weckglas über eine Gummidichtung und sogar einen Spann-Verschluss, die Abdichtung kommt bei eingekochter Marmelade aber durch den Unterdruck zustande, den der langsam abkühlende Inhalt verursacht. So befand sich der Arduino nach wenigen Tagen unten in einer kleinen Pfütze.

Nun konzentrierten wir uns auf zwei Gehäuse-Familien. Zum einen die Otterbox, die es in verschiedenen Größen gibt, zum anderen das "project case" von Adafruit, ebenfalls in mehreren Größen verfügbar. Die Otterbox ist extrem stabil (angeblich kann ein Auto ohne Schaden drüberfahren), hervorragend verarbeitet und hat einen praktischen, sehr gut abdichtenden Schließmechanismus. Leider ist das Gehäuse nur mäßig lichtdurchlässig und etwas eigenwillig geformt. Die Wahl fiel auf die eleganten quadratischen Gehäuse von Adafruit, die einen transparenten Deckel haben und ebenfalls über gute Abdichtungen verfügen.

Zwei Fragen bleiben offen und müssen im Praxisbetrieb geklärt werden: Erstens konnten wir nicht ermitteln, ob Probleme durch Kondenswasser entstehen, wenn sich die Elektronik aufwärmt und die Außentemperatur sehr gering ist. Hier müsste vielleicht für Luftausgleich gesorgt und Material beigefügt werden, das überschüssige Feuchtigkeit aufnimmt. Zweitens bleibt die Frage, ob das geplante Solar-Panel im Gehäuse oder außen montiert werden sollte. Das Panel verliert an Leistung, wenn es hinter einem Acrylglas betrieben wird, es könnte verschmutzen und beschlagen. Erste Dauertests mit dem im Gehäuse angebrachten Solar-Panel verliefen vielversprechend. Demnächst werden wir Varianten mit außen angebrachten kleineren Panels testen, die sich auch selbst ausrichten.

GPS ohne GPS

Auf ihrer Reise durch Europa wollten wir die Sensoren verfolgen. Ein GPS-Modul für den Arduino kam nicht in Frage, da es viel Strom benötigt, Ortung nur bei Sichtkontakt zu Satelliten funktioniert und es uns zu teuer war. Im GSM-Netz gibt es eine spannende Alternative: viele GSM-Module können die GPS-Koordinaten der aktuellen Mobilfunkzelle per AT-Befehl auslesen. Die Angaben sind ungenauer als echte GPS-Daten, aber sie stehen kostenlos und ohne zusätzliche Hardware zur Verfügung, auch wenn das Modul keinen Sichtkontakt zum Himmel hat. In den Liefer-LKWs der Post-Dienste hätten GPS-Module nur selten ein Signal empfangen – unser GSM-GPS funkte zuverlässig einmal pro Stunde die aktuelle Position durch.

Kennzeichnung, Datenschutz und Transparenz

Das Internet of Things bringt große Herausforderungen im Datenschutz mit sich. Daher wollten wir mit Lösungen herumexperimentieren. Wir statteten die Sensoren mit einem QR-Code aus, der auf die Thingspeak-Seite des Projekts verwies. Dort konnten die Sensor-Daten sowie weitere Informationen zum Projekt und zum Sensor-Standort nachgelesen werden. Zukünftig könnte es wichtig sein, zusätzlich auf dem Gerät mit allgemein verständlichen Symbolen aufzuklären, was es konkret tut. Verarbeitet es personenbezogene Daten? Werden diese Daten mit anderen Parteien geteilt? Liegen Quellcode und Hardware-Design des Gerätes unter offener Lizenz vor, sodass überprüft werden kann, was das Gerät genau tut? Auf diesem Feld ist noch viel Arbeit vonnöten, wenn das Vertrauen der Passanten in das Internet of Things nicht verspielt werden soll.