Autor: user

Im Verlauf des Projekts hat sich herausgestellt, dass die Anforderungen des SIM800L an die Stromversorgung nicht ganz unerheblich sind. Zuletzt hatte ich immer mal wieder schwer nachvollziehbare Aussetzer der Geräte.

Um das Problem einzugrenzen habe ich ein Testprogramm geschrieben, das einen gegenüber dem Regelbetrieb höheren Stromverbrauch provoziert. Mit diesem Testprogramm konnte ich nachvollziehen, dass das SIM800L in bestimmten Betriebssituationen so viel Energie benötigt, dass auf der anderen Seite der Arduino ein Reset erfährt.

Ein Elektrolyt-Kondensator mit 470uF in die Stromversorgung dicht an dem SIM800L hat hier das Verhalten stabilisiert. Memo an mich für die nächste Revision:

• Elko mit in das Schaltungslayout aufnehmen

Ja und da hat es dann auch dieses Projekt erwischt mit den globalen Lieferengpässen. Das GG2 arbeitet ja mit einem Klon des Arduino Pro Mini mit einem ATmega 168p von Microchip. Wo man früher noch beliebig in die virtuellen Regale greifen konnte, wartet jetzt eine intensiver Recherche auf einen, wo es diese Module noch käuflich zu erwerben gibt.

Die erste Reaktion war: Macht ja nichts, es gibt doch Module mit dem ATmega 328p wie Sand am Meer, der kostet dann halt ’nen Euro mehr und gut ist.

Das ist dann aber auch eher die graue Theorie, als die Praxis 🙁

Leider sind die Spannungsregler auf diesen günstigen Modulen von sehr unterschiedlicher Qualität. Während die auf den Modulen mit dem ATmega 168p doch vergleichsweise gut waren und aus den 4,2V, die für das SIM800 aufbereitet wurden, ganz entspannte 3,3V machten, verhielt sich das bei den Modulen mit dem ATmega 328p gänzlich anders. Dort benötigt der eingesetzte Linearregler offensichtlich eine Spannungsdifferenz von 1-2V. Regelmäßig stieß der Controller damit an die Brown-Out-Spannung und hat sich neu gestartet.

Aktuelle Lösung:

• Der ATmega 328p kann durchaus mit 4,2V direkt betrieben werden
• Auf dem Modul wird neben der Power-LED auch der Linearregler entfernt
• Die Stromversorgung auf dem Board wird modifiziert
  • Versorgung via RAW wird gekappt
  • Die 4,2V werden direkt auf Vcc gegeben

Damit ist die Zukunft dieses Projektes gesichert. Ein umgebauter Prototyp läuft gerade Probe.

In der letzten Fangjagdsaison wurden die fünf Prototypen des GG2 intensiv eingesetzt. Einer der Erfahrungswerte war, dass die Anordnung der Stromversorgung im Deckel – diplomatisch ausgedrückt – suboptimal ist. Zum Wechseln des Akku brauch man eigentlich drei Hände und die Anschlussstellend er Kabel neigen irgendwann zum Brechen.

Ein weiterer, negativer Aspekt war, dass dieses kleine Modul für den Tiefentladeschutz beim Akkuwechsel etwas zickig war. Legte man einen frischen Akku ein, wurde die Spannung nicht zwingend durchgeschaltet. Manchmal musste man es öfter versuchen, sprich den Akku wieder entnehmen und erneut einlegen.

Also musste ein Redesign her. Dabei gab es zwei Hauptziele

• Stromversorgung auf dem Board integrieren
• Tiefentladeschutz über den Arduino laufen lassen

Während der erste Punkt über entsprechende Platinen-Halter für 18650-Zellen noch relativ einfach zu realisieren ist, ist der zweite Teil da schon etwas schwieriger. Die Spannungsversorgung wird über ein P-Kanal MOSFET geschaltet. Am Anfang war angedacht, das über einen NDP6020P von onsemi zu relisieren. Da stellte sich in der Umsetzung leider heraus, dass die verfügbaren Teile offensichtlich Nachbauten sind, die nicht den Spezifikationen des Datenblattes entsprechen. Deswegen musste noch umgeschwenkt werden auf einen SMD-Ersatztyp IRLML6402.

Der MOSFET wird dann indirekt durch den Arduino angesteuert. Da dieser ja die Steuerung erst übernehmen kann wenn er auch mit Strom versorgt wird, gibt es einen Start-Knopf, der temporär die Ansteuerung der MOSFET übernimmt.

D.h. zum Start des Gerät

1. Akku einlegen
2. Start-Knopf drücken

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