Kategorie: DIY

Bei uns im Revier setzen wir neben den Fallenmeldern und dem dazugehörigen Web-Frontend auch die Revierwelt-Anwendung ein. An der Stelle kommt man jetzt spätestens zu der Fragestellung, was denn in einer Web-Anwendung für Fallenmelder alles enthalten sein soll, und was nicht. Im weiteren Verlauf des Artikels wird diese Web-Anwendung HGM (Hunting Ground Manager) genannt.

Im Austausch mit den Jagd-Kameraden haben wir folgende Punkte herausgearbeitet:

• Im HGM müssen Reviere gepflegt werden können
• Im HGM müssen Melder gepflegt und Revieren zugeordnet werden können
• Es muss eine rudimentäre Benutzerverwaltung geben
• In einer Übersicht pro Revier sollen alle Fallen und ihr Status einsehbar sein
• Streckenliste gehört in die Revierwelt
• Standort gehört in die Revierwelt
• Fangmeldungen in der Revierwelt wären wünschenswert

Das gliedert sich damit in drei Bereiche:

• Nicht-Anforderungen –> Quasi schon umgesetzt 😉
• Anforderungen
• Schnittstelle zur Revierwelt

Und an der Stelle wurde es ganz wundersam. Ich hatte einfach mal ganz dreist den Support von der Revierwelt angeschrieben, ob es denn eine Standard-API dafür gäbe. Die Antwort war grob: Nein, haben wir nicht, gib uns eine Spec, wir bauen das ein. Da war ich mal positiv überrascht. Coole Jungs (y)

So, jetzt befindet sich grad eine API in der Abstimmung. Ich werde berichten, wie das weitergeht.

Beim praktischen Einsatz der Melder gab es immer wieder den Effekt, dass die Geräte sich zwar alle 6 Stunden gemeldet haben, das aber nicht zu den gewünschten Zeiten. Ursächlich war, dass beim Start der Anwendung die Ermittlung der Uhrzeit über NTP fehlgeschlagen ist.

Ich habe die URL des NTP-Server-Pools geändert auf das deutsche Subset an Servern

Damit war das Problem behoben, die Zeit wurde seitdem deutlich zuverlässiger ermittelt.

Im praktischen Einsatz fiel auf, dass bei der bisher verwendeten Schaltung der verwendete Akku maximal entladen wird. Das geht natürlich ganz massiv auf die Lebensdauer des Akkus. Um hier den Akku zu schonen, wurde eine kleine Schutzschaltung dazwischen gesetzt. Die bezeichnun der Schaltung beim einschlägigen Versandhandel lautet „1S 3,7 V 3A li-ion BMS PCM“ und kostet ca. 0,20€.

Mit dieser Schutzschaltung wird die Spannungsversorgung gekappt, wenn der Akku bis auf 2,9V entladen ist.

Zusätzlich habe ich noch eine dedizierte Leitung für die Akkuspannung hinzugefügt. Damit und einer kleinen Änderung an der Schaltung kann jetzt die eigentliche Spannung des Akku gemessen werden und nicht die Spannung nach dem Step-Up-Wandler.

Das Herzstück des Melders ist ein Arduino, also benötigt man da auch noch das passende Programm für. Insgesamt setzt sich die Software auf dem Melder aus einem Arduino-Sketch und zwei Bibliotheken zusammen.

In typischen Beispielprogrammen für den Arduino, gerade den Arduino Pro Mini, erfolgt folgende Aufteilung:

• die physische, serielle Schnittstelle wird für das Debugging verwendet
• für die Kommunikation mit einem SIM800 wird eine SoftSerial verwendet

Dieser Aufteilung wollte ich nicht folgen, da die Kommunikation mit dem SIM800 für die Gesamtfunktion relevanter ist und ich hier den physischen UART der per Software emulierten Schnittstelle als überlegen ansehe.

Entsprechend gibt es die Bibliothek DebugOverSoftSerial, die Debuginformationen über eine SoftSerial ausgeben kann.

Zusätzlich gibt es die Bibliothek SimpleSim800, die verschiedene Funktionen gegenüber dem SIM800 bereitstellt. Hier erfolgt die Kommunikation über den physischen UART.

In dem Programm TrapSensor werden die verschiedenen, durch die Hardware bereitgestellten Funktionen, miteinander verwoben.

Welche Funktionen beinhaltet das Programm?

• Messen den Versorgungsspannung
• Auslesen der externen Schalter
• Zyklisches Auslesen der Schalter und Meldung bei Veränderung
• Zyklische Meldung zu definierten Uhrzeiten
• Ansteuerung der verschiedenen LEDs

Was muss man jetzt machen, wenn man das selber in Betrieb nehmen möchte?

Im Hauptprogramm TrapSensor.ino ist die URL der Web-Application hinterlegt. Hier muss einer zur eigenen Installation passende URL hinterlegt werden.

const char url[] = "http://yourdomain/traps/ping";

In der Datei SimpleSim800.cpp sind APN und PIN der verwendeten SIM-Karte definiert. In Abhängigkeit von der SIM müssen hier ggf. Anpassungen vorgenommen werden.

// 1NCE
const char _networkAPN[] = "iot.1nce.net";
const char _userName[] = "";
const char _passWord[] = "";

const char _simPin[] = "9545";

Für die Auswahl eines passenden Mobilfunkanbieters ist das zu erwartende Transfervolumen an Daten nicht unerheblich. In einem früheren Artikel hatte ich beschrieben, dass ich die Karten von 1NCE nutze.

Das Zwischenergebnis aus dem Monat Januar ist, dass 5 aktive Melder in einem Monat ein Volumen von 0.66MB verbrauchen.

Würde man das Standard-Angebot von 1NCE nutzen, nicht das AWS-Sonderangebot, wären voraussichtlich die 10 Jahre Laufzeit schneller abgelaufen, als die verfügbaren 500MB Volumen.

Eine der spannenden Fragen ist ja, wie lange bei dem Gerät der Akku hält. Die bisherigen Versuchsläufe sind bei Zimmertemperatur erfolgt. Als Akku habe ich eine 18650 von Samsung mit 2.200mAh verwendet. Das erste Gerät ist jetzt nach über 30 Tagen ausgefallen. Start des Tests war der 24.12.2020 07:53 Uhr. Letzte Meldung war der 28.01.2021 00:02 Uhr. In diesem Zeitraum hat das Gerät zuverlässig 4x am Tag seinen Status gemeldet. D.h. das Gerät kann mit einer Akku-Ladung ca. 140 Statusmeldungen absetzen. Von den übrigen, bekannten Parametern her passt das. Beim Verbindungsaufbau zieht das GSM-Modul bis zu 2A. Der Akku könnte das 66 Minuten lang liefern. Bei ca. 30 Sekunden für eine Verbindung sieht das schlüssig aus. Die nächste Versuchsreihe findet bei Außentemperatur statt.

Update:

Inzwischen habe ich von mehreren Geräten die Messwerte:

Gerät	Start	Ende	Laufzeit	Meldungen
572638	24.12.2020 07:53	28.01.2021 00:02	~ 36d	~ 140
266927	2021-01-08 06:46	2021-02-04 12:03	~ 27d	~ 110
912194	2021-01-01 10:04	2021-02-02 12:01	~ 32d	~ 130
348553	2021-01-01 09:50	2021-02-03 18:03	~ 33d	~ 130

Für die Nutzung des GSM-Moduls benötigt man entsprechende SIM-Karten. Die ersten Versuche habe ich mit Prepaid-Karten von congstar gemacht. Sie waren für den Einsatz in GSM-Kameras schon vorhanden. Da liegt man bei ca. 3€ / Monat.

Über einen Artikel vom heise-Newsticket bin ich auf ein Angebot von 1NCE gestoßen. Das richtet sich direkt an die Entwickler von IoT-Anwendungen. Das charmante an den Produkten von 1NCE ist, dass sie weniger auf monatliche Kosten abzielen, sondern den verbrauchten Traffic. In Deutschland nutzt 1NCE das Netz der Telekom.

Aktuell laufen mehrere Melder im Probebetrieb um eine Einschätzung erhalten zu können, wie viel Traffic durch die Melder generiert wird und wie lange ein Volumen von X MB halten würde. Den Verbrauch kann man bei 1NCE ganz komfortabel in einem Dashboard einsehen.

Basierend auf der Schaltung habe ich ein Board erstellt. Als Tool dafür habe ich die freie Version von Autodesk Eagle verwendet.

Die Abmessungen des Board sind genau so gewählt, dass es sich in dem IP67 Gehäuse montieren lässt.

Mangels meiner Fähigkeiten, SMD zu verlöten, habe ich konventionelle Bauteile gewählt.

Die Schaltung hat als Kernelemente

• SIM800L GSM-Modul
• Arduino Pro Mini

Die Eingangsspannung liegt an JP1 an. Die Versorgungsspannung hatt ich im vorangegangenen Artikel beschrieben, sie liegt bei 4,1 V.
Der Abschluss JP2 bietet die Möglichkeit, einen USB-Seriell(TTL)-Wandler anzuschließen. Über eine SoftSerial des Arduino können dort Debug-Ausgabe ausgelesen werden.
Am Pin A3 kann die Versorgungsspannung gemessen werden. Über einen Spannungsteiler wird sie entsprechend heruntergebrochen. Referenzspannung ist die interne Bandgap-Spannung des Arduino.
An den Anschlüssen JP3 und JP4 können zwei Schalter angeschlossen werden. Diese dienen der Zustandsfeststellung der Falle.
Zwei LEDs (plus die weitere LED auf dem Arduino-Board) dienen der optischen Kontrolle des Geräts.

Eingangs hatte ich schon geschrieben, dass möglichst eine Standard-Bauform von Akku verwendet werden soll. Initiale Idee war, das Gerät direkt mit

• drei AA Akkus, z.B. den eneloop von Panasonic zu betreiben
• einer 18650 Zelle

In der Entwicklung hat sich herausgestellt, dass das verwendete GSM-Modul SIM800L bei einer Spannung von ca. 3,7 V aussteigt. Das bedeutet, dass bei beiden Varianten das Gerät zwar mit voll geladenen Akkus eine Zeit lang läuft. Im Betrieb fällt die Spannung aber schon nach wenigen Tagen auf die Nennspannung der Akkus zurück und das Gerät wird dysfunktional.

Die aktuelle Lösung liegt in einer 18650 Zelle im Zusammenspiel mit einem MT3608 Spannungswandler. Datenblätter zu diesem Spannungswandler finden sich im Internet. Der Wandler kann die 3,7 V der 18650 Zelle in eine 4,1 V Spannung wandeln, die ideale Betriebsbedingungen für das SIM800L darstellt. Um die Spannung des MT3608 noch etwas zu glätten, habe ich ausgangsseitig noch einen 100uF Tantal Kondensator spendiert.

Hinweis für den Nachbau: Das SIM800L kann zum Zeitpunkt des Verbindungsaufbaus durchaus mal 2 A ziehen. Übliche Haltemodule für 18650 Zellen haben so dünne Käbelchen, dass der Innenwiderstand dort zu hoch ist. Ich habe die Haltemodule mit Kabel im Querschnitt von 0,5mm² verdrahtet, damit funktioniert das.