Datenlogger

Gewünschter Funktionsumfang

• 4 bis 10 Temperaturmesskanäle
• Thermowiderstände (Pt100, Pt1000) oder Thermoelemente, auch gemischt
• Thermowiderstände vorzugsweise in Vierleiterschaltung
• 1 bis max. 10 Abtastwerte pro Sekunde (über alle Kanäle)
• Spannungsmessung, Strommessung sind optional
• Akkubetrieb über mind. 8 h
• Sinnvolle Visualisierung
• Speicherung als CSV-Datei

Realisierung

Auf Basis Raspberry Pi 3 mit 7"-Touch-Display und Analogmesskarte mit 24-Bit-A/D-Wandler ADS1256. Dazu PowerBank, Gehäuse. Ein Gehäuse und ein Raspberry Pi 2 war bereits da, weil jenes Projekt eingestellt wurde.

Nötig ist noch eine Vorsatzplatine mit folgenden Eigenschaften:

• Mechanisch günstiger Anschluss der Thermosensoren
• Passend für Gehäuseeinbau
• Viele Eingänge bei wenig Aufwand
• ESD-Schutz (hier: Vorwiderstände)
• Möglichst universell konfigurierbare Eingänge

Es ist elend, dass für dieses Projekt der Raspberry Pi mit Standard-Hardware erweitert werden muss, die sich, wie sich zeigt, nur sehr schwer kollisionsfrei in Betrieb nehmen lässt. Für einen Anfänger ist das absolut ungeeignet!

Software

• Herunterfahren mit dem Power-Knopf: powerbutton.zip. Der Power-Knopf ist zwischen SCL und GND anzuschließen. Da SCL auch betriebsmäßig nach Low geht, prüft der „powerbutton-Dienst“ auf 0,3 s permanent Low. (Bei ausgeschaltetem Bildschirm ist nichts vom Drücken der Taste zu sehen, es wird kein „Tastaturereignis“ generiert.) Das Wiederanlaufen des (noch unter Spannung stehenden) Raspberry macht derselbe Power-Knopf durch vorhandene Hardwareunterstützung.
• Installation der Echtzeituhr: rtc-ds3231.zip
  • Auslesen der Temperatur vom Echtzeituhr-Chip: ./temp-ds3231 ausführen. Genaueres siehe unten. Das Skript verlässt sich auf den vorhandenen Pfad, dieser stimmte 2022 nicht.
  • Aufweckzeitpunkt für Raspberry Pi festlegen: ./wake +10min ausführen und herunterfahren, Zusatzbeschaltung erforderlich.
• WLAN-Konfiguration: wlan-lab.zip. Da diese Datei ein Passwort enthält, ist sie im geschützten Bereich, nur für Mitarbeiter von etit-tu-chemnitz.de. Mittlerweile (2022) hinfällig: Einbindung in tuc-special ist nahezu problemlos.
• A/D-Wandler auslesen (probeweise): logger1.zip. Die chinesische Software wurde vor allem um das Initialisieren der Portpins für RESET und PowerDown erweitert, damit der A/D-Wandler nicht mit schwimmenden Pegeln konfrontiert wird.
• Daten loggen:
• Webserver: In Entwicklung. Der komplett in C++ neu geschriebene Server wsss, auf openssl aufgesetzt, startet für jede Verbindung einen Thread und lädt ein Shared Object als Plugin. Mit tuc-special ist das obsolet, wenn man nicht gleichzeitig einen normalen Webserver benutzt. Denn die gängigen Browser verhindern wss wenn's nicht vom gleichen Server kommt wie die HTML-Seite.
• Darstellung: In Entwicklung. Darstellung und Laden/Speichern von Historiendaten geht heutzutage alles im Browser mit JavaScript. Ein moderner Browser mit Unterstützung von Pfeilfunktionen und mglw. Generatoren wird hierfür vorausgesetzt.

Die beiden Logger sind (in der Domäne etit.tu-chemnitz.de) erreichbar unter:

• messpi1 bzw. messpi2 wenn am Ethernet-Kabel
• messpi1-w bzw. messpi2-w wenn im WLAN

Richtige Lösung

Für die gegebenen Forderungen ist eine USB-basierte Lösung die bessere. Mittlerweile (2022) mit WebUSB und Smartphone. Auch das Kombinieren von Thermoelementen und Thermowiderständen an einer Buchsenleiste ist eher schwierig. Daher dort der Neuanfang.

Konfigurierbare Eingänge

Schaltplan

Die Umschaltung der Eingangskonfiguration für die verschiedenen Messaufgaben erfolgt mit einem DIL-Schaltersatz. Bei 24-V-Speisung von Sensoren mit 4..20-mA-Ausgang muss die +24 V an X17-1 zugeführt werden. Die Platine ist prinzipiell für ±-Spannungseingänge ausgelegt; dann muss U_EE an –5 V angeschlossen werden. Ansonsten wird U_EE mit Masse GND verbunden, wie dies beim verwendeten A/D-Wandler auch gar nicht anders möglich ist.

Wie in China üblich sind sämtliche Durchsteck-Bauelemente oben und SMD-Bauelemente unten. Als Bestückungsvariante für die 4-poligen Sensoranschlüsse wurden die großen mit 5,08 mm Raster ausgewählt. Alternativ bietet die Platine Löcher für die kleinen mit 3,5 mm Raster. Die Platine wurde in Eagle mit metrischem Raster entwickelt.

PowerOn-Logik und Akkubetrieb

Beim Betrieb des Raspberry Pi mit einer Powerbank (= Akkupack) muss dieser mit einem extra Schalter oder einer gesonderten Logik nach dem Herunterfahren vom Akku getrennt werden.

Da irrtümlicherweise eine Power-Bank mit Spannungsunterbrechung beim Umschalten zwischen Laden und Entladen ausgewählt wurde, wurde eine zusätzliche NiMH-Akkustütze mit 4,8 V Nennspannung vorgesehen. Dazu sind 2 Schalttransistoren oder ein Relais mit 2 Schaltkontakten erforderlich. Da der Raspberry Pi recht empfindlich auf Spannungseinbrüche reagiert, wurde ein 5-V-Relais mit 2 Arbeitskontakten verwendet, um sich Probleme mit R_DSon von MOSFETs mit kleiner Gatespannung vom Hals zu halten.

Der Power-Knopf soll genauso wie beim PC arbeiten:

• Kurz drücken im ausgeschalteten Zustand = Einschalten und Hochfahren
• Kurz drücken im eingeschalteten, hochgefahrenen Zustand = Herunterfahren und Ausschalten
• Lang drücken (im eingeschalteten Zustand) = Ausschalten (Auch ein Raspberry Pi stürzt mal ab!)

Dabei sind noch folgende Fallstricke zu beachten:

• Auch wenn im Internet das Gerücht herumgeistert, dass der heruntergefahrene Raspberry Pi am Low an Pin 8 (TxD, GPIO14) erkennbar ist, es stimmt nicht. Zumindest nicht für den hier vorliegenden Pi3. Software muss dieses Pin auf High setzen. Während des Bootvorgangs hat das Pin wechselnde Pegel, siehe Grafik im Schaltplan. Richtig ist, dass das Pin ohne Zutun von Software im Halt-Zustand auf Low geht oder hochohmig wird. Um nicht während des Bootvorgang den Raspberry Pi auszuschalten, sollte das Abschalten (am einfachsten) mit einer Zeitverzögerung von einigen Sekunden geschehen.
• Da der kurze Knopfdruck zum Einschalten auch dann funktionieren sollte, wenn der Raspberry sich im Halt-Zustand befindet und noch nicht abgeschaltet wurde (= im Timeout), sollte der Raspberry Pi auch eingeschaltet werden. Dazu muss Pin 5 (I²C SCL, GPIO3) auf Low gezogen werden. Da an diesem Pin auch die I²C-Echtzeituhr hängt, blockiert ein Tastendruck die Abfrage derselben. Das ist verzeihlich, da die Abfrage nur einmal beim Hochlauf erfolgt.
• Das Pin 5 dient auch zur Signalisierung des Herunterfahr-Wunsches. Dazu läuft Software als Systemdienst, die dieses Pin abfragt. Ich habe den Kode von dort kopiert und erheblich angepasst:
  • Die winzige Binärdatei läuft per se als normaler User (zum Testen), allenfalls das Herunterfahren benötigt entsprechend „erhöhte“ Rechte. Sollte in jedem „Runlevel“ laufen.
  • Läuft parallel zum I²C-Verkehr, ohne diesen zu beeinträchtigen.
  • Benötigt keine externen Bibliotheken, keine libbcm2835.a, öffnet nur /dev/gpiomem.
  • Binärdatei ohne dynamische Abhängigkeite, ohne system(), ohne fork(), Austausch des Prozess-Abbildes durch execlp().
  • Installation und Ablauf via moderneres systemd und nicht mehr via init.d.
  • Makefile mit Zielen „install“ und „uninstall“: Also Aufruf:
    • Zum Bauen und Installieren (als Dienst in systemd): sudo make install
    • Zum Deinstallieren aus systemd: sudo make uninstall

  Bei Low-Pegel wird systemctl poweroff abgesetzt. Komfortabler wäre ein grafisches Auswahlmenü, aber so funktioniert es auch ohne Display.

• Das alte Python-Programm legt den I²C-Bus und damit die Echtzeituhr lahm (i2cdetect -y 1 findet nichts mehr), und dieser lässt sich danach nur noch mittels sudo modprobe -r i2c_bcm2835 und anschließendem sudo modprobe i2c_bcm2835 wiederbeleben! Eine Untersuchung des Python-Programms mittels strace zeigte auf, dass die RPi.GPIO-Bibliothek auf die Dateien unter /sys/class/gpio aufsetzt. Benutzt man diese Dateien „zu Fuß“ (Beispiel) gibt es das gleiche Phänomen; echo 3 > unexport lässt I²C unbeeindruckt, es bleibt tot. Das Datenblatt des BCM2835 verrät hingegen, dass das Portpin in jeder Konfigurationsart gelesen werden kann. Daher ein Neuansatz als C++-Programm. Die statische Linkbibliothek bcm2835 funktioniert via Shared Memory, benutzt /dev/mem. Dieses Programm funktioniert nun auch gemeinsam mit I²C. Außerdem lässt es sich mit Strg+C beenden.
• Die „Lösung“ mit der Datei /boot/config.txt und der Zeile dtoverlay=gpio-shutdown ist völlig wirkunslos.
  Beachte den Unterschied zwischen shutdown und poweroff! shutdown ist Herunterfahren ohne Ausschalten: Korrekterweise sollte auf dem Bildschirm „Sie können den Computer jetzt ausschalten“ bzw. “It's now safe to turn off your computer” stehen. Wie beim AT-Netzteil. Bekannterweise (?) kann man beim Raspberry einen Neustart ohne Spannungstrennung durch Lo-Pegel an GPIO3 = SCL = Pin 5 auslösen.
• Die Stromaufnahme mit Display liegt bei 700 mA. (Muss ein Messfehler sein!) Der Verzicht auf das Abschalten würde den Akku leerziehen. Das gesonderte Abschalten des Displays funktioniert nicht. (Jedenfalls weiß ich nicht wie.)
• Das Abschalten der Stromversorgung nach systemctl poweroff erfordert auf jeden Fall eine gesonderte Signalisierung! Etwa:
  • Hi an GPIO26 = Pin 37, wie beim X728, Vorgabe für dtoverlay=gpio-poweroff, ermöglicht kürzestmögliche geordnete Abschaltzeiten;
  • Lo an einem Pin mit eingebautem Pullup und nicht allzu langem Lo-im-Betrieb, nahe­liegender­weise GPIO2 = SDA = Pin 3 oder auch GPIO3 = SCL = Pin 5;
  • via I²C-Slave an einen Chip (etwa ATtiny45, ATmega8), der auch den Rest der USV, insbesondere den Gleich­spannungs­wandler steuert.

Auf jeden Fall ist ein externer Knopf zum Herunter­fahren erforderlich, damit der Anwender sich das Herunterfahren auch angewöhnt. Denn der Logger schreibt naturgemäß ständig Daten auf die SD-Karte, und Stecker ziehen beantwortet der Raspberry Pi irgendwann mal mit einem kaputten Boot­vorgang. (Bei der Version ohne Akkustütze.)

1. Nicht vollständig entladbare Energiespeicher (d.h. alle gängigen Akkus) müssen abgetrennt werden. Vollständig entladbare Energiespeicher (Elkos, Superkondensatoren) können angeschlossen bleiben.
2. Alle „Power-Bänke“ schalten sich von selbst ab. Nicht alle sind dann spannungsfrei, sondern legen dann ihre Akkuspannung auf die Ausgänge. Alle schalten sich bei zu geringer Ausgangslast ab. Das ist beim Raspberry kaum ein Problem, da seine Stromaufnahme ziemlich hoch ist. Alle geben im abgeschalteten Zustand Spannungsimpulse aus, um zu prüfen, ob ein Verbraucher angesteckt wurde. Das bedeutet, dass man die Abschalt-Elektronik der Powerbank nicht nutzen kann.
3. Für Raspberry Pi 4 erscheinen „Power-Bänke“ ungeeignet, weil man für diesen besser 5,4 V Speisespannung einstellt. Sonst drosselt dieser unvermittelt seine Taktfrequenz, sichtbar an Ping-Zeiten im Sekundenbereich.

Diskret mit 4093

Mit dem Vierfach-Schmitt-Trigger-NAND sollte das einfach zu realisieren sein. Die Schaltung ist im AUS-Zustand ruhestrom­frei. TxD wird nicht verwendet.

Beschreibung:

• Im Einschalt- und Ruhezustand ist C1 entladen, die LED leuchtet, und das Relais ist angezogen. Über den integrierten Pullup des Raspberry ist GPIO3 auf Hi-Pegel, und das hält den Kondensator C1 entladen.
• Der kurze Druck auf den Taster (ca. 1 s) liefert Lo an GPIO3, am Zeitglied R1C1 passiert erst mal nichts. Die 100 ms kurze Lo-Nadel an IC1C durch den Hochpass R2C2 bewirkt ebenfalls nichts, da der andere Eingang des NAND-Gatters auf Lo liegt und liegen bleibt. Der Dienst powerbutton bemerkt Lo-Pegel an GPIO3, der gegenüber betriebsmäßigem I²C-Takt oder I²C-ClockStretch länger anhält. (Der betriebsmäßige I²C-ClockStretch muss zeitlich begrenzt sein!) Der Dienst „startet“ systemctl poweroff, d.h. er versetzt das System auf den Weg der Abschaltung.
• Der lange Druck auf den Taster (> 7 s) macht dasselbe im Raspberry Pi wie der kurze Druck. Hingegen lädt sich C1, und nach ca. 7 s wird LED + Relais (zwangs-)abgeschaltet. Der unbestromte Raspberry hält daraufhin über seinen Pullup den Eingang auf Lo-Pegel. Dieser Zustand hat keinen Ruhestromverbrauch.
• Der geordnete Herunterfahr-Vorgang macht GPIO3 zum Ausgang (ohne I²C) und legt diesen auf Lo-Pegel. Das wirkt wie ein langer Tastendruck und schaltet schließlich ebenfalls die Stromversorgung ab.
• Das Aufwecken aus dem ausgeschalteten Zustand erfolgt über RC2. Hingegen das Aufwecken eines bestromten Raspberry funktioniert wie gehabt durch Lo an GPIO3.
• Parallel zum Taster ließe sich ein Komparator anschließen, der bei niedrigem Akkustand eine Abschaltung (geordnet oder Zwang) auslöst.
• Ebenfalls parallel zum Taster wird der Interrupt-Ausgang einer Echtzeituhr zum Aufwecken des Raspberry angeschlossen. Der Interrupt-Ausgang muss dazu einen kurzen Lo-Impuls ausgeben, da ein Dauer-Lo zum Ausschalten führen würde und die I²C-Kommunikation blockiert. Bei Dauer-Lo erscheint es einfacher, C1 zu entladen. Aber dann würde eine fehlerhafte Interrupt-Deaktivierung zum Versagen der Zwangsabschaltung führen.

Aufgebaut wurde das Ganze auf einer Lochrasterplatine. Die TxD-Signalisierung wird ignoriert.

Die Schaltung funktioniert gut, solange die Akkuspannung hinreichend konstant ist. Bei einbrechender Spannung machen die Zeitglieder allesamt Probleme. Daher ist der dauerhafte Betrieb nur an der Powerbank problematisch, denn diese schaltet bei fehlender Last den internen Hochsetzsteller ab und gibt nur noch die LiIon-Akkuspannung aus. Diese liegt zwischen 3 und 4,2 Volt.

Nach kurzer Zeit war der NiMH-Akku tot, und diese Schaltung wurde verworfen. Die Platine kam schließlich später bei der angezapften Powerbank zum Einsatz.

Mit Mikrocontroller

Es erscheint seltsam, um einen dicken Mikrocontroller namens Raspberry Pi einen Mikrocontroller herum zu bauen. Aber es ist richtig so, weil der Raspberry Pi im PowerDown-Modus immer noch viel zuviel Strom zieht und sich so ein direkter Akku-Anschluss verbietet. Auch kann er nicht ohne DC/DC-Wandler leben wie so ein weitbereichsfähiger 8-Bit-Mikrocontroller.

Mit ATtiny4

Diese Sechsbeiner liegen gerade herum und lösen alle oben genannten Probleme ohne weitere Hardware. Ein billigerer PIC10F200 tut's auch.

Mit ATtiny45 oder PIC12F508

Der Raspberry Pi unterhält sich mit dem Mikrocontroller über I²C, und dieser kann den Akku-Ladezustand zurückgeben (wenn an einer frisierten Powerbank herausgeführt). Dazu sollte ein Mikrocontroller mit A/D-Wandler eingesetzt werden.

Auch hier blieb es beim Konzeptstadium, da keine geeignete Powerbank mit befriedigender Funktion gefunden wurde. ATtiny13 ist unpraktisch da dieser keine I²C-Funktion in Hardware unterstützt. (Software-I²C ist zwar möglich aber bei 400 kHz Taktrate schon sehr anspruchsvoll.) Der ATtiny45 enthält ein Universelles Serielles Interface (USI) mit I²C-Unterstützung und Hardware-Clock-Stretch, was Taktraten von 400 kHz erlaubt und so andere Hardware nicht ausbremst.

Mit ATmega48

Dieser kann sogleich die Funktion der Echtzeituhr inklusive Wakeup übernehmen, die am asynchronen Zeitgeber 2 mit einem 32-kHz-Uhrenquarz betrieben wird. Mit seinen vielen PWM-Anschlüssen kann dieser sämtliche MOSFETs und DC/DC-Konverter für eine Gesamtlösung betreiben:

• Switched-Capacitor-Netzwerk zur Bereitstellung einer leistungsarm verdreifachten Gate-Ansteuerspannung
• Abtrennen des Akkus via 1. MOSFET und Pegelwandler oder Relais
• Aufwärtsregler vom Akku zum Raspberry Pi via 2. MOSFET und Spule
• Abwärtsregler zum Laden des Akkus via 3. MOSFET und dieselbe Spule
• Abwärtsregler zum Netzbetrieb des Raspberry Pi via 4. MOSFET und weitere Spule
• Messen aller zum Betrieb erforderlichen Spannungen und Ströme

Muss mal gebaut werden, spätestens nach dem Reinfall mit dem PiUPS+.

Für die Schalter gibt es inzwischen hinreichend gute p-Kanal-MOSFETs IRLML2244, für die kein extra High-Side-MOSFET-Treiber mehr erforderlich ist. Das ändert den Schaltplan erheblich. Den Akkustrom misst man am einfachsten mit einem Shunt auf der Minus-Seite. Für alle anderen Ströme nimmt man besser den INA138, auch wenn dieser mit 2 € schon recht teuer ist. Der Verzicht auf den Weitbereichs-Eingang (also nur 5 V) erspart einen Transistor mit seiner Ansteuerung sowie eine der beiden Spulen. Es ist auch keine soo schlechte Idee, den Raspberry Pi weiterhin mit einem Relais zu schalten.

Mit PIC16F1459

Dieser 20-beinige Mikrocontroller erscheint noch maßgeschneiderter für diese Aufgabe, auch wenn man sein USB-Interface nicht (oder nur als Urlader) braucht. Siehe mittleres Bild. Er enthält die dazu nötige Hardware:

• Asynchroner 32-kHz-Quarzoszillator (2 = RA5) (3 = RA4)
• Komplementärer PWM-Generator (5 = RC5) (6 = RC4)
• Einfacher PWM-Generator (8 = RC6)
• I²C 400 kHz Slave (11 = SCL = RB6) (13 = SDA = RB4)
• A/D-Wandler (16 = RC0) (15 = RC1) (14 = RC2) (7 = RC3) (9 = RC7), zur Not (12 = RB5)
• Digitale Ein-/Ausgänge (12 = RB5) (10 = RB7), zur Not (4 = RA3 = Reset), (19 = RA0 = USB D+), (18 = RA1 = USB D-)

Mit PIC16F1708

Wie oben, jedoch enthält dieser Mikrocontroller bereits die beiden OPV zur bidirektionalen Akkustrommessung und ist noch billiger.

Ebenfalls sehr preiswerte 16- und 32-Bit-Mikrocontroller und -Boards, etwa STM32F103, sind weniger gut geeignet wegen ihrer Beschränkung auf 3,3 V E/A-Spannung.

Mit USV

Es gibt für 35 € ein USV-Modul zu kaufen, an dem nur noch der Lithium-Akku anzuschließen ist. Dazu gibt es passende Software. Dieser sprengt leider das zur Verfügung gestellte Budget. Akkus aus defekten Notebooks finden sich. Als besonderes Feature bietet dieses Modul einen Weitbereichs-Eingang, sodass man ein nahezu beliebiges Steckernetzteil verwenden kann.

Schaltplan und Mikrocontroller-Firmware habe ich nicht gefunden, ist anscheinend nicht open-source.

Nun (September 2018) ist das Budget da, und auch Akkus haben sich angefunden. Das USV-Modul soll nun die alte Schaltung vollständig ersetzen. Schade, dass dieses Modul nicht gleich die Echtzeituhr enthält. Hätte man ja in den dort verbauten ATmega8 mit einbauen können. Wieder so eine halbgare Lösung.

Wichtige Infos zu diesem Teil gibt es in diesem Forum. Auch da kann niemand programmieren; das verbesserte Python-Skript zum Auslesen des ATmega8 ist hier. Dieses kann endlich (wenigstens) permanent Spannungen und Ströme anzeigen und ist zu Python3 kompatibel.

Schließlich wurde dieses Board wieder verworfen. Im Testfall während eines Hochlaufs zog es vom Akku 7 A (!). Irgendetwas muss dabei sehr heiß geworden sein. Wahrscheinlich kann man damit keinen Raspberry Pi 3 mit Display betreiben. Auch habe ich partout nicht herausgefunden, wie man das Teil so verwendet, dass es bei Erreichen von „Akku leer“ das Herunterfahren auslöst, nicht nach einer Zeitspanne. Auch ist der Akku-Ladestrom von 100 mA, durch Reduktion von R4 von 10 kΩ auf 2 kΩ dann 500 mA, eher mickrig. (Während der Erprobung war der Ladestrom dann wacklig und nur etwa 400 mA. Vermutlich kommen die eingesetzten MOSFETs an ihre Grenzen.)

Resümee: Das PiUPS+ erscheint nicht dafür gemacht, einen Raspberry Pi mit Akku zu betreiben. Es ist ausschließlich dafür gemacht,

• kurzzeitige Stromversorgungslücken zu überbrücken
• den Flash-Speicher zu schützen

Dafür funktioniert das Teil gut. Aber für mehr taugt es nicht.

Nachtrag

Inzwischen (Herbst 2018) gibt es eine neue USV bei Reichelt zu kaufen, für 40 € teurer als der Raspberry Pi selbst. Die Echtzeituhr ist da mit eingebaut. Vielleicht ist dieses Board ja deutlich besser als das oben angegebene.

Mit angezapfter Powerbank

Am 20. September 2018 traf schließlich ein Powerbank-Bausatz aus China ein. Er beinhaltet alles außer die Akkus. Diese wurden bereits im Vorfeld aus einem alten Akkuschrauber- oder Notebook-Akku ausgeschlachtet. Die Zellen mit mehr als 3 V gelten als noch in Ordnung. Mit einem extra leistungsstarken Lötkolben wurden vier Zellen mit dickem Draht parallel geschaltet. Der dicke Lötkolben sorgt für möglichst geringe Erwärmung der Zelle, die eigentlich nur punktgeschweißt werden darf.

Im Innern ist nur ein einziger achtpoliger Schaltkreis und eine winzige Spule. Ohje! Vom Schaltkreis TP4395 gibt es keinerlei Dokumentation. Beim Testbetrieb zeigte sich, dass die Powerbank nur:

• laden kann, mit ca. 600 mA (das dauert über 20 Stunden!), und dann am Ausgang nichts ausgibt, oder
• entladen kann, dann den benötigten Strom für den Raspberry Pi 3 mit Display locker liefern kann.

Damit ist auch diese Powerbank nicht zur Versorgung eines Raspberry Pi geeignet. Aber man kann das Ding jederzeit öffnen und so den Akku direkt nach außen führen. Ich habe dazu kurzerhand die beiden Datenkontakte der USB-A-Buchse genutzt. Daran einen Hochsetzsteller PTN04050C (mal als Muster bestellt) über das Relais der diskreten Schaltung angeschlossen funktionierte das Ensemble endlich ordentlich. Allerdings muss man bei der Verwendung des Ganzen beachten, dass das Laden der Akkus länger dauert als das Entladen. Das bedeutet, dass auch bei angestecktem Netzkabel die Akkus irgendwann leer werden. Dagegen hilft nur eine Doppel-Schottky-Diode in der Akkuleitung. Diese vermindert allerdings die Effizienz der 5-V-Versorgung ganz erheblich. Richtig wäre eine gesteuerte Diode, also ein weiterer MOSFET. Für geringen Bahnwiderstand bei geringer Gatespannung müsste es ein ganz besonderer Typ sein. Daher ist es schließlich besser, auf eine Mikrocontroller-Lösung auszuweichen, die zusätzlich eine höhere Gatespannung bereitstellt und viel mehr Komfort bietet. Vor allem bietet nur die Mikrocontroller-Lösung das geordnete Herunterfahren bei schwach werdendem Akku. Oder ein zusätzlicher Komparator: Mehr Aufwand.

Die Überwachung der Akkuspannung erfolgt über den A/D-Wandler, am Eingang ADC6. Damit ist diese nicht unabhängig von der Betriebssoftware, dem Logger, aber das ist hier verzeihlich. Die Akkuspannung kommt vom Ausgang 3 des '4093 und ist nicht direkt angeschlossen, da bei ausgeschaltetem Relais ein permanenter Entladestrom in den Eingang des A/D-Wandlers fließen würde. Der Eingang ADC7 wird verwendet, um über den Spannungsabfall über die Schottky-Diode eine Schätzung über die Stromaufnahme zu bekommen.

Diese Schaltung hat nur noch folgende Mankos:

• Die Zeit für das Festhalten des Power-Knopfes bis zur Zwangsabschaltung ist an das Hochlaufverhalten des Raspberry Pi gekoppelt:
• Keine Zwangsabschaltung bei entladenem Akku; dass kann/muss die Betriebssoftware am A/D-Wandler tun

Beides ließe sich mit einer noch komplexeren Schaltung lösen, aber das wird besser einem Mikrocontroller überlassen, der noch vieles mehr besser kann.

Mit X728

Die unterbrechungsfreie Stromversorgung X728 funktioniert halbwegs zuverlässig, mit folgenden Macken:

• Ein externer Austaster prellt, während der eingebaute geht. Das führt dazu, dass (machmal oder immer) nach Zwangs-Ausschalten (ich nenne das mal „PowerCut“) der Raspberry wieder startet.
  Lösung: Ein kleiner Kondensator parallel zum Taster. Foto der Modifikation: Links der Kondensator
• Den Austaster habe ich auf-Teufel-komm-raus nicht zur Funktion des geordneten Herunterfahrens hinbekommen. An GPIO5 passiert absolut nichts. Die zu installierende Software lässt mir die Hände über den Kopf zusammenschlagen.
  Lösung: Eine Diode vom Taster nach GPIO3 = SCL = Pin 7 macht den X728 kompatibel zu einfachen Lösungen ohne USV. Foto der Modifikation: Links die Diode mit Drahtverlängerung. Dazu dieser (mein) Hintergrundprozess. Dieser benötigt nur wenig CPU-Last und beißt sich nicht mit I²C, weder in Hard- noch in Software. Zu installieren mit sudo make install. Zum Herunterfahren Power-Taste ca. 1 s drücken. Kürzere Spikes werden wegignoriert, denn das könnte vom I²C-Bus kommen.
• Mit der zu installierenden Software kommt ein Programm, das GPIO26 zu früh setzt, um das Abschalten (in etwa parallel zum Tastendruck) zu signalisieren. Außerdem ist es sinnlos groß und in Python. Sollte das Herunterfahren länger als 7 s dauern, sind die Daten futsch.
  Lösung: Der Raspberry bringt ein Kernel-Overlay namens gpio-powerdown mit, welches GPIO26 spätestmöglich setzt. Es wird mit dtoverlay=gpio-powerdown in die /boot/config.txt eingetragen. Dass dabei eine Kernel-Panik auftaucht ist nicht mein Bier: Offensichtlich sind der PowerOff-Schleife die 7 Sekunden zu viel.
• Warum auch immer ein Jumper den Einschaltmodus auswählt: Viel cleverer wäre das via Mikrocontroller und EEPROM einstellbar. Genauso wie beim PC wählbar zwischen
  • Immer aus
  • Letzter Zustand
  • Immer ein

Richtig beschrieben/gemacht ist die Installation der Echtzeituhr mittels Kernel-Overlay.

Was noch fehlt:

• Batteriefüllstandsanzeige für die GUI (im System-Tray): Erledigt!
• Automatisches geordnetes Herunterfahren bei Batterie-Leer-Warnung und entsprechende Konfiguration: Erledigt!
• Aufwecken des Raspberry von eingebauter Echtzeituhr (erfordert weitere kleine Bastelei)

Die nicht funktionierenden Leitungen wurden durch Überwachung aller GPIO nachgewiesen: sudo watch -n 0.1 busybox devmem 0xfe200034 läuft ohne irgendetwas installieren zu müssen. Der Timer '555 scheint voll für die Katz' zu sein. Und auch die „Warning“-LEDs (neben den Akkus) habe ich noch nie leuchten sehen.

Das All-in-one-Installationsskript offenbart die Funktion der Batteriefüllstandmessung: Auf I²C-Adresse 0x36 befindet sich der A/D-Wandler mit folgenden I²C-Daten:

• Auf Subadresse 2 die Spannung × 0,000078125 V als 16-Bit-Wert (I²C-typisch Big-Endian)
• Auf Subadresse 4 der Füllstand × 0,00390625 % als 16-Bit-Wert

Ladezustandsanzeige in LXDE

Auf den Raspberry-Desktop gehört eine Ladezustandsanzeige in den System-Tray (neben das WLAN- und Bluetooth-Icon). Das wird vom Hersteller „Geekworm“ bzw. „SupTronics“ nicht angeboten. Deshalb habe ich's hier (nach einer mehr oder weniger grauenvollen Vorlage) in Python3 nachgeschoben.
Mein erstes ernsthaftes Python-Programm, dazu mein erstes Qt-Programm. PyQt5 ist auf dem Raspberry bereits vorinstalliert, nichts ist mit pip3 zu installieren.

Kann schon:

• Spannung und Füllstand anzeigen: Füllstand via veränderliches Symbol, beides via Tooltip (= Maus darüberhalten für Textanzeige)
• Auswerten von GPIO6 (Netzbetrieb vs. Akkubetrieb) und entsprechend veränderte Anzeige
• Piezokapsel an GPIO20 ansteuern (bei drohendem Powerdown mit 1 Hz)
• Erzwungenes (unbeobachtetes) Powerdown ausführen (kurioserweise geht das ohne extra Rootrechte)
• Deutsch mit Komma statt Punkt (QLocale)
• Einstellungsdialog (siehe Screenshot) (QDialog)
• Einstellungen (die beiden Schwellwerte) speichern (QSettings)
• Anzeigen der Zeit des letzten erzwungenen Powerdown (nach Neustart)
• Symbolgröße an die anderen Symbole anpassen (typisch 32×32, 24×24 oder 16×16)
• Symbol malen statt eine Liste von PNG-Dateien voraussetzen
• Symbol animieren bei Füllstand ≤ 30 %
• Ohne externe Dateien auskommen, dadurch bequem autostartbar: In /etc/xdg/lxsession/LXDE-pi/autostart eintragen: @/pfad/X728BatteryStatus.py -a
  (Das -a schaltet den Menüpunkt Beenden ab.)

TODO:

• Mehrsprachigkeit
• Piezo-Sound und erzwungenes Powerdown ohne GUI über einen Systemdienst. Möglicherweise derselbe Systemdienst wie mein PowerButton. Datenübertragung (sicherlich) per mqtt.

Echtzeituhr

Gibt es zu kaufen. Aufgelötet ist der Chip DS3231. Dieser Chip enthält bereits den Quarz, und das Modul hat auf der Unterseite eine Lithium-Knopfzelle der Größe 1632 (?), nicht 2032 wie häufig angegeben.

Inbetriebnahme

Ist bei der Zeitschrift „Raspberry Pi Geek“ dokumentiert (und kostenlos zugänglich). Man vermeide sudo apt-get upgrade, das installiert viele Megabyte WolframAlpha. Falsch ist heutzutage (2018) das Hinzufügen von Zeilen zu /etc/rc.local. Stattdessen in die Datei /boot/config.txt die Zeile dtoverlay=i2c-rtc,ds3231,wakeup-source.

Üblicherweise wird in der Uhr die Lokalzeit geführt, die zwischen Sommer- und Normalzeit springt. Aber ich denke mal, dass das beim Raspberry Pi anders ist. Da warte ich mal die nächste Zeitumstellung ab …

Dummerweise ist die 5-polige 1-reihige Pfostenbuchse des DS3231-Moduls nicht verpolungssicher. Glücklicherweise verträgt der Echtzeituhr-Chip die Falschpolung unbeschadet. Nur das I²C-Interface erscheint blockiert, merkbar daran dass i2cdetect -y 1 ewig braucht und nichts findet. Also: Richtig herum anstecken! Und am besten Pin 1 extra markieren: Mit Malerkrepp und rotem Filzstift.

Erweiterung: Alarm = Aufwecken

Der Chip hat einen Alarm-Ausgang, der beim Erreichen der Weckzeit auf Low geht.

1. Differenziert auf ≈ 0,2 s kann man damit einen schlafenden, unter Spannung stehenden Raspberry Pi wecken, an SCL. SCL (und auch SDA) ist bereits mit 1,8 kΩ Pullup versehen. Da der notwendige Koppelkondensator mit C = τ/R = 100 µF unverschämt groß sein müsste, nimmt man einen pnp-Transistor dazu: Die Koppelkapazität verringert sich um den Stromverstärkungsfaktor des Transistors. Ohne Differenzierung wäre das Rücksetzen des Alarms nicht möglich, da dieser den I²C-Bus blockiert. Diese Art eignet sich besonders für Raspberrys mit Netzbetrieb.
2. Eine gesonderte Schaltung kann einen spannungslosen Raspberry Pi wecken, mit einem Relais. Beispiel, noch ein Beispiel. Diese Art eignet sich besonders für Raspberrys mit Batteriebetrieb. Die Batterie kann obendrein die Knopfzelle ersetzen.

Das differenzierte Signal ist wiederum so kurz, dass es nicht zum Herunterfahren (mit dem Programm powerbutton) reicht; das ist so sinnvoll und gewollt. Der parallel über die Emitter-Kollektor-Strecke des pnp-Transistors angeschlossene Ein-/Ausschalter muss eben etwas länger gedrückt werden, um sicher vom I²C-Signalspiel unterschieden werden zu können. Die beiden 82-kΩ-Widerstände entladen den 100-nF-Koppelkondensator nach dem Startimpuls wieder. Die rote LED dient nur der Funktionsanzeige. Der Schaltplan des Differenziergliedes ist im Bild „Schaltplan“ oben links ersichtlich. Eigentlich gibt es das Programm rtcwake zum Steuern des Aufweckens. Dieses bezieht sich jedoch leider auf einen falschen Pfad: /sys/class/rtc/rtc0/device/power/wakealarm. Das (mein) Programm ./wake bezieht sich auf /sys/class/rtc/rtc0/wakealarm und funktioniert so erst einmal. Die Systemdatei bekommt die relativ unleserliche Epochen-Zeit zum Fraß bzw. liefert diese (= Sekunden seit 1.1.1970), ./wake macht daraus etwas menschenlesbares. Das Einschreiben einer Null oder vergangenen Zeit löscht die Alarmzeit. Jeglicher Schreibvorgang löscht den Alarmzustand (rote LED im Versuchsaufbau). Der Alarm wird unabhängig vom Betriebszustand des Raspberry Pi ausgelöst, nicht erst wenn dieser ausgeschaltet ist. Irgendwer entfernt den Alarmzustand automatisch nach rund 10 Minuten, vermutlich das Kernel-Overlay. Außerdem wird der Alarmzustand beim Hochfahren gelöscht. Der Echtzeituhr-Chip DS3231 erlaubt nur das Aufwecken innerhalb der folgenden 28..31 Tage.

Erweiterung: Temperaturmessung

Der DS3231 enthält einen eingebauten Temperatursensor, der ebenfalls in Logdaten einfließen kann. Die Software ist lächerlich einfach, denn im Kernel-Overlay ist das wichtigste eingebaut. Die Temperatur steht in Tausendstel °C in der Datei /sys/bus/i2c/devices/1-0068/hwmon/hwmon0/temp1_input als Integerzahl zur Verfügung. Es scheint dass die Temperatur einiges zu hoch ist. Bei mir zumindest, auf beiden Exemplaren. Die Auflösung des Chips beträgt 0,25 K. Die Aktualisierung erfolgt standardmäßig alle 64 Sekunden.

Batterie-Ersatz

Ist in Zukunft die Knopfzelle leer,

• [Netzbetrieb] wird diese durch eine größere und haltbarere CR2032 mit Fassung ersetzt.
• [Akkubetrieb] wird der DS3231 direkt vom Akku gestützt, genauso wie der 4093 oder der Mikrocontroller.

WLAN

Hier geht es um die Einbindung in das TU-eigene Netzwerk „lab“. Laut URZ so etwas ähnliches wie „eduroam“, aber mit statischer IP-Adresse, geeignet für den Fernzugriff.

Mit LAN geht es problemlos, wenn mich nicht gebrochene Kabel ins Bockshorn gejagt hätten.

Inbetriebnahme

Eine merkwürdige Eigenart beider Raspberrys (2 und 3) ist, dass bei angestecktem LAN-Kabel das WLAN tot, von außen nicht erreichbar ist!! Also muss man beim Herumfummeln Tastatur und Maus anstecken, da WLAN via SSH über LAN nicht zur Funktion zu bewegen ist: Die Anzeigen (bei ifconfig, iwconfig sowie in der GUI) sehen allesamt normal aus, aber weder ping noch ssh (Putty) geht von außen über WLAN. ping -I wlan0 www.google.de, also herauszu geht allerdings. Ich hatte zunächst das URZ im Verdacht …

Der Netzwerk-Manager wird nicht benötigt: sudo apt remove network-manager. Vom URZ kommen Login-Name und Passwort. Dazu eine Zertifikat-Datei. Aus der wpa_supplicant.conf, die vom Netzwerk-Manager mit den gefundenen freien WLAN-Netzen gefüllt wurde, kann man getrost alles löschen und nur den einen mit essid="lab" (siehe Zip-Datei oben) eintragen. Es muss vermutlich alles haarklein stimmen. Durch Starten von sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf kann man die Funktion testen. (Notfalls vorher mit sudo killall wpa_supplicant einen laufenden Prozess beenden.) Das Programm spuckt im Normalfall permanent etwas aus und bricht nicht ab. Währenddessen zeigt die GUI die WLAN-Verbindung an, sowie die vom URZ zugewiesene IP-Adresse. Strg+C lässt das WLAN wieder zusammenbrechen. Ein Reboot startet dann wpa_supplicant wieder. Ohne Netzwerk-Manager.

Nunmehr läuft das WLAN schön zuverlässig, und es kann endlich weitergehen. Erst nach rund 2 Tagen kappt sich die WLAN-Verbindung; Ursache ungeklärt.