Skip to main content

Blog

LoraWAN GPS-Tracker konfigurieren

von Constantin Müller, Maximilian Richt, Stefan Kaufmann · 25. September 2020

Neben den Wifi-Trackern benutzen wir als GPS-Tracker hauptsächlich die LoRaWAN GPS-Tracker Dragino LGT 92 in der Ausführung mit eingebautem Akku. Zwar testen wir auch andere Trackermodelle, möchten aber in diesem Artikel kurz beschreiben, wie wir die Tracker konfiguriert haben. Der Vorteil dieser Tracker ist, dass sie als fertiges Produkt gekauft werden können, aber trotzdem komplett Open Hardware sind und die Firmware als Freie/Open-Source-Software veröffentlicht wird. Die Annahme von Bugfixes auf GitHub scheint aber noch nicht so gut zu funktionieren. Der große Vorteil, dass man die Firmware selber anpassen und auch Firmwareupdates selbstständig einspielen kann, bleibt natürlich bestehen. Und das ist bei solchen Geräten nicht selbstverständlich, wie wir bei Experimenten mit Trackern anderer Hersteller schmerzlich feststellen mussten.

Wir möchten in diesem Artikel festhalten wie wir unsere Tracker konfiguriert haben. Die Konfiguration findet, wie in der Anleitung ab Seite 20 beschrieben mit AT-Kommandos über die serielle Konsole statt.

Eine Liste aller AT-Kommandos findet sich in der AT-Anleitung des Herstellers. Hier solltet ihr überprüfen ob die Firmware auf dem Stand der Dokumentation ist, und diese im zweifel aktualisieren.

Akkulaufzeit optimieren

Dragino Tracker beim Laden

Da GPS sehr stromhungrig ist, bieten die Tracker eine Reihe von Konfigurationsmöglichkeiten um für verschiedene Anwendungsfälle die bestmögliche Laufzeit herauszuholen. Wichtigster Punkt: Wie oft wird der GPS-Chip gestartet um die Position zu erfassen.

Das Gute an den Dragino-Trackern ist, dass diese einen Beschleunigungssensor eingebaut haben und ab Firmwareversion 1.5 lässt der Tracker so konfigurieren, dass dieser uns beim Stromsparen sehr hilft: Unsere Räder stehen die meiste Zeit des Tages ja an einem Fahrradständer. Solange sie stehen brauchen wir keine regelmäßigen Positionsupdates im System. (Vielleicht alle paar Stunden mal, um sicher zu gehen, dass das Rad noch dort steht und kein Lora-Paket zwischendurch verloren gegangen ist.) Mit dem Beschleunigungssensor kann der Tracker erfassen, wann das Rad bewegt wird, und dann anfangen seine Position häufiger zu senden.

Mit AT+TDC kann man konfigurieren, in welchem Intervall in Millisekunden der Tracker seine Position sendet, wenn er bewegt wird. Und mit AT+KAT den Abstand zwischen Aussendungen in Millisekunden, solange keine Bewegung registriert wurde. Momentan nutzen wir die Werte AT+TDC=90000 und AT+KAT=1800000. AT+KAT ist bei uns mit 30 Minuten sehr gering eingestellt, da wir das Feature mit der neuen Firmware erst einmal testen wollten. Wahrscheinlich ist es aber sinnvoll, diesen Wert auf drei Stunden erhöhen. AT+TDC ist bei uns mit 90 Sekunden auch relativ gering, weil wir überlegen in Zukunft MDS-Daten zu generieren.

Ein Zweiter, für die Akkulaufzeit relevanter Faktor ist, wie lange der GPS-Chip versucht, eine Position zu ermitteln. Sucht dieser nicht lang genug nach Satelliten, ist die Genauigkeit der Position möglicherweise sehr schlecht. Stehen Fahrzeuge öfter unter Brücken, unter Dächern oder an sonstigen Orten mit schlechtem GPS-Empfang, verbraucht der GPS-Chip bei zu langer erfolgloser Suche sehr viel Strom. Diese Zeit lässt sich mit AT+FTIME konfigurieren. (Wert in Sekunden, in unserem Fall AT+FTIME=180) Damit im Zusammenhang steht auch die konfigurierbare Mindestgenauigkeit. Das heißt, wir können konfigurieren, ab welcher Genauigkeit sich der Tracker mit der Position zufrieden gibt und diese sendet. Da der Empfänger für eine genauere Position länger braucht und damit mehr Strom verbraucht, müssen wir hier also ein gutes Verhältnis zwischen Genauigkeit und Akkulaufzeit finden. Dies kann sich je nach Anwendungsfall unterscheiden. Nach unserer Erfahrung ist die vorkonfigurierte Genauigkeit von AT+PDOP=3.00 teilweise erschreckend ungenau. Unsere Tracker sind mit AT+PDOP=2.00 konfiguriert. Bei DOP handelt es sich nicht um eine Genauigkeit in Metern, sondern um eine dimensionslose Maßzahl für die Streuung der erfassten Positionswerte. Wenn die Genauigkeit AT+PDOP in der Erfassungszeit AT+FTIME nicht erreicht wurde, wird die bis dahin am genausten erfasste Position gesendet. AT+PDOP und AT+FTIME stehen hier also in einer gewissen Abhänigkeit zueinander - wir haben unser Optimum dabei auch noch nicht gefunden.

Ein Problem mit der aktuellen Firmware ist, dass leider die Genauigkeit der GPS-Position nicht mit per Lora übermittelt wird. Andere GPS-Chips in neueren Hardwarerevisionen könnten sich anders verhalten. Wir haben Tracker in der Hardware-Version 1.4 mit dem Quectel L70-RL GPS-Chip. Es gibt wohl auch eine Nachfolgegeneration auf dem ein anderer GPS-Chip verbaut ist.

Reichweitenoptimierungen

Für Orte die nicht so gut mit LoRaWAN abgedeckt sind, gibt es zwei relevante Einstellungen.

Datenrate

Datarate Calculator

Die Datenrate (oder auch Spreading Factor): LoRaWAN-Nodes können ihre Daten in verschiedenen Geschwindigkeiten senden. Um so langsamer die Daten gesendet werden, um so höher ist die Wahrscheinlichkeit, dass das Gateway zwischen vielen Störfaktoren das gesendete Signal noch herausfiltern kann. Dementsprechend steigt mit niedrigerer Datenrate (höherem Spreadingfactor) also auch in der Regel die Reichweite des Signals. Allerdings ist dabei zu beachten, dass wir uns das Übertragungsmedium mit allen anderen LoRa-Geräten und noch vielen anderen Sendern teilen, die diese offene Frequenz benutzen. Das heißt, um so länger wir senden, um so länger beeinträchtigen wir die Frequenz für alle anderen Teilnehmenden. Neben den rechtlichen Regelungen, die aus diesem Grund die Bundesnetzagentur getroffen hat, gibt es auch noch restriktivere Beschränkungen, die sich die TTN-Community selbst auferlegt hat. Das soll dafür sorgen, möglichst vielen Geräten die Teilnahme am Netzwerk zu ermöglichen. In der Praxis bedeutet dies: Es gibt einen Richtwert, wie lange jedes Gerät pro Tag maximal senden sollte. Wie viele Daten das sind, wie oft ein GPS-Tracker also seine Daten übermitteln kann, hängt dementsprechend auch mit der Datenrate zusammen.

Um auszurechnen, wie häufig der Dragino-Tracker bei welcher Datenrate senden darf, gibt es diesen großartigen Rechner: https://avbentem.github.io/airtime-calculator/ttn/eu868. Hier sehen wir, dass die Tracker bei einer Payload-Größe von 21 Byte und der voreingestellten Datenrate (DR5 / SF7) 16 mal pro Stunde, also etwa alle 4 Minuten, ihre Position senden könnten. Damit stoßen wir an keine realen Grenzen, denn schon allein aus Akkulaufzeitgründen ist es nicht sinnvoll dauerhaft so oft die Position zu übermitteln. Selbst bei der niedrigsten festeinstellbaren Datenrate (DR2/SF10) dürfen wir noch mehr als zwei Geolocations pro Stunde senden, was in gut ausgelasteten System in denen die Räder mehrere Fahrten pro Tag machen noch deutlich ausreicht, da die Fahrräder sich ja trotzdem die meiste Zeit nicht bewegen.

Mit dem AT-Kommando AT+DR=4 kann man somit die Datenrate auf 4 setzen, was dem Spreadingfaktor 8 entspricht. DR1 und DR2 dürfen nur benutzt werden, wenn ADR (Adaptive Data Rate) aktiviert ist, was in unserem Anwendungsfall eher wenig praktikabel ist.

Single Channel Gateways

Selbstbau Single-Channel-Gateway aus der gleichen Hardware, die wir auch für unsere Wifi-Tracker verwenden

LoRaWAN benutzt im Normalfall 8 Unterfreuqenzen (Channels/Kanäle). Dies dient dazu das geteilte Frequenzband besser auszunutzen. Das heißt auch, dass standardkonforme Gateways auch gleichzeitig auf alle 8 Kanäle hören sollten, um alle gesendeten Nachrichten empfangen zu können. Die Clients wählen sich zufällig einen Kanal, um das Band möglichst gleichmäßig auszunutzen.

Solche vollwertige Gateways sind nicht für alle einfach erschwinglich, auch wenn der Preis für manche Geräte mittlerweile auf unter 100€ gefallen ist. Deswegen existieren Bauanleitungen für Selbstbau-Gateways, die nur auf einem Kanal empfangen und senden. An Orten ohne systematisch aufgebaute TTN-Infrastruktur sind dies womöglich die ersten und einzigen verfügbaren Gateways, oder auch im eigenen Arbeitszimmer für Experimente.
Da diese Gateways im Durchschnitt aber nur jede achte Nachricht überhaupt empfangen, kann der Effekt solch eines Single-Channel-Gateways erst mal sehr enttäuschend sein. Um temporär Abhilfe zu schaffen, können die Dragino-Tracker in den Single-Channel-Mode versetzt werden. Wenn man die eingesetzte Frequenz des Single-Channel-Gateways kennt, kann der Tracker dann mit z.B. AT+CHS=868100000 auf diese Frequenz festgesetzt werden. Das Problem ist, dass dadurch die vorhin angesprochene gleichmäßige Verteilung von Aussendungen auf alle Channels unterwandert wird. Deswegen sollte der Tracker wieder in den Multi-Channel-Mode gesetzt werden (AT+CHS=0), sobald er in einem „richtigen“ TTN-Netz mit ausreichend vielen standardkonformen Gateways eingesetzt wird.

Gedanken zur Fahrradrückgabe, Benachrichtigungen und Authentifizierung

von Constantin Müller, Maximilian Richt, Stefan Kaufmann · 07. Juli 2020

In den letzten Wochen haben wir uns immer wieder Gedanken über die Rückgabe von Fahrrädern gemacht. Das ist ein Themengebiet, das erstmal recht einfach erscheint, wir durch den Bikesharing-Betrieb aber schon einiges gelernt haben und jetzt mehr spannende Fragen sehen als vorher.

Momentan ist es so, dass unsere Räder kostenlos ausgeliehen werden können. Wir beschränken dabei auch die Länge der Ausleihe/Fahrt nicht. Bei kommerziellen Anbietern gibt es meist den Anreiz möglichst kurz zu fahren (weil z.B. die ersten 30 Minuten kostenfrei sind), oder bei Nichtbenutzung die Leihe auch schnellstmöglich wieder zu beenden, da minütlich abgerechnet wird. Bei unserer kostenfreien Ausleihe bestehen diese Anreize zurzeit nicht - was dazu führt, dass wir immer wieder mehrere stunden- bis tagelange Ausleihen gesehen haben, ohne dass sich das Rad bewegt hat. Leute haben also vergessen, die Ausleihe des Rads zu beenden und somit anderen wieder zur Verfügung zu stellen.

Am naheliegensten wäre nun bei Ausleihen, die deutlich länger als die Durchschnittsausleihe dauern, die ausleihende Person zu benachrichtigen und zu erinnern, bei Nichtbenutzung das Rad auch wieder zurückzugeben. Unsere Oberfläche ist aber aktuell eine Webapp. Diese können nur unter Android überhaupt (Web-)Push-Nachrichten auslösen, unter iOS ist dies aktuell gar nicht möglich.

Eine weitere Möglichkeit Nutzerïnnen über noch offene Leihen zu informieren, wären bereits bestehende Kanäle wie E-Mail, SMS oder diverse Messenger. Da wir in cykel aber keine Registrierung und Login selbst anbieten, sondern dies über externe Dienste per oAuth2 abbilden, bekommen wir diese Kontaktmöglichkeiten nur in seltensten Fällen. Zudem werfen wir diese Daten - falls doch übermittelt - sogar aktiv weg. Dies hilft uns dabei, möglichst datensparsam mit persönlichen Daten umzugehen, denn eine wunderbare Möglichkeit für Datenschutz ist es, wenn man Daten gar nicht erst erfasst.

Nun stellt sich jedoch die Frage, ob wir diese Prinzipien über Bord werfen müssten, um über vergessene Rückgaben informieren zu können. Zudem würden uns mehr personenbezogene Daten nur noch mehr Probleme bereiten, wenn wir das zukünftig angedachte Roaming zwischen verschiedenen OpenBike-Instanzen einbauen. In dem Fall müssten diese personenbezogenen Kontaktdaten dann mitwandern.

Wir suchen also einen Weg, Benutzerïnnen Nachrichten zukommen zu lassen, ohne dass wir zwingenderweise einen Bezug zwischen einer Ausleihe, der Nachricht, dem Nachrichtenweg und der Person haben müssen.

Momentan benutzt die Kernkomponente von OpenBike zur Authentifizierung oAuth2. Einige Dienste, mit denen eine oAuth2-Authentifizierung möglich ist, bieten selbst auch eine Messenging-Funktion (wie z.B. Twitter mit Direktnachrichten), mit der wir benachrichtigen könnten. Aber nicht alle Dienste bieten das an und zudem gibt es bei den einzelnen Diensten dafür auch keine einheitliche Schnittstelle. Dies ist aber auch gar nicht das Ziel von oAuth2 - dieser (und verwandte) Standards wie OpenID Connect sind ja eigentlich für die Absicherung von Schnittstellen gedacht.

Noch dazu besitzen viele Menschen ja bereits eine Menge an Möglichkeiten, über die sie erreichbar wären - neben klassisch E-Mail und SMS kämen da noch diverse Messenger, Soziale Netzwerke und andere Dienste in Betracht, die vielleicht sogar schon auf den Smartphones installiert sind und Push-Nachrichten ausspielen.

Unsere Idee wäre es nun eine weitere Komponente zu bauen, die zwischen OpenBike und den Authentifizierungsprovidern liegt und sich einerseits um die Abwicklung der Authentifizierung mit verschiedenen Providern und andererseits um das Weiterleiten von Nachrichten über diese kümmert. Diese Komponente sollte also können:

  • selbst oAuth Provider sein
  • mehrere andere oAuth Provider für den Login unterstützen
  • für die Provider die es anbieten, Messaging unterstützen
  • für alle anderen die Hinterlegung einer E-Mail-Adresse oder Handynummer (für SMS) ermöglichen
  • der Benutzer:in wählen lassen, über welchen Weg sie kontaktiert werden will
  • die Zurordnung zu einer Mailadresse, Handynummer oder Loginprovider aufheben können (für E-Mail-Addresswechsel, neue Handynummer, oder gesperrtem/neuen Account bei einem Provider)
  • selbst eine Schnittstelle für Benachrichtigungen anbieten

Damit schaffen wir zwar wieder ein zentrales System, das personenbezogene Daten hortet, aber dieses wäre zumindest von den Ausleihvorgängen auf unterschiedlichen OpenBike-Instanzen unabhängig. Das ist auch der Grund, warum wir dies nicht direkt in cykel einbauen möchten - einerseits sollte diese Kommunikationskomplexität mit zig unterschiedlichen Anbietern nicht in die eigentliche Bikesharingsoftware rein, andererseits sollen auch die personenbezogenen Daten möglichst weit weg davon. Nehmen wir einen kollektiven Betrieb von vielen kleinen OpenBike-Instanzen in unterschiedlichen Nachbarschaften und Städten an, würde ein zentraler Service, der sich um dieses Problemfeld kümmert immerhin den Fokus auf Datenschutz und entsprechende Regelungen an dieser einen Stelle bündeln. Trotzdem können natürlich unterschiedliche Instanzen auch ihre eigenen Login/Notificationservices hosten.

Wir sind uns aber auch nach viel drüber grübeln noch nicht ganz sicher, ob das die sinnvollste Variante ist, das Notificationproblem zu lösen. Auch welche Protokolle dort in Betracht kommen könnten - aktuell klingen zumindest oAuth2 und ActivityPub interessant - ist noch offen.

Wir freuen uns daher über weitere Ideen, Anmerkungen oder auch Vorschläge das Ganze komplett anders zu machen. Gerne per Mail an openbike@ulm.dev - oder sogar besser im öffentlichen #transport-bikesharing:matrix.org Matrix-Channel.

Save the date: Eine kleine OpenBike-Konferenz

von Constantin Müller, Maximilian Richt · 30. Juni 2020

Schon von Anfang an gab es am Projekt OpenBike Interesse aus den verschiedensten Richtungen. Und vor allem einen großen Bedarf an Vernetzung und Austausch zum Thema Bikesharing. Nun ist es soweit und wir wollen Verwaltungsmitarbeitende, EntwicklerInnen, Fahrradaktivisten, Mobilitätsabteilungen, ehrenamtliche Fahrradverleiherinnen, Fahrradinteressierte und Raumschiffpilotinnen zusammenbringen. Und zwar in Form einer kleinen Minikonferenz. Das ganze wird am 7. und 8. August stattfinden. Und zwar online.
Hier gehts zur Anmeldung und zum aktuellen Programmplan

Themen über die wir sprechen wollen:

  • Entwicklungsstand von OpenBike
  • Betriebs und Wartungmodelle von Bikesharingsystemen
  • Kommunale Zusammenarbeit bei der Free und OpenSource Software Entwicklung
  • Einbindung von Sharingsystemen in den ÖPNV
  • Zusammenarbeit von Kommunen mit privaten Sharinganbietern
  • Datenaustausch zwischen Anbietern und Kommunen
  • Trackinghardware für Sharingräder
  • Aufsetzen eigener OpenBike-Instanzen
  • Software und Hardwareentwickung
  • Einführung in die OpenBike Softwareentwicklung

Und natürlich werden wir in der Auflistung noch einige Themen vergessen haben, deswegen freuen wir uns über Feedback, welche Themenbereiche und Aspekte für euch noch interessant wären, die hier noch fehlen. Und natürlich freuen wir uns um so mehr, wenn ihr euch mit einbringen wollt und einen Vortrag oder Workshop zu einem der Themen halten könnt. Das Programm soll kein Frontalunterricht werden, sondern vor allem dem Erfahrungsaustausch, Diskussion und als Inspiration dienen.

Also: Den 7. und 8. August vormerken und hier anmelden! Wir haben es absichtlich auf Freitag/Samstag gelegt, sodass sowohl für Menschen in Verwaltungen, als auch begeisterte Leute aus dem Ehrenamt die Teilnahme möglich wird. Und überlegt euch doch, zu welchem Thema ihr etwas beitragen oder mehr erfahren wollt, eure Themenvorschläge könnt ihr bei der Anmeldung mit angeben.

Wir freuen uns auf euch!