Durchflusssensor auswerten

[Searcher]

Hallo,
einiges was mir bis jetzt so auffällt:

Interner RC Oszillator. Ansonsten orginal Fusebits.

Der Mega8 läuft dann mit 1MHz und $crystal muß auf 1000000 berichtigt werden
Das hat Auswirkungen auf die wait Anweisungen - die werden mit $crystal = 2Mhz doppelt so lang wie angegeben.

Und die Grundlage zur Berechnung der Liter pro Sekunde stimmt nicht.

    Tempsingle = 31250 / Templong                             'Liter pro Sekunde

Die Frequenz des Timers mit Prescale 64 ist nicht 31250Hz sondern 15625Hz

Auswerten:

  Tempword1 = Tcnt1l
  Tempword = Tcnt1h * 256
  Tempword = Tempword + Tempword1

Geht auch mit Tempword = Tcnt1, dann macht Bascom den 16 Bit Registerzugriff aber kein Problem


Insgesamt finde ich die Methode zum Messen der Impulse nicht optimal.

Gruß
Searcher

[Felix H.]

hi,

habe den Oszillator schon auf 2 Mhz stehen habe testweise auch 4 oder 8 versucht (mit abgeändertem Programm). Ohne Erfolg.
Wieso stimmt die grundlage zur berechnung nicht? Templong hat den Wert, den 1 Liter an Zeit braucht. Wenn ich 1 Sek. durch diesen Wert teile bekomme ich das richtige Ergebnis.

Ich habe eher das Gefühl, dass der Timer nicht richtig läuft.

Nein schön ist es nicht. Aber ich hab mehrere Versionen durchgetestet und nichts hat funktioniert.

[MagicWSmoke]

Das Ganze ist nur "nicht schön", sondern ein wildes Durcheinander. Wenn der Code Eingangs auf Low des Pins prüft und dann in beiden Subs nochmal, warum das, wegen Sensorprellen ? Wenn der Prellvorgang bei fallender Flanke geschieht, ist's sowieso egal, weil die LCD-Ausgabe bereits entprellt, so wie der Code angelegt ist. Sollte hingegen das Prellen bei steigender Flanke entstehen, so triggern dieses Prellen den Messvorgang, daraufhin wird in der ersten Sub auf fallende Flanke gewartet. Sobald die eintritt, wird die erste Sub verlassen und in der zweiten auf genau das Gleiche gewartet. Je nachdem durch welches Prellen die Messung usgelöst wird, gibt's 'ne längere und kürzere Periode. Außerdem muss bei abweichenden Clocks <> 1 MHz das entsprechende Calibration Byte in OSCCAL geschrieben werden, siehe Datenblatt.

[Searcher]

habe den Oszillator schon auf 2 Mhz stehen habe testweise auch 4 oder 8 versucht

$crystal ist NICHT der Oszillator!

Der $crystal Wert bestimmt nicht die µC Frequenz sondern umgekehrt. Der Wert muß auf den Wert eingestellt werden, mit dem der µC läuft. BASCOM-Help: http://avrhelp.mcselec.com/crystal_1.htm

Zum Berechnen der Durchflußmenge in Deinem Programm:

Die Timerfrequenz ist mit "Config Timer1 = Timer, Prescale = 64" auf 15625 Hz eingestellt
Ich gehe immer noch davon aus, daß der µC wegen der unveränderten Fuses mit 1Mhz läuft (1Mhz / 64 = 15625Hz)

Mit dem Oszilloskop hast Du eine Zeit von Flanke zur Flanke des Sensorsignals von 0,060 Sekunden gemessen.
In dieser Zeit sollte also der Timer vom Start bis zum Stopp 938 (937,5) Schritte gemacht haben. Es sollte also in der Auswerteroutine

in "Tempword" ein Wert von 938 stehen.

Templong = Tempword * 95                                          '(Templong = 89110)
Tempsingle = 31250 / Templong                                     '(Tempsingle = 0,35...)
Durchflusstemp = Tempsingle * 3600                              '(Durchflusstemp = 1262)
If Durchflusstemp > 200 And Durchflusstemp < 1000 Then
   Durchfluss = Durchflusstemp
end if

In Durchfluß müßte also 0 oder ein ungültiger Wert stehen, da 1262 nicht kleiner als 1000 ist.

Ohne Bedingung würde in Durchfluss also ungefähr das Doppelte von dem stehen, daß Du haben müsstest (625 Liter)
Wenn Du statt mit 31250 mit 15625 rechnest (der "echten" Timerfrequenz), kommst Du auf 631 Liter, also fast den richtigen Wert. Man merkt schon, daß das durch Meßungenauigkeit und Rundungsfehler schon nicht besonders gut ist.

Falls trozdem große Abweichungen entstehen: Du läßt ja Tempword am Display ausgeben. Was steht den da drin? Falls da zu große Differenzen auftauchen müßte man die eigentliche Messung mal genauer unter die Lupe nehmen.



PS

Der AVR zeigt mir aber irgendwas um die 910 Liter an

Ist das am Ende die Displayausgabe von Tempword und Durchfluß wird aus o.g. Gründen irgendwie nicht angezeigt

Noch ein PS:

96 Impule pro Liter,

Warum rechnest Du mit 95 ("Templong = Tempword * 95")? Mit 96 wird es genauer


Gruß
Searcher

[Felix H.]

$crystal ist NICHT der Oszillator!

hat auch niemand behauptet. Der Oszillator im AVR (Fusebits) steht auf 2Mhz wie im Programm selbst auch. Die Formel ist richtig, wie du selbst rausgefunden hast. Ok das mit den 95 stimmt natürlich. Mein Fehler.

In der Displayroutine:

If Displaywarten = 50 Then
Locate 1 , 1 : Lcd "Durchfluss:"
Locate 2 , 1 : Lcd Durchfluss ; " L/h " ; Tempword ; " "
Displaywarten = 0
End If

Lass ich mir nach L/h den Wert "Tempword" anzeigen. Der wird in

Tempword = Tempword + Tempword1

als letztes Berechnet und sollte Theoretisch den Timerwert darstellen. Auf dem Display steht aber immer nur 31 bzw. 32 egal bei welchem Durchfluss. Ich bin Ratlos...

Zudem liegt der Messfehler ja im Bereich von über 30%. So viel kann ein Oszillator doch nicht falsch gehen oder?

[Felix H.]

Wenn der Code Eingangs auf Low des Pins prüft und dann in beiden Subs nochmal, warum das, wegen Sensorprellen ? Wenn der Prellvorgang bei fallender Flanke geschieht, ist's sowieso egal, weil die LCD-Ausgabe bereits entprellt, so wie der Code angelegt ist.

Kapier ich nicht. Anfangs wird auf Low gewartet und der Timer gestartet. Danach wird auf High gewartet und nicht auf low?!? Zudem wird die LCD routine nur alle 50 Messungen aufgerufen. Weiss nicht was da dann Entprellen soll.

Sollte hingegen das Prellen bei steigender Flanke entstehen, so triggern dieses Prellen den Messvorgang, daraufhin wird in der ersten Sub auf fallende Flanke gewartet. Sobald die eintritt, wird die erste Sub verlassen und in der zweiten auf genau das Gleiche gewartet.

Ebenfalls Quark.

Je nachdem durch welches Prellen die Messung usgelöst wird, gibt's 'ne längere und kürzere Periode. Außerdem muss bei abweichenden Clocks <> 1 MHz das entsprechende Calibration Byte in OSCCAL geschrieben werden, siehe Datenblatt.

Stimmt. Aber das Signal müsste schon heftig Prellen um 30 oder 40% Fehler zu verursachen

[Sauerbruch]

Es ist aber auch ein wenig schwierig, das Konzept in dem Code zu erkennen.

Zum einen habe ich es im Simulator gerade mal getestet: Mit der Do-Loop-Schleife im Unterprogramm wird der Return-Befehl niemals erreicht. Wozu soll das denn gut sein???

Und der Sinn des Unterprogramms Wait_one erschließt sich auch nicht ohne weiteres (selbst wenn man sich die Do-Loop-Schleife wegdenkt):

Wait_one: 

Do 

If Pind.0 = 0 Then  
 Return 
End If 

Loop

Return

Das heißt doch im Klartext: Wenn PIND.0 = 0, dann folgt return - und wenn nicht, dann auch
Vielleicht stehe ich ja nur auf dem Schlauch (das ist um diese Uhrzeit manchmal der Fall) - aber ich kann beim besten Willen nicht erkennen, wozu diese Sub gut sei soll.

Du willst doch nur den Zeitabstand zwischen zwei fallenden Flanken messen. Warum legst Du das Signal nicht einfach auf einen der Interrupt-Eingänge, konfigurierst ihn auf falling, und liest in der ISR den Timerinhalt aus?

[Searcher]

Der Oszillator im AVR (Fusebits) steht auf 2Mhz wie im Programm selbst auch

Na gut.

Auf dem Display steht aber immer nur 31 bzw. 32 egal bei welchem Durchfluss

Wenn das der echte Tempword Inhalt ist, kann bei der Durchflußberechnung nichts sinnvolles herauskommen/angezeigt werden.

Um das mal zu überprüfen, könnte man nach der Zeile: "Tempword = Tempword + Tempword1"
Tempword mit dem erwarteten Wert überschreiben, also "Tempword = 1875" (bei dem 2MHz Systemtakt) und schauen, was das Display für Tempword und Durchfluss anzeigt.

Gruß
Searcher

[Felix H.]

Das heißt doch im Klartext: Wenn PIND.0 = 0, dann folgt return - und wenn nicht, dann auch

Jetzt beginne ich langsam an der Qualität dieses Forums zu zweifeln Sag mir doch bitte mal wie deiner Meinung nach ein Return erfolgen soll wenn pind.0 = 1 ist.
Statt dem Return in der If pind.0 = 0-Bedingung könnte man natürlich auch ein Exit Do einfügen. Kommt aufs gleiche raus. Es wird nur ein Return ausgeführt wenn pind.0 = 0 ist

[Sauerbruch]

Auf dem Display steht aber immer nur 31 bzw. 32 egal bei welchem Durchfluss.

Wie soll´s denn auch anders sein?

Dass etwas angezeigt wird bedeutet doch, dass das Programm bei "Gosub Auswerten" angekommen ist.
Und danach kommt "Gosub Wait_one".
Und in dieser Subroutine bleibt der Controller dank "Do-Loop" hängen - bis zum jüngsten Tag. Die erste Anzeige ist also auch die letzte.

Solange das so ist, sind alle Überlegungen zu Taktfrequenzen, Rechenwegen und allem sonstigen drum & dran müßig