BEANTWORTET: Unrealistische Werte? Fehlersuche!

Hallo, wie ich in einem anderen Thread schon mal beschrieben habe möchte ich die Umdrehungen des Laufrads meines Zwerghamsters auswerten. Dazu verwende ich einen Reed-Kontakt und einen am Rad befestigten Magneten.

Mein momentanes Projekt zählt zunächst nur die Umdrehungen mittels eines Arduino und gibt diese auf einem LCD-Display aus. (Projektbeschreibung hier)

Nun habe ich den Arduino eine Nacht lang laufen lassen und kam auf rund 23000 Umdrehungen und somit (Bei einem Radumfang von 66 cm) auf ca 15,5 Kilometer gelafene Strecke! Der Wert erscheint mir irgendwie inrealistisch hoch und ich vermute, dass in meinem Programmcode ein Fehler ist, der irgend wann die Werte unrealistisch hoch werden lässt.

Wenn ich das Rad von Hand drehe stimmt soweit vom ersten Eindruck alles: 100 Umdrehungen entsprechen z. . 66 Metern.

Wenn sich bitte mal jemand den Quellcode (siehe unten) anschauen und analysieren könnte ob es irgend wo einen Überlauf gibt, der diese sehr hogen Werte (Sowohl die Umdrehungsanzahl als auch den “Kilometerstand”) erklären könnte? 15 Kilometer in einer Nacht halte ich irgendwie für sehr unrealistisch.

Hier der Quellcode:

#include <LiquidCrystal.h>

int reedPin = 8; // PIN8 als Eingang
int resetPin = 9; // Taster zum Zurücksetzen an PIN9
int ledPin = 13; // Status-LED an PIN13
int count = 0; // Anzahl der Umdrehungen
int actualState = 0; // Aktueller Status
int lastState = 0; // Letzter Status global gespeichert
LiquidCrystal lcd(2, 3, 4, 5, 6, 7); // LCD-Display auf LCD-Shield initialisieren

void setup()
{
pinMode(reedPin, INPUT); // An PIN8 Reed-Schalter initialisieren
pinMode(ledPin, OUTPUT); // Status LED an PIN13
pinMode(resetPin, INPUT); // Zähler durch Taster an PIN9 auf Null setzen
lcd.begin(16,2); // LiquidCrystal Init: Display hat 2 Zeilen à 16 Zeichen.
}

void loop() // Hauptschleife: Anzahl der Umdrehungen, Aktueller Status und letzter Status auf LCD ausgeben
{
readReed(); // Auslesen des Reedschalters in externer Funktion
if (digitalRead(resetPin) == 1) // Checken ob Reset gedrückt wurde
{
count = 0;
lcd.clear();
}
digitalWrite(ledPin, actualState); // Anzahl der Umdrehungen und gelaufene Meter auf dem Display ausgeben
lcd.home();
lcd.print(count);
lcd.print(" Umdrehungen");
lcd.setCursor(0,1);
lcd.print(count*0.66);
lcd.print(" Meter");
}

void readReed() // Status des Reed-Schalters auslesen
{
actualState = digitalRead(reedPin);
if (actualState == 1 && lastState == 0)
{
count++;
lastState=actualState;
}
if (actualState == 0)
{
lastState=0;
}
}

Danke und Grüße

Nico

Hmm, vielleicht könntest Du noch ein paar Millisekunden sleep() in Deiner Schleife einbauen, vielleicht prellt ja der Reedschalter ein bisschen.

Ich hab auch mal im Netz geguckt, die Strecke könnte, was man so liest, je nach Hamster schon hinkommen... :o

Hmmm, die readReed()-Funktion entprellt eigentlich schon über die beden gespeicherten States lastState und actualState.

Im "Trockentest", wenn ich den Magneten von Hand am Reed-Kontakt vorbei bewege habe ich auch eine sehr stabile Zählung. Auch wenn man den Magneten dauerhaft vor den Reedkontakt hält bleibt der Zähler stehen (Hatte ohne die Entprellung in reedRead() den Fehler, dass wenn der Magnet vor dem Reed-Schalter stehen blieb der Zähler "durch die Decke ging")

Ich hatte ja erst die Vermutung dass einer der verwendeten Datentypen für die Variabeln "überläuft" aber selbst der Typ "int" geht ja bis 32768.

Glaube ich muss mich doch damit "anfreunden" dass die Werte realistisch sind. :wink:

Grüße

Nico

Nein, das ist keine Entprellung, Du zählst damit nur ansteigende Signalflanken und verhinderst damit, dass der Zähler unkontrolliert hochzählt, wenn das Rad unter dem Kontakt steht.

Dein Hamster bewegt aber nicht nur das Rad sauber und gleichmäßig am Kontakt vorbei, sondern wird das Rad durch sein Gewicht beim Laufen auch in Schwingungen versetzen (haben unsere zumindest gemacht, das Rad hat dann so "gerattert"), und ich könnte mir vorstellen, dass das alle paar Umdrehungen zu einem Sprung im Signal und damit einer Fehl-Flanke führen könnte...

Immer vorausgesetzt, Du hast nicht einfach einen Marathonhamster und fertig... :wink:

Vielleicht noch eine Beobachtung:

Bevor ich gestern abend schlafen gegangen bin habe ich den Hamster ein paar Minuten beim Lauf im Rad beobachtet. Das waren so zwischen 100 und 200 Umdrehungen die ich "live" miterlebt habe. Der Zähler hat dabei wirklich sehr zuverlässig pro Umdrehung jeweils um 1 erhöht.

Grüße

Nico

Naja, dann hast Du vermutlich wirklich einen Marathonhamster... :wink:

Wie wärs denn mit einem zweiten, etwas versetzten Sensor?
Dann könntest Du nicht nur sicher sagen, dass sich das Rad bewegt hat, sondern auch noch die Richtung bestimmen... :slight_smile:

Hatte schon mal jemand vorgeschlagen (siehe hier http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264671954/4#4)

Bevor ich sowas mache will ich erst mal das die Zählung allgemein stimmt.

Habe nochmal in einem Zwerghamster Forum nachgefragt, ob die Werte überhaupt realistisch sind. Vielleicht hat da ja jemand eine Info.

Grüße

Nico

Hatte schon mal jemand vorgeschlagen (siehe hier http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264671954/4#4)

Bevor ich sowas mache will ich erst mal das die Zählung allgemein stimmt.

Ich denke auch, dass man auf diese Weise überprüfen kann, ob die Wert stimmen.
Wenn du dem Wert nicht traust, muss du dir Gedanken machen, wie man diese Zahl verifizieren kann. Vom Forum erwartest du Vorschläge, wenn solche kommen, willst du sie aber nicht umsetzen.
Sollen wir jetzt bei dir vorbeikommen und die Umdrehungen von Hand zählen?
Ich erwarte schon auch etwas Initiative von dir. Sorry, wir sind hier kein Problemlösungsservice. Wir können dich unterstützen, aber den Rest must du machen. >:(

Vielleicht kannst du mit einem Velocomputer den Wert überprüfen. Diese arbeiten ja nach dem selben Prinzip.

Hallo Webmeister,

Vom Forum erwartest du Vorschläge, wenn solche kommen, willst du sie aber nicht umsetzen.

Es war nicht meine Absicht, dass dieser Eindruck entsteht, natürlich freue ich mich über jeden Hinweis der kommt. Ich sammle nur zu Beginn gerne erst mal verschiedene Hinweise und Eindrücke bevor ich an tatsächliche Fehlerlösung gehe.

Ich erwarte schon auch etwas Initiative von dir. Sorry, wir sind hier kein Problemlösungsservice. Wir können dich unterstützen, aber den Rest must du machen.

Auch hier: Es war nicht meine Absicht, jemanden vor den Kopf zu stoßen und ich bin etwas erstaunt, dass hier an dieser Stelle der Diskussion auf einmal die Stimmung derartig umschlägt.

Ich werde die gesammelten Infos jetzt erst mal verarbeiten, da ich sowieso erst abends wieder an dem Projekt weiterarbeiten kann. Beobachtungen und Erfahrungen werde ich dann wieder hier zur Verfügung stellen.

Nur Abschließend dazu: Ich denke halt nicht, dass das zusätzliche auswerten der Drehrichtung (durch Hinzufügen von Sensoren) die Fehlersuche einfacher macht.

Grüße

Nico

Velocomputer

Das ist doch mal ne Idee. :slight_smile:

Es war nicht meine Absicht, jemanden vor den Kopf zu stoßen

Hast du nicht. Aber mein Hinweis soll dich einfach daran erinnern, dass ein Forum nicht ein kostenloser A-Z-Service ist. Wie gesagt unterstützt dich das Forum gerne und gibt Tips und Unterstützung.

Aber dies soll nur soweit gehen, dass man mit bei seinem Problem ein Stück weiterkommt.

Vielleicht gibt es ja auch noch andere Lösungen wie man diese Impulse zählen kann. Siehe mein Tip betr. dem Velocomputer. Diese gibt es ja mittlerweile schon sehr günstig zu kaufen. Teilweise günstiger als ein Arduino-Board.

Ich denke halt nicht, dass das zusätzliche auswerten der Drehrichtung

Es ist ja nicht nur die Drehrichtung, sondern vor allem die Info ob sich das Rad wirklich gedreht hat.

Vielleicht werden da auch nur Störimpulse gezählt. Dazu gibt es eine Debounce-Bibliothek die solche Störungen oder Prellimpulse von Schaltern unterbindet.

Aber mein Hinweis soll dich einfach daran erinnern, dass ein Forum nicht ein kostenloser A-Z-Service ist.

Davon ging ich noch nie aus. Ich verstehe immer noch nicht, an welcher Stelle der Diskussion der Eindruck entstanden ist, dass ich hier eine 1000%ige Fehlerbehebung haben möchte aber egal, lassen wir das. Ich denke ich verstehe was Du damit meinst.

Siehe mein Tip betr. dem Velocomputer. Diese gibt es ja mittlerweile schon sehr günstig zu kaufen. Teilweise günstiger als ein Arduino-Board.

Siehe auch meine ursprüngliche Projektbeschreibung: Endziel ist dass die ausgewerteten Werte getwittert werden sollen. DAS kann ein Fahrradcomputer meines Wissens nach NOCH nicht. :wink:

Thread ist damit für mich beantwortet. Danke nochmals für alle Anregungen.

Grüße

Nico

Endziel ist dass die ausgewerteten Werte getwittert werden sollen. DAS kann ein Fahrradcomputer meines Wissens nach NOCH nicht.

Nein, das kann er nicht, aber das war ja auch nicht Sinn der Sache: Damit könntest Du überprüfen, ob Deine Ergebnisse Sinn machen. :wink:

Wenn Du also zufällig ein Fahrrad mit einem digitalen Tacho rumstehen hast, der mal ne Nacht nicht gebraucht wird, dann wär das ne Möglichkeit... :slight_smile:

Okay, werd noch mal nachschauen, ob ich noch einen Fahrradcomputer irgend wo auftreiben kann!

Grüße und schönen Abend

Nico

Würde den Radumfang im Tacho auf einen Meter einstellen, um genau zu sehen wieviele Umdrehungen das Rad hatte. Müsste präziser sein als mit dem echten Umfang 'rumzuhantieren... :wink:

Schönen Abend!

Also Joghurt hat völlig recht. Die "Entprellung" ist keine. --> 50ms Verzögerung sollten das zuverlässig beheben (ausser der Hamster schafft mehr als 10 Umdrehungen pro Sekunde).

Was mögliche Überläufe angeht: dann nimm halt "long int" statt "int" oder "long double" falls das auch nicht reicht empfehle ich einen Generator an das Laufrad anzuschliesse und den Hamster zur Energieerzeugung laufen zu lassen.

Gruß, Udo

P.S. Mangels Radcomputer würde ich den Nager per Video überwachen.