- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: Durchflusssensor auswerten

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    34
    Beiträge
    240
    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.

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    01.10.2009
    Beiträge
    437
    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.

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    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.

    Code:
    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
    Geändert von Searcher (20.10.2012 um 08:39 Uhr)
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  4. #4
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    34
    Beiträge
    240
    $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?

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    34
    Beiträge
    240
    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

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    706
    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):

    Code:
    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?
    Geändert von Sauerbruch (20.10.2012 um 11:14 Uhr)

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    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
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  8. #8
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    34
    Beiträge
    240
    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

  9. #9
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    19.02.2008
    Ort
    Pohlheim
    Alter
    34
    Beiträge
    240
    So, hab jetz die 1875 gesetzt. Resultierender Durchfluss = 631L/h. Auf dem Display erscheinen nun auch die 1875 für Tempword.

  10. #10
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    706
    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

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Frequenzen auswerten mit dem RP6
    Von hmellermann im Forum Robby RP6
    Antworten: 4
    Letzter Beitrag: 25.08.2008, 09:31
  2. AVR Butterfly PKW-Verbrauchsmessung mittels Durchflusssensor
    Von Beginner85 im Forum C - Programmierung (GCC u.a.)
    Antworten: 6
    Letzter Beitrag: 13.05.2008, 20:28
  3. PWM auswerten
    Von The Man im Forum Assembler-Programmierung
    Antworten: 3
    Letzter Beitrag: 08.06.2007, 13:46
  4. PWM auswerten
    Von The Man im Forum Elektronik
    Antworten: 3
    Letzter Beitrag: 07.06.2007, 16:36
  5. Fernsteuerungssignale auswerten
    Von Ringo im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 17.09.2006, 18:17

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests