Das wäre ja schon mal ein ganz schön nettes shield! Sind diese dann eigentilch auch mit den anderen pycom varianten benutzbar (LoPy im Speziellen)?
Mit SD haben wir ja immer auch unsere Schwierigkeiten, wegen z.B. der Feuchteanfälligkeit. Aber solange sie tut tut sie, ist ein billiges (Zwischen-) Speichermedium und wenn das Betriebssystem da nicht drauf liegt passt das.
Wichtiger fände ich die Überlegung, ob da nicht noch eine RealTimeClock mit extra Stromversorgung an einem Interrupt mit dran hängen sollte. Oder kann der ESP richtig “schlafen”? Natürlich ist es auch nett für das erzeugen des Zeitstempels am Datensatz.
Wir haben das nochmal gestern am Telefon diskutiert und etwas Probleme die “eierlegende Wolmilchsau” zu definieren. Bei den 1-4 Wägezellen ist z.B. die Frage, ob sie parallel geschaltet werden sollen oder differentiell ausgelesen werden sollen. das hat deutliche Auswirkungen auf den verwendeten Wägezellen-Chip.
Bei der Zwischenspeicherung sehe ich aktuell eher Bedarf für einen kurzfristigen Puffer, z.B. die Werte eines Tages zu puffern, um nur einmalig das WLAN oder GSM-Modul … anschalten zu müssen, damit Strom gespart wird aber auch die ggf. vorhandene Störung durch nahe am Stock positionierte Funkmodule zu minimieren. Dafür könnte der auf dem ESP vorhandene Speicher reichen.
Klar ist SD als backup schön. Wir bräuchten dann aber wieder die Möglichkeit diese Daten händisch im backend hochzuladen. Nur als CSV wird die sich vermutlich niemand mehr anschauen.
Nochmal zum Deckelthema… obwohl mir andere hier genannte Ideen sehr gut und eigentlich besser gefallen, nochmal eine Anmerkung hierzu:
Ist natürlich auch eine Möglichkeit, die wir öfter wieder verworfen haben, weil das Lesegerät ja den Strom braucht/induzieren muss. Wenn es aber um die bloße Makierung geht: - Imker ist da - könnte mensch den Spieß auch umdrehen.
Auf der Beute klebt irgendwo ein NFC-Tag. Das Imker_ding kommt vorbei und ließt den Tag mit dem Smartphone aus. Damit identifiziert sich die Beute, nun müsste da noch eine kleine App sein, die beim Lesen eines Tags einen HTTP-Post absetzt, welcher eine Annotation in der Datenbank erzeugt, dass jetzt an der Beute gearbeitet.
Danach kann sich wieder auf die gleiche Art abgemeldet werden. Später (oder in einer etwas umfangreicheren App), könnte dann diese Annotation einen Direktlink zum Stocktagebuch darstellen. (Aber dass ist natürlich unabhängig von der Art wie das Zeitereignis bestimmt wird).
Zu den Sensoren, die ja weitgehend Standard sind gäbe es noch zwei Taster für das “taren” und das “eichen” der Waage.
Für den LadeIC (BQ24072) haben wir uns entschieden nachdem wir das OSBH-Buzzboard getestet haben und der ziemlich gut performt.
Tipps und Anmerkungen sind willkommen!
Außerdem die Frage an @Clemens und @Caro ob sie das so nutzen wollen würden. Die Pycom-Boards haben etwa 500kb flash-speicher frei für Zwischenspeicherung. Also nicht länger als wenige Sekunden Audio.
Als stecker könnten vielleicht JST PH’s genutzt werden? Einwände? ;-)
Zu den Steckern: wie ist das in der Praxis gedacht? Die Crimpzange für die JST PH kostet (bei digikey) ca 500Euro. Das wird sich ja niemand zulegen, um nur eine oder einige wenige Beuten zu bauen.
Für mich ist es wichtig, dass wir auch Imker*innen an Bord holen, die nicht löten können. Ich fände einen Aufbau optimal, bei dem die Stecker entweder zum Aufschrauben oder Quetschen sind. Oder wie hattet ihr euch das gedacht, wie kommen die Sensoren an die oben verlinkten Kabelstücke ran?
Gruß caro
Aber auch mit der billigeren Zange ist das nicht so einfach und auch wenn die “nur” 35 EUR kostet wird man sich die nicht für zwei Stecker kaufen wollen. Theoretisch soll so was auch mit einer kleinen Flachzange gehen, da muss man ebenfalls Ahnung haben und das auch schon ein paar mal gemacht haben. Daher würde ich die JST-Verbindungen nur verwenden, wenn Verpolungssicherheit kritisch ist und wir die Stecker schon irgendwo fertig haben, z.B. an einer Solarzelle oder an einem LiPo!
@iconize und @marten.schoonman von Beep verwenden auch JST-Stecker machen die Verbindung aber anders. Sie kaufen fertig konfektionierte Kabel und verlöten dann den Stecker mit dem Kabel am Kabel des Sensors. Ich denke man kann dann aber auch gleich Schraubklemmen nehmen. Wenn man doch mal tauschen möchte oder muss, können Stecker auch hinderlich sein, da sie nicht mehr durch die Kabeldurchführung am Gehäuse gehen!
Für den Anschluss von Sensoren oder der Wägezelle würde ich Schraubklemmen verwenden, die sind günstig, überall zu bekommen und kann jeder “bedienen”, am liebsten im 3,5 mm Rastermaß. Da sind die Abstände etwas größer und man kann die Kabel gut einführen.
Habe gerade mal einen kurzen Blick ins Datenblatt geworfen. Ist der nur für USB, also 5 V spezifiziert? Können wir da nicht etwas verwenden, das auch Solar kann? Etwa den CN3065, der beim Seeeduino Stalker verbaut ist? Der kommt auch mit USB zurecht, kann aber auch Solar. Oder verwendet den OSBH ausserhalb der Spec auch mit Solarzelle?
Wenn es nicht anders geht, müssten wir uns auch entscheiden, ob ein Dauerbetrieb mit Solar das default-Szenario ist, oder wir sagen Batterien, die dann aber bis zum Ende “ausgelutscht” werden, d.h. wir würden eher in Richtung Boost-Converter gehen. Dann könnten wir aber keine Akkus mehr an diesem System betreiben! Mein Favorit wäre etwas mit Solar.
Den CN3065 habe ich noch nicht testen können. Der BQ24072 erwähnt im Datenblatt nicht, dass er für Solar geeignet ist, hat aber ein Regelkreis für schlechte USB-Ladequellen eingebaut, welcher sich auch für Solar zu eignen scheint. Operation voltage ist ähnlich dem CN3065 ab 4,4V. Hier die Grafik aus dem Datenblatt dazu.
Ein Vorteil wäre meines Erachtens, dass beim BQ24072 die Batterie vom Rest des Systems getrennt werden kann (es gibt separate OUT-Pins) - beim CN3065 wird die Load direkt an die Batterie gehangen, was eventuell zu Tiefenentladung und schädigung des Akkus führen kann. Allerdings habe ich noch nicht genau verstanden wann der BQ24072 die Batterie vor Tiefenetnladung schützt (im Datenblatt steht was von VBsup2 threshold…)
Richtige Solarlade-ICs mit Step-Up Konvertern sind aufwändiger und teurer. Beelogger verwendet z.B. den SPV1040. Und ob der für L-Ion-Akku-Laden geeignet ist, scheint mir nicht ganz klar. (Wobei auch die Frage nach der Akku-Chemie noch aussteht…? )
@Clemens könntest du versuchen den Ladestrom von dem CN3065 Board mit dem Solarladeboard von Adafruit zu vergleichen? Bei unseren Tests hatte der BQ24072 ungefähr doppelt so viel Leistung aus der Solarzelle herausgeholt als das Adafruit-Board.
Wie der mit ungleichmäßiger Eingangsspannung von der Solarzelle vs. andere Lader für Konstantspannung (bei USB) umgeht kann ich auf die Schnelle nicht sagen. Vielleicht hat @weef da mehr Ahnung.
Hier ist jetzt Schaltplan und 3D-Ansicht von dem easyhive-Testboard. Die Pin-Header sind nur symbolisch - da wäre dann Platz für Schraubklemmenstecker - allerdings 2,54mm Rastermaß. @Clemens Wir haben uns wegen des Platzmangels gegen 3,5mm entschieden…
Die Beschriftung der Verbindungsteile steht noch aus…
@Caro: I2C konnten wir noch mit einplanen - leider nicht testen mit eurem Sensor, aber wir hoffen mal dass es geht.
Zu den einzelnen Bauteilen kann ich jetzt wenig sagen außer dass wir uns an die datenblätter gehalten haben von den ICs und wir hoffentlich keine sinnlos verbaut haben.
Ist das für dich wegen des DIY-Charakters entscheidend @Clemens?
Anschlüsse für weitere Wägezellen mussten erstmal wegen platzmangel wegfallen, aber die könnte man ja auch zusammen an die schraubklemmen befestigen, oder?
Wir würden diese Woche dann ein erste Platine für einen Prototypen bestellen wollen. Falls ihr noch Anmerkungen habt, dann gerne her damit.
Bin bisher davon ausgegangen, dass ein HX711 breakout board verbaut wird. Bekommt ihr denn den nackten chip irgendwo her? Falls nicht wäre ein ADS1232 eine Alternative, dann müssste der Schaltplan aber angepasst werden!
Hmm, Stifteleiste mit Schraubklemmen einfach tauschen, die brauchen etwas mehr Platz, könnt ihr bitte das mal virtuell testen, ob die neben dem LoPy noch Platz haben, Danke!
Sorry, ich bin nicht so tief in der Materie, was Energieversorgung angeht. Könnt ihr mir nochmal kurz das Energiekonzept erklären? Sehe ich das richtig, dass es jetzt keine Möglichkeit gibt, den Lopy an ein Netzteil zu hängen? Man braucht einen LiPo, und muss den, falls man nicht an einem sonnigen Fleckchen wohnt, mit einem externen Ladegerät laden?
Wie kam es zu der Designentscheidung, den HX711 mit auf das Board zu holen? Handelt man sich da nicht recht viel Störung ein, wenn man die Analogsignale unverstärkt bis in die Beute hoch zieht?
Hey @Caro& @Clemens
das Energiethema ist ein guter Punkt.
Wir könnten einen optional usb-anschluss auf das Board bringen, sodass das System auch per USB betrieben (und falls man möchte aufgeladen) werden kann.
Ich rede mal mit unserem PCB-Designer dazu.
Den Hx711 haben wir auf dem Board verbaut weil bei unserer Waage das Board in der Nähe der Wägezelle liegt, der Hx711 deutlich günstiger ist als der ADS1232 und die gängigen Breakout-Boards für den Hx711 für 5v und nicht für 3V ausgelegt sind und damit unbrauchbar (siehe beelogger-Solar - Beschaltung & Aufbau - Arduino Datenlogger mit Stockwaage für Imker unter Modifikation HX711-Board)
Hx711 lassen sich (anscheinend) günstig über alibaba - bestellen.
für erste Tests werden wir die von den Breakout-Boards runterlöten.
Das sind pro Stück maximal 1,5€ mehr. Der DHT22 wirft häufig genug (ab Werk oder nach einigen Monaten) dauerhaft eine Feuchte von >= ~99% und ist damit unbrauchbar.
Bzgl. einer meteorologisch grob fachgerechten Anbringung verweise ich an dieser Stelle noch auf den Thread zu Klein-Wetterhütten.
Wieder einmal eine super geile Grafik von @wtf, Danke! Frage mich gerade warum die Luftdaten-Daten (LDI = LuftDaten.Info) bei der Temperatur ganz andere Wertebereiche haben als der DWD. Ich gehe mal von mir aus und sage, da sind auch indoor-Sensoren dabei? Verfälscht das dann den Feuchte-Vergleich?
Ja, es ließe sich ja nur am Wert erahnen ob der Sensor drinnen hängt. Wie erwähnt ist der “Ausschnitt” aus dem LDI noch sehr groß: Teile Norditaliens und Kroatiens sind südlich mit drin. Eine fleißige Biene namens @Andreas plant dazu aber schon ne schöne Wabe namens “Stationsliste”.
Ein Verfälschen findet also gleichsam überall statt: Wir haben ja auch keinen Einfluss auf die Verteilung der unterschiedlichen Sensortypen oder treffen eine repräsentative Auswahl. (Noch nicht? ;)
wir gratulieren Euch vielmals zum ersten Release der Arbeiten an diesem Datenlogger. Sehr spannend was Ihr da treibt: Zum Entwickeln von solchen Geräten mit der Leistungsfähigkeit des ESP32 und dann obendrein mit dem Komfort von Python programmierbar ist die ganze Angelegenheit eigentlich mein derzeitiger persönlicher Wunschkandidat, was Firmwareentwicklung angeht.
Pycom und Adafruit kommen uns da ja grade grundsätzlich sehr entgegen (siehe ESP-IDF and beyond: Lua with NodeMCU, Pycom's MicroPython fork and Adafruit's CircuitPython), nur selbst hatte ich zum Rantasten bisher noch nicht die Gelegenheit. Umso toller ist es nun, dass Ihr Euch nun schon stellvertretend die Finger schmutzig gemacht und die Grundlagenarbeit geleistet habt (danke!), auf der man weiter aufbauen kann.
Auf Englisch würde ich dazu im TLDR; Stil sagen:
[quote blueprint]
Nice to see some MicroPython code from the wild in the context of beehive monitoring, looking forward to send some PRs.
Hi Ron, super!! Da sitzt gerade ein GPy drauf, von den pins könnte aber auch ein LoPy für LoRa oder ein günstiger WiPy für WiFi only drauf, oder? Habt ihr schon sourcen für den HX711 als chip alleine gefunden? Bisher habt ihr den ja von einem HX711 breakout runtergelötet.
