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?
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.
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.
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.
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
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.
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.
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.
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.
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 ...
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.
Muss eh kalibriert werden. Controller ist schon da, kann man also direkt ein Kennfeld bei unterschiedlichen Durchflussmengen erstellen. Oder sich ein passendes Polynom bauen.
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ß.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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...
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 ...
Hardware-Plattform: STM32-Nucleo (z.B. der H723ZG oder F756ZG)
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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?!
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 :)
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, 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
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):
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.
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.
inzwischen konnte ich den NPN-Sensor erfolgreich testen, quasi ganz unten im V-Diagramm, direkt am μCU angeschlossen.
Beim Versuch nun den Sensor in ein erweitertes Modul zu integrieren, stell ich fest, dass die registrierte Pulszahl viel zu hoch ist, ca. Faktor 100x als erwartet. Kann das mit den Grounds zusammenhängen? Auch habe ich gelesen, dass ein NPN angeblich den Ausgang auf Ground schaltet, ist das richtig? Dann kann ich am Digital-In des μCU garnicht ein positives Signal sehen, oder?
Danke euch
stell ich fest, dass die registrierte Pulszahl viel zu hoch ist, ca.
Faktor 100x als erwartet. Kann das mit den Grounds zusammenhängen?
Man kann das mit einem Oszilloskop messen: Masseklemme direkt an den µC-Massepin und den Tastkopf direkt an den µC-Eingangspin. Dann sieht man, was da abgeht.
Wenn es mit dem angeklemmten Oszilloskop auf einmal funktioniert, dann hängt es mit floatenden Bezugspunkten (gemeinhin Masse oder anglizistisch Ground genannt) zusammen.
Denn natürlich muss der GND vom Sensor mit dem GND vom µC verbvunden sein.
Dann kann ich am Digital-In des μCU garnicht ein positives Signal
sehen, oder?
Du brauchst einen Pullup, wenn du einen NPN Schalter gegen Masse hast.
Dazu ein Tipp: der interne Pullup eines µC reicht hier nicht.
Und noch ein weiterer Tipp: ein STM32 wird nicht mit 5V versorgt...
inzwischen konnte ich den NPN-Sensor erfolgreich testen, quasi ganz
unten im V-Diagramm, direkt am μCU angeschlossen.
Beim Versuch nun den Sensor in ein erweitertes Modul zu integrieren,
stell ich fest, dass die registrierte Pulszahl viel zu hoch ist,
Dann frage man sich, was du als erfolgreichen Test bezeichnest?
Was für ein "erweitertes Modul"?
Wie hast du die Pulszahl registriert?
Hast du dir die Signale mit einem Oszi angesehen - bei deinem Test und beim "erweiterten Modul"(Screenshots)?
Das Bild nützt wenig. Ein Blockschaltbild mag für die Konzeption oder als Übersicht ganz gut sein, taugt aber nichts, wenn es um Details der Schnittstelle geht.
habe ich gelesen, dass ein NPN angeblich den Ausgang auf Ground
schaltet, ist das richtig? Dann kann ich am Digital-In des μCU garnicht
ein positives Signal sehen, oder?
Das ist richtig, aber der Sensor hat gar keinen reinen NPN Ausgang. Also wenn es der ist, den du mal verlinkt hast. Der hatte einen Pullup- Widerstand schon im Sensor verbaut.
Der hatte einen Pullup- Widerstand schon im Sensor verbaut.
Dann müsste man am offenen Ausgang des Sensor (=nichts anderes angeschlossen) eine Spannung messen können, bei minimalstem Durchfluss eventuell auch mit einem Multimeter als springender Wert. Bei 24V-Versorgung des Sensors würden die auf den Eingang des "erweiterte Moduls" treffen. Verträgt das "erweiterte Modul" dies. Falls der Pull-Up im Sensor einen Wert von 10kΩ besitzt, wären das 2mA, die irgendwo hin müssen.
Bei
24V-Versorgung des Sensors würden die auf den Eingang des "erweiterte
Moduls" treffen. Verträgt das "erweiterte Modul" dies. Falls der Pull-Up
im Sensor einen Wert von 10kΩ besitzt, wären das 2mA
Wurde alles schon diskutiert und Lösungen genannt. Aber um 2mA würde ich mir keine Platte machen. Das vertragen die Schutzdiodem im µC.
==> Die Pulse hatte ich mir am Oszilloskop angeschaut, die sahen relativ
normal aus, evtl. etwas abgerundet
Dann passt was in der HW Konfiguration oder der Auswertung in der SW nicht, wenn du augenscheinlich 100x zu viele Impulse zählst.
BTW: ein komprimiertes JPG-Foto aus der realen Welt, das in einem Bildbearbeitungsprogramm geändert wird, sollte natürlich weiterhin ein JPG sein. Denn PNG oder GIF sind nur dann effizient, wenn nur wenige Farben im Spiel sind. Soweit sollte man seine "Tools" aus der Ecke "Bildformate" kennen.
Dank euch Lothar und Rainer; diese Vorschläge sind konstruktiv. Einen Schaltplan der Eingangsstufe habe ich nicht..Ich melde mich wieder zeitnah; denn wir mussten den Leihsensor zurücksenden und ich warte jetzt auf die neuen Sensoren:)
