Hallo Forum, ich soll bei jedem Bewässerungszyklus von Nutzpflanzen, das kumulative Wasservolumen (in Liter) messen. Zu diesem Zweck erscheint aufgrund diverser Projektfaktoren die einzige praktikable Lösung solch ein Flügelradzähler: https://www.ddm-sensors.de/wp-content/uploads/2023/04/data-sheet-datenblatt-pelton-wheel-flowmeter-fluegelradzaehler-15-l-min-800-serie.pdf Die Durchflussrate (in Liter/Minute) wird in Pulsausgänge artikuliert, wahrscheinlich konstanter Periode aber variierender Frequenz. Und genau diese möchte ich nun mit einem STM32-Board erfassen, anhand der Qudraratur-Enkoder-Funktion. Ich verstehe noch nicht, ob man dazu weitere Elektronik benötigt, abgesehen von der Versorgungsspannung. Das Schaltbild auf der zweiten Seite unten rechts zeigt mehrere Widerstände, Transistoren, Spannungsregler et.c....meint ihr die brauche ich? Besten Dank
:
Bearbeitet durch User
Lysandros schrieb: > Das Schaltbild auf der zweiten Seite unten rechts zeigt mehrere > Widerstände, Transistoren, Spannungsregler et.c.... Diese Bauteile sind im Sensor eingebaut. > Und genau diese möchte ich nun mit einem STM32-Board erfassen, anhand > der Qudraratur-Enkoder-Funktion. Der Sensor hat keinen Quadratur-Ausgang. Du kannst also die Flussrichtung nicht bestimmen und brauchst lediglich einen Zähler für die Pulse. > Ich verstehe noch nicht, ob man dazu weitere Elektronik benötigt Kein Problem, kann man lernen. Eigentlich wäre es einfach, denn der Ausgang ist ein OpenCollector. Blöd ist aber, dass der einen Pullup nach Vcc hat und Vcc im Bereich von "4.5 to 24Vdc" sein muss. Das passt nicht zum STM mit seinen 3,3V. Also brauchst du im einfachsten Fall so eine Schaltung:
1 | 3V3 |
2 | | |
3 | 10k |
4 | | |
5 | O/P ---|<---o----- IN |
6 | |
7 | Sensor STM32 |
8 | |
9 | GND -------------- GND |
Oder sowas:
1 | 3V3 |
2 | | |
3 | - |
4 | ^ |
5 | | |
6 | O/P ---1k---o----- IN |
7 | |
8 | Sensor STM32 |
9 | |
10 | GND -------------- GND |
Ein Tipp: überleg dir einfach mal, wie diese beiden Schaltungen im Zusammenspiel von Sensor und STM32 funktionieren. Ich selbst verwende auf jeden Fall keine Schaltung, wenn ich sie nicht grundlegend verstanden habe. Denn sonst kann ich ja auch keinen Fehler suchen.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Eigentlich wäre es einfach, denn der Ausgang ist ein OpenCollector. Blöd > ist aber, dass der einen Pullup nach Vcc hat und Vcc im Bereich von "4.5 > to 24Vdc" sein muss. Das passt nicht zum STM mit seinen 3,3V. Hhhmmm, das sind 2 Pullups im Datenblatt, einer rechts unten im DB und einer in der Mitte, der scheint evtl. extern zu sein.
Stephan S. schrieb: > das sind 2 Pullups im Datenblatt Unschön. Da müsste man für die zweite Schaltung messen, ob der im Sensor intern tatsächlich verbaut ist. Wenn der nicht drin ist, dann wird die Ankopplung ganz einfach:
1 | 3V3 |
2 | | |
3 | 10k |
4 | | |
5 | O/P --------o----- IN |
6 | Sensor STM32 |
7 | GND -------------- GND |
Aber egal wie der Ausgang des Sensors aussieht, ob OC mit oder ohne Pullup oder gar als PushPull: die erste Schaltung funktioniert immer.
:
Bearbeitet durch Moderator
Frank E. schrieb: > Oder einen Optokoppler dazwischen - saubere Trennung. Nur, wenn dann die Versorgung des Sensors auch tatsächlich getrennt ist. Aber hier ist eh' keine "noch viel sauberere Trennung" nötig, weil der Sensor selber schon "sauber" und galvanisch von der Umwelt getrennt ist. Also wäre ein OK letztlich nur technischer Overkill.
:
Bearbeitet durch Moderator
Lysandros schrieb: > Die Durchflussrate (in Liter/Minute) wird in Pulsausgänge artikuliert, > wahrscheinlich konstanter Periode aber variierender Frequenz. Ähhm. Nein. Da drin ist ein Flügelrad (daher der Name) das vom Flüssigkeitsstrom angetrieben wird. Wie ein Wasserrad an einem Bach oder unter dem Strahl aus dem Wasserhahn. Pro durchgeflossenem Volumen (z.B. 10ml) gibt es einen Impuls. Wenn also 100 Impulse gezählt wurde, ist 1 Liter durchgeflossen. Dummerweise gibt der Hersteller nicht das Volumen pro Impuls an, sondern einen dämlichen "k-Faktor". Man soll also seinen Zähler mit dazukaufen (an dem man dann den k-Faktor einstellt). Tolle Wurst! Das Puls-/Pausenverhältnis ist nicht spezifiziert. Aber ich würde bei konstantem Durchfluß von ca. 1:1 ausgehen. Wenn der Durchfluß stoppt, hören die Impulse auf. Dabei kann sowohl ein Dauer-L als auch ein Dauer-H auftreten. Je nachdem wie das Flügelrad stehen bleibt. > Und genau > diese möchte ich nun mit einem STM32-Board erfassen, anhand der > Qudraratur-Enkoder-Funktion. Nur daß der Sensor kein Quadratursignal ausgibt. Sondern eben Impulse. Das allerdings recht langsam. Die kann man problemlos in einem Pinchange-Interrupt mitzählen. Oder im Timerinterrupt mit z.B. 1ms pollen. Oder halt an einen der Timer/Counter verfüttern. Was man halt hat. STM32 ist ein weites Feld. > Schaltbild auf der zweiten Seite unten rechts zeigt mehrere Widerstände, > Transistoren, Spannungsregler et.c....meint ihr die brauche ich? Das steht doch dran. Auf der rechten Seite ist schematisch die Innenschaltung des Sensors angegeben. Der Ausgang ist ein npn-Transistor mit Pullup von 10K nach Vcc des Sensors. Warum der Hersteller dann nochmal einen externen Pullup empfiehlt, müßtest du ihn fragen. Elektrisch ist der unnötig. Wenn du den Sensor mit 5V versorgst, könntest du den Ausgang direkt mit einem 5V-toleranten Eingang des STM verbinden. Evtl. noch mit einen Serienwiderstand (Angstwiderstand) dazwischen.
Hatte mal ein ähnliches Problem, wo ein Flügelradzähler an einen Quadraturzähler (hier fixes Panelinstrument) angeschlossen werden musste. Ein RC Glied von Kanal A zu B hat dann eine kleine Verzögerung gemacht, die eine Drehung simulierte und alles funktionierte prima. Edit: 2x Tau (=R*C) war etwas größer als die max. Pulsrate des Instruments WIMRE
:
Bearbeitet durch User
Henrik V. schrieb: > Hatte mal ein ähnliches Problem, wo ein Flügelradzähler an einen > Quadraturzähler (hier fixes Panelinstrument) angeschlossen werden > musste. Beim STM32 (oder µC allgemein) kann man idR. den Pin ohne Quadratur direkt einem Zähler zuordnen. Schlimmstenfalls muss der "Richtige" der beiden Quadratureingägne ausgewählt werden. Insofern ist die Forderung "einen Quadraturzählereingang verwenden" unsinnig/unnötig.
Hier gibt es z.B. diverse Zähler mit Ausgang 0,25l/Impuls oder 1l/Impuls: https://www.energie-zaehler.com/epages/61422236.sf/de_DE/?ViewAction=View&ObjectID=157721947&PageSize=30&OrderBy=ListPrice&OrderDesc=0&FocusReference=ep-SortOrder
Axel S. schrieb: > Dummerweise gibt der Hersteller nicht das Volumen pro Impuls an, sondern > einen dämlichen "k-Faktor Das pro-Impuls-Volumen lässt sich sehr einfach mit einem Testaufbau bestimmen: Trichter, Eimer, provisorische Befestigung am Eimer, Messbecher, ggf. Schlauch, Spannungsversorgung, Pullup-Widerstand, Impulszähler oder Digitaloszilloskop. Dann einfach mal z.B. 10L durchschicken und die Impulse zählen (lassen). Hernach 10000cm³ durch die Anzahl der Pulse teilen und fertig? mfg mf
:
Bearbeitet durch User
Axel S. schrieb: > Dummerweise gibt der Hersteller nicht das Volumen pro Impuls an, sondern > einen dämlichen "k-Faktor". Man soll also seinen Zähler mit dazukaufen Das ist DEINE Interpretation. Man kann auch einfach das Wasser in ein Gefäß laufen lassen, das Gefäß vorher und nachher wiegen und dann selber das Wasservolumen ins Verhältnis zu der Zahl der Pulse setzen. Da braucht man gar nichts zu kaufen und muss nur sein Hirn bemühen.
Ein besonderes Problem der 'Flügelradzähler' ist noch, daß die bei sehr geringem Durchfluß oft recht ungenau werden. Zwischen dem Flügelrad und der Wandung liegt naturgemäß ein Spalt, durch den das Wasser bei geringem Durchfluß 'sickert' ohne das Rad adäquat mitzunehmen. Eine Art 'Schlupf' sozusagen. Da es bei Bewässerung schätzungsweise um geringe, aber kontinuierliche Mengen geht kann sich das rasch zu erheblichen Fehlern summieren. Der TO sollte sich die Daten daher diesbezüglich genau anschauen.
Moin, aus Interesse an der Fragestellung habe ich mir einmal ein beliebiges Datenblatt eines deutschen Herstellers herausgegriffen, um einen Eindruck von der möglichen Genauigkeit zu bekommen, vielleicht kann mir das ja später auch selbst noch nützlich sein. http://www.interin.de/produkte_de/pdf/fl_de_fluegelrad-durchflussmesser.pdf Vergleicht man das mit Anemometer-Typ-Flügelrädern, dürfte auch hier eine gewisse Anfangsnichtlinearität vorhanden sein, die allerdings wohl nur bei sehr geringer Wasserströmung ins Gewicht fällt. Mein Ansatz wäre daher, mir einen Flügelradsensor mit einem möglichst ausführlichen und guten Datenblatt zu besorgen – und dann damit praktisch zu arbeiten. Duck und weg, Gerhard
Axel S. schrieb: > Dummerweise gibt der Hersteller nicht das Volumen pro > Impuls an, sondern einen dämlichen "k-Faktor". Wird wohl Pulse/Liter sein bei Flüssigkeiten (https://www.ddm-sensors.de/kalibrierservice-drucksensoren-durchflussmesser/durchflussmesser-kalibrieren/) > Man soll also seinen Zähler mit dazukaufen Nicht so viel phantasieren ... (an dem man dann den k-Faktor einstellt). Wie das? Weil Du den K-Faktor nicht kennst, musst du einen Zähler dazu kaufen, bei dem Du einen K-Faktor einstellen musst, den Du doch gar nicht kennst? Schräge Logik ...
Moin, Der von mir erwähnte FRZ war leider etwas teuer. Dieser hier dürfte besser ins Hobby Budget (€35) passen und hat gute Daten: https://www.ddm-sensors.de/wp-content/uploads/2023/04/data-sheet-datenblatt-pelton-wheel-flowmeter-fluegelradzaehler-10-l-min-beverage-meter.pdf https://www.ddm-sensors.de/wp-content/uploads/2025/02/manual-bedienungsanleitung-pelton-wheel-flowmeter-fluegelradzaehler-beverage-meter.pdf Natürlich tut es auch ein billigerer; nur hat dann mehr Arbeit bei der Kalibrierung. Gerhard
:
Bearbeitet durch User
Jens G. schrieb: > Wird wohl Pulse/Liter sein bei Flüssigkeiten Je nach Herstellerland könnten es auch Pulse/Gallone sein. Es ist eine Frechheit, in einem Datenblatt einen 'K'-Faktor für einen Durchflussmesser als dimensionslose Größe anzugeben.
:
Bearbeitet durch User
Lysandros schrieb: > wahrscheinlich konstanter Periode aber variierender Frequenz Die Periode ist der Kehrwert der Frequenz. Da gibt es nichts, was man davon unabhängig variieren könnte.
Frank E. schrieb: > Oder einen Optokoppler dazwischen - saubere Trennung. Warum nicht einfach einen Widerstand?
Rainer W. schrieb: > Es ist eine > Frechheit, in einem Datenblatt einen 'K'-Faktor für einen > Durchflussmesser als dimensionslose Größe anzugeben Wäre denn eine Angabe in Volumen/Puls auch bei unterschiedlichen Flüssigkeiten/Viskositäten/Temperaturen immer gleich?
Norbert schrieb: > Rainer W. schrieb: >> Es ist eine >> Frechheit, in einem Datenblatt einen 'K'-Faktor für einen >> Durchflussmesser als dimensionslose Größe anzugeben > > Wäre denn eine Angabe in Volumen/Puls auch bei unterschiedlichen > Flüssigkeiten/Viskositäten/Temperaturen immer gleich? Eine Angabe von Volumen/Pulse wäre genauso immer gleich, wie die Angabe des 'K'-Faktors.
Muss eh kalibriert werden. Controller ist schon da, kann man also direkt ein Kennfeld bei unterschiedlichen Durchflussmengen erstellen. Oder sich ein passendes Polynom bauen.
Achim M. schrieb: > Axel S. schrieb: >> Dummerweise gibt der Hersteller nicht das Volumen pro Impuls an, sondern >> einen dämlichen "k-Faktor > > Das pro-Impuls-Volumen lässt sich sehr einfach mit einem Testaufbau > bestimmen: Rainer W. schrieb: > Axel S. schrieb: >> Dummerweise gibt der Hersteller nicht das Volumen pro Impuls an, sondern >> einen dämlichen "k-Faktor". Man soll also seinen Zähler mit dazukaufen > > Das ist DEINE Interpretation. > > Man kann auch einfach das Wasser in ein Gefäß laufen lassen Herrgott! Natürlich kann man das auch bestimmen. Aber warum sollte man das überhaupt erst müssen? Der Hersteller weiß das doch. Also kann er das auch einfach ins Datenblatt schreiben. Aber nein, da wird herumgeheimnist in der Hoffnung, daß der Anwender den vermutlich horrend überteuerten Mengenzähler gleich mitkauft. Oder welchen anderen Grund sollte es haben, statt Impulse/Liter einen dimensionslosen "k-Faktor" anzugeben? Einen Widerstand kaufe ich doch auch nicht unter Angabe eines Blafasel-Quotienten mit einem bestimmten, aber eben nicht genannten Verhältnis zum Leitwert, das ich erst messen muß.
Achim M. schrieb: > Das pro-Impuls-Volumen lässt sich sehr einfach mit einem Testaufbau > bestimmen: Sicher. Aber vom Datenblatt eines Sensors erwarte ich, dass ich eben das nicht tun muss. Die können ja meinetwegen durchaus den K-Faktor angeben. Aber dann gehört, verdammt nochmal, auch die Formel, in der dieser Faktor vorkommt, mit in das Datenblatt.
Ob S. schrieb: > Achim M. schrieb: > >> Das pro-Impuls-Volumen lässt sich sehr einfach mit einem Testaufbau >> bestimmen: > > Sicher. Aber vom Datenblatt eines Sensors erwarte ich, dass ich eben das > nicht tun muss. > > Die können ja meinetwegen durchaus den K-Faktor angeben. Aber dann > gehört, verdammt nochmal, auch die Formel, in der dieser Faktor > vorkommt, mit in das Datenblatt. Da mich das Thema auch sehr interessiert, recherchierte ich ein bisschen und fand dieses (nützliche) Dokument: https://trigasfi.com/wp-content/uploads/2023/08/FI-UVC-Principles_D.pdf
Ein paar Gedanken dazu: Wenn ich die Eingangsfrage richtig verstanden habe, genügt es, die Impulse pro Messzyklus zu summieren und durch den angegebenen K-Wert zu teilen, um so, innerhalb der angegebenen Messtoleranz, das übertragene Volumen zu erhalten. Beispielsweise: Beim DDM 300-010 Sensor mit einem K-Wert von etwa 1420 ergäben 14200 Impulse in einem Bewässerungszyklus ein Gesamtvolumen von 10l +/- 2.5 %. Ist die prozentuale Abweichung reproduzierbar, ließe sich das möglicherweise noch besser kalibrieren. Der Hersteller weist allerdings auf einen "ungefähren" K-Wert hin. Falls also keine Reproduzierbarkeit gegeben ist, bleibt die Messung eben nur so genau wie die spezifizierte Messgenauigkeit des Sensors. Wie genau das Messvolumen in dieser Anwendung bekannt sein muss, kann ich nicht beurteilen. Bei 10 l entspräche die Ungenauigkeit +/- 250 ml, für den genannten Zweck scheint mir das eigentlich ausreichend. Der K-Faktor hat insofern seinen Sinn, als er durch den jeweiligen Durchflussmessbereich bzw. die Baugröße bestimmt ist: Je größer der Durchflussmessbereich, desto kleiner fällt der K-Faktor aus. Die Durchflussrate in Lpm wäre dann (f x 60) / K . Z.B.: 142Hz entsprächen dann einer Durchflussrate von ~6lpm. Die Frequenz per lpm Durchflussrate: f = lpm x K / 60; (6 x 1420) / 60 = 142Hz Es wird übrigens empfohlen vor der Turbine ein 80μ Filter zu installieren und auf keinen Fall vertikal zu installieren. Ob dies alles stimmt, kann ich Mangels praktischer eigener Erfahrung nicht bestätigen. Jedenfalls verstehe ich es aber so. Ich habe mir vor Jahren, ähnliche Durchflussmesser gekauft, mich aber noch nicht damit beschäftigt. Deshalb interessiert mich euer Thread.
:
Bearbeitet durch User
Axel S. schrieb: > Der Hersteller weiß das doch. Also kann er das auch einfach ins > Datenblatt schreiben. Tut er doch. Da aber jeder Zähler individuell kalibriert wird, kann er im Datenblatt nur einen ungefähren 'K'-Faktor angeben, d.h. einen groben, konstruktiv angestrebten Wert. Der genaue Wert wird durch Kalibrierung bestimmt und fällt von Zähler zu Zähler unterschiedlich aus. Um in den Spezifikationen zu bleiben muss diese wahrscheinlich regelmäßig überprüft werden muss. > Oder welchen anderen Grund sollte es haben, statt Impulse/Liter einen > dimensionslosen "k-Faktor" anzugeben? Die Frechheit ist, die Einheit für den Faktor nicht anzugeben. Üblicherweise gibt der 'K'-Faktor bei Durchflussmessern nach dem Flügelradprinzip die Impulse pro Volumen an. Ob S. schrieb: > Aber dann gehört, verdammt nochmal, auch die Formel, in der dieser > Faktor vorkommt, mit in das Datenblatt. Bei einer einfachen Proportionalität kann man auf die explizite Angabe einer Formel schon einmal verzichten. So viel Grundlagenwissen sollte beim Anwender schon vorhanden sein. Nur ist es bei einem Durchflussmesser mit einer einfachen Formel nicht getan, weil der 'K'-Faktor bei genauerer Betrachtung vom Durchfluss und von der Viskosität abhängt. Da hilft nur das Kennlinienfeld.
Jochen schrieb: > Ein besonderes Problem der 'Flügelradzähler' ist noch, > daß die bei sehr geringem Durchfluß oft recht ungenau werden. Daher gibt es den Sensor ja in 6 Bereichen. Der Typ 803 gibt z.B. bei 0,5l/min etwa 142Hz aus und geht runter bis 0,05l/min. Außerhalb des Bereiches steigt der Fehler. Ob der 10k Pullup schon intern ist, kann man ja leicht messen. Generell empfiehlt sich eine Entstörung per Mehrfachabtastung im Timerinterrupt.
Henrik V. schrieb: > Ein RC Glied von Kanal A zu B hat dann eine kleine Verzögerung gemacht, > die eine Drehung simulierte und alles funktionierte prima. Ist aber nur nötig, wenn die Firmware eine Blackbox ist und nicht konfiguriert werden kann.
Axel S. schrieb: > Oder welchen anderen Grund > sollte es haben, statt Impulse/Liter einen dimensionslosen "k-Faktor" > anzugeben? Vielleicht, weil Aufbereitungselektronik (Impulsgenerator) und Flügelrad zwei getrennte Dinge sind. Die Elektronik, die die Impulse erzeugt, bleibt die gleiche, wird aber auf Zählerunterbauten für unterschiedliche Durchströmungen gesetzt. So ist es bei stinknormalen Wasseruhren für den Haushalt auch der Fall. Siehe auch https://de.wikipedia.org/wiki/Wasserz%C3%A4hler#Baugr%C3%B6%C3%9Fen_und_Dimensionierung, inbesondere die Dimensionierung.
Gerhard O. schrieb: > Beim DDM 300-010 Sensor mit einem K-Wert von etwa 1420 > ergäben 14200 Impulse in einem Bewässerungszyklus ein Gesamtvolumen von > 10l +/- 2.5 %. Ist die prozentuale Abweichung reproduzierbar, ließe sich > das möglicherweise noch besser kalibrieren. Möglich, aber für die Anwendung (Bewässerung quantitativ erfassen) eher unsinnig. Da halte ich um die 2% Genauigkeit für vollkommen ausreichend. Und wie ein Vorposter schon sagte: die Abdichtung zwischen Flügelrad und Kammerwand ist nicht 100% dicht. Das kann man nicht quantitativ erfassen, weil es von der transportierten Flüssigkeit, deren Temperatur, dem Alter des Sensors und noch gefühlt 1000 weiteren Faktoren abhängt. Deshalb ja auch die ± 2% Meßfehler. Wenn Meßkammer und Flügelrad Spritzgußteile sind (wäre anzunehmen) dann kann man die mit deutlich besserer Genauigkeit herstellen. > Der Hersteller weist allerdings auf einen "ungefähren" K-Wert hin. Der Hersteller bleibt allgemein sehr vage. Genauso gibt er ja auch eine "typische" Frequenz an. Aber für welche Durchflußrate? Für das Maximum? Oder Minimum? Irgendeinen Wert dazwischen? Man weiß es nicht. > Der K-Faktor hat insofern seinen Sinn, als er durch den jeweiligen > Durchflussmessbereich bzw. die Baugröße bestimmt ist: Je größer der > Durchflussmessbereich, desto kleiner fällt der K-Faktor aus. Der Durchflußmeßbereich ist ja extra noch angegeben. Im Gegensatz zu den anderen Angaben aus dem Datenblatt sogar mal brauchbar. Dafür braucht man den k-Faktor also schon mal nicht.
Harald K. schrieb: > Vielleicht, weil Aufbereitungselektronik (Impulsgenerator) und Flügelrad > zwei getrennte Dinge sind. > > Die Elektronik, die die Impulse erzeugt, bleibt die gleiche, wird aber > auf Zählerunterbauten für unterschiedliche Durchströmungen gesetzt. Ganz andere Baustelle. Ich glaube nicht, daß in den Flügelrad-Sensoren die der TE verlinkt hat, nennenswert Elektronik verbaut ist. Der Prinzip-Schaltplan, der da für den "Sensor-Block" angegeben ist, ähnelt frappierend dem eines Hallsensors (z.B. TLE4905). Im Zweifelfall enthält das Dingen außer dem Hallsensor nur noch den Pullup und einen Magneten.
:
Bearbeitet durch User
Angehängte Dateien:
-
10_18_Spannungsteiler.png
8,9 KB
Hallo, wenn man vom Eingangstext und Datenblatt ausgeht und der Durchflussmesser mindestens 5V benötigt und einen internen Pullup verbaut hat, dann reicht es aus, einen Pulldown als Spannungsteiler anzuklemmen. Mit internen 10K, extern 18k und man hat ein 3,3V Signal. Ist einfach zum ausprobieren. Wenn das Signal passt, würde ich paar Messreihen aufnehmen.
Axel S. schrieb: > ähnelt > frappierend dem eines Hallsensors (z.B. TLE4905). Ja und nein! Dieser Flügelradsensor hat das übliche in der Industrie verbreitete Interface. Wird für viele Sensortypen verwendet. Optische, magnetische, kapazitive, Näherungs usw. Hunderte verschiedene, es gibt. Vorgesehen für den direkten Anschluss an SPS Beispiel: https://datasheet4u.com/pdf-down/L/J/1/LJ12A3-ETC2.pdf
Arduino F. schrieb: > Axel S. schrieb: >> ähnelt >> frappierend dem eines Hallsensors (z.B. TLE4905). > > Dieser Flügelradsensor hat das übliche in der Industrie verbreitete > Interface. > > Wird für viele Sensortypen verwendet. > Optische, magnetische, kapazitive, Näherungs usw. > Hunderte verschiedene, es gibt. ... > https://datasheet4u.com/pdf-down/L/J/1/LJ12A3-ETC2.pdf Stimmt auch wieder. Das paßt auch zu dem Bild des Flügelradsensors. Der Hersteller baut anscheinend lediglich das Gehäuse mit Meßkammer, Flügelrad und eingegossenem Magnet selber. Der Rest wird zugekauft.
Beitrag #7930288 wurde vom Autor gelöscht.
Rainer W. schrieb: > Die Frechheit ist, die Einheit für den Faktor nicht anzugeben. Ganz genau. > Bei einer einfachen Proportionalität kann man auf die explizite Angabe > einer Formel schon einmal verzichten. Nö. In der Formel könnte nämlich genau das, was selbst du als fehlend reklamiert hast, mit untergebracht werden. Und obendrein wäre auch jeder Zweifel darüber, wie der K-Faktor anzuwenden ist, ausgeräumt. Z.B.: ob der Zusammenhang tatsächlich (näherungsweise) linear ist. Könnte man an der Formel sofort direkt sehen. Tja, Formeln haben schon was für sich. Deswegen finden sie sich oft in Datenblättern. In diesem halt leider nicht...
Ich habe mir deren Website mal angesehen- Da gibt es einiges an technischer Dokumentation. Das Blättchen was wir oben verlinkt sehen ist da eher ein Tropfen auf dem heißen Stein. Der K Wert ist sicherlich irgendwo beschrieben, konnte aber nicht auf den ersten Blick erkennen, wo. Anfragen per Email scheinen willkommen zu sein. Nein, die machen auf mich nicht den Eindruck sowas geheim halten zu wollen. Nachtrag, hier findet sich was: https://flowmeters.co.uk/wp-content/uploads/pdfs/tech-data/data-sheet-og7-01-23.pdf > Approx ‘K’ factor (Pulses/Litre) 15
:
Bearbeitet durch User
Peter D. schrieb: > Generell empfiehlt sich eine Entstörung per Mehrfachabtastung im > Timerinterrupt. Hall-Sensoren besitzen selber eine Hysterese. Mit Störungen von Sensorseite ist deshalb eher nicht zu rechnen. Ob S. schrieb: > Nö. In der Formel könnte nämlich genau das, was selbst du als fehlend > reklamiert hast, mit untergebracht werden. Seit gut 50 Jahren ist es üblich, die Einheiten von irgendwelchen Größen und ggf. irgendwelche Umrechnungsfaktoren von Einheiten nicht in der Formel unterzubringen, sondern bei den Größen zu lassen. Auch die Tatsache, dass andere Hersteller den 'K'-Faktor durchaus mit Einheit angeben, spricht dagegen. Arduino F. schrieb: > Nachtrag, hier findet sich was: > https://flowmeters.co.uk/wp-content/uploads/pdfs/tech-data/data-sheet-og7-01-23.pdf >> Approx ‘K’ factor (Pulses/Litre) 15 Um das Anlaufverhalten in einer Formel abzubilden, reicht die Tiefe der Modellbildung bei weitem nicht aus. > Z.B.: ob der Zusammenhang tatsächlich (näherungsweise) linear ist. > Könnte man an der Formel sofort direkt sehen. Das siehst einem Skalierungsfaktor mit einer Dimension von 1/Volumen ebenfalls an. Sonst müssten weitere Faktoren mit anderen Potenzen genannt werden.
:
Bearbeitet durch User
> Um das Anlaufverhalten in einer Formel abzubilden, reicht die Tiefe der > Modellbildung bei weitem nicht aus. > Meiner Meinung nach wäre das Anlaufverhalten wegen nicht konstanter Reibung, Inertia und anderen mechanischen Umständen ohnehin nicht sehr reproduzierbar. Eine Erfassung dieses Bereichs hat deswegen also wenig Sinn. Ferner gibt der Hersteller deswegen einen Minimumwert an, den man für Messzwecke geflissentlich nicht unterschreiten sollte, weil dann das Laufverhalten der Turbine unterhalb dieses Grenzwerts nicht mehr zuverlässig und reproduzierbar genug ist. Abgesehen davon spielen im Einsatz von Strömungsmessungen noch einige andere Störfaktoren mit. Nicht umsonst zeigt der Hersteller seinen Meßaufbau so genau. Den Sensor einfach so irgendwo einzubauen garantiert nicht einmal die angegebene Hersteller Spezifikation. Die Eigenschaften des Strömungsverhalten (Turbulent bis laminar) wird durch die bekannte Reynoldsnummer quantifiziert. Deshalb wird man ohne sorgfältigen Messungen und Messreihen nicht herumkommen. So bekommt man dann ein Bild der Abweichungen vom Idealwert und seiner Reproduzierbarkeit und Konsistenz und kann notwendige Korrekturen miteinbeziehen - "Know your Sensor !" Ich würde den Sensor so ideal wie möglich einbauen, durchmessen und dann damit arbeiten. Falls die Messgehauigkeit dann die +/- 2.5% nicht übersteigt, ist dann das Volumen bei 10l immerhin auf +/- 0.25l bekannt. Man sollte meinen, daß eine solche Genauigkeit in diesem Anwendungsfall völlig ausreichend wäre. Duck und weg, Gerhard
Rainer W. schrieb: > Hall-Sensoren besitzen selber eine Hysterese. Mit Störungen von > Sensorseite ist deshalb eher nicht zu rechnen. Nun, der Sensor wird wohl nicht im µC integriert sein, sondern es gibt ein Kabel zwischen beiden. Und da µCs sauschnell sind, können sich auf dieses Kabel sehr leicht Störungen (kapazitiv, induktiv, Erdschleife) einkoppeln. Eine störfreie Umgebung ist eine Illusion. Mal das Handy, Staubsauger, Bohrmaschine, Schaltnetzteile, WLAN-Router usw. neben das Kabel halten.
Peter D. schrieb: > Eine störfreie Umgebung ist eine Illusion. Das brauchst du mir nicht zu erzählen. Andererseits besitzt ein Digitaleingang, der durch die Leitungskapazität kurze Pulse platt macht, einen ganz gesunden Störabstand. Eine TVS-Diode und Schmitt-Triggereingang mit einem RC-Tiefpass wäre bei nach außen führenden, längeren Leitungen sowieso angeraten. Gegen Erdschleifen hilft eine vernünftige Leitungsführung, gegen induktive Einkopplung eine Symmetrierung durch verdrillt Leitung und gegen kapazitive eine Schirmung. Erstmal hat der TO noch viel grundlegendere Probleme.
Gerhard O. schrieb: > Ich würde den Sensor so ideal wie möglich einbauen, durchmessen und dann > damit arbeiten. Falls die Messgehauigkeit dann die +/- 2.5% nicht > übersteigt Abgsehen davon, dass die "Messgenauigkeit" hier eigentlich "Messfehler" oder etwas holpriger "Messungenaugkeit" heißen sollte, ist das exakt die Strategie, die der TO verfolgen sollte. Und "durchmessen" ist hier durchaus so zu verstehen, dann man erst mal das Signal des an den µC angeschlossenen Sensors mit einem Oszilloskop misst. Und dann, wenn das Signal dort am µC Eingang gut und nachvollziehbar aussieht (die Pegel passen, die Pulszeiten sind ok, die Flanken sind sauber und die ausgegebene Frequenz passt zum Durchfluss) das Programm so schreibt, dass die erwarteten Werte herauskommen. Peter D. schrieb: > Eine störfreie Umgebung ist eine Illusion. Das mag sein, aber genauso wie die Diskussion um die Genauigkeit bei verschiedenen Durchflussraten und Einbaurichtungen ist eine Diskussion um die Ströfestigkeit hier verfrüht. Jetzt soll der TO Lysandros doch einfach erst mal seinen Sensor an seinen µC anschließen und ein paar Impulse einlesen. Und wenn er anschließend einfach einen niederohmigeren Pullup mit 1k gegen Vcc in die Schaltung macht, dann sind schon ganz ganz viele Störungen zu schwach, um etwas auszurichten. > Mal das Handy, Staubsauger, Bohrmaschine, Schaltnetzteile, WLAN-Router > usw. neben das Kabel halten. Ich hätte da entwicklungsbegleitend als besser definierten Störer noch den "Burst-Test des kleinen Mannes" anzubieten wie im Beitrag "Re: Tiefentladungsschutz mit Attiny und P-Kanal Fet" beschrieben. Kabelverbindungen teste ich, indem ich sie auf ca. 30 cm mit Alufolie umwickle und dann links und rechts in auf diese Folie draufhalte:
1 | Alufolie |
2 | <-- 30cm --> |
3 | ~~~~~~~~~~~~ |
4 | --========={============}===========- Eingang
|
5 | Sensor { }
|
6 | --========={============}===========- GND
|
7 | o~~~~~~~~~~~~o Blitze ___ |
8 | | '</\/===| | Viehtreiber |
9 | | | | |
10 | '-----------------===|___| |
:
Bearbeitet durch Moderator
Moin, Diesen "Burst Test" machte ich früher gerne mit dem Weller Magnastat Lötkolbenkabel in unmittelbare Nähe der zu beobachtenden digitalen Eingangs-Schaltungsteile gelegt. Beim Abschalten des Magnastats gab es dann beträchtliche Impuls-Energie, die ungeschützte Schaltungen immer störten. Erst wenn da nichts mehr passierte, konnte man sicher sein, daß die Schaltung zufriedenstellend robust war. CMOS Logik war da besonders anfällig. Deine Methode kann ich Mangels an HW leider nicht ausprobieren. Den O.C. Ausgang des Sensors könnte man bequemerweise mit einem Opto-Isolator von der uC Schaltung trennen. Das Schmitt-Trigger Verhalten des Logik Eingangs kommt den langsamem Schaltverhalten des Opto-Isolators ohnehin entgegen und man braucht eigentlich keinen Tiefpass. Der Hall Ausgang sollte eigentlich prellfrei sein. Aber schaden würde ein RC TP natürlich nicht. Ein One-Shot wäre hier Overkill. Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Ein One-Shot wäre hier Overkill. Ein "One-Shot" würde bei jedem Störimpuls schießen - wozu sollte das gut sein?
Peter D. schrieb: > https://www.schwille.de/produkt/esd-piezo-pruefpistole-100-900/ Ich hatte den oben beschriebenen Test vorher immer mit einem Piezozünder eines Feuerzeugs gemacht. Da gibt es aber eben immer nur 1 kurzen Impuls pro 1x Drücken. Der Viehtreiber macht bei kleinem Kontaktabstand in diesen Zeit zigtausend "kleine" knisternde Störungen. Oder er knattert bei größerem Abstand vernehmlich und recht bedrohlich vor sich hin. Den Versuch einer "Kontaktentladung" direkt auf einen Eingangspin oder die Versorgung würde ich mit dem Viehtreiber auf keinen Fall machen. Ich denke, die von ihm erzeugte Energie reicht aus, um irgendwelche Siliziumstrukturen in ICs auch mit "üblichem" externen ESD-Schutz hinreichend zu schädigen.
Rainer W. schrieb: > Gerhard O. schrieb: >> Ein One-Shot wäre hier Overkill. > > Ein "One-Shot" würde bei jedem Störimpuls schießen - wozu sollte das gut > sein? Das stimmt natürlich, war aber nicht der Zweck. Der O.S. sollte nur mögliches Prellen unterbinden, um extra Zählimpulse zu verhindern. Das ist beim Hall-Effekt Sensor natürlich nicht zu erwarten. Abgesehen davon wäre auf Grund der niedrigen Turbinenfrequenz eine Periodenmessung wahrscheinlich günstiger, weil man dann auf Grund der kürzeren Messdauer pro Periode viele Periodenwerte mit höherer Auflösung als bei der einfachen Frequenzmessung mitteln kann. Bei z.B. 10MHz Timer Taktfrequenz würden bei 100 Hz (10ms) im Capture Register ein Wert von 100000 fest gehalten. Folglich ergibt jede Messung in einer Periodenmessung sehr hohe Auflösung. Natürlich muß man Mitteln, weil sonst durch Jitter in der Capture Erfassung einzelne Messwerte beträchtlich um den Zentralwert pendeln würden.
Gerhard O. schrieb: > Der O.S. sollte nur mögliches Prellen unterbinden, um extra Zählimpulse > zu verhindern. Das ist beim Hall-Effekt Sensor natürlich nicht zu > erwarten. Eben. Unterbinden ließe sich das Prellen damit sowieso nicht, sondern allenfalls herausfiltern.
Vielen Dank euch allen, für eure größtenteils sehr konstruktive Vorschläge und Hinweise!
Gerhard O. schrieb: > Abgesehen davon wäre auf Grund der niedrigen Turbinenfrequenz eine > Periodenmessung wahrscheinlich günstiger, weil man dann auf Grund der > kürzeren Messdauer pro Periode viele Periodenwerte mit höherer Auflösung > als bei der einfachen Frequenzmessung mitteln kann. Theoretisch ja, aaaber: Dann gibt es das "Abschaltproblem" - also, wenn das Flügelrad bei Bewässerungsstop stehenbleibt, der Zähler aber immer noch weiterläuft... Die Software muss dann die Auswertezeit begrenzen. Sollte bei der Programmierung berücksichtigt werden.
Gerhard O. schrieb: > Abgesehen davon wäre auf Grund der niedrigen Turbinenfrequenz eine > Periodenmessung wahrscheinlich günstiger, Wozu will man eine Frequenz oder Periodendauer messen, wenn das geflossene Gesamtvolumen interessiert? Einfache die Anzahl der Pulse durch den "K-Faktor" zu dividieren, ist zu einfach? Wenn die Grundfunktion läuft, die Auflösung aber zu gering ist, kann man sich immer noch mit zeitgesteuerten Interpolationsalgorithmen und deren Fallstricken beschäftigen.
Hallo nochmals liebe Leute, für die Software, Zephyr-RTOS gibt es scheinbar noch keine ausgereifte API für einen Puls-Zähler. Aus diesem Grund tendiere ich zu einem dedizierten IC zwischen Sensor und μCU, um a) die Timing/Counter-Hürde in Zephyr RTOS zu überwinden und b) Prellen oder ähnliches zu unterbinden. Seltsamerweise habe ich nur LS7366R bzw. LS7866 gefunden und beide sind nicht so gut verfügbar. Auch ATtiny202, erfüllt nicht wirklich den Zweck...Irgendwelche Ideen? Vielen Dank
Lysandros schrieb: > b) Prellen oder ähnliches zu unterbinden. Wie sehen die Signale und die Störungen aus, die von deinem Geber kommen. Darauf muss eine Signalvorverarbeitung eingestellt sein. Zeig einmal ein paar Beispielsignale, wie sie bei deinen Durchflussraten vom Sensor kommen. Was genau meinst du mit "ähnliches"? Falls der Sensor prellt, dann ist das so. Das kannst du dann nicht unterbinden, sondern müsstest es aus dem Signal herausfiltern, bevor es zum Zähler geht.
:
Bearbeitet durch User
Lysandros schrieb: > Auch ATtiny202, erfüllt nicht wirklich den > Zweck Was stört Dich denn am ATtiny202, der ist doch super flexibel und leistungsfähig, sowie einfach in C zu programmieren. Ein ATtiny25 ginge natürlich auch. Zephyr-RTOS sagt mir allerdings überhaupt nichts, worauf soll das denn laufen? Und worüber soll das den mit dem ATtiny kommunizieren? Der ATtiny202 kann UART, I2C oder SPI.
Für mein Prototyp-Hobbybastler-Dosimeter, hab ich einen ~3€ Flügelradzähler* verbaut. Die Störungen hab ich durch Polling umgangen. Das Problem, das er auch Luft misst, durch Einbau in falscher Lage. Der Fehler hat sich dadurch zwar fast auf 5% erhöht aber besser als Luft messen. Ist aber auch nicht für mehr als ~200-300l im Jahr ausgelegt, tut aber bereits seit ~10J ohne Änderung in der "Genauigkeit". *) !ACHTUNG! Der zählt überhaupt keine Flügelräder! 8-O
Bisher habe ich noch nicht den Sensor bekommen, k.A. also wie sauber das Signal ausschauen wird. Deswegen habe ich noch keine Daten. "Zephyr" ist ein Echtzeitbetriebssystem, um Mikrocontroller zu programmieren. ATtiny202 und ATtiny25 sind ja echte Mikrocontroller... Mein Ansatz ist, das Signal mit einem möglichst simplen IC zu konditionieren, und dann anhand eines STM32 zu erfassen (z.B. über I2C oder sogar analog) und weiterzuverarbeiten
Lysandros schrieb: > ATtiny202 und ATtiny25 sind ja echte Mikrocontroller. Der Kandidat hat 100 Punkte. Spezial-ICs gibt es nur noch im Museum und es werden definitiv auch keine neuen mehr entwickelt. Ein zusätzlicher µC ist nur dann notwendig, wenn das "Zephyr" sich dagegen sträubt, diese läppische Aufgabe mit zu übernehmen. Ein STM32 ist dafür allerdings extrem oversized.
Lysandros schrieb: > "Zephyr" ist ein Echtzeitbetriebssystem, um Mikrocontroller zu > programmieren. Gibts einen besonderen Grund, warum du deinen µC unbedingt geheim halten möchtest? Oder wozu du Zephyr brauchst um Hardware Zähler auszulesen....
Lysandros schrieb: > Bisher habe ich noch nicht den Sensor bekommen, k.A. also wie sauber das > Signal ausschauen wird. Ein Signal von einem Hall-Sensor ist idR. sehr sauber. Habe ich auch schon über 3m ungeschirmtes Kabel direkt an PB0 eines ATMega328 mit 10k Pullup gehängt und ausgewertet. > "Zephyr" ist ein Echtzeitbetriebssystem, um Mikrocontroller zu > programmieren. Was ist daran so toll, daß du es verwenden mußt? Wenn es keine Impulse zählen kann, taugt es offensichtlich nicht für diese Aufgabe. > ATtiny202 und ATtiny25 sind ja echte Mikrocontroller... Der STM32 ist auch ein "echter" µC. > Mein Ansatz ist, > das Signal mit einem möglichst simplen IC zu konditionieren, und dann > anhand eines STM32 zu erfassen (z.B. über I2C oder sogar analog) und > weiterzuverarbeiten Und das alles nur, weil du zu faul/unfähig bist, die Impulse mit den STM32 zu zählen? Meine Güte ...
Aus mehreren Gründen sind wir gebunden an: 1) Software: Zephyr RTOS 2) Hardware-Plattform: STM32-Nucleo (z.B. der H723ZG oder F756ZG) 3) Zeitliche Fristen, die das anlernen von Custom-Timing-Funktionen zurzeit nicht ermöglichen Da dies rigide Anforderungen sind versuche ich nun das benötigte Equipment zu finden. Es wäre toll, falls jemand einen IC vorschlagen kann, der ohne Programmierung das Quadratur-Signal per I2C oder ähnlich an meinen STM32-Nucleo sendet. Vielen Dank
Lysandros schrieb: > Mein Ansatz ist, > das Signal mit einem möglichst simplen IC zu konditionieren, und dann > anhand eines STM32 zu erfassen Du meine Güte, mit welcher Datenrate/Impuls-Frequenz rechnest du denn? Irgend etwas im Terahertz Bereich?
Lysandros schrieb: > Seltsamerweise habe ich nur LS7366R bzw. LS7866 gefunden und beide sind > nicht so gut verfügbar. Auch ATtiny202, erfüllt nicht wirklich den > Zweck...Irgendwelche Ideen? Ja, egal was du zuvor gemacht hast, hiermit bist du maximal überfordert. Gib das wieder ab und kehre zurück zu deinen Leisten!
Ein Quadratur-Signal gibt es nicht! Gib einfach die Pulse auf einen Zählereingang des STM32 und lies ihn zyklisch aus. Zum Abgleich fülle einen 10l Eimer mit Wasser und bilde die Differenz aus Zählerstand davor und danach. Fertig.
Peter D. schrieb: > Zum Abgleich fülle einen 10l Eimer mit Wasser und bilde die Differenz > aus Zählerstand davor und danach. Der "K-Faktor" sind die Impulse pro Liter! :DDD
Teo D. schrieb: > Der "K-Faktor" sind die Impulse pro Liter! :DDD Woher nimmst du diese Information? Im Datenblatt steht davon nichts. Vielleicht sind es auch Impulse pro Gallone - je nach Glaubensrichtung. Davon abgesehen - die Werte dazu im Datenblatt sind nur Richtwerte ("Approx."), d.h. wenn man mit dem Sensor vernünftig messen möchte, kommt man um eine Bestimmung des Wertes nicht drumherum (falls der Kalibrierwert nicht mitgeliefert wird).
Rainer W. schrieb: > Woher nimmst du diese Information? Im Datenblatt steht davon nichts. > Vielleicht sind es auch Impulse pro Gallone - je nach Glaubensrichtung. Ich glaube an Mathematik... (und ein klein wenig an die Vernunft) :D
:
Bearbeitet durch User
Teo D. schrieb: > Ich glaube an Mathematik... (und ein klein wenig an die Vernunft) :D Dann glaub mal schön ... Zur aktuellen Situation der Vernunft in den USA ... (Tabelle im Abschnitt "Do I Need to Know the K Factor for My Flow Meter?") https://koboldusa.com/articles/common-questions/what-is-k-factor-for-flow-meters/
Es sind 17000 Pulse pro Liter laut OEM-Datenblatt. Bei einer Menge von 800mL pro Sitzung, sind es ca. 13600 Pulse. Mit einer Pumpenförderrate von 400mL/min, wird es 120 Sekunden lange dauern, sprich die Pulse werden mit ca. 120Hz erscheinen. Ich versuche mal einen klassischen Interrupt aufzustellen; kann noch nicht sagen ob der STM32 es schafft, jeden Puls mitzukriegen und dabe den Zähler zu inkrementieren. Zephyr heisst zwar "RTOS", aber ob es wirklich Echtzeit ist...k.A.
Lysandros schrieb: > Ich versuche mal einen klassischen Interrupt aufzustellen; kann noch > nicht sagen ob der STM32 es schafft, jeden Puls mitzukriegen und dabe > den Zähler zu inkrementieren. Wenn der es nicht schafft, 120Hz-Impulse zu zählen, liegt das nicht am STM. Einen HW-Timer/Counter als Zähler zu konfigurieren, so dass er ganz ohne Interrupts, Softwareunterstützung und RTOS-Echtzeitanforderungen die Impulse an einem GPIO zählt, funktioniert beim STM32 nicht? Jeder Arduino mit ATmega328 macht das nebenbei.
Lysandros schrieb: > Zephyr heisst zwar "RTOS", aber ob es wirklich Echtzeit ist...k.A. Wie üblich: (schlechte) Software macht Rechner langsam. Ein jedes RTOS beherrscht Echtzeit nur, wenn der Programmierer es richtig anwendet. Rainer W. schrieb: > Einen HW-Timer/Counter als Zähler zu konfigurieren, so dass er ganz ohne > Interrupts, Softwareunterstützung und RTOS-Echtzeitanforderungen die > Impulse an einem GPIO zählt, funktioniert beim STM32 nicht? Doch, klar geht das. Das konnte schon das Urgestein 8048 aus dem letzten Jahrtausend. Und genau so macht man es auch beim STM32: man wählt als Clock-Source für den Zähler einfach einen externen Pin (ETR) aus. - https://wiki.st.com/stm32mcu/wiki/Getting_started_with_TIM#Timer_clock_source_selection - https://blog.embeddedexpert.io/?p=2323 - https://community.st.com/t5/stm32-mcus-products/count-external-pulses-using-timer/td-p/59349
:
Bearbeitet durch Moderator
Lysandros schrieb: > aber ob es wirklich Echtzeit ist...k.A. Es gibt nicht DIE Echtzeit. Betriebssysteme, die sich RTOS nennen, garantieren eine maximale Antwortzeit auf externe Ereignisse, mehr nicht. Wie die spezifiziert ist und ob dieser Wert zur Aufgabe passt, muss man anhand der garantierten Werte prüfen und nicht ausprobieren, es sei denn, man hat eine spezielle SW-Testumgebung, um worst-case Szenarien darzustellen und abzuprüfen.
Lothar M. schrieb: > Doch, klar geht das. Das konnte schon das Urgestein 8048 aus dem letzten > Jahrtausend. Und genau so macht man es auch beim STM32: man wählt als > Clock-Source für den Zähler einfach einen externen Pin (ETR) aus. > - > https://wiki.st.com/stm32mcu/wiki/Getting_started_with_TIM#Timer_clock_source_selection > - https://blog.embeddedexpert.io/?p=2323 > - > https://community.st.com/t5/stm32-mcus-products/count-external-pulses-using-timer/td-p/59349 Das das in der Art überhaupt Erwähnung finden muss? Die Herangehensweise ergibt sich schon rein aus den logischen Erfordernissen. Vielleicht weiss der TO einfach nicht, wie er diesen "Funktionsblock" erstellt und in sein RTOS einbindet? Dann kann er das halt nicht machen. Aber es muss doch ein gewissen Grundverständnis geben? Wenn ich einem Kollegen eine Aufgabe zuweise, bin ich mit dessen Wissensstand soweit vertraut, das ich weis, ob er das kann oder nicht. Ich kann doch nicht wahllos einen freien Mitarbeiter hernehmen und ihm sagen: "Mach mal". Verstehe ich wirklich nicht. Ich setz mich ja auch nicht ans Catia, SolidWorks, Fusion360 usw. und fange an, irgendwas zu konstruieren. Also; mein Chef geht damit in die Konstruktionsabteilung und kommt nicht zu mir damit. Diss wird doch nix. Oft weiss man garnicht, welche Fragen man sich eigentlich stellen, und wie das insgesamt hier weitergehen soll.
Lysandros schrieb: > Ich versuche mal einen klassischen Interrupt aufzustellen; kann noch > nicht sagen ob der STM32 es schafft, jeden Puls mitzukriegen und dabe > den Zähler zu inkrementieren. Zephyr heisst zwar "RTOS", aber ob es > wirklich Echtzeit ist...k.A. Mal unabhängig davon, das ein (externer) Interrupt nichts mit RTOS Fähigkeiten zu tun hat, schauen wir uns mal andere Systeme an: Micropython: RP2350, Standard CPU Takt, ca. 183000 IRQs pro Sekunde möglich. IN PYTHON! Beim älteren RP2040 noch ca. 135000 IRQs pro Sekunde. Wenn man an 120 IRQs pro Sekunde in ›C‹ scheitert, dann gibt's nur eine Lösung: Zurück zum alten Job: Weizenmehl, Roggenmehl, Wasser mischen, gehen lassen, und dann ca. 55…65 Minuten bei 180°C ausbacken.
Axel R. schrieb: > Vielleicht weiss der TO einfach nicht, wie er diesen "Funktionsblock" > erstellt und in sein RTOS einbindet? Dann kann er das halt nicht machen. Dann muss er es eben lernen. Oder andersrum: wo kommt man hin, wenn man immer nur das macht, was man schon kennt? > Ich kann doch nicht wahllos einen freien Mitarbeiter hernehmen und ihm > sagen: "Mach mal". Wenn er gut ist, dann kann ich das. > Ich setz mich ja auch nicht ans Catia, SolidWorks, Fusion360 usw. und > fange an, irgendwas zu konstruieren. Ich gehe doch sehr davon aus, dass jemand, der eine Hardware bauen und eine Software programmieren will, grundlegende Erfahrung damit hat. Denn sonst beginnt die Lernerei eben viel, viel weiter vorne beim Systemverständnis. > Also; mein Chef geht damit in die Konstruktionsabteilung und kommt nicht > zu mir damit. Aber es ist immer gut, wenn man als Hard-/Softwerker auch die Mechanik versteht, für die die Hard-/Software entwickelt wird. Schon so manches Mal konnte ich mit entsprechenden Tipps an die Mechaniker die Steuerungsentwicklung vereinfachen. > Wenn ich einem Kollegen eine Aufgabe zuweise, bin ich mit dessen > Wissensstand soweit vertraut, das ich weis, ob er das kann oder nicht. Ich habe eher den Verdacht, das hier ist eine Studienarbeit, wo sich die Studenten in ihrem Können überschätzt haben. Aber zusammenfassend: der µC kann die für die Aufgabe hier nötige Funktion mit seiner eingebauten Hardware erledigen (die hat man beim Kauf des µC bezahlt, man darf sie straflos verwenden). Die Verwendung eines Interrupts für diese Zählerei ist im Grunde bereits ein Workaround und zeigt, dass man das Datenblatt seiner Hardware nicht gelesen bzw. verstanden hat.
Lothar M. schrieb: >> Wenn ich einem Kollegen eine Aufgabe zuweise, bin ich mit dessen >> Wissensstand soweit vertraut, das ich weis, ob er das kann oder nicht. > Ich habe eher den Verdacht, das hier ist eine Studienarbeit, wo sich die > Studenten in ihrem Können überschätzt haben. Oder ein Cannabis-Social-Club Mitglied, das völlig überzogene Vorstehlungen einer Bewässerung (Klimaregelung?!) und das "in Echtzeit" propagiert hat und meinte "Geld? Kein Problem, ICH bau euch das". Wie Fachfremd muss man den sein, um einen Open-Collector Ausgang, mit einem Inkrementalgeber zu verwechseln?! Bewässern in Echtzeit...
Leute, vielen Dank für die konstruktiven Vorschläge und die Weblinks. Es funktioniert jetzt bei 100Hz. Habe eine Beispiel-Applikation gefunden, die den Status einer nativen Taste des μCU per Interrupt überwacht. Den Code nun etwas angepasst, damit ein bestimmter externer Hardware-Pin als Quelle verwendet wird. Einen zweiten μCU verwende ich als Quelle, der generiert eigentlich PWM-Signale. Ich verstehe allerdings noch nicht genau, wie der Interrupt funktioniert, denn es gibt offenbar noch eine externe Zeit-Schleife. Naja.. https://docs.zephyrproject.org/latest/samples/basic/button/README.html Es geht übrigens um Hülsenfrüchte :)
Lysandros schrieb: > Es funktioniert jetzt bei 100Hz. Habe eine Beispiel-Applikation > gefunden, die den Status einer nativen Taste des μCU per Interrupt > überwacht. Was hast du dabei immer mit dem Interrupt. Was spricht gegen einen simplen Timer/Counter, der direkt die Pulse am GPIO als Takt bekommt und ganz ohne Softwareaktivität das Volumen mitzählt?
Rainer W. schrieb: > Was hast du dabei immer mit dem Interrupt. Was spricht gegen einen > simplen Timer/Counter, Du bist nicht der Erste, der das sagt.... Aber da ist kein Durchkommen, warum auch immer. Hier habe ich das schon vor 3 Tagen probiert: Beitrag "Re: Signalkonditionierung für Flügelradzähler" Keine Reaktion darauf.
:
Bearbeitet durch User
Rainer, Arduino, natürlich wäre ein Timer/Counter die bevorzugte Lösung. Aber es gibt noch keine ausgereifte Timer-API für RTOS Zephyr; das ist ein bekanntes Thema in der Zephyr-Community. Eine Bare-Metal-Programmierung kommt für mich nicht infrage. Danke euch für eure Kommentare
Ich glaube, du kannst dir gar nicht vorstellen, wie absurd sich das für mich anhört. Aber OK, jedem sein eigen Himmelreich!
:
Bearbeitet durch User
Lysandros schrieb: > natürlich wäre ein Timer/Counter die bevorzugte Lösung. Aber es gibt > noch keine ausgereifte Timer-API für RTOS Zephyr Kaum glaublich. Laut Wikipedia ist Zephyr seit 2016 in Version 1.0.0. Und da hat es 9 Jahre später immer noch keine API für die Hardware-Timer? Ich wiederhole meine Frage (keine Antwort bekommen): Axel S. schrieb: > Was ist daran so toll, daß du es verwenden mußt? Wenn es keine Impulse > zählen kann, taugt es offensichtlich nicht für diese Aufgabe.
Axel S. schrieb: > Kaum glaublich. Laut Wikipedia ist Zephyr seit 2016 in Version 1.0.0. > Und da hat es 9 Jahre später immer noch keine API für die > Hardware-Timer? Ich glaub's. ;-) Wenn man sich die Liste der unterstützten Geräte und Architekturen anschaut (vom Schweissfuß-Wärmer bis zum Remote-Control-Onaniergerät), so darf man darauf schließen, dass es zwar extrem breit, dafür aber auch extrem flach aufgestellt ist. Erst mal das Geraffel irgendwie zum Funktionieren bringen, dann langsam reifen** lassen und mal schauen ob's noch irgend einer irgend wann mal richtig machen möchte. Eine Krankheit unter der anscheinend viele Projekte leiden. **Wie ein empfindlicher Käse in der Sonne
Lysandros schrieb: > Aber es gibt noch keine ausgereifte Timer-API für RTOS Zephyr; Dann schmeiß das RTOS raus. Was willst du damit?
Lysandros schrieb: > Eine Bare-Metal-Programmierung kommt für mich nicht infrage. Und warum nicht? Weil es verboten wurde? Oder weil du nicht willst? Das sind doch nur eine Handvoll Register, die da beschrieben werden müssen. Auf jeden Fall hätte man das mit ein wenig gutem Willen und dem Lesen der Doku in den vergangenen 18 Tagen (so lange geht dieses Drama hier schon!!) locker und luftig selber programmieren können. Wer mit µC herummachen will muss sich schon ein wenig mit µC beschäftigen. > Danke euch für eure Kommentare Keine Ursache.
Rainer W. schrieb: > Lysandros schrieb: >> Aber es gibt noch keine ausgereifte Timer-API für RTOS Zephyr; > > Dann schmeiß das RTOS raus. Was willst du damit? Warum leckt sich der Hund die Eier...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.