Autonome Zelle #3: Bodentemperaturen mit CubeCell, DS18B20, Solar & LoRa

Den Versuchsaufbauten der Autonomen Zellen #1-2 (Diskussion) folgend ist nun eine dritte passiert! (:

Idee: solarbetriebener LoRa-Node mit sechs Thermometern

  • Messung der Bodentemperaturen in 5, 10, 20, 50 und 100cm Tiefe sowie der 5cm-Lufttemperatur.
  • Stromversorgung per Solarzelle.
  • Datenübermittlung per LoRaWAN.

Umsetzung

  • 1x MCU HTCC-AB01: Heltec CubeCell Dev-Board (20€)
  • 1x LiPo-Akku, 3.7V, 2Ah (8€) (ggf. zzgl. JST1.25-Stecker)
  • 1x Solarzelle 6V/5W (12€)
  • 1x IP66-Gehäuse Spelsberg TK PC 97-6-TM (6.5€)
  • 1x Druckausgleichselement M12 (2.6€)
  • 2x Kabelverschraubung M12 (0.6€)
  • 3x Gegenmutter M12 (1€)
  • 1x IP54-Abzweigdose (0.5€)
  • 4x Verbindungsklemmen (3€)
  • 6x DS18B20-Thermometer & 1x 4.7kΩ Widerstand (19€)
  • 30cm Installationsrohr M16 (0.3€)
  • 5x Klemmschelle M16 (1€)
  • 1x Wäscheklammer
  • Lochrasterplatine, Pfostenstecker/-buchsen (3€)
  • Holz- und Kabelreste
  • kleine Kabelbinder

Eine “in-Gehäuse”-Antenne samt U.FL-Anschlusskabel liegt der MCU mit bei. Alternativ kann mensch natürlich eine Außenantenne für besseren Empfang anbauen.

Messaufbau

Um die Abstände zu halten sind die Temperatursonden an einem Holzstab angebracht. Obgleich der DS18B20 selbst am (hier: unteren) Ende ein jeder Sonde sitzt, sitzt die Sonde mittig zur Messhöhe, da sie ja aus diesem gut leitendem Stoff, Metall, ist. Der Holzstab ist “so dick wie nötig, so dünn wie möglich” gewählt, um eine thermische Beeinflussung durch ihn zu minimieren.

Der Stab wurde mehrere Stunden nachts, waagerecht der Außenluft ausgesetzt um eine “Angleichung” der Messwerte der Thermometer untereinander vorzunehmen.

Die Sonde für die Lufttemperatur wird von einer Wäscheklammer auf der gewünschen Höhe gehalten, die mit einem kleinem Holzspieß verklebt wurde. In die Wäscheklammer wurden noch zwei kleine Kerben gefeilt damit das Kabel gut gegriffen wird.

Gehäuse & Verdrahtung

Die Schaltung ist über zwei Gehäuse verteilt: Zum Einen in einem kleinen IP66-Gehäuse (MCU und Akku), zum Anderen in einer IP54-Abzweigdose (Klemmen für OneWire-Bus). So ist der OneWire-Bus eher in einer “Opfer”-Umgebung, aber die Verkabelung kann so deutlich einfacher/günstiger ausfallen, und der teuere und empfindlichere Teil bleibt im IP66-Gehäuse gut geschützt.

Akku

Auf dem Board ist eine ungewöhnlich kleine JST1.25-Buchse für den Akku verbaut. Die Belegung von Plus und Minus ist atypisch, aber beschriftet. Da ist noch eine kleine Verbindungsklemme drin, um ggf. wieder den Strom messen zu können.

Klemmschellen-Scharnier” für Solarzelle.

Damit sich die Neigung nicht verändert wurde einerseits (am Solarpanel) durch die beiden Klemmschellen und dem Installationsrohr je ein heißer Nagel eingebracht. Andererseits (zum Holzbrett mit den Gehäusen) sind die Klemmpunkte am Rohr mit Gewebeklebeband verstärkt, sodass hier mehr Klemmkraft ensteht, aber das Panel weiterhin einstell- und abnehmbar bleibt. (Das Klebeband wird wohl bei häufiger Nutzung gelegentlich erneuert werden wollen.)

Das Solarpanel ist mit 5W vmtl. arg überdimensioniert. Mal schauen.

Code

Zum Git-repository.

Praktisch ausschließlich aus den von Heltec bereitgestellten Examples (es gibt da nen guten Haufen) konnte ich recht zügig was zusammenzimmern, das erstmal recht zufriedenstellend zu tun scheint. Bin mal über die nächste Zeit gespannt.

Als Empfehlung zum Stromsparen schnappte ich in dem Kontext des Boards noch auf: RGB-LED disablen und auf die serielle Ausgabe verzichten.

Abgefackelt wird der Traffic über The Things Network (TTN), von dort via MQTT von nem Telegraf abgeholt und in eine InfluxDB gestopft. Die Daten werden mittels CayenneLPP verpackt. Die sieben Werte nutzen mit einer Airtime von 87ms und einem Sendeintervall von 5 Minuten wohl auch ziemlich genau die “Konsens-Airtime” pro Node (bei höchster Datenrate).

Tests

Bei nem Mess- & Sende-Intervall von 5 Minuten:

  • LoRa-WAN-Gateway ist zwischenzeitig aus (ca. 11 Minuten): Node läuft weiter, glaubt sich weiterhin im Netz “gejoined” und verhält sich wie sonst auch. Wenn Gateway wieder up, kommen auch wieder Daten. Ok.
  • LoRaWAN-Gateway ist aus während Node startet: nach Timeout: “join again at 30s later”. Gateway an, ca. 11 Minuten nach Node-Start: Klappte nicht. Gateway nochmal neu gestartet: Klappt. Hrm?!?.
  • Zwei DS18B20 fallen während der Laufzeit aus (Vdd abgeklemmt): Es wird nur noch ein Sensor ausgelesen. Nicht ok. Die beiden DS18B20 werden zur selben Laufzeit wieder angeklemmt: Wieder alle da. Okayisch.

Dashboard or it didn’t happen

Zum Dashboard.

Ausblick: Nächstes Design?

Vielleicht wird die 6V/5W-Solarzelle noch gegen ein kleinere (6V/150mA) getauscht. Eine Idee wäre es noch einem ähnlichen Setup, aber mit so nem “ultra low-power energy harvester”-Stein (ST SPV1050) und ner 2V/160mA-Solarzelle, ne Chance zu geben (Solar Power Manager Micro – DFRobot). Würde an nem CubeCell natürlich dessen Solarladeregler-Fähigkeit ignorieren. Ich hätte aber auch noch so nen TTGO mit LoRa da. Hmhmmhm.

5 Likes

Schön, dass sogar im November 3 Stunden (oben 7 - 10 Uhr) reichen, um den Akku wieder zu laden. Bin da zuversichtlich, dass die 5 W-Solarzelle auch im Dezember bei 5-Minuten-Intervallen reicht. But let’s see!

Sehr gut dokumentiert. Vielen Dank.
Was für ein Gateway setzt du ein?

Danke, und gerne. Bei Fragen; fragen. Aktuelles Mini-Update: Es gibt im LoRaWAN ja ein Konzept zur Anpassung von Datenrate und Sendeleistung, wenn der Empfang besonders gut oder schlecht wird. Adaptive Data Rate (optional). Das scheint bislang mit den CubeCells nur halb zu funktionieren; bei schlechtem Empfang wird die Datenrate runtergesetzt, aber bei wieder besser werdendem Empfang werden wohl noch die vom Netz gesendeten Empfehlungen ignoriert. (Es gibt Patches, ich teste …)

Ein Pygate von der Firma Pycom. @clemens hatte das hier Forum mal vorgestellt. Ich bin noch nicht so ganz begeistert; dafür steigt mir das zu häufig (alle paar Tage) aus und aus der seriellen Ausgabe wird man auch zum Zeitpunkt des Abrauchens nicht schlau. (Es mag noch nen mechanisch-thermischen Zusammenhang geben, da das PoE-Shield mit seinen Kontakten fast auf nem Kühlkörper aufliegt, very design-fail.)

Als nächstes Gateway würd ich dem wAP LoRa8 kit von Mikrotik ne Chance geben, da es sich preislich ähnlich einordnet und gleich samt PoE in nem Outdoor-Gehäuse kommt.

2 Likes

2 posts were merged into an existing topic: Pycom Pygate 8-channel LoRaWAN gateway

Ich hab das Board jetzt in der Entwicklung. Fast alles funktioniert. Als ich jedoch im Sketch LoRaSender den Sensor DS18B20 (DallasTemperature) einbinden wollte, gab es einen Konflikt mit OnWire-Library die in ASR650 eingebunden ist.

Ich habe verschieden Sachen versucht. Funktioniert nicht. Bei deinem Sketch erhlate ich den gleichen Fehler. Was hast du mit deinem Enviroment besonderes gemacht?

Ich bekommen diesen Fehler:
    WARNUNG: Bibliothek LoRa behauptet auf ASR650x-Arduino Architektur(en) ausgeführt werden zu können und ist möglicherweise inkompatibel mit Ihrem derzeitigen Board, welches auf CubeCell Architektur(en) ausgeführt wird.
WARNUNG: Bibliothek OneWire behauptet auf ASR650x-Arduino Architektur(en) ausgeführt werden zu können und ist möglicherweise inkompatibel mit Ihrem derzeitigen Board, welches auf CubeCell Architektur(en) ausgeführt wird.
WARNUNG: Bibliothek RGB behauptet auf ASR650x-Arduino Architektur(en) ausgeführt werden zu können und ist möglicherweise inkompatibel mit Ihrem derzeitigen Board, welches auf CubeCell Architektur(en) ausgeführt wird.
libraries\DallasTemperature\DallasTemperature.cpp.o: In function `DallasTemperature::blockTillConversionComplete(unsigned char)':
**E:\workspace_CubeCell\libraries\DallasTemperature/DallasTemperature.cpp:446: undefined reference to `yield()'**
collect2.exe: error: ld returned 1 exit status
exit status 1
Fehler beim Kompilieren für das Board CubeCell-Board(HTCC-AB01).

Das Problem: E:\workspace_CubeCell\libraries\DallasTemperature/DallasTemperature.cpp:446: undefined reference to `yield()’

Hast du da eine Idee?

Yay! (:

Stimmt, da bin ich auch reingerannt … ne andere oneWire-library musste her … mich dünkt, dass ich naheliegenderweise diese hier von Heltec selbst genommen hab [edit: also sichergestellt hab, dass sich statt der “klassichen” oneWire-lib lieber dieser hier im “Library”-Verzeichnis von “Arduino” befindet]:

Das ist nicht das Problem. Die Library DallasTemperature enthält einen Aufruf yield(). Dieser kann nicht aufgelöst werden. Ich hatte immer die neueste Version von Dallas installiert 3.9.0… Das ist das Problem.
Mit der Version 3.8.0 funktioniert es, egal welche OneWire installiert ist.

Aber Danke für deine Antwort.

PS: ohne Dallas geht es auch. Das Beispiel “DS18x20_Temperature.ino” funktioniert, nur etwas mehr Aufwand.

Oh, pardon. Du hast völlig recht & meine Erinnerung trügte – hab grad nochmal in die libraries geschaut und find dort für DallasTemperature auch die v3.8.0 und die OneWire scheint “vanilla” zu sein. Top fürs Rausfinden und näxtes Mal schreib ich solche Besonderheiten gleich mit auf ;)

Viel Spaß am Gerät!
Bleib ich mal auf weitere Erfahrungen gespannt.

Hab hier soweit auch noch 1-2 zu berichten:

  • Es gibt im LoRaWAN ein Feature namens “Adaptive Data-Rate (ADR)” um die Datenrate bei gutem/schlechtem Empfang anzupassen (robust vs sparsam): Das scheint mir soweit nur in eine Richtung (robust) zu klappen: Die Datenrate wird bei schlechtem Empfang gemindert, aber bei besserem nicht wieder erhöht. Da das aber auch vom LoRa-Gateway supported werden muss bin ich mir nicht sicher ob das allein dem HelTec-Stack anzulasten wäre. (Aktuell isses so natürlich ne Katastrophe für den Stromverbrauch, nen fixieren der Datarate/deaktiveren von ADR scheint mir in meinem Setup grad angezeigt.)
  • Manchmal steigt der Sensor aus, aber nen Reboot des Gateways hat geholfen. Manchmal auch erst der zweite Reboot des Gateways. Das macht mich jetzt noch nicht sooo sehr am HelTec aber wieder mehr an meinem Gateway zweifeln.

Sag uns bitte, daß das nicht die echte Akku-Spannung des Geräts ist - aber was ist das dann? ;)

Hmm, cool wäre jedenfalls, wenn die Solarzelle den Lipo in so kurzer Zeit laden könnte, im Winter und bei wenig Sonne. Schaut fast so aus als wäre es die LiPo-Spannung wenn keine Sonne scheint und wenn Sonne scheint die Spannung der Solarzelle, die könnte ja theoretisch bis 6 V, peak ggf. noch mehr. Wo misst denn das Gerät die Spannung?

Das sollte die Akku-Spannung des Gerätes sein. Wurde nur 1x mit einem Punkt kalibriert. Aber da sich die Kiste seit diesem 4.79V-Zeitpunkt auch nicht wieder (auch nach Neustarten des LoRa-GW) gemeldet hab, fürchte ich schon schlimmstes … ich tingel alsbald mal zum Ort des Geschehens und berichte … [edit, ps: bei nem ähnlichen Gehäuse hatte ich neulich Probleme mit diesem Wasser, da biss mich wohl der fehlende Gummiring an der Kabelverschraubung … let’s see and have silicone ready]

Ich hab aus dem Beelogger Projekt die Solar-Variante mit LoRa nachgebaut und mit viel Mühe einen SPV1040 aufgelötet. Der soll schon ab 0,3V Eingang aus einem Mini Solarpanel 3V, 0,3W einen LiPo Akku 18650 mit 2400mAh laden. Bei abgeklemmter Batterie messe ich am Ausgang tatsächlich 4,15V bei total trübem Schmuddelwetter und 0,4-0,5 V Solarspannung. Lora ist alle 6 min für 60 ms aktiv, um die Payload abzusetzen, dann geht das System wieder in den Deep-Sleep Mode. Nach drei Tagen zeigt der Akku einen Abfall von 0,01 V. Bin gespannt auf den Dauerbetrieb bei besser werdendem Licht.

Im folgenden Thread untersuche ich die Zusammenhänge von Akkuspannung, Solarladung und Messzeit: