Ich fürchte, dieses Gehäuse wird wohl nicht mehr aufzutreiben sein :)
Bei Conrad gibt es das noch!! Aber die neuen von Reichelt sind besser.
Didi
Ich finde Caros Vorschlag für das Gehäuse gut. Es ist geräumig und man hat genügend Platz für das Board mit HX711, die Kabel und Verschraubungen. (Edit: ich hatte für das Bild leider nicht genug Schraubklemmen mit 3,5 mm Pin-Abstand )
Wer will, kann das Board nach Bedarf weiter bestücken mit OLED-Display, Tastern, LEDs und Buchsen/Schraub-Steckern.
Dann ist der BOB-HAT ein vollständiges Entwicklungsboard für die Entwicklung mit MicroPython und Arduino-IDE, Taster Reset und Flash sind leicht zugänglich. Auch LTE- und LoRa-Antenne passen gut ins Gehäuse. Vom Expansion-Board kann die USB-Schnittstelle, die SD-Card und das Laden des Akkus benutzt werden.
Die solare Stromversorgung sollte im 2. Schritt in einem extra Gehäuse erfolgen. Ich habe vorbereitet:
- flexibles Solarmodul 20 Wp,
- Stepdown-Regler 6 – 30 V auf 5 V,
- Powerbank 10000 mAh.
Diese Box kann dann das USB-Netzteil ersetzen.
Viele Grüsse
Didi
Wie bekommen wir ein Micro-USB-Kabel durch die Kabel-Durchführung? Oder gibt es USB-TO-JST, die durchpassen sollten?
Ein Micro-USB-Stecker passt durch eine M16x1,5 Kabeldurchführung. Hab ich gerade ausprobiert.
Edit: Leider nur die abgerundeten, die eckigen passen nicht.
Ich habe meinen Fritzing-Entwurf überarbeitet:
BOB-HAT-V2.fzz (51,4 KB)
Die Platine
Der Schaltplan
Es muss nur nach Bedarf bestückt werden.
Didi
Vermutlich hat das von dir vorgeschlagene Gehäuse mit durchsichtigem Deckel mich zu der Annahme verleitet, dass hinter einen transparenten Deckel eine Solarzelle muss! ;-) Je nach Sendefrequenz wird auch ein Akku – den ich bei Andreas gefunden habe – schnell leer, daher mein Ansinnen mit der Solar-Ladeelektronik. Kann, muss aber nicht, ok!
Man muss die Kabel auch nicht zwingend da herausführen wo die Schraubklemmen sind. Meist ist es einfacher etwas Kabel zu geben und dann die Kabel im Gehäuse mit 90° oder auch 180° an anderer Stelle auszuführen.
Juhuu, @weef, freut sich gerade sehr, weil ihm meine Schraubklemmen schon seit Jahren suspekt sind. gerade wenn die Kabel verzinnt sind “läuft” die Verzinnung unter dem Schraubendruck weg und macht den Kontakt weniger stabil. Federklemmen passen sich den veränderten Druckverhältnissen an und sind, so @weef, für diverse Kabel"veredelungen" geeignet, von Kabelendhülsen bis verzinnt
Wie (per PM schon) gesagt. Spelsberg ist natürlich eine andere Liga, unser “Wetterfrosch” / @wtf verwendet die sehr gerne. Bei dem von dir verlinkten Gehäuse sind allerdings Aussparungen für M16er Kabeldurchführungen.
“Meine” M12er Kabeldurchführungen sind für Kabel von 3-7 mm Durchmesser, die M16er dann schon für Kabel ab 4,5-10 mm, s. ESKV-SET, mit Gegenmutter - Kabeleinführungen - WISKA, das bedeutet, dass dünne Steuerleitungen hier nicht mehr gehen, ich hatte die Abschnitte der Temperatursensoren z.B. für Außensensoren verwendet, das wäre mit den M16er grenzwertig. Ansonsten sollte das passen.
Was mich wundert:
https://www.spelsberg.de/nc/produktdatenblatt/an/10600901/Produktdatenblatt.pdf
> Geeignet für Aussenanwendung: Nein
> Witterungsbeständigkeit: Nein
??? Hmmm … warum nicht, weil das Acryl bei Sonne blind wird? Oder gibt es andere Gründe?
Das Kabel hat aber nicht 4,5 mm Durchmesser, oder?
bzgl. der
Gehäusedurchgänge
fand ich es immer unpraktisch, wenn die Sensorkabel roh durch das Gehäuse müssen.
In der Erfahrung hat sich das bisher oft so gestaltet, dass ich einen Node debuggen/reparieren/weiter entwickeln musste und dazu muss er aus dem Gehäuse raus. Die Sensoren können aber natürlich nicht mit, weil die mehr oder minder fix (z.B. je nach Jahreszeit, oder Aufwandsbereitschaft) mit der Beute verzahnt sind. Wenn ich den Node dann wieder zurück ins Feld bringe, muss ich dann wieder die Belegung der Kabel wissen, wenn ich sie mit dem Node verschraube.
Dann war es mir auch immer zu aufwändig, für jedes Kabelchen (z.B. 4xDS18B20) einen eigenen Gehäusedurchbruch zu spendieren. Wenn ich aber mehrere Kabel durch eine Gehäusedurchführung bringe, ist das nicht mehr rund, also auch nicht mehr richtig abgedichtet. Daher bin ich jetzt bei einem dreiergespann angelangt:
- Sensornode mit Schraubklemmen
- Gehäuse mit fest verklebten Kabeln (Durchbrüche) und Steckern
- Sensorik mit Steckern.
Das sieht dann ungefähr so aus:
Die Stecker sind aus dem Bootssport ggf auch KFZ-Bereich. An der Kabeldurchführung habe ich die Kabel mit Schrumpfschlauch und Heißkleber an Ort und Stelle (Die Kombi macht Spaß) fixiert. Die
WAGO Klemmen splitten hier die Stromverorgung bequemer für mehrere Verbrauchen auf.Dieses Gehäuse ist üppig groß, kleiner geht also auch. Ich mag ja transparente Deckel, um noch eine LED signalisierung sehen zu können, wenn alles zusammengesteckt und an Ort und Stelle ist, der FinaleTest, bevor ich dann wieder zuhause drinnen am Rechner sehen muss, dass doch kein Signal da ist.
1 Like
Ich denke man muss unterscheiden, ob es Hardware in der Entwicklung ist oder halbwegs ausgereift. Fürs Basteln ist sicher eine Steckerlösung sinnvoll, wenn ich oft oder öfter an den Microcontroller ran muss! Bei unseren Imkern sollte das aber nicht so sein, die sollen das System einmal aufbauben und dann aufstellen. Weitere Stecker machen die Hardware teurer und vor allem muss irgendwie der Sensor dann angelötet werden. Wir wollten eigentlich so weit wie möglich aufs löten für den Zusammenbau verzichten.
Fürs Basteln und prototyping super Anregungen @einsiedlerkrebs! Für die Anwender sollte es in manchen Punkte aber professioneller sein, z.B. keine heraushängenden Stecker, keine WAGOs (jetzt bekomme ich hier bestimmt gleich Schimpfe, weil ich sage, dass WAGOs nicht professionell seien ;-)
Ach, es ging doch nicht darum die professionelle Lösung zu präsentieren… . Ging nur um Input von Problemen und Lösungen.
Ich habe mal mit 2 mal M16 Kabel-Durchführungen experimentiert:
Der weisse Micro-USB-Stecker passt gerade durch das Loch, der abgerundete Python und der eckige nicht mehr. Wenn man die Verschraubung ganz zusammendreht, sitzt das Kabel einigermaßen fest. Das ist meiner Meinung nach ausreichend wasserdicht.
Didi
Wir haben im Workshop im Oktober diese Boxen verteilt, da wir damals noch davon ausgegangen waren, dass wir Strom vor Ort haben und damit auch ein USB Netzteil in der Box unterbringen wollen. Was mir an diesen Boxen immer gut gefallen hat, ist die zweigeteilte Kabeldurchführung. Man muss sich keine Gedanken um Steckergrößen machen. Ich hatte von diesen Boxen wieder Abstand genommen,weil der FiPy darin so verloren aussieht.
Wären diese für euch auch ne Option? Vorteile: kein Bohren für die Kabeldurchführungen, genug Platz für ein Ladegerät oder auch ne große Powerbank. Nachteile: kein transparenter Deckel.
Ich leite daraus ein JA! ab, und dass ihr das Fritzing entsprechend anpasst?
Ja für Federklemmen, ich würde aber nicht die mit 5 mm RM nehmen, die verschenken zu viel, die gibt es auch im 3,5 RM, die würde ich nehmen (dann braucht es keine Änderung der Platine, ausser die sind deutlich breiter als die Schraubklemmen), bin gerade noch am Suchen, ob top entry (also Kabelzuführung von oben), von der Seite oder 45°. Bei Segor finde ich die gerade nur mit top / 180°. @weef du hattest irgendwo mal ein Foto gepostet, was waren das für welche?
@didilamken, du hast bei deiner Platine den untersten pin der Schraubkelmme für die Wägezelle mit dem dritten pin verbunden, der dann zu E- der Wägezelle geht, hmmm E- hört sich erst mal nach GND an, ist es aber nicht, sondern exitation - der load cell. Bin auch nicht der Experte, habe aber immer die Schirmung der Wägezelle mit GND verbunden!
Ist halt nur IP54, das von PyCom hat IP67, das Spelsberg IP66!
Habe gerade bei Spelsberg angerufen:
Das von dir @caro vorgeschalgene Gehäuse TK PS 1309-6-tm ist aus Polystyrol (PS), daher das “PS” und damit sei es nicht witterungsbeständig. Das gibt es aber auch in Polycarbonat (PC) als TK PC 1309-6-tm.
Mit Vorprägungen für M12er Kabelverschraubungen haben sich nicht wirklich etwas brauchbares, sondern nur mit den M16er, wie gesagt können wir dann nicht die Abschnitte der DS18B20 als Kabel von der Box in den Stock (oder andere “normale” Steuerleitungen) verwenden, sondern müssen dickere (geschirmt?) nehmen.
Ab 50 Gehäusen fräsen sie auch Löcher (z.B. für M12) nach unseren Vorgaben, kostet dann allerdings ca. 85 ct (war glaube ich brutto) pro Bohrung.
…sagt der Mann, der IKEA-Becher-Gehäuse propagiert :)
Es wäre super ärgerlich, wenn uns die Hardware kaputt geht, weil zu viel Wasser eindringt, schon richtig. Es wäre aber auch super ärgerlich, wenn reihenweise Sensoren kaputt gehen, weil sie verpolt ansgeschlossen werden - weil der Stecker nicht durch die Durchführung passt und rohe Kabel irgendwo angeklemmt werden müssen.
Was ist wahrscheinlicher, dass die Box zeitweilig untertaucht, oder dass sich ein Imker vertut beim Verkabeln? Ich weiß es nicht.
Schick mir doch bitte das Angebot von Spelsberg rüber für die Cases aus PC mit 4 M12 Löchern, dann kann ich das gegen die Variante mit geschirmten Kabeln und M16 rechnen.
1 Like
Vor einem Jahr habe ich bei Langzeitmessungen Messwert-Ausreisser des HX711 beobachtet, wie @tox auch. Meine Beobachtungen sind in diesem Papier:
RaspiD-Waage-HX711.pdf (338,3 KB)
Bei einer Wägezelle sind sehr kleine analoge Signale ( wenige mV ) auf der Leitung, die abgeschirmt wird. Bei der analogen Messtechnik soll die Abschirmung an die zentrale Masseleitung in der Nähe des empfindlichsten Einganges gelegt werden. Bei einer Musik-Anlage sind das die Mikrofon-Eingänge. Alle anderen Masseleitungen sollen sternförmig daran angeschlossen werden, um sogenannte “Brummschleifen” zu vermeiden.
Wenn man den Schaltplan des HX711-Breakout-Boards betrachtet, erkennt man 2 unterschiedliche Massen: die analoge Masse AGND und die digitale Masse DGND, die im HX711-IC verschwinden. Je nach Hersteller des Boards sind sie verbunden oder aber nicht. Bei unseren grossen grünen Boards ist die Verbindung offen.
Auf meinem Raspi-Testboard konnte ich im laufenden Betrieb AGND und DGND mit einem Jumper verbinden oder öffnen. Leider habe ich keine eindeutigen Ergebnisse erzielt. Zwar änderte sich der Offset deutlich, aber die Messwert-Ausreisser änderten sich kaum. Grösser war der Effekt, ob ich in meinem Zimmer ( Temperaturschwankunken und Erschütterungen der Holzdecke ) oder auf dem Kellerfußboden ( konstant 15 °C und Beton ) gemessen habe.
Bei den Aussreissern hatte ich den Eindruck, dass immer nur ein oder wenige Bit fehlen, die aus irgend einem Grund verschluckt werden, genauso wie bei der ersten Tara-Messung nach dem Einschalten. Deshalb rufe ich Tara mehrfach auf und verwerfe die erste Messung.
Aus diesen Gründen schliesse ich den Schirm der Wägezelle an den Eingang E- an, der ja auch die analoge Masse AGND ist.
1 Like
Interessant, Sparkfun macht das bei seinem HX711-Board übrigens auch so, wie ich gerade sehe:
Zumindest die Häufigkeit und zeitliche Exposition der Gefahrenquelle “Imker” ist wesentlich überschaubarer als die des Wetters (edit: und der Gravitation, Korosion von Schrauben, des Morsch-werdens von Holz). SCNR!
Hallo Didi,
Vielen Dank für Deine Beobachtungen beim Auslesen des HX711 mit einem RaspberryPi.
Das ist absolut plausibel, über den wahrscheinlichsten Grund haben wir im Beitrag Use realtime systems for reading digital sensors ein paar Zeilen geschrieben:
Auch dieser Artikel passt zum Thema:
Man sollte also wirklich nicht mit non-realtime Systemen an das Auslesen der Sensoren herangehen, ungeachtet der Tatsache, dass man entsprechenden Code dazu im Netz findet, der versucht, die Sache zu kompensieren à la
Raspberry Pi sometimes reads invalid data because the pin
pd_sckis high for 60 micro seconds or longer. To eliminate this problem, a simple filter solves this problem. Therefore it provides better and more precise readings.– GitHub - gandalf15/HX711: Read HX711 ADC for Weigh Scales on Rasperry PIs.
– HX711/HX711_Python3/hx711.py at 6a160dc223196fd3e0e1afe33783c84be6dda37c · gandalf15/HX711 · GitHub
Das bedeutet zwar nicht unbedingt, dass man den RaspberryPi gleich abschreiben muss, aber mit einem regulären Linux Kernel wird man Messungen, in denen immer nur ein oder wenige Bit fehlen wohl niemals ganz ausschließen können.
Es könnten zwar Verbesserungen erreicht werden, indem man den Prozess mit einer höheren Priorität versieht oder eine in C/C++ geschriebene Variante verwendet, die u.a. das gleiche tut (z.B. HX711/HX711_C at master · gandalf15/HX711 · GitHub), das Problem, dass Prozess jederzeit vom Linux Kernel unterbrochen werden kann, während er gerade mit der Hardware kommuniziert, bleibt jedoch bestehen.
Es gibt jedoch auch Realtime Erweiterungen für den Linux Kernel. Wenn wir also das Auslesen des HX711 in diese Realtime Domäne verlagern könnten, wäre ein RaspberryPi- oder Beagblone-basierter Datenlogger, der auch ohne Workarounds solide Werte liefert, durchaus machbar.
Beim Beaglebone könnte man auch noch die PRU Mikrocontroller verwenden, die genau für solche Dinge vorgesehen sind und ebenfalls Realtime Fähigkeiten anbieten. Der dort verbaute Sitara-Chip enthält zwei 32-Bit-Mikrocontroller, die sogenannten programmierbaren Echtzeit-Einheiten oder PRUs. Wie man das examplarisch tut, wird unter [1,2,3] beschrieben.
Viele Grüße,
Andreas.
[1] PRU tips: Understanding the BeagleBone's built-in microcontrollers
[2] How to run C programs on the BeagleBone's PRU microcontrollers
[3] http://catch22.eu/beaglebone/beaglebone-pru-c/