Da unsere bisherigen Versuche eine Verbindung mit einem Gateway aufzubauen gescheitert sind und wir vermuten, dass es sich um den beigelegten Antennen Connector nicht um eine Antenne, sondern nur um ein Gewinde für eine Antenne handelt, testen wir eine andere Antenne Dazu verwenden wir einen einen SMA auf U.FL (Anschluss am CubeCell Controller) Koaxial Adapter: (Bildquelle: Amazon.de) als Antenne wird eine gängige ausziehbare SMA Stabantenne genutzt CubeCell Controller mit SMA Antenne: Leider konnten wir trotzdem keine Verbindung zu einem Gateway aufgebaut werden (verwendet wurde das SendReceive Example aus der Heltec Bibliothek) Vermutung: Kein Gateway in Empfangsreichweite
Unsere letzte Vermutung beim Testen der SMA Antenne war, dass sich kein Gateway in der Nähe befand. Deshalb probieren wir eine Verbindung mit dem HTW Gateway aufzubauen. Dazu waren wir am Parkplatz vor dem S-Gebäude, also in direkter Sichtverbindung zum Gateway auf dem Dach am Ende des südlichen Teils des S-Gebäudes. Auch dies führte nicht zum Erfolg. Da praktisch direkter Sichtkontakt zum Gateway herrscht kann das Problem nicht an der Antenne bzw.
Um sicherzustellen, dass der Mikrocontroller auch wirklich Daten sendet und ordnungsgemäß funktioniert, wollen wir mithilfe eines HackRF One das Funkspektrum analysieren. Der HackRF One ist ein Software Defined Radio (SDR), welches eine breitbandige Analyse des Elektromagnetischen Spektrums zwischen 1 MHz und 5 GHz erlaubt. Nicht nur das Empfangen, sondern auch das Senden von Daten über den genannten Bereich ist (ggf. mit entsprechender Lizenz) möglich. Weitere Informationen zum HackRF One und zum Thema Software Defined Radio Zur Auswertung und Visualisierung des Funkspektrums wird das Programm GQRX verwendet.
Versuch eines Verbindungsaufbaus mittels ABP anstatt von OTAA. Dazu wurde das Codebeispiel LoraWan.ino verwendet und die Variablen nwkSKey, appSKey sowie devAddr entsprechend den Werten aus der TTN Applikation angepasst.
Resultat: Kein Erfolg, auf dem Serial Monitor konnte lediglich nachvollzogen werden, dass der Mikrocontroller immer wieder vergeblich versucht Daten zu senden. Auch in der TTN Konsole war keine Verbindung ersichtlich.
Nach einer Recherche entdeckten wir, dass der Controller ein Debug Modus besitzt.
Das Codebeispiel ReadSHT2x.ino wurde verwendet, um die Daten aus dem Sensor auszulesen. Resultat: Wir bekommen keine Daten. Deshalb überprüfen wir die Verbindung zwischen dem Sensor und dem Mikrocontroller. Nach dem Ausführen des Codes isConnected.ino wird ersichtlich, dass keine I2C Verbindung zwischen den beiden Geräten besteht.
Ziel: Überprüfung des Empfanges von LoRa-Gateways in Dresden mithilfe der TTN-Mapper App die App ermöglicht es die Stärke des Empfang der Gateways auf den aktuellen Standort durch die GPS Daten des Handys zu mappen und dadurch eine Heatmap zu erstellen Der Mikrocontroller muss dabei eine Verbindung zu einem Gateway aufbauen und mit diesem Pakete austauschen. Bei jedem erfolgreichen Datenaustausch mit dem Gateway werden Metadaten wie Empfangsstärke und Name des Gateways mitgeloggt.
Arbeit im Laborbereich
Arbeitsschutzunterweisung und Einführung in die Geräte
Spannungsmessung mithilfe eines Multimeters an den Bus-Schnittstellen, beim Senden wurde eine Spannung festgestellt, allerdings nicht an allen Pins -> Vermutung: Nicht alle Pins wurden korrekt verlötet -> Erneutes Löten der Pins im Labor (Nutzung von bleifreiem Zinn)
Neuer Versuch, aber die Temperatur wird immer noch nicht gemessen -> Rausnehmen des Delays für die Messung ändert auch nicht viel
Daher analysieren wir die Signale des I2C Protokolls mithilfe eines digitalen Oszilloskop.
Wir ändern die Ausgangsleistung von VIN auf VEXT und verwenden digitalWrite(), um den Sensor ein- und auszuschalten. Durch Hinzufügen der Übertragung zwischen Wire.begin() und Wire.end() kann der Scanner den Sensor erkennen. Daher können wir erfolgreich einen Befehl an den Sensor senden, erhalten aber keine Daten. Das heißt der Bus ist entweder nicht frei oder Wire.read() wartet nicht auf den Sensor. Das Hinzufügen einer Schleife mit Wire.available() oder delay() ändert nichts.
Wir kombinieren unsere bisherigen Programme zu einem einzigen Programm. Nachdem sich der Mikrocontroller mit dem TTN-Netzwerk verbunden hat, schaltet er den VEXT-Pin ein, liest die Daten vom Sensor und shaltet den Pin dann aus. Der Mikrocontroller sendet nun die Daten, plant die nächste Übertragung und geht schlafen. Die Nutzlast enthält 4 Bytes Feuchtigkeit und 4 Bytes Temperatur.
Um eine Langzeitmessung vorzunehmen ist es nötig die vom TTN-Netzwerk empfangenen Daten in irgendeiner Form persistent zu speichern. Bisher war es uns nur möglich, die vom Gateway empfangen Daten in der TTN Konsole einzusehen, diese wurden aber nicht gespeichert. Daher greifen wir mittels MQTT die empfangenen Daten ab. Dazu verwenden wir zunächst den MQTT Client Mosquitto: mosquitto_sub -h "<host>" -p "<port>" -u "<user>" -P "<access-key>" -t "<topic>" -d Host (MQTT Broker): eu1.
Um die über MQTT empfangenen Sensordaten zu speichern und grafisch darzustellen bzw. später evtl. für Automationen zu verwenden, wollen wir diese Daten mit Home Assistant abgreifen. Home Assistant ist eine Open Source Smart Home Zentrale mit Fokus auf Privacy. Home Assistant kann bspw. auf einem Raspberry Pi selbst gehostet werden und bietet durch seine Vielzahl an Geräte- und Protokollintegrationen nahezu unbegrenzte Möglichkeiten diese miteinander zu kombinieren, Automatisierungen zu bauen oder einfach nur Daten zu visualisieren.