Hardware für node im Feld (BOB Projekt, Phase 2)

bob

#1

Parallel zu den ersten Schritten im BOB Projekt (siehe Hardware für kontinuierliche Audio-Aufzeichnung (BOb-Projekt, Phase 1)) müssen wir die Hardware der später im Feld verwendeten nodes definieren.

“Im Feld” ist dabei wörtlich zu nehmen. Nach der ersten Phase - in der wir vor allem große Mengen Sounddaten sammeln möchten, um daraus Algorithmen zu generieren - sollen im Anschluss nur noch kurze Sound-snippets aufgezeichnet und vorausgewertet. In der restlichen Zeit soll der node schlafen. D.h. wir benötigen keine dauerhafte Stromversorgung über eine Steckdose, sondern können mit Batterien oder Akkus + Solar arbeiten und wir brauchen keine kontinuierliche Internetanbindung über WLAN oder Ethernet. Grob habe ich meine Idee zur Hardware schon mal hier vorgestellt.

Zum Thema gab es schon ein kurzes Telefonat (@caro, @tox, @Andreas) das ich aufgreifen möchte. Mein Vorschlag wäre:

Anforderungen

  • Batterie-/Akkubetrieb muss möglich sein
  • mit Arduino-IDE programmierbar
  • möglichst “Standardkomponenten”, die jeder einfach und kostengünstig überall - im besten Fall weltweit - besorgen kann
  • flächendeckend Datenübertragung in Deutschland, d.h. GSM/GPRS
  • leicht konfigurierbar, damit Imker ohne Elektronik-Wissen vorkonfigurierte Hardware in Betrieb nehmen oder anpassen können (besonders, anderen AP für GSM festlegen, Waage justieren)
  • Audio-Analyse muss möglich sein
  • eine Waage und “Kleinkram” wie Temperatur-, Feuchtesensoren usw. müssen natürlich auch angeschlossen werden können ;-)

Hardware

  • Microcontroller / SoC: ESP32
    WLAN zur einfachen Konfiguration eines vorprogrammierten nodes (optional auch zur Datenübertragung)
    I2S-Schnittstelle für digitales Audio
    zu klären ist, ob der ESP32 die Arduino Sound library oder ähnliches mit FFTAnalyzer unterstützt, falls nicht wäre ein Microcontroller mit Cortex M0-Prozessor eine Alternative, der kann aber für sich kein WLAN
  • Datenübertragung per GSM/GPRS: SIM800 (oder 808 with GPS)
  • (optionaler) Funk via LoRa / TTN: RFM95
  • Temperatursensoren: DS18B20
  • Feuchte-Sensoren: DHT22
  • Wägezellen-IC: HX711
  • über die Waage müssen wir noch gesondert sprechen

Prototyp sollen bis spätestens Herbst 2018 stehen, damit wir den Winter für Stabilitätstest verwenden können.


Vollständige Anleitung / wie kann ich helfen?
System für kontinuierliche Audio-Aufzeichnung (BOB Projekt, Phase 1)
#2

save the link: Sollten wir irgendwann soweit sein, ein audio Kondensat direkt auf einem Microcontroller auswerten zu können, möchte ich hier mal auf den teensy 3.6 hinweisen, der 4 i2s microphone vertragen kann.
Es handelt sich dabei um ein 32 bit 180 MHz ARM Cortex-M4 processor dev board.


#3

Stimmt, und für den Teensy gibt es von Paul Stoffregen auch eine Audio-Lib mit FFT:
https://www.pjrc.com/teensy/td_libs_Audio.html


#4

Das mit dem teensy klingt super, denn Thorsten ist immer noch sehr enthusiastisch, ein Ambisonicsystem umzusetzen.

Eine weitere Sache: ich habe heute mit Marten über die annotation der Daten via beep gesprochen. Dabei hat er viele Denkanstöße zum Thema Sychronisation gegeben. Ich glaube, wir sollten einen “Deckel auf” Sensor vorsehen. Wenn ein Teilnehmender imkerliche Eingriffe vornimmt, diese aber vergisst zu dokumentieren, dann sitzen wir womöglich verwirrt vor den Daten und fragen uns, was da los war. Wenn wir messen würden, wann der Deckel der Beute geöffnet wird, hätten wir einen Zeitstempel des Eingriffs (auch wenn er nachträglich dokumentiert wird) und wir hätten zumindest einen Anhaltspunkt dafür, wenn in einem Datensatz möglicherweise einfach die Doku fehlt. Dazu könnte man z.B. einen Helligkeitssensor oder Drucksensoer nehmen - was meint ihr?


#5

Danke, endlich - mein Reden seit Jahren! ;) Dieser eine Zustandsanzeiger bringt eine Menge, da neben er den von Dir beschriebenen Gründen auch noch gegen Freveler oder Diebe (z.B. zusammen mit GPS-Tracking per SMS… ab Sensor-Event) eingesetzt werden kann.

Ja, es bieten sich aber auch einfache, durch Magnet bediente, robust gekapselte reed-Schalter an. Sowas gibt es in großen Stückzahlen seit Jahren als Geber für Schaltschranktüren, Alarmanlagen, Museums-Objektsicherungen usw. :
image

Die lassen sich auch verdeckt bzw. im Inneren verbauen, Propolis und Wachs sind ohne Bedeutung für die Funktionsfähigkeit. Abgebildet oben ist ein NO-reed-Kontakt (normally open), er wird also per Magnet geschlossen, die Unterbrechung dieses Stromkreises ist dann also das auszuwertende Ereignis. Ein Kontakt umgekehrter Polarität (NC) wäre hier nicht günstig, da mit Magnet dann “kein Stromfluß” auch identisch sein könnte mit “Schalter abgetrennt” - der dabei eingesparte Ruhestrom im Normalfall spart also an Funktionalität, da man mit NO-reeds auch immer die ordnungsgemäße Verbindung testet. Der Ruhestrom darf auch sehr klein bemessen sein und muß auch nicht 24/7 anliegen.

Wenn man lediglich einen (verdeckten) reed-Kontakt verbaut, der dann manuell per Magnet getriggert werden muß, könnte man auf den fest verbauten Gegenmagneten verzichten - die Erfahrung zeigt aber, daß dieser erstere ‘lose’ Magnet verloren geht, vergessen wird usw., lieber eine Lösung mit festem Magnet auf der anliegenden Seite der Magazinbeute.


#6

Moin.

So als ganz “Neuer” eine Überlegung.

Was haltet ihr von einer RFID-Legitimation? Also Imker kommt an seinen Stock und hält kurz seinen Chip an die Antenne und das wird dann als legitimierter Zugriff gewertet und registriert.

Zu Datenübertragung: Ist ein Imker jeden tag vor Ort? Was haltet ihr davon etwaige Daten via Handyaccespoint einzusammeln, oder gleich an den heimischen Server zu übertragen? Bluetooth würde ev. ja auch gehen.

Wenn LoRa als Übertragungsweg zum Tragen kommen sollte, würde mir noch der Grashopper einfallen. Allerdings ist der im Moment vom Preis her noch ähnlich teuer wie der Feather M0. Zu erwerben ist der Grashüpfer bei Tindie.

Gruß

Tante Edit: Nein ich bin selbst kein Imker.


#7

Absolut, @einsiedlerkrebs hat sogar schon Reed Kontakte hier, die im nächsten Prototypen installiert werden sollen und genau für den von @caro beschriebenen Zweck vorgesehen sind. Danke auch hier nochmal an Euch beide dafür, dass Ihr die für den Praxiseinsatz wichtige Detailaspekte wieder auf den Tisch bringt.


#8

Für mich war es immer wichtig, dass Beuten ohne Umbau genutzt werden können. Ich sehe da mindestens zwei Probleme (1) Wenn wir im oberen Magazin einen Reed mit Kabel haben muss das Kabel durch die Beute innen oder außen bis zum Boden. Wie bekomme ich die Magazine dann auseinander? Oder anders rum von der Waage zum Deckel. (2) Was passiert, wenn ein Magazin / Honigraum dazu kommt? (ggf.3) Oder der Deckel um 180 ° gedreht wird? Wünschenswert finde ich es, mir ist nur keine praktikable Lösung dazu eingefallen außer ein Bewegungssensoren ohne Kabel nur mit Funk im Deckel.

Für RFID sehe ich keinen Einsatz. Der switch muss triggerbar sein, auch wenn der Microcontroller schläft. Wenn der immer fragen muss, ob der RFID-reader das richtige tag sieht können wir den sleep mode vergessen, genauso BLE, ggf. Kann man mit einem Taster zuvor aufwecken und dann RFID oder was auch immer machen. Ich finde es zu viel Aufwand, online sagen ich imkere und alte Daten in der Zeit werden verworfen.


#9

Wir haben uns auch ziemlich von den Kabeln der Temperatursensoren behindert gefühlt, die wir fest in die Rähmchen/Oberträger verbaut hatten. Ich stimme dir voll zu @clemens, wir müssen es praktikabel bauen. Wir werden uns eine Lösung für die Kabel ausdenken müssen, denn sicherlich können wir nicht alle Sensoren kabellos machen.

Wenn das Kabel des Reed am Deckel hängt und außen liegt, kann ich mir vorstellen, dass man den Deckel einfach bei Seite Stellen kann und es nicht groß stört.

Für die Magnet-Hälfte wäre eine Idee, sie ohne großen baulichen Aufwand an die jeweils oberste Zarge zu kleben/hängen. Bei Segeberger Styroporbeuten ist innen echt wenig Platz zwischen Deckel und Rähmchen, vor allem wenn da noch die Folie drauf liegt.

Alternativ fällt mir sonst noch ein, die Gewichtsmessung hochfrequent laufen zu lassen, z.B. 1Hz. Dann können wir in den Messdaten der Waage sehen, wenn der Honigraum abgenommen wird und die Empfindlichkeit schätze ich auch hoch genug ein, dass man sieht, wenn Rähmchen gezogen werden. Ob sie ausreicht, um das Gewicht des Deckels zu detektieren, müssten wir testen.

Da mir die Info, wann geimkert wurde, vor allem für die Annotation der Messdaten als Trainingsdaten für die Algorithmen wichtig ist, könnte ich auch mit einer stromfressenden Lösung leben. Ich bin recht zuversichtlich, dass wir die Info später aus der Sensorfusion rauskitzeln können (Änderung im Gewicht+Temperatur+Feuchte+Sound)


#10

Der Deckel-Sensor ist eine Möglichkeit imkerliche Eingriffe zu tracken. Aber auch damit können Artefakte auftreten, z.B. lege ich immer Material wie Stockmeißel, oder andere Dinge des Nebenvolks wie den Honigraum, Deckel oder was auch immer auf dem Nachbarvolk ab, wenn ich das Volk daneben bearbeite, hier kann immer mal ein falscher Wert durch die Bearbeitung entstehen. Wir brauchen hier eine universelle Lösung, wie du @caro schon schreibst werden wir das eh detektieren, die Bruttemperatur geht runter, Feuchtigkeit ändert sich, ggf. ändert sich das Gewicht. Ich würde das mit einer notification / Alarm verbinden und den Imker fragen, ob er in der Zeit bearbeitet hat. Falls ja, wird das vermerkt und ggf. Daten verworfen. Paralllel hat der Imker natürlich die Möglichkeit das im Voraus per Internet anzukündigen, dann werden die Benachrichtigungen für x Minuten deaktiviert und ggf auftretenden Messwert-Differenzen nicht als Alarm ausgewertet.

Das wäre eine Möglichkeit das Kabel nicht am Magazin zu führen, sondern am Deckel, was es nicht elleganter aber zumindest handhabbarer vom Kabel her macht. Bleibt immer noch das Problem des um 180 ° gedrehten Deckels, das man mit zwei Gegenstellen am Magazin lösen könnte. Das größte ungelöste Problem ist aber der Magazinwechsel. Bei Zander / DN habe ich ggf. einen zweiten Brutraum und zwei, ggf. auch drei Honigräume. Für alle bräuchte ich Gegenmagenete und zwar je zwei, die ggf. mit einer Fräsung des Holzes eingelassen werden müssen.

@weef, die Sonsoren oben, wie müssen die montiert werden? Müssen sie auf der flachen Seite sich berühren - dort wo beide den Aufdruck haben - oder auf der flachen Seite, d.h. so wie sie auf dem Foto auch liegen? Bei letzterem sehe ich noch die höchsten Realisierungschancen. Bekommt man einen zweiten Magneten auch “solo”, damit man den use case “Deckel gedreht” auch abdecken kann? Wobei das bei entsprechender Kabelführung am Deckel nicht so häufig vorkommen sollte.

Als unauffälliger Diebstahlschutz ist eine Außenmontage vielleicht nicht so toll, aber für unseren Zweck sehe ich eigentlich nur das als Möglichkeit. Auch wenn es innen vom Platz ginge müsste das Kabel ja dann über BR 1, BR 2, HR 1, HR 2, HR x geführt werden, die dann nicht mehr bearbeitbar wären, oder nur mit viel Kabel daziwschen.

1 Hz ist für Phase 2 nicht realisierbar, wir nehmen schon jetzt den Median aus 5 Messungen mit jeweils 3 Sekunden dazwischen um Ausreisser, die z.B. durch Winddruck verursacht werden und bei professionellen Waagen berichtet werden zu eliminieren. Wir können so was gerne für Phase 1 einplanen, da wird die Masse eh von den Audidaten Audiodaten ;-) generiert, für Phase 2 sehe ich das nicht. Wir schaffen mit einer Messung pro Sekunde sicher keinen Batteriebetrieb, auch wenn wir lokal auswerten. Der Batteriebetrieb ist für Phase 2 aber eine conditio sine qua non.


#11

Moment … wir sind hier nicht in Würzburg bei Tautz! :)


#12

Wegen dem Deckelsensor, mal pragmatisch gedacht: auf meinen Beuten liegt ein 5-6 kg schwerer Stein. Wenn ich an der Beute arbeite nehme ich den Stein runter und sehe das ziemlich eindeutlich in der Gewichtsmessung, wäre also ein Frage des Timing (wann,wie oft wird gemessen) und ist einfach zu korrelieren.


#13

Heyho, mal eine neue Richtung in diesem Thread:

Bei easyhive wollen wir dieses Jahr noch einen Prototyp für eine sigfox-Waage aufbauen. Für’s erste wollen wir versuchen ein Shield für die Boards von Pycom zu entwerfen. Damit das auch für BOB sinnvoll verwendbar ist, könnten wir uns hier nochmal über die Anforderungen an so ein Shield abstimmen.

bisher wären das aus unserer Sicht:

Steckverbinder-Anschlüsse für:

  • Wägezelle(n) (1 - 4) -> je nachdem wie viele reinkommen muss evtl. auch ein anderer ADC dahinter gestellt werden. Für unser System brauchen wir höchstwahrscheinlich 2 Eingänge.

  • One-Wire Temp-Sensoren (GND,VCC,DATA)

  • Feuchtigkeitssensoren

  • I2S-Audio-Breakouts, die im Stock positioniert werden können

  • Batterie

  • Solarpanel (+Ladereglersystem)

Gibt’s weitere wichtige Anforderungen an das Shield? was ist mit einem SD-Kartenslot?


#14

Hi.

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.

An welche Art von “Anschüsse” denkt ihr da?


#15

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.


#16

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).


#17

Heyho,
wir haben jetzt ein Blockdiagramm basierend auf unserem Breadboardaufbau gebastelt. Das sieht folgendermaßen aus:

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? ;-)


#18

Hi,
ich freue mich, dass ihr Fortschritte macht!

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


#19

Zum Thema JST (PH)-Verbindungen crimpen habe ich mal einen neuen thread erstellt.

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.


#20

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.