Posts by hadi

Quote

... desweiteren habe ich den Bodenfeuchtesensor mit dem Digitalen Ausgang programmiert. Dies funktioniert auch, jedoch weiß ich noch nicht wie ich den Analogen Ausgang verwenden kann. Benötige ich dafür vielleicht einen AD-Wandler?

Falls du noch auf der Suche bzgl. Auswertung des analogen Ausgangs deiner Bodenfeuchtigkeitssensoren bist: hier, in meinem Beitrag zum Thema Gartenbewässerung(!) habe ich beschrieben, wie ich das mit einem AD-Wandler MCP3008 realisiert habe. BTW, mein Trick, die Sensoren immer nur während der Messung mit Spannung zu versorgen, hat sich echt bewährt. Auch jetzt nach Monaten messen die China-Billigsensoren immer noch zuverlässig und mit dem Auge kann ich keine auffälligen Korrosionsspuren entdecken.

Hallo mangab,

bitte entschuldige meine späte Antwort. War die letzten Monate kaum mehr im Forum unterwegs. Aber zu deiner Frage: Nein, das mit der Wildschweinkamera war ja eher als Joke gemeint und für die Übertragung größerer Datenmengen ist das oben diskutierte LoRa auch nicht ausgelegt. Ich hoffe du wirst oder bist schon anderswo fündig geworden.

Grüße, hadi

Hi Subsonic,

Ich habe mal ein paar Bezeichnungen eingefügt damit wir uns leichter verständigen können.

Wenn ich die Schaltung richtig verstehe, läuft der Motor wenn entweder T1 UND T4 oder T2 UND T3 durchgeschaltet sind. Einmal läuft er links herum, einmal rechts herum. Oder umgekehrt, ist ja erst mal egal.

Ich kann mir vorstellen dass GPIO a und GPIO b, wenn sie auf High-Level sind, den T4 (GPIO a) bzw. T3 (GPIO b) durchschalten können. Aber die Spannung reicht niemals um T1 oder T2 zu schalten! Da die Spannung am Gate höher sein muss als an Source, muss nach meinem Verständnis an Punkt A eine Spannung von nahezu 9V anliegen damit T1 in den leitenden Zustand kommt. (Dito für Punkt B und T2). Denn stellen wir uns mal vor, T1 und T4 seien in offenem Zustand, so dass der Motor läuft. Dann sollte sich an Punkt C (Source von T1) eine Spannung von 9V minus Spannungsabfall an der Drain-Source-Strecke von T1 einstellen. Das sind vielleicht 7 bis 7,5V. Da muss die Gate-Spannung noch einmal mindestens 1V drüber liegen damit T1 im leitenden Zustand bleibt! Das ist mit den 3,3V der GPIOs nicht zu machen. Ich würde versuchen, das mit einer Vorstufe zu lösen, die mit einem weiteren Mosfet und zwei Widerständen einen Spannungsteiler schafft, der mit dem Gate von T1 verbunden ist. Dito fürT2.

Grüße, hadi

Hallo raspygert,

verstehe ich richtig dass du zwei Skripte/Programme parallel laufen hast - das bereits bestehende, in 2.7 geschriebene und das neue, in 3.x noch zu entwickelnde? Und du möchtest Daten vom einen an das andere übergeben?

Da gäbe es verschiedene Möglichkeiten: Wenn die Daten in größeren Zeitabständen anfallen und gesammelt übergeben werden, könntest du sie in eine Datei-Schnittstelle (z.B. CSV oder JSON) schreiben. Falls die Daten laufend übertragen werden müssen (z.B. Realtime-Messung), könntest du IPC (Interprocess Communication) ins Auge fassen.

Grüße, hadi

Quote from Balkanbeat

ich habe mir einen Versuchssand aufgebaut mit nem

https://shop.baumarkt-goellnitz.de/index.php?cl=d…ASABEgLAIPD_BwE

Hauswerk habe aber auf das Manometer nicht geachtet sobald der Druck abfällt schaltet sich die Pumpe hinzu!

Meinst du die Druckschwankungen verursachen die Messfehler?

Hhm, ich kenne das Gerät nicht. Aber das sieht schon nach 'ner massiven Pumpe aus die womöglich nicht sehr zimperlich mit deinem Sensor umgeht . Also ich kann mir gut vorstellen dass die einen schwankenden Wasserdruck produziert. Wenn der Druckbehälter leer wird, sinkt der Druck bis irgendwann die Pumpe anspringt. Die füllt den Behälter, der Druck steigt dabei bis die Pumpe bei einem Grenzwert abschaltet und das Spiel beginnt vor vorn. Aber das ist Spekulation. Nur: wenn es zutrifft, kannst du den Sensor eigentlich nicht vernünftig kalibrieren.

Und wahrscheinlich willst du die Kombi aus Pumpe und Sensor dann auch in deinem Projekt so verwenden - oder? Also messen wie viel Wasser gefördert wurde?

Hi,

wenn du es tatsächlich schaffst, den Druck über den ganzen Messvorgang konstant zu halten, dann sollte die Anzahl Impulse linear zur durchgeflossenen Wassermenge sein. (Abgesehen mal von den 10% Messungenauigkeit die das Datenblatt erwähnt). Doppelt so viel Wasser benötigt dann doppelt so lange. Halb so viel Wasser halb so lange. D.h. die Fließgeschwindigkeit ist in allen Fällen gleich. Und damit auch die Wirbelbildung oder was auch immer die Nichtlinearität bei Druckänderung verursacht. Dieser Störfaktor fällt dann weg, weil konstant.

Aber wie bekommst du das mit konstant 3 Bar hin? Anschluss an Wasserleitung?

Gruß, Dieter

Hi,

finde ich toll dass du experimentiert hast. Das wollte ich oben sogar vorschlagen, fand es dann aber doch zu aufdringlich und hab's gelassen.

Quote from Balkanbeat

... Ich verstehe auch hier nicht warum? Es ist ein Rad drin welches beim vorbeikommen einen Impuls erzeugt!

Da die obere Grafik aus Post #13 vom Hersteller stammt, gehe ich davon aus dass es kein Messfehler ist. Ich bin zwar kein Physiker und kenne mich nicht besonders mit Strömungsmechanik aus, aber ich vermute, dass an dem Rädchen Wirbel entstehen, die bei höherer Drehzahl (=höherem Wasserdruck) zunehmend bremsen. D.h.das Rädchen dreht sich nicht mehr so schnell wie es der vorbeiströmenden Wassermenge entsprechen würde. Daher der Korrekturfaktor der mit steigender Drehzahl (F) ebenfalls zunimmt.

Den Faktor habe ich übrigens per mathematischem "Bauchgefühl" ermittelt. Ein paar Versuche in einer Excel-Tabelle. War selbst überrascht wie schnell es gepasst hat.

Quote from RichardEb

Die genannte Formel scheint zu funktionieren. Ich habe jetzt mehrmals den Wasserstrom mit einem Eimer gemessen und das Ergebnis entspricht in etwa F=8.1×Q - 3 So auf +/- 15Liter/h genau in meinem Fall

Also (Pulse+3)/8,1 Bsp: (22+3)/8,1

Schau dir mal noch diesen Post an. Diese Billig-Durchflussmesser arbeiten nicht linear. Zumindest lese ich das aus dem Datenblatt dieses Modells. Das könnte auch auf dein Teil zutreffen wenn es von der Bauart vergleichbar ist. Dann würde die aus deinen Versuchen abgeleitete Formel nur für genau den Wasserdruck stimmen, so wie er sich aus deinem Versuchsaufbau ergab. (Höhe der Wassersäule über dem Sensor).

Das Verhältnis 1l Wasser=477 Impulse würde dann nur bei einem bestimmten Wasserdruck gelten. Bei höherem Druck würden 477 Impulse weniger, bei niedrigerem Druck mehr als 1l entsprechen.

Quote from daxb

Leider ist dein Satz bzgl. Stromverbrauch im Standby und Leerlauf in dieser Form nichtssagend. Du muss schon schreiben, was/wo/wie du gemessen hast. Ohne die Spannung sind A oder mA Angaben auch wenig hilfreich. P=U*I

Im Ernst jetzt? 5V - was hast du denn gedacht?

Schau mal hier. Einfach googeln, z.B mit "raspberry über gpio starten"

Aber Vorsicht, falls du mit Akku oder Batterie arbeitest: Herunterfahren bedeutet nicht, dass der Pi dann keinen Strom mehr verbraucht! An einem Zero W habe ich gemessen, dass er im Standby immerhin noch ca. 40 mA verbrät, verglichen zu 120 mA im Leerlauf nach dem Booten.

Hi,

ich habe mir mal die Grafik des Herstellers angeschaut. Hier wird der Zusammenhang zwischen Frequenz und der Durchflussmenge pro Minute (Quantity) abgebildet:

Man sieht dass die Menge nicht linear mit der Frequenz (also der Drehzahl des Flügelrads oder was auch immer da drin verbaut ist) ansteigt. Doppelte Frequenz bedeutet nicht doppelte Quantität, sondern weniger.

Ich habe versucht, das mit meiner Formel aus Post #2 nachzubilden. Ergebnis ist die gelbe Kurve. Die rote Kurve entspricht den Angaben des Herstellers, die ich aus seiner Grafik entnommen habe:

Man sieht, dass meine Formel bei steigender Drehzahl die Durchflussmenge überschätzt. D.h. es muss ein Korrekturglied in die Formel.

Meine Formel (für die gelbe Kurve) ist:

Q = 1/383 * F * 60 

(statt der Impulsdauer wie in #2 habe ich deren Kehrwert, die Frequenz genommen, was die Formel einfacher aussehen lässt)

Mit dem folgenden Korrekturglied

Q = 1/383 * (F - F/2,5 + 5)*60

ergibt sich die grüne Kurve, die mit der "Realität" schon deutlich besser übereinstimmt.

Viele Grüße

Dieter

PS: Mir ist schon klar, dass das nicht das Datenblatt war das genau zu deinem Modell passt. Aber ich denke das Problem mit der Nichtlinearität und seiner Korrektur sind durchaus übertragbar, sofern die Konstruktion der beiden Modelle ähnlich ist.

Hallo,

möchtest du die Durchflussgeschwindigkeit (also Liter pro Minute) oder die durchgeflossene Menge (in Liter) messen? Das ist mir nicht klar.

Wenn es dir nur um die Menge (Liter) geht, brauchst du ja nur die Impulse zu zählen:

liter = anzahl_impulse / 383

Beispiel: Du hast 1000 Impulse gezählt, ergibt 1000/383 = 2,61l

Willst du aber die Durchflussgeschwindigkeit, musst du die Zeit zwischen zwei Impulsen messen

liter_pro_sekunde = 1 / (383 * impuls_abstand_in_sekunden)

Beispiel 1: Zeit zwischen zwei Impulsen = 10msek = 0,01sek => 1 / (383 * 0,01) = 0,26 l/sek = 15,7 l/min

Beispiel 2: Zeit zwischen zwei Impulsen = 157msek = 0,157sek => 1 / (383 * 0,157) = 0,0166 l/sek = 1l/min

Um Messungenauigkeiten zu vermeiden, würde ich entweder mehrere solcher Messungen mitteln oder gleich die Dauer von z.B. 10 Impulsen messen.

Gruß hadi

PS: Die Formel aus dem Datenblatt ist meines Erachtens Unsinn. Da kommen ja nicht mal die Einheiten hin.

Zottel: Nein, ich meine die Codierung in C. Du hattest ja den Thread eröffnet mit

Quote

Ich habe an die Gpio Pins je eine LED (LED Nummernanzeige) geschalten. und ein Programm dazu gefunden um die LED's einzeln anzusteuern. Sprich ein Lauflicht.

Ich möchte aber auch Zahlen bis 99 anzeigen lassen. dazu müsste ich jedoch mehrere Gpio Pins gleichzeitig ansteuern, was ich nicht so richtig hinbekomme.

Weiter oben hast du noch geschrieben, du könntest jetzt immerhin mehrere LEDs gleichzeitig aufleuchten lassen. Bist du denn jetzt in der Lage, Ziffern anzeigen zu können?

Quote from Zottel386

Muss ich dazu noch was schreiben? Erledigt und Danke.

Na ja, ich hätte es schon interessant gefunden, wenn du dein Ergebnis mit uns teilen würdest.

Hallo noisefloor,

ich will keine Battle vom Zaun brechen, aber so ganz ohne Widerspruch kann ich's nicht stehen lassen. Damit ich nicht gleich am Anfang die Lust verliere, mich in dieses Forum einzubringen, muss ich für meinen Seelenfrieden (und andere die das vielleicht verfolgen) klarstellen, dass ich mir bei meinem Vorschlag durchaus etwas gedacht habe und dass dieser seine Berechtigung hat.

Es ging mir nicht darum, Zottel ein fertiges Programm zu liefern das er nur noch auf seinem Pi laufen lassen muss. Etwas Eigeninitiative wird hier ja zu recht immer gefordert. Vielmehr ging es um eine Idee, wie er komfortabel die richtigen LEDs ansprechen kann ohne in ein If-Else-Dickicht oder andere Abwege zu geraten. Dazu habe ich einen Vorschlag gemacht, wohl wissend dass das nur eine von vielen anderen Lösungsalternativen ist. Aber genau darin sehe ich den Sinn eines solchen Forums: dass man die Ideen diskutiert. Und ob eine Idee in C oder in Python ausgedrückt wird, ist für mich dabei zweitrangig und keinesfalls abwegig.

Viele Grüße

Dieter

Quote from noisefloor

Weil du dich dann nicht implizit darauf verlassen musst, dass die Reihenfolge in deiner Liste / deinem Tupel der Reihenfolge der Zahlen entspricht. Du legst für jede Zahl einen Schlüssel an, der Wert ist, welche Pins dafür auf `high` gesetzt werden müssen.

Klar könnte man die Ziffern in beliebiger Reihenfolge definieren, aber das scheint mir im konkreten Fall ziemlich absurd. Im Sinne von Code-Verständlichkeit finde ich es hier eigentlich zwingend, die Ziffern in der Reihenfolge 0 bis 9 zu definieren. Und so hat der Index seine Berechtigung und ist obendrein performanter als eine Suche über den Schlüssel.

Quote

Am besten gar nicht. Entweder schreibst du idomatisches Python oder idomatisches C. Etwas 1:1 von Programmiersprache A nach Programmiersprache B übertragen zu wollen ist in der Regel irgendwas zwischen schlechte Idee und kapitaler Fehler.

So wie ich versuchen kann, eine Idee auf Englisch oder Deutsch zu erklären, geht das auch mit Python und C. Ich muss mich dabei halt bemühen, Sprachelemente zu verwenden, für die es in der anderen Sprache eine Entsprechung gibt. Und da ist die Liste/ das Tupel dem Array näher als das Dictionary und die Iteration mit Index näher als ein enumerate. Wenn meine Aussprache des "Pythonischen" einen leichten C-Akzent hat, mag das hier sogar von Vorteil sein

Quote

Steht doch im vorherigen Post von mir: das ist ein Anti-Pattern in Python.

Ok, wenn du geschrieben hättest: "Es gibt da ein paar Leute im Internet, die haben sich viel Mühe gegeben, einen guten Programmierstil für Python zu beschreiben. Die empfehlen an dieser Stelle ein enumerate zu verwenden. Und das Tolle dabei: das enumerate liefert dir sogar den Index den du im nächsten Statement zum Ansteuern der GPIO-Pins benötigst". Ich glaube, wenn du so geschrieben hättest, dann hätte ich mich ganz schnell mit dem enumerate angefreundet. (Was dann wiederum Zottel vor ein Problem gestellt hätte falls er nicht auf C++ und eine Klassenbibliothek umsteigen will...)

Quote

Ja, natürlich. Weil: dann hast du den Fehler auch ausgebaut...

Es ging um die Idee und nicht um ein gebrauchsfertiges Programm.

Quote

Der eigentliche Punkt: jemand hat eine Frage zu C und sagt, er muss / will C benutzen - da brauchst du nicht mit Python anfangen und dann auch noch suboptimalen Python-Code in den Thread werfen. Das ist in keinster Weise hilfreich noch zielführend.

Wie gesagt, das sehe ich anders.

Vielleicht können wir es bei dieser Gegenrede dann auch belassen, was meinst du? We agree that we disagree und begegnen uns bei anderer Gelegenheit gerne wieder?

Hallo Leute,

ich denke ich schließe den Thread jetzt ab und bedanke mich noch einmal für eure Beiträge! Insbesondere die Diskussion zu LoRa hat mir eine neue Richtung aufgezeigt in die ich sicher weiter forschen werde. Und Zentris keine Sorge, ich werde die lokale LoRa-Infrastruktur schon nicht zum Erliegen bringen

Zum Schluss noch eine Grafik welche die Wirksamkeit der Bewässerung zeigt:

Je höher der angezeigte Wert, desto trockener ist der Boden. Die blaue Linie zeigt die Messwerte von Sensor 1 im bewässerten Boden.

Sensor 2 (rote Linie) liegt außerhalb dieses Bereichs, buchstäblich im Trockenen. So lange kein Regen fällt geht der nur nach oben.

Dank & Gruß an alle Teilnehmer

Quote from kle

"Python Anti-Pattern" sind Sachen die man in Python nicht machen sollte. Gib das in die Suchmaschine deines Vertrauens ein.

Danke für den Hinweis. Bin ziemlich schnell bei The Little Book of Python Anti-Patterns gelandet. Interessanter Stoff.

Quote from doing

Das Elektronik-Kompendium spricht aber auch von maximal 59 Byte Nutzerdaten pro LoRa Paket.

Dann wären bei optimalen Bedingungen 800 Pakete/s drin. Da ist halt die Frage, ob die darüber liegenden Schichten ein Protokoll wie Telnet oder SSH ermöglichen. Rein von der Datenrate her sollte es nicht unmöglich sein. Eine zeichenbasierte Terminalsitzung ist ja nicht sehr anspruchsvoll. Aber ich bin da wissensmäßig noch blank. Habe hier im Forum leider noch nichts entdeckt wo ich mich dran hängen könnte.

Hhm, warum so unfreundlich im Ton, noisefloor? Sonst könnte man ja ins Gespräch kommen.

Dann würde ich sagen, bei mir läuft der Code. Wenn ich das GPIO.output durch ein print ersetze, kommt für die Darstellung der 0 folgendes Ergebnis:

(1, 1)
(2, 1)
(3, 1)
(4, 1)
(5, 1)
(6, 1)
(7, 0)

D.h. die Pins 1 bis 6 würden auf High gesetzt werden.

Außerdem würde ich sagen, dass für einen Anfänger wie Zottel der Begriff Liste verständlicher ist als Tupel und ich würde dich fragen, weshalb du meinst dass ein Dictionary hier besser geeignet ist (und wie Zottel das nach C übersetzen soll) und was an der Iteration mit range schlecht ist, wenn alle Listen, verzeih: Tupel, aus Prinzip die selbe Länge haben. Und zum Schluss würde ich fragen, ob PEP8 ein Gesetz oder lediglich eine Empfehlung ist, von der man auch abweichen darf, solange der Code verständlich und lesbar bleibt.

Aber ich weiß nicht, ob wir so ins Gespräch kommen würden.

Lieber Gruß

Dieter

Quote from doing

Das mit dem Updaten eines Raspberry Pi über LoRa kannst du dir gleich aus dem Kopf schlagen, dazu ist LoRa nicht entwickelt worden. Bei LoRa geht es darum Daten über eine möglicht große Entfernung zu senden und das bei möglichst geringem Stromverbrauch.

Siehe Long Range Wide Area Network (LoRaWAN)

Ooops, das klingt aber sehr pessimistisch. Das Elektronik-Kompendium spricht immerhin von 0,3 bis 50 KB/s. Selbst wenn ich da im unteren Drittel wäre, sollte es möglich sein, ein geändertes Python-Modul zu übertragen. Ich will ja kein ganzes Image oder so aufspielen. Selbst eine Remote-Terminalsession könnte drin sein. Mal sehen was die Praxis bringt...