Plattfuß lässt grüßen: Automatische Aufzeichnung und Analyse der Qualität von Fahrradwegen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Nachhaltige Kommunikationsnetze
Universität Bremen
Prof. Dr. Anna Förster
Bachelorarbeit
Plattfuß lässt grüßen: Automatische
Aufzeichnung und Analyse der Qualität von
Fahrradwegen
von
Ivan Reichert
Matr.-Nr. 3059324
Bremen, den 30. Januar 2021
Betreut durch:
Prof. Dr. Anna Förster
Prof. Dr. Peter Haddaway
Dipl.-Ing. Jens Dede
Ich versichere, daß die vorliegende Arbeit – bis auf die offizielle Betreuung durch den Lehrstuhl – ohne fremde Hilfe von mir durchgeführt wurde. Die verwendete Literatur ist im Literaturverzeichnis vollständig angegeben. Bremen, den 30. Januar 2021 (Ivan Reichert)
ZUSAMMENFASSUNG In einer stetig wachsenden Globalisierung werden immer mehr Grünflächen in der Stadt zugebaut und mit städtischem (urbanem) Chaos gefüllt. Deshalb achten Menschen, die von Natur mit der Welt um sie herum einig sind, darauf, dass ihr Weg zur Arbeit/Schule mög- lichst angenehm ist (ruhige Umgebung, saubere Luft). Bei der Wahl dieses Weges lassen sich die Menschen entweder von ihren eigenen Beobachtungen oder von den Beobachtungen anderer leiten und haben kein vollständiges Bild von der Stadt um sie herum. Das Ziel dieser Arbeit ist, solchen Menschen zu helfen, den besten Weg zwischen zwei Punkten zu finden, damit sie sich in den Momenten, in denen sie von zu Hause weg sind, wohl fühlen. Darüber hinaus wurde entschieden, die Sammlung von Umweltdaten in Form eines Dienstes zu organisieren, mit dessen Hilfe die gesammelten Daten ausgewertet und ein ökologisches Bild der Stadt erstellt werden konnte. Um das Dienst mit den Daten zu befüllen wurde eine mobile Messstation gebaut, die die Sammlung von den wichtigen Umweltdaten (die Feinstaubbelastung, der Geräuschpegel) ermöglicht. Die Daten werden von der Messstation zum Handy (Android-Anwendung) verschickt, wo sie mit den Metadaten ergänzt und an den Server übermittelt werden. Auf dem Server wurden die Streckenauswertung-Algorithmen entwickelt und eine Weboberflä- che gefertigt. Die Ergebnisse zeigen, dass die Daten schnell gesammelt werden können und somit das ökologisches Bild der Stadt erstellt werden kann. Aus diesen Gründen sollen mehrere Messstationen gefertigt und kostenlos an die Benutzer in verschiedenen Stadtteilen verteilt werden, um die Datenbank mit den Daten zu befühlen.
INHALTSVERZEICHNIS
Zusammenfassung 1
1 Einführung 5
2 Systemanforderungen 7
2.1 Allgemeine Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Anforderungen an Hardware und Embedded Software . . . . . . . . . . . . . 7
2.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Embedded Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Anforderungen an die Android-Anwendung . . . . . . . . . . . . . . . . . . 8
2.3.1 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Anforderungen an den Server . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2 Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Anwendungsfälle 10
3.1 Die Messung der Daten mit der Messeinrichtung . . . . . . . . . . . . . . . 10
3.1.1 Der Messablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Mögliche Kommunikationskanäle . . . . . . . . . . . . . . . . . . . . 10
3.1.2.1 Mobilfunknetz . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2.3 Drahtloses lokales Netzwerk (WLAN) . . . . . . . . . . . . 12
3.1.3 Kommunikation zwischen ESP32 und Android Gerät . . . . . . . . . 12
3.1.3.1 Auswahl des Datenformats . . . . . . . . . . . . . . . . . . 12
3.1.3.2 Spezifikation des Datenformats - ESP32->Andorid-Anwendung 13
3.1.3.3 Kommunikationskanal . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 Die Kommunikation zwischen dem Android Gerät und dem Server . 14
3.1.4.1 Das Datenformat zwischen der Android-Anwendung und
dem Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4.2 Der Kommunikationskanal . . . . . . . . . . . . . . . . . . 15
3.2 Die Anfrage der Streckenqualität auf der Internetseite . . . . . . . . . . . . 15
3.2.1 Die Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Eingabefelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Berechnung der Ratings . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Ausgabe zur Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Die Anpassung des Systems für weitere Zwecke . . . . . . . . . . . . . . . . 16
4 Hardware und eingebettete Software 17
4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Der Mikrocontroller - ESP32 . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Feinstaubsensor (SDS011) . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 19
4.1.2.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Inhaltsverzeichnis 3
4.1.2.3 Abfragen/Auslesen der Messdaten . . . . . . . . . . . . . . 19
4.1.3 GPS-Empfänger (EM506) . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 21
4.1.3.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3.3 Abfragen/Auslesen der Messdaten . . . . . . . . . . . . . . 22
4.1.4 Lautstärke-Sensor (Grove Loudness) . . . . . . . . . . . . . . . . . . 23
4.1.4.1 Allgemeine Funktionsweise . . . . . . . . . . . . . . . . . . 25
4.1.4.2 Anschließen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4.3 Abfragen der Messdaten . . . . . . . . . . . . . . . . . . . . 25
4.1.5 Gesamtaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.5.1 Energieversorgung . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.5.2 Funktionale Möglichkeiten der Messeinrichtung . . . . . . . 28
4.2 Eingebettete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 Arduino Integrated Development Environment (IDE) . . . . . . . . . 29
4.2.1.1 ESP32 Grundeinrichtung in Arduino IDE . . . . . . . . . . 29
4.2.1.2 Struktur des Codes . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Verwendung von Bibliotheken . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2.1 AnalogWrite Bibliothek . . . . . . . . . . . . . . . . . . . . 30
4.2.2.2 BLE Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . 30
5 Android Anwendung 31
5.1 Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Verbindung mit der Messeinrichtung . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Anzeige der gemessenen Daten . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 Server 34
6.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.1 Model-View-Presenter-Schema . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 Die Stuktur von Django Code . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4.1 Die Einstellungen der Datenbank im Django-Framework . . . . . . . 36
6.4.2 Die Einstellungen der Datenbank auf dem Server . . . . . . . . . . . 36
6.4.3 Die Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.3.1 Klasse DataTable . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.3.2 Klasse TelemetryTable . . . . . . . . . . . . . . . . . . . . . 37
6.4.3.3 Klasse HistoryTable . . . . . . . . . . . . . . . . . . . . . . 38
6.5 Funktionsweise (Funktionale Teile) . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.1 Bearbeitung von POST-Request . . . . . . . . . . . . . . . . . . . . 38
6.5.2 Umrechnung der Koordinaten . . . . . . . . . . . . . . . . . . . . . . 40
6.5.3 Streckenauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.5.3.1 Die Weboberfläche . . . . . . . . . . . . . . . . . . . . . . . 41
6.5.3.2 Berechnungsskripten . . . . . . . . . . . . . . . . . . . . . . 42
6.5.4 Webinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Inhaltsverzeichnis
7 Die Testergebnisse des Systems 46
7.1 Die Strecke: Neckarstr. 4, Bremen - Hermann-Köhl-Straße 7, Bremen . . . . 46
7.2 Die Strecke: Neckarstr. 4, Bremen - “AOK - Hauptgeschäftsstelle Bremen”,
Bürgermeister-Smidt-Straße, Bremen . . . . . . . . . . . . . . . . . . . . . . 48
7.3 Datennutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.4 Energieeffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8 Zusammenfassung und Ausblick 51
8.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A Anhang 52
A.1 Einrichtung von Arduino IDE für ESP32 . . . . . . . . . . . . . . . . . . . 52
A.2 Django Installationsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3 models.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.4 views.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.5 map.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Abbildungsverzeichnis 65
Tabellenverzeichnis 66
Abkürzungsverzeichnis 67
Literaturverzeichnis 68KAPITEL 1
Einführung
Im Zeitalter von Computergeräten und Netzwerktechnologien werden immer mehr Um-
weltdaten gesammelt. Auch wenn die Daten mithilfe von verschiedenen Sensoren gemessen
werden können, gibt es heutzutage zu wenige mobile Stationen, womit die wichtigen und
für die Menschheit relevanten Daten gesammelt werden. Die Messboxen, die in einer Stadt
verteilt sind, können nur die Daten in näheren Umgebung erkennen und messen. Somit
es ist fast unmöglich einen gesamten Überblick zu erschaffen und die Situation an einem
bestimmten Ort zu bewerten. Dieses Problem wird heutzutage so gelöst, dass die Forscher
die Messgeräte mitnehmen, zum bestimmten Ort fahren und die Messdaten auf Papier
schreiben, um sie später in eine Tabellenkalkulationsanwendung zu übertragen, oder die
Daten werden direkt in die Tabellen eingetragen, was aber noch spätere Bearbeitung und
die Auswertung im Büro benötigt. Noch schlimmer wird es, wenn mehrere Daten von
verschiedenen Sensoren gemessen oder die Position ermittelt werden sollen. Da werden die
Stunden verbraucht, um solche Daten vollständig auszulesen.
Für diese Bachelorarbeit wurde eine Messeinrichtung zusammengebaut, die die Messung
der wichtigsten Umweltdaten durchführt. Es wird gezeigt, dass es heute schon möglich ist,
eine mobile Messstation zu bauen, die die Daten automatisch aufnimmt und weiter an den
Server verschickt. Auf dem Server ist es machbar, die Daten vollautomatisch mit verschie-
denen Skripten auszuwerten und für die menschliche Analyse darzustellen. Außerdem sind
die Originaldaten in einer Datenbank gespeichert und für die Betrachter zugänglich.
Die Bachelorarbeit wurde von zwei Personen gefertigt (Ivan Reichert aus Fachbereich 1
und Dmytro Reznik aus Fachbereich 3) um das System komplett entwickeln zu können.
Das System ist demzufolge in 3 Teile aufgeteilt:
• Die Messeinrichtung auf Basis von einem ESP32-Mikrocontroller ist von Herrn Ivan
Reichert gefertigt
• Die Android Anwendung ist von Herrn Dmytro Reznik erstellt[1]
• Der Server für die Lagerung und die Auswertung von den gemessenen Daten ist von
Herrn Ivan Reichert aufgesetzt, konfiguriert und programmiert. Außerdem sind von
Ihm die Koordinaten-Umrechnungsskripten und das Webinterface erstellt. Herr Dmy-
tro Reznik hat seinerseits sich mit den Streckenauswertungs-Algorithmen beschäftigt.
Die Hauptfunktionalität des Systems ist die punktweise Ermittlung der Umweltdaten (Fein-
staubbelastung, Geräuschpegel, GPS Position) entlang einer Strecke, die Weiterleitung
der Daten via Bluetooth zu der Android Anwendung, hinzufügen von Metadaten auf dem
Handy und das Verschicken der Daten an den Server. Auf dem Server werden die Da-
ten ausgewertet, gespeichert und zur weiteren Bearbeitung vorbereitet. Außerdem wurde
die Möglichkeit erschaffen, auf einer Internetseite mithilfe von Google API, die Strecken
zwischen zwei Punkten zu finden und Anhang von den gemessenen und im System ge-
speicherten Daten die Bewertung (die Luftqualität, der Geräuschpegel) von den einzelnen6 1. Einführung Strecken darzustellen. Somit haben die Benutzer die Möglichkeit einen am besten passen- den Weg (sowie Fahrrad als auch Fußgängerweg) zwischen zwei Punkten zu finden. Die Messeinrichtung ist auf Basis von einem ESP32-Mikrocontroller realisiert. Der ESP32 ist “Arduino Kompatibel” und es können somit alle Sensoren benutzt werden, die eine Schnittstelle zu Arduino haben. Die von Sensoren gemessenen Daten werden dann über ei- ne Bluetooth-Verbindung an die Android-Anwendung gesendet. Da die Android-Plattform meistens niedrigere Einstiegspreise bittet und sehr verbreitet ist, wurde entschieden, zuerst auf Android Geräten zu konzentrieren. Für die Hardwareteile des Systems ermöglicht die ESP32-Plattform, dass die Hardware von jedem mit grundlegenden Kenntnissen der elek- tronischen Schaltungstechnik zusammengebaut bzw. verändert werden kann, während die Verwendung der C-basierten Arduino-Programmiersprache nur geringe Vorkenntnisse der Programmierung eingebetteter Systeme erfordert, um den Code an neue Anwendungsfälle anzupassen. Die folgende Bachelorarbeit beginnt mit der Analyse der grundlegenden Systemanforderun- gen des Projektes, da das Projekt aus vielen Komponenten besteht und damit es verständ- lich wird, was mit dem System zu erreichen ist. Außerdem werden drei Anwendungsfälle betrachtet und die Hauptkomponente des Systems und deren Kommunikationskanäle vor- gestellt. Im Anschluss werden für die Teststrecken die Daten gesammelt und die Strecken- auswertungen dargestellt. Die Testergebnisse werden zusammengefasst und analysiert. Außerdem wird das System und die einzelnen Komponente des Systems bewertet.
KAPITEL 2
Systemanforderungen
In diesem Kapitel werden die grundlegenden Anforderungen und Eigenschaften für die in
dieser Arbeit benutzten Teile definiert.
2.1 Allgemeine Systemanforderungen
Das Ziel der Bachelorarbeit ist die Entwicklung und die Tests des Systems, das die posi-
tionsbasierten Messungen durchführen und die Ergebnisse nachher in einem Webinterface
anzeigen kann. Das System soll aus 3 Teilen bestehen:
• Auf ESP32 basierte Messeinrichtung
• Android Anwendung
• Server für die Datenlagerung und die Datenbearbeitung mit einer Weboberfläche
Die Messeinrichtung soll mit dem Android Gerät kommunizieren. Die Kommunikation
erfolgt via Bluetooth. Wenn die Bluetooth Verbindung aufgebaut ist, soll die Messein-
richtung mit den Messungen anfangen. Es sollen die Global Positioning System (GPS)-
Position, die Feinstaubbelastung und der Geräuschpegel gemessen werden. Nachdem alle
Daten von Sensoren ausgelesen worden sind, sollen die Daten via Bluetooth zum Handy
verschickt werden. Auf dem Handy (Android Anwendung) soll das Hinzufügen von Me-
tadaten erfolgen. Das gesamte Datenpaket soll danach an den Server verschickt werden.
Beim Verschicken soll das Representational State Transfer (REST)-Application Program-
ming Interface (API) Prinzip benutzt werden, dh. es wird ein JavaScript Object Notati-
on (JSON) über Hypertext Transfer Protocol (HTTP) gesendet. Auf dem Server soll die
Datenspeicherung in die PostgreSQL Datenbank erfolgen. Zusätzlich sollen auf dem Server
die Algorithmen für die Streckenauswertung entwickelt werden und es soll für die Benut-
zer möglich sein, anhand der gemessenen und in der Datenbank gespeicherten Daten eine
Streckenauswertung zu bekommen und somit einen am besten passenden Weg zwischen
zwei Punkten finden zu können.
2.2 Anforderungen an Hardware und Embedded Software
Die Messeinrichtung soll folgende grundlegende Eigenschaften haben:
• Tragbar
• Eigene Versorgungsquelle (Batterie)
• Kompakt
• Erweiterbar (große Auswahl von möglichen Sensoren)
• Arduino-Plattform kompatibel
• Leistbar (Kostengünstig)
2.2.1 Hardware
Aus den Eigenschaften können die folgenden Kriterien für Hardware Auswahl abgeleitet
werden. Die Sensoren sollen:
• kompakt sein8 2. Systemanforderungen
• eine entsprechende Masse haben (geringes Gewicht)
• möglichst geringe Energieverbrauch haben
• Arduino kompatibel sein (eine Serielle Schnittstelle haben)
2.2.2 Embedded Software
Die Software sollte auf möglichst vielen Gerätetypen laufen. Außerdem soll der Code gut
dokumentiert und leicht anpassbar sein. Es soll auch möglich werden, das System mit den
weiteren Sensoren zu erweitern.
2.3 Anforderungen an die Android-Anwendung
Die Anwendung soll auf vielen unterschiedlichen Geräten laufen, die eine Bluetooth Funk-
tion haben. Die Anwendung soll auch an den Low-Budget Geräten benutzbar sein.
2.3.1 Eigenschaften
Die Anwendung soll die Möglichkeit haben:
• in der nähe verfügbaren Geräte anzuzeigen
• die gemessenen Daten zu bekommen
• die Metadata hinzufügen zu können
• die Daten von Sensoren anzuzeigen
• den Status anzuzeigen, wenn ein Sensor ausgefallen ist.
2.3.2 Benutzeroberfläche
Die Benutzeroberfläche soll Benutzerfreundlich sein. Die Knöpfe und Texte sollen gut
lesbar sein. Die Funktionalität der Android Anwendung soll auch nicht stark von Standard
abweichen und bei der Möglichkeit die Standardfunktionen haben. Außerdem soll die
Anwendung das Fenster mit der Liste der verfügbaren Bluetooth-Geräten haben, wo die
Messeinrichtung (die Messbox) für die Verbindung ausgewählt werden kann. Es soll ein
weiteres Fenster vorhanden sein, wo die gemessenen Daten angezeigt werden.
2.4 Anforderungen an den Server
Es soll einen Server sein, wo die Windows oder Linux Betriebssystem installiert werden
kann. Der Server soll eine Internetverbindung haben, um die Daten bekommen zu können.
Außerdem ist es wichtig, dass der Server auch eine statische Internet Protocol (IP)-Adresse
hat, um von außen erreichbar zu sein. Es sollen die Streckenbewertungsalgorithmen er-
stellt werden und es soll im Webinterface möglich sein, nach der Eingabe von Start und
Endpositionen die Streckenbewertung zu bekommen.
2.4.1 Server Hardware
Die Server-Hardware soll die folgenden Voraussetzungen erfüllen:
• 2 CPU-Kerne
• 2 GB RAM
• 3 GB Speicherplatz
• Netzwerk Anschluss
• optimal: eine unterbrechungsfreie Stromversorgung (USV)2.4. Anforderungen an den Server 9 Außerdem soll es möglich sein, dass der Server mit einem Raspberry Pi realisiert werden kann, was die Kosten für Server Hardware reduzieren wird. 2.4.2 Weboberfläche Die Weboberfläche soll Benutzerfreundlich sein. Es soll ein “single page” Webinterface er- stellt werden. Die Grundfunktionalitäten des Projektes sollen da erwähnt und die Strecken- auswertung in der Oberfläche angezeigt werden. Außerdem soll die Weboberfläche Mobil- optimiert sein. Das Webinterface soll für alle Benutzer zugänglich sein. Die Administrator-Seite des Djan- go Frameworkes soll die Authentifizierungsseite haben.
KAPITEL 3
Anwendungsfälle
Da das entwickelte System komplex und vielfältig ist, sollen es 3 unterschiedliche Anwen-
dungsfälle betrachtet werden:
• Die Messung der Daten mit der Messeinrichtung
• Die Anfrage der Streckenqualität auf der Internetseite
• Die Anpassung des Systems für weitere Zwecke
3.1 Die Messung der Daten mit der Messeinrichtung
Der erste Fall der Benutzererfahrung ist, dass der Benutzer eine vorprogrammierte Box
kriegt und per Bluetooth mit der Box verbindet. Danach erfolgt die automatische Messung
und Übermittlung der Daten an den Server.
3.1.1 Der Messablauf
Der Benutzer soll zuerst die Spannungsversorgungsquelle anschließen. In unserem Fall es
soll einen Knopf auf der Powerbank getätigt werden. Es kann auch abweichen, wenn eine
andere Versorgungsquelle benutzt wird. Ab dem Moment der Einschaltung hat der Benut-
zer ca. 30 Sekunden um mit der Messeinrichtung zu verbinden. Wenn es in 30 Sekunden
nicht geschieht, werden die Sensoren ausgeschaltet und die Messeinrichtung wird in Schlaf-
modus geschickt. Ab dem Moment der erfolgreichen Verbindung brauchen die Sensoren
die Zeit um richtig zu starten. Feinstaubsensor (SDS011) braucht ca. 10 Sekunden um
die erste Luftmenge einzusaugen und zu messen, GPS-Empfänger (EM506) braucht laut
offizielle Dokumentation ca. 45 Sekunden (Cold start) um die Postion zu bestimmen. Die
Sensoren liefern die Daten über die Serielle Schnittstelle und der ESP32 ist so pro-
grammiert, dass der Mikrocontroller im Datenstrom von Sensoren nach dem benötigten
“Header” sucht, um die Daten danach auszulesen. Die genaue Vorgehensweise ist im Ka-
pitel Hardware beschrieben. Der Messablauf ist für die Veranschaulichung im Form von
einer Diagramm auf der Abbildung 3.1 dargestellt.
3.1.2 Mögliche Kommunikationskanäle
In diesem Abschnitt werden die gängige Kommunikationsstechnicken erklärt und deren
Vorteile genannt.
3.1.2.1 Mobilfunknetz
Mobilfunknetz ist eine der Arten der mobilen Funkkommunikation, die auf einem zellularen
Netzwerk basiert. Das Hauptmerkmal ist, dass das gesamte Versorgungsgebiet in Zellen
unterteilt wird, die durch die Versorgungsgebiete der einzelnen Basisstationen definiert
sind. Die Zellen überlappen sich teilweise und bilden zusammen ein Netzwerk.
Das Netz besteht aus räumlich getrennten Sendeempfängern, die im gleichen Frequenzbe-
reich arbeiten, und Vermittlungseinrichtungen, die es ermöglichen, den aktuellen Standort3.1. Die Messung der Daten mit der Messeinrichtung 11
Abbildung 3.1: Der Messablauf auf dem ESP32
der mobilen Teilnehmer zu bestimmen und die Kontinuität der Kommunikation zu gewähr-
leisten, wenn sich ein Teilnehmer von einem Abdeckungsbereich in einen anderen bewegt.
Es kann sowohl UMTS (3G) als auch LTE (4G) Mobilfunkstandard benutzt werden, da
die beiden Datenübertragungsraten für die Projektzwecken ausreichend sind.
3.1.2.2 Bluetooth
Bluetooth ist eine Herstellerspezifikation für drahtlose persönliche Netzwerke . Bluetooth
ermöglicht es, den Geräten über eine zuverlässige und kostenlose Funkfrequenz für die
Kommunikation im Nahbereich zu kommunizieren. Über Bluetooth können diese Geräte
miteinander austauschen, wenn sie sich in einer Reichweite von ca. 10 m in älteren Versio-
nen des Protokolls und bis zu 1500 m ab der Bluetooth-Version 5 befinden. Die Reichweite
ist stark abhängig von Hindernissen und Störungen, auch im gleichen Raum.1
Bluetooth Low Energy (BLE) - ist eine Version der Kernspezifikation für die Bluetooth-
Funktechnologie, deren wichtigster Vorteil der extrem niedrige Spitzen-, Durchschnitts-
und Leerlaufstromverbrauch ist.
Geräte, die BLE verwenden, verbrauchen weniger Strom als andere Bluetooth-Geräte frü-
herer Generationen. In vielen Fällen können die Geräte mehr als ein Jahr lang mit einer
einzigen Miniaturbatterie laufen, ohne dass sie wieder aufgeladen werden müssen. Auf
diese Weise wird es möglich sein, z.B. kleine Sensoren im Dauerbetrieb (wie einen Tempe-
ratursensor) mit anderen Geräten (z.B. das Handy) kommunizieren zu lassen.
1
Vgl. Bluetooth Tutorial | Tutorial-Reports.com: in: tutorial-reports.com, [online] http://www.tutorial-
reports.com/wireless/bluetooth/tutorial.php [Abgerufen am 30.01.2021] [2].12 3. Anwendungsfälle Diese Version der Bluetooth-Spezifikation ermöglicht die Unterstützung einer breiten Pa- lette von Anwendungen und reduziert die Größe des Endgeräts für den bequemen Einsatz in den verschiedenen Bereichen.2 3.1.2.3 Drahtloses lokales Netzwerk (WLAN) Wireless Local Area Network (WLAN) ist ein lokales Netzwerk, das auf drahtloser Tech- nologie basiert. Bei dieser Art des Netzwerkaufbaus erfolgt die Datenübertragung über die Luft. Die Geräte werden ohne Kabelverbindungen in das Netzwerk eingebunden. Die am weitesten verbreitete Methode der Konstruktion ist Wireless Fidelity (WI-FI). WI-FI ist die Technologie der kabellosen Netzwerken mit den Geräten, die IEEE 802.11 Standarten entsprechen. 3.1.3 Kommunikation zwischen ESP32 und Android Gerät In diesem Abschnitt werden das Datenformat und der Kommunikationskanal zwischen dem ESP32 und der Android-Anwendung vorgestellt. 3.1.3.1 Auswahl des Datenformats Es gibt verschiedene Datenformate, die für die Kommunikation zwischen zwei Geräten benutzt werden können. Bei der Auswahl des Formats der Datendarstellung wurden Extensible Markup Langua- ge (XML) und JSON verglichen. Das sind die zwei Datenformaten, die gut für Maschinen und Menschen lesbar sind. Außerdem haben sie auch entsprechende Vorteile, die folgend angeschaut werden. Extensible Markup Language (XML) XML ist eine Auszeichnungssprache, die eine Reihe von Regeln für die Kodierung von Dokumenten in einem Format definiert, das sowohl für Menschen als auch für Maschinen lesbar ist. Die Design-Ziele von XML betonen Einfachheit, Allgemeinheit und Verwend- barkeit im Internet. Es ist ein textuelles Datenformat mit starker Unterstützung durch Unicode für verschiedene menschliche Sprachen. Obwohl sich das Design von XML auf Dokumente konzentriert, wird die Sprache häufig für die Darstellung beliebiger Daten- strukturen verwendet, wie z.B. in Webdiensten.3 JavaScript Object Notation (JSON) JSON ist ein offenes Standard-Dateiformat und Datenaustauschformat, das menschenles- baren Text verwendet, um Datenobjekte zu speichern und zu übertragen, die aus Attribut- Wert-Paaren und Array-Datentypen bestehen. Es ist ein sehr verbreitetes Datenformat mit einer Vielzahl von Anwendungen, wie z.B. als Ersatz für XML in Asynchronous JavaScript and XML (AJAX)-Systemen. Außerdem ist JSON ein sprachunabhängiges Datenformat. Parser und Generatoren sind in allen populären Sprachen vorhanden.4 Da es an dieser Stelle wenig um die Webdatenaustausch handelt, wurde für die Kommunika- tion zwischen dem ESP32 und der Android-Anwendung ein JSON ausgewählt. Außerdem 2 Vgl. Wikipedia contributors: Bluetooth Low Energy, in: Wikipedia, 20.01.2021b, [online] htt- ps://en.wikipedia.org/wiki/Bluetooth_Low_Energy [Abgerufen am 30.01.2021] [3]. 3 Vgl. Extensible Markup Language (XML): in: w3.org, [online] https://www.w3.org/XML/ [Abgerufen am 31.01.2021] [4]. 4 Vgl. Einführung in JSON in: json.org, [online] https://www.json.org/json-de.html [Abgerufen am 30.01.2021] [5].
3.1. Die Messung der Daten mit der Messeinrichtung 13
bietet JSON auch gute Testmöglichkeiten, da es schnell umgebaut werden kann und von
Menschen gut lesbar ist.
3.1.3.2 Spezifikation des Datenformats - ESP32->Andorid-Anwendung
JSON Datenbeispiel:
1 {
2 " pdegree " : " 5 3 " ,
3 " pminutes " : " 0 4 . 3 7 6 1 " ,
4 " pole " : " N " ,
5 " hdegree " : " 0 0 8 " ,
6 " hminutes " : " 4 7 . 1 5 1 4 " ,
7 " hemisphere " : " E " ,
8 " mic " : " 8 1 3 " ,
9 " pm 1 0 " : " 1 4 " ,
10 " pm 2 5 " : " 6 " ,
11 " bat " : " 0 . 0 0 "
12 }
Grade des Breitengrads (pdegree)
Der GPS-Empfänger liefert die Daten im Form von Dezimalgrades. Für die bequeme Wei-
terverarbeitung werden die Daten schon auf dem ESP32 getrennt und separat im JSON
eingegeben. Somit hat der Schlüssel “pdegree” den Grad-Wert. Der Grad-Wert bezieht
sich auf den Pol (entweder Nord- oder Südpol)
Minuten des Breitengrads (pminutes)
Der Schlüssel “pminutes” liefert demzufolge den Minuten-Wert des Dezimalgrades.
Pol des Breitengrads (pole)
Der Schlüssel “pole” bestimmt ob es um einen geografischen Nord- oder Südpol handelt.
Der Wert kann nur “N” oder “S” sein.
Grade des Längengrads (hdegree)
Gleich wie “pdegree” hat der Schlüssel “hdegree” den Grad-Wert der Hemisphäre.
Minuten des Längengrads (hminutes)
“hminutes” liefert dementsprechend den Minuten-Wert der Hemisphäre.
Hemisphäre des Längengrads (hemisphere)
Der Schlüssel “hemisphere” bestimmt ob es um die östliche und die westliche Hemisphäre
handelt, nach dem Längengrad bezüglich des Nullmeridians und des 180. Längengrads.
Der Wert kann nur “E” (östliche) oder “W” (westliche) sein.
Geräuschpegel (mic)
Hier wird ein Mittelwert der letzten 50 Messungen des Geräuschsensors (Grove Loudness
Sensor) eingegeben.
Feinstaubbelastung (pm10 und pm 25)
Das Feinstaubsensor (SDS011) verwendet das Prinzip der Laserstreuung und kann die Par-
tikelkonzentration zwischen 0,3 bis 10 µm in der Luft ermitteln. Der Sensor kann in zwei14 3. Anwendungsfälle
Bereichen die Teilchen in der Luft messen und liefert entsprechend zwei Werte. Der Wert
µg
‘pm10‘ gibt an, wie viel Teilchen (in m 3 ) im Bereich um 10 µm in der Luft sind. Der
µg
Wert “pm25” gibt an, wie viel Teilchen (auch in m 3 ) im Bereich um 2.5 µm in der Luft
vorhanden sind.
Batterie (bat)
Der Schlüssel “bat” ist für die Batteriemessung vorgesehen, wenn ein Lithium-Polymer-
Akkumulator benutzt werden soll. Jetzt hat die externe Powerbank eigene Batterieanzeige
und muss nicht extra gemessen werden.
3.1.3.3 Kommunikationskanal
Nachdem die Daten (die Feinstaubbeslastung, die GPS-Position und die Lautstärke der
Umgebung) ausgelesen wurden, werden die Daten in ein JSON zusammengebunden und
für die Ausgabe vorbereitet (JSON wird bei jeder Messung aktualisiert). Da die Gerä-
te (der ESP32 und das Android-Gerät) sich immer in der Nähe befinden und der ESP32
schon das Bluetooth Modul auf der Platine hat, wurde es entschieden den Bluetooth Kanal
für die Kommunikation zwischen zwei Geräten zu nutzen. Für die Energieeffizienz wurde
das BLE Protokoll ausgewählt. BLE bietet im Vergleich zum Bluetooth deutlich geringe-
ren Stromverbrauch, was in diesem Projekt sehr relevant ist, da eine mobile Messstation
möglich länger von einer Stromquelle arbeiten soll.
3.1.4 Die Kommunikation zwischen dem Android Gerät und dem Server
Folgend wird der Verbindungskanal und das Datenformat zwischen der Android-Anwendung
und dem Server erklärt.
3.1.4.1 Das Datenformat zwischen der Android-Anwendung und dem Server
JSON Datenbeispiel:
1 {
2 " pdegree " : " 1 2 . 0 5 " ,
3 " pminutes " : " 2 4 " ,
4 " pole " : " N " ,
5 " hdegree " : " 5 2 . 0 2 " ,
6 " hminutes " : " 3 2 . 0 1 " ,
7 " hemisphere " : " W " ,
8 " time " : " 1 4 : 3 0 : 5 9 " ,
9 " mic " : " 2 3 " ,
10 " pm 2 5 " : " 1 5 " ,
11 " pm 1 0 " : " 2 5 " ,
12 " uuid " : " aee 0 bd 3c - 6 fa 7 -4 8 b 5 -8 9 da - 1 4 cfee 8 8 0 ff 1 " ,
13 " bat " : " 7 . 5 "
14 }
Wie im Beispiel zu sehen ist, wurden noch extra Felder in JSON hinzugefügt.
Aktuelle Uhrzeit (time)
Wird für die statistischen Zwecken benutzt, um die gemessenen Daten auf dem Server
richtig zu strukturieren.3.2. Die Anfrage der Streckenqualität auf der Internetseite 15
Universally Unique Identifier (UUID)
Der Schlüssel UUID ist eine 128-Bit-Zahl, welche identifiziert, von welchen Gerät die In-
formationen gekommen sind und somit kann es bestimmt werden, welcher Gerät die Daten
aufgenommen hat. UUID ist eindeutig und wird bei der Bluetooth-Kommunikation zwi-
schen dem ESP32 und dem Android-Gerät benutzt.
3.1.4.2 Der Kommunikationskanal
Als Hauptkommunikationskanal zwischen dem Android-Gerät und dem Server wurde für
dieses Projekt das Mobilfunknetz ausgewählt. Die Internetverbindung soll stabil sein, um
die Daten ohne Verluste an den Server zu schicken.
Für Datentransport von dem Android-Gerät an den Server wird das REST API Prinzip
benutzt.
REST API
REST steht für Representational State Transfer, API für Application Programming Inter-
face. Das ist eine Schnittstelle, die für die Kommunikation zwischen dem Client und dem
Server dient. Das REST Prinzip wird in der Praxis meistens per HTTP/S umgesetzt. Die
Dienste werden über URL-Anfragen angesprochen. Die HTTP-Methoden (GET, POST,
PUT,...) geben an, welche Operation ein Dienst ausführen soll.5
In unserem Projekt wird die POST HTTP-Methode benutzt, um die Daten (JSON) an
der Server zu übermitteln. JSON wird von dem Server empfangen, geprüft ob alle Daten
vorhanden sind und JSON korrekt ist. Nachdem die Prüfung abgeschlossen ist, erfolgt
das Einlesen der Daten, die Umrechnung der GPS-Koordinaten in richtiges Format und
Speichern der Daten in der Datenbank.
3.2 Die Anfrage der Streckenqualität auf der Internetseite
Der zweite Fall ist, dass der Benutzer auf der Internetseite die Start- und Endpositionen
eingibt und die Streckenauswertungen bekommt, um am besten passende zu ihm Strecke
auswählen zu können.
3.2.1 Die Weboberfläche
Die Weboberfläche des Projektes ist ausgehend aus den Anforderungen konzipiert und
programmiert. Es wurde entschieden eine Single-Page-Webanwendung (single page app-
lication) zu erstellen, damit die Benutzer sofort die Funktionen des Projektes benutzten
könnten. Das Web-Interface verfügt über eine kleine Beschreibung des Projektes (Ab-
bildung 6.5 und 6.6), zeigt die im Projekt benutzten Komponenten (Abbildung 6.7) und
verfügt über zwei Eingabefelder (Abbildung 6.3), wo es Start- und Endposition eingegeben
werden soll. Nach der Eingabe der Daten in die Felder werden die Fahrtstrecken ermittelt
und auf der Karte angezeigt. Außerdem werden die Streckenauswertungen in einer Tabelle
unter der Karte (Abbildung 6.4) eingetragen und farblich markiert.
5
Vgl. Karlstetter, Florian: Was ist eine REST API?, in: CloudComputing-Insider, 20.07.2020, [online]
https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/ [Abgerufen am 30.01.2021] [6].16 3. Anwendungsfälle
3.2.2 Eingabefelder
Die Felder dienen für die Eingabe der Informationen von Benutzern und verfügen über eine
Autovervollständigungsfunktion von Google Maps. Nach der Eingabe der Daten werden
aus der Start- und Endposition mithilfe von Google API die Fahrtstrecken bestimmt.
3.2.3 Berechnung der Ratings
Aus den Fahrtstrecken werden die Polylinien (Polylines) bestimmt und daraus werden alle
Punkte ermittelt, die zu dieser Polylinie gehören. Danach wird Punktweise mit den in der
Datenbank gespeicherten Daten verglichen und ausgewertet. Die Funktionsweise und die
Auswertung werden genauer im Kapitel 6 dem Abschnitt Streckenauswertung erklärt.
3.2.4 Ausgabe zur Weboberfläche
Nachdem die Streckenauswertungen von dem Server berechnet worden sind, werden die
Strecken auf der Karte angezeigt und die entsprechende Werte werden in der Tabelle ein-
getragen und farblich markiert (Beispiel siehe Abbildung 6.3 und 6.4)
3.3 Die Anpassung des Systems für weitere Zwecke
Der dritte Fall ist, dass es entschieden wird, die Messeinrichtung weiter anzupassen und/o-
der den Service (Web-Anwendung) zu optimieren.
Hier kann man davon ausgehen, dass es folgendes angepasst wird:
• Anpassung von Hardware-Teilen
• Anpassung der Android-Anwendung
• Anpassung des Servers
Um die Sachen anpassen zu können, wird es empfohlen, die Kapitel Hardware und ein-
gebettete Software, Android Anwendung und Server zu lesen. Da wird erklärt wie die
grundlegenden Teile funktionieren, wie die Abhängigkeiten sind und wie das System zu-
sammengebaut ist. Außerdem wird im Kapitel 4 auf alle technischen Besonderheiten und
Details eingegangen.KAPITEL 4
Hardware und eingebettete Software
In diesem Kapitel werden die technischen Aspekte und Zusammenhänge erläutert. Außer-
dem wird auf die einzelnen Komponente des Systems eingegangen und die Funktionsweise
erklärt.
4.1 Hardware
4.1.1 Der Mikrocontroller - ESP32
In dieser Bachelorarbeit wurde ein ESP32 Mikrocontroller benutzt. Der Mikrocontroller
befindet sich auf der Platine ESP32 Thing der Firma SparkFun. Die SpakFun ESP32
Thing Platine (Abbildung 4.1) ist so ausgerüstet, dass es alles zum Programmieren und
Entwickeln dabei ist. Außerdem hat ESP32 ein WI-FI/Bluetooth Modul in dem Chip
integriert, der für die drahtlose Kommunikation benutzt wird. Zusätzlich ist ein FTDI
FT231X Chip auf der Platine vorhanden, der USB in eine serielle Schnittstelle umwandelt
und die Programmierung und die Kommunikation mit dem Computer ermöglicht. Es gibt
noch die Status LEDs und die Tasten auf der Platine, welche für die Entwicklungszwecke
benutzt werden können.1 Somit erledigt die Platine alle im Projekt vorgesehene Ziele
(Energieeffizienz, Tragbarkeit, Arduino-Kompatibilität) und passt zum Systemkonzept.
Abbildung 4.1: SparkFun ESP32 Thing
Der ESP32 hat für die Kommunikation mit den anzuschließenden Geräten verschiedene
Möglichkeiten und Schnittstellen-Ausführungen. Um die Sensoren (den Feinstaubsensor
und den GPS-Empfänger) an der Platine anzuschließen, werden die Serielle Schnittstellen
1
Vgl. SparkFun ESP32 Thing: in: DEV-13907 - SparkFun Electronics, 30.06.2017, [online] htt-
ps://www.sparkfun.com/products/13907 [Abgerufen am 30.01.2021] [7] .18 4. Hardware und eingebettete Software
benötigt.2
Serielle Schnittstelle ist eine Schnittstelle zur Datenübertragung zwischen zwei Geräten,
wobei die einzelnen Bits zeitlich nacheinander übertragen werden.
Für die Kommunikation mit dem GPS-Empfänger (EM506) und dem Feinstaubsensor
(SDS011) wird die Universal Asynchronous Receiver Transmitter (UART)-Schnittstelle
benutzt. Die UART-Schnittstelle dient für die Datenübertragung (Senden und Empfan-
gen) über eine Datenleitung (RXD und TXD Anschlüsse) und bildet den Standard der
seriellen Schnittstellen an PCs und Mikrocontrollern. Die Aufbau der UART Schnittstelle
wird auf der Abbildung 4.2 dargestellt.3 Im Übrigen werden die UART-Pins der ESP32
mit 3.3V betrieben (und nicht wie in Arduino mit 5V ), was direktes Anschließen den
Sensoren ermöglicht und auch ein Grund für die Verwendung des ESP32 war.
Abbildung 4.2: Aufbau der UART Schnittstelle
Der ESP32 in der Ausführung der Firma SparkFun hat drei Hardware UART Schnittstellen
für die Kommunikation mit den externen Geräten. Eine davon wird für die Kommunika-
tion mit dem Computer benutzt und zwei werden für die GPS- und Feinstaubsensoren
verwendet. Außerdem wenn noch weitere Schnittstellen benötigt werden, kann die Softwa-
reSerial Bibliothek 4 benutzt werden. Wie die Sensoren an ESP32 angeschlossen sind, wird
im Kapitel Gesamtaufbau dargestellt. Grundsätzlich wird der ESP32 Mikrocontroller als
Steuerelement in der Messeinrichtung benutzt. Auf dem ESP32 läuft einen Programmcode,
der in einer Schleife ausgeführt wird.
4.1.2 Feinstaubsensor (SDS011)
“Feinstaub entsteht vor allem bei Verbrennungsprozessen in Kraftfahrzeugen,
Kraftwerken und Kleinfeuerungsanlagen, in der Metall- und Stahlerzeugung,
durch Bodenerosion und aus Vorläufersubstanzen wie Schwefeldioxid, Stickoxi-
den und Ammoniak. Es ist erwiesen, dass Feinstaub die Gesundheit schädigt” 5
.
2
Vgl. ESP32 Thing Hookup Guide - learn.sparkfun.com: in: Sparkfun, [online]
https://learn.sparkfun.com/tutorials/esp32-thing-hookup-guide [Abgerufen am 30.01.2021] [8] .
3
Vgl. Weissgärber, Jirka: UART, in: Schlaufuchs, 02.03.2019, [online] Link [Abgerufen am 30.01.2021]
[9] .
4
Link zu SoftwareSerial Bibliothek: https://www.arduino.cc/en/Reference/SoftwareSerial,[Abgerufen am
15.01.2021]
5
Umweltbundesamt, Luftqualität 2019, S:6 [Abgerufen am 30.01.2021] [10]4.1. Hardware 19
4.1.2.1 Allgemeine Funktionsweise
Der Feinstaubsensor misst die Menge der Feinstaubteilchen in der Luft. Der Sensor kann
laut offizieller Dokumentation[11] die Teilchen im Bereich zwischen 0.3 µm und 10 µm
messen. Der SDS011 basiert auf dem Prinzip der Lasermessung. Die Luftmenge wird
mittels eingebauten Lüfter eingesaugt, die Teilchen fliegen durch die Laserstrahlen und es
wird gemessen. Der Feinstaubsensor liefert zwei Messwerte: einen PM10 und einen PM2,5
Wert. Der Unterschied liegt daran, dass PM10 Wert angibt, wie viele Objekte, die im
Durchmesser kleiner als 10 µm in der Luft vorhanden sind und der PM2,5-Wert, wie viele
Objekte kleiner als 2,5 µm. Der Feinstaubsensor ist auf der Abbildung 4.3 dargestellt.
4.1.2.2 Anschließen
Die Informationen, die für das Anschließen des Feinstaubsensors benötigt werden, sind
seinem Datenblatt[11] entnommen. Die 5V Versorgungsspannung wird von ESP32 geliefert.
Die UART-Pins (RXD und TXD) werden an die Pins 25 und 27 des ESP32 angeschlossen
(Abbildung 4.11)
Abbildung 4.3: Der Feinstaubsensor der Firma “Nova Fitness Co., Ltd.”
4.1.2.3 Abfragen/Auslesen der Messdaten
Der Feinstaubsensor soll mit den Befehlen gesteuert werden. Um einen Messwert auf-
zunehmen soll er zuerst in den Arbeitsmodus (WORKCMD) versetzt werden. Danach
soll der Abfragebefehl (DATACMD) von ESP32 zum Feinstaubsensor (SDS011) verschickt
werden und danach kann das Auslesen der Daten von dem Feinstaubsensor erfolgen. Als
Datenquelle für die Steuerung von SDS011 wurde die SDS011 Bibliothek von R. Zschiegner
benutzt.6
Um den Feinstaubsensor in den Arbeitsmodus versetzen zu können, soll folgender Befehl
(WORKCMD) verschickt werden (Tabelle 4.1)
6
https://github.com/ricki-z/SDS011, [Abgerufen am 29.01.2021]20 4. Hardware und eingebettete Software
Byte Nr. Name HeX
0 Anfang des Befehls 0xAA
1 Befehls ID 0xB4
2 Daten Byte 1 0x06
3 Daten Byte 2 (1 um den Modus einzustellen) 0x01
4 Daten Byte 3 (1 für Work) 0x01
5 Daten Byte 4 0x00
6 Daten Byte 5 0x00
7 Daten Byte 6 0x00
8 Daten Byte 7 0x00
9 Daten Byte 8 0x00
10 Daten Byte 9 0x00
11 Daten Byte 10 0x00
12 Daten Byte 11 0x00
13 Daten Byte 12 0x00
14 Daten Byte 13 0x00
15 Daten Byte 14 (Device ID Byte 1, FF = Beliebig) 0xFF
16 Daten Byte 15 (Device ID Byte 2, FF = Beliebig) 0xFF
17 Checksum 0x06
18 Ende des Befehls 0xAB
Tabelle 4.1: Aufbau des WORKCMD-Befehls von dem SDS011
Um eine Messung mit dem SDS011 durchzuführen, soll ein DATACMD-Befehl verschickt
werden. Der Aufbau des DATACMD-Befehls ist in der Tabelle 4.2 dargestellt.
Byte Nr. Name HeX
0 Anfang des Befehls 0xAA
1 Befehls ID 0xB4
2 Daten Byte 1 0x04
3 Daten Byte 2 (0 um keinen Modus einzustellen) 0x00
4 Daten Byte 3 0x00
5 Daten Byte 4 0x00
6 Daten Byte 5 0x00
7 Daten Byte 6 0x00
8 Daten Byte 7 0x00
9 Daten Byte 8 0x00
10 Daten Byte 9 0x00
11 Daten Byte 10 0x00
12 Daten Byte 11 0x00
13 Daten Byte 12 0x00
14 Daten Byte 13 0x00
15 Daten Byte 14 (Device ID Byte 1, FF = Beliebig) 0xFF
16 Daten Byte 15 (Device ID Byte 2, FF = Beliebig) 0xFF
17 Checksum 0x02
18 Ende des Befehls 0xAB
Tabelle 4.2: Aufbau des DATACMD-Befehls von dem SDS0114.1. Hardware 21
Aus dem Datenblatt[11] erfährt man, wie der SDS011 die gemessenen Daten ausgibt. Nach
der Messung wird vom Feinstaubsensor das Datenpaket geliefert, das in der Tabelle 4.3
dargestellt ist.
Byte Nr. Name Hex
0 Anfang des Datenpakets 0xAA
1 Commander No. 0xC0
2 Daten für den PM2.5 Wert PM2.5 Low Byte
3 Daten für den PM2.5 Wert PM2.5 High Byte
4 Daten für den PM10 Wert PM10 Low Byte
5 Daten für den PM10 Wert PM10 High Byte
6 ID Byte 1
7 ID Byte 2
8 Die Summe der Bytes 2 bis 7 Checksum
9 Ende des Datenpakets 0xAB
Tabelle 4.3: Das Datenpaket des SDS011
Das Datenpaket beginnt mit Anfangs-Byte 0xAA. Damit das Datenpaket vollständig aus-
gelesen wird, muss als erstes nach dem Anfangs-Byte gesucht werden. Falls dies gefunden
wird, werden die restlichen 9 Bytes des Pakets gelesen und in einem Array gespeichert.
Danach wird dieses Array auf die richtigen Anfangs- End-Bytes überprüft und, falls diese
auch stimmen, wird das Checksumme-Byte überprüft. Dabei werden die Bytes 2 bis 7 aus
Tabelle 4.3 miteinander addiert. Falls das Ergebnis dem Checksumme-Byte entspricht,
dann ist das Datenpaket korrekt übertragen worden und kann ausgegeben werden. Die
Bytes 2, 3 und 4, 5 aus Tabelle 4.3 werden dabei jeweils mit der Formel:
µg High−Byte·256+Low−Byte
W ert( m3) = 10
verrechnet um den Messwert des Sensors zu erhalten. Am Ende werden die errechneten
Werte jeweils in einer Variable gespeichert.
Wie auf der Abbildung 4.11 zu sehen ist, wird der Feinstaubsensor mit einem MOSFET
gesteuert. MOSFET wird in diesem Fall als einen Schlüssel funktionieren und die Ver-
bindung zum “GND” Anschluss herstellen oder trennen. Somit wird die Energieeffizienz
erreicht, da der Sensor beim Bedarf ausgeschaltet werden kann.
4.1.3 GPS-Empfänger (EM506)
4.1.3.1 Allgemeine Funktionsweise
Der GPS-Empfänger EM-506 von USGlobalSat (Abbildung 4.4) findet mithilfe von GPS-
Satelliten seine Position und kann diese im Form von geografischen Koordinaten ausgeben.
Um die Position zu bestimmen, braucht der GPS-Empfänger mindestens 3 Satelliten (die
Anzahl von gefundenen Satelliten kann auch ausgegeben werden). Außerdem kann der
EM506 die aktuelle Uhrzeit in UTC-Format ausgeben, dafür soll es zu mindestens einem
Satelliten die Verbindung haben.[12] Der GPS-Empfänger hat folgende Vorteile:
• benötigt keine externe Internetverbindung (hat eine eingebaute Patch-Antenne)
• ist sehr kompakt
• verfügt über eine integrierte Spannungsregelung
• verfügt über LED-Statusanzeige (wird angezeigt, ob die Position gefunden wurde)22 4. Hardware und eingebettete Software
• bietet eine überragende Empfindlichkeit und Leistung, selbst in städtischen Umge-
bung
• hat einen UART Ausgang
Abbildung 4.4: Der GPS-Empfänger EM-506 von USGlobalSat
4.1.3.2 Anschließen
Im Datenblatt[12] des EM506 ist beschrieben, wie der Sensor an den Mikrocontroller an-
zuschließen ist. Als Versorgungsspannung braucht der Sensor 5V und seine UART-Pins
laufen mit 3.3V. Die UART-Pins (RXD und TXD) werden an die Pins 16 und 17 des
ESP32 angeschlossen (Abbildung 4.11)
4.1.3.3 Abfragen/Auslesen der Messdaten
Aus dem Datenblatt[12] wird auch erfahren, wie die Datenpakete des GPS-Empfängers
aussehen und wie mit den Daten gehandelt wird. Der EM506 braucht keine Steuerbefehle
und gibt die Daten über UART ständig aus. Bei dem GPS-Empfänger werden die Daten
nacheinander in verschiedenen Format auszugeben. Da in dieser Arbeit nur die Position
die Relevanz hat, wurde es entschieden das GGA-Datenpaket zu nutzen (Tabelle 4.4)
Format Beschreibung
$GPGGA Message ID
hhmmss.sss Uhrzeit im UTC Format
ddmm.mmmm Breitengrad
N Angabe ob Nord (N) oder Süd (S)
dddmm.mmmm Längengrad
W Angabe ob Westen (W) oder Osten (E)
1 Angabe ob eine Position bestimmt wurde: 0 - nein, 1/2 - ja
07 Anzahl der gefundenen GPS-Satelliten
... In diesem Fall irrelevante Bytes
Zeilenumbruch am Ende des Datenpakets
Tabelle 4.4: Aufbau des GGA-Datenpakets
Um dieses Datenpaket auszulesen, wird zuerst nach dem Anfangbyte “$” gesucht. Nach
diesem Byte werden die nächsten Bytes überprüft, ob sie dem Header “GPGGA” entspre-4.1. Hardware 23
chen. Falls der GGA-Datenpaket gefunden wird, werden die restlichen Bytes ausgelesen
und in ein Array gespeichert. Danach wird überprüft ob die Position bestimmt wurde
(siehe Tabelle 4.4). Wenn die Position bestimmt wurde, werden die Koordinaten aus dem
Array ausgelesen und in Variablen gespeichert.
4.1.4 Lautstärke-Sensor (Grove Loudness)
Für die Auswahl des Lautstärke-Sensors wurden vier verschiedene Mikrofone und deren
Ausführungen ausgewählt. Da alle Mikrofon-Platinen einen eingebauten Filter haben,
wurde es entschieden einmal alle Platinen im Serial Plotter des Arduino IDE anzuzeigen
und die Interessanten im Labor mit dem Oszilloskop zu messen.
Die zur Auswahl vorhandene Platinen waren:
• Big Sound Sensor
Abbildung 4.5: Big Sound Sensor der Firma “Elegoo”
• Small Sound Sensor
Abbildung 4.6: Small Sound Sensor der Firma “Elegoo”
• Grove Loudness Sensor
Abbildung 4.7: Grove Loudness Sensor24 4. Hardware und eingebettete Software
• Geräuschsensor auf dem Chip LM393 des unbekannten Herstellers
Abbildung 4.8: Hersteller X - Chip LM393
Der Small Sound und der Sensor Hersteller X haben beim Plotten in der Arduino IDE kei-
ne vernünftige Ergebnisse angezeigt und kaum eine Reaktion gezeigt. Die beiden anderen
haben im Vergleich zu den oben genannten Sensoren auf die Umgebungsgeräusche reagiert
und da es nicht bekannt war, wie gut die Sensoren die Umgebungsgeräusche messen kön-
nen, wurde es entschieden, den Grove Loudness und den Big Sound Sensor noch mal mit
dem Oszilloskop zu testen, um den Frequenzgang zu überprüfen.
Die Überprüfung lief so, dass es mit dem Tongenerator das Geräusch mit der Frequenz
1.4 kHz generiert wurde und die Sensoren gleichzeitig gemessen wurden. Big Sound hat
folgendes gemessen und angezeigt (Abbildung 4.9):
Abbildung 4.9: Die Messung mit dem Big Sound Sensor auf der Frequenz 1.4kHz
Auf der Abbildung 4.9 ist zu sehen, dass der Big Sound Sensor periodisch die Frequenzen
anzeigt, die gar nicht generiert worden sind.
Die Messung mit dem Loudness Sensor war erfolgreicher (Abbildung 4.10):4.1. Hardware 25
Abbildung 4.10: Die Messung mit dem Grove Loudness Sensor auf der Frequenz 1.4kHz
Auf der Abbildung 4.10 ist überschaubar, dass der Grove - Loudness Sensor nur die gene-
rierte Frequenz anzeigt. Aus diesem Grund wurde der Grove - Loudness Sensor im Projekt
benutzt. An dieser Stelle sollte auch erwähnt werden, dass wegen dem eingebauten Filter,
die Frequenzen abgeschnitten werden, die höher als ca. 5-6 kHz sind.
4.1.4.1 Allgemeine Funktionsweise
Der Grove - Loudness Sensor (Abbildung 4.7) nimmt die Lautstärke von Geräuschen in der
Umgebung auf[13]. Mit Hilfe eines Verstärkers des Typs LM2904[14] und eines eingebauten
Mikrofons verstärkt und filtert das Produkt die hohen Frequenzen, die über das Mikro her-
ein kommen, und generiert eine positive Hüllkurve als Ausgang. Das ist die Signalerfassung
für den ESP32. Der Ausgabewert hängt dabei vom Niveau des eingegangenen Geräuschs
ab. Um unnötige Signalstörungen zu vermeiden, geht das Eingangssignal zweimal durch
Filter im Modul. Außerdem gibt es auch noch ein Schraubpotentiometer zum Regeln der
Ausgangsverstärkung. 7
4.1.4.2 Anschließen
Der Sensor wird von ESP32 mit 5V Versorgungsspannung betrieben. Der Ausgabe Pin des
Sensors wird an den 36 I/O Pin des ESP32 angeschlossen.
4.1.4.3 Abfragen der Messdaten
Die Messung ist so realisiert, dass es 50 Messwerte von dem Sensor aufgenommen werden.
Aus diesen 50 Werten wird einen Mittelwert ausgerechnet und der Mittelwert wird in eine
7
Vgl. Zuo, Baozhu: Grove - Loudness Sensor - Seeed Wiki, in: Seeed The IoT Hardware Enabler, [online]
https://wiki.seeedstudio.com/Grove-Loudness_Sensor/ [Abgerufen am 30.01.2021].26 4. Hardware und eingebettete Software
Variable gespeichert. Die Variable wird in JSON ausgelesen und mit den anderen Daten
zum Android Gerät verschickt.
4.1.5 Gesamtaufbau
Auf der Abbildung 4.11 ist die Schaltskizze des Gesamtaufbaus der Messeinrichtung dar-
gestellt.
Abbildung 4.11: Schaltskizze des Gesamtaufbaus8
Und auf der folgenden Abbildung 4.12 ist der Gesamt-Hardware-Aufbau abgebildet. Hier
ist auch die Powerbank der Firma “Spigen” zu sehen, die die gesamte Messeinrichtung mit
der Energie versorgen wird.
Abbildung 4.12: Der Gesamt-Hardware-Aufbau
8
Das SDS011 Fritzing Symbol - https://forum.fritzing.org/t/sds011-dust-sensor/7924/2, [Abgerufen am
15.01.2021]4.1. Hardware 27
Abbildung 4.13: Der Gesamtaufbau in einer Kunstglasbox
4.1.5.1 Energieversorgung
Damit die Messbox unabhängig von einer Stromquelle funktionieren kann, muss die Schal-
tung eine eigene Versorgungsquelle haben. Nach der Recherche in allen Datenblättern
wurde ausgerechnet, dass die Schaltung im Peak maximal 260 mAh verbrauchen würde.
Im Sleep-Modus soll die Schaltung nur maximal 5 mAh verbrauchen. Um die Schaltung
dauerhaft zu versorgen und keinen Aufwand mit den auswechselbaren Batterien zu betrei-
ben, wurde es entschieden in erstem Entwurf eine Powerbank zu nutzen. Die Kapazität der
Powerbank ist 20000 mAh und somit erreicht man ca. 100 Stunden konstanter Arbeitszeit.
Danach kann die Powerbank durch einen Akkumulator ersetzt werden.
Um die Energieeffizienz zu erreichen, sollen die Sensoren und der ESP32 Mikrocontroller
möglichst geringeren Energieverbrauch haben. Somit ist es logisch, dass wenn die Mes-
seinrichtung nicht benutzt wird, soll sie auch entweder ausgeschaltet oder in Sleep-Modus
gesetzt werden. Der ESP32 und der Feinstaubsensor (SDS011) haben die Möglichkeit in
Deep-Sleep Modus zu wechseln. Bei dem GPS-Sensor ist es technisch unmöglich. Deswegen
wurde an dieser Stelle entschieden, dass die Sensoren über MOSFETs an die Versorgungs-
quelle angeschaltet werden. Somit kann man von ESP32 die MOSFETs steuern und die
Sensoren dann an- oder ausschalten, wenn es benötigt wird.
Die MOSFET-Schaltung sieht folgenderweise aus (Abbildung 4.14):
Abbildung 4.14: Die MOSFET-Schaltung28 4. Hardware und eingebettete Software
Wenn der Steuerpin des ESP32 3.3V (HIGH) liefert, wird MOSFET geöffnet und der
Sensor wird angeschaltet. Wenn der Steuerpin aber 0V (LOW) liefert, bleibt der MOSFET
geschlossen und somit der Sensor inaktiv. Die MOSFETs sind so ausgewählt, dass sie
maximal 500 mA durchlassen können, was in unserem Fall ausreichend ist, da die Sensoren
maximal 55 mA (GPS Sensor EM506) und 80 mA (Feinstaubsensor SDS011) verbrauchen.
4.1.5.2 Funktionale Möglichkeiten der Messeinrichtung
Außerdem hat die Platine der Messeinrichtung noch paar Funktionale Teile, die erwähnt
werden sollen.
Es wurde eine Status-RGB-LED eingebaut (Abbildung 4.11, rechts unten). Somit ist es
für Benutzer nachvollziehbar, in welchem Modus sich gerade die Platine befindet. Die
möglichen Modi sind:
• Warten auf die Bluetooth-Verbindung (Farbe: Hellblau)
• Die Bluetooth-Verbindung ist hergestellt, die Messung wird ausgeführt (Farbe: Grün)
• Die Bluetooth-Verbindung ist verloren, die Messung wird nicht ausgeführt (Farbe:
Rot)
• Die Platine ist im Sleep-Modus/Ausgeschaltet (LED ist inaktiv)
Wenn die Messeinrichtung keine Verbindung zu dem Android-Gerät herstellen kann, wird
sie im Sleep-Modus versetzt. Das bedeutet, dass die Messung nicht mehr ausgeführt wird,
die Sensoren nach ca. 30 Sekunden ausgeschaltet werden und der ESP32 wird nach ca.
1 Minute auch in Sleep-Modus gesetzt. Um die Platine wieder funktionsfähig zu bekom-
men, wurde ein externer “Wake-Up” Knopf eingebaut (Abbildung 4.11 “WAKE UP” rechts
unten). Der ESP32 überwacht im Sleep-Modus einen Pin (in unserem Fall den Pin 33)
und wenn auf diesen Pin die Spannung angelegt wird, wird ein Interrupt (eine kurzfristige
Unterbrechung der normalen Programmausführung) ausgelöst und der ESP32 wird wieder
in das Normalbetrieb wechseln.
Zusätzlich hat die Messeinrichtung einen externen “Reset” Knopf (RST Knopf auf der Ab-
bildung 4.11 rechts unten) bekommen, womit es möglich ist, die Platine und die Ausführung
des Programmcodes neu zu starten. Das ist für denn Fall gedacht, wenn die Messbox nicht
wie gewohnt funktioniert.
Auf der Abbildung 4.11 kann man auch sehen, das es noch ein Kondensator (C1 10 µF) im
“RESET” Zweig eingebaut ist. Ohne diesen Kondensator wird bei dem Flashen des Codes
relativ oft ein Fehler (Abbildung 4.15) auftreten, da der ESP32 nicht in das Flash/Update-
Modus wechseln kann. Das ist ein Fehler der Entwicklung des ESP32-Chips und es kann
nur wie oben beschrieben, gelöst werden.Sie können auch lesen
