Anregung zu Signalauswertung

Tag zusammen,

Ich hab folgendes Problem. Ich möchte ein Signal einer Tachowelle auswerten. Der Verlauf des Signals ist zwar etwas komisch, aber das sollte nicht das Problem sein.
Ich bekomme bei ca. 70cm Laufstrecke eines Reifens eine Pegeländerung von HIGH auf LOW. Wobei LOW nur kurz ansteht und der Pegel dann wieder HIGH ist...quasi ein Kurzer Impuls alle 70cm.
Das Problem ist dass ich im Maximalfall alle 8,3ms einen Impuls bekommen (entspricht ca. 300km/h) und im Minimalfall alle 2,52s einen Impuls bekomme (entspricht 1km/h.
Das ganze soll ausgewertet werden und 3-stellig auf einen 128x64 LCD ausgegeben werden (also wenn die Geschwindigkeit 47km/h beträgt soll 047 km/h ausgegeben werden). Das Display soll ca. alle 500ms aktualisiert werden.

Jetzt ist mein erstes Problem die Signalerfassung ohne dass mein Signal prellt.
Das zweite Problem ist dass sich mein ATMEGA32 bei höheren Geschwindkigkeiten (ca. 120km/h) aufhängt, bzw sich wieder neu startet. Ich weis nicht ob das was mit der Impulsdauer und der Ausgabezeit zu tun hat. Im Moment lasse ich einen Timer laufen, der pro 1s 10000 Überläufe liefert (ist etwas übertrieben glaub ich....aber in der Overflowroutine frage ich auch den Zustand des Eingangspins für die Pegeländerung ab und da muss die Abtastrate bei hohen Geschwindigkeiten auch so hoch sein).
Gibt es da nicht eine bessere Lösung? Bin um jeden Beitrag und Kritik dankbar.

Mfg Mel

Hi,

so etwas hatte ich auch mal vor, doch leider wieder verworfen. Wie hast Du das Signal denn an den atmega angeschlossen ? Wie sieht dein Code aus ?

Gruß BlaueLed

Ich bastel im Moment noch wie ich das beste Signal bekomme. Im Moment hab ich die Tachowelle über einen Spannungsteiler einfach an nen Pin gehängt. Wenn ich es schaffe stell ich nachher mal das oszilloskopierte Signal und Code rein.

Hallo
Löse bei einer Zustandsänderung einen Interrupt aus, dann brauchst Du nicht ständig zu "lauschen" oder leg das Signal gleich auf einen Counter.

Mit freundlichen Grüßen
Benno

Hi!

Ich denke, dass Du bei hohen Geschwindigkeiten einen Stack-Überlauf produzierst und der AVR dadurch vermeintlich neu gestartet wird. Nimm lieber den den Timer/Counter und zähl die Impulse, die anliegen. IMHO kann der mit maximal fosz / 4 getaktet werden.

Du must nur in regelmäßigen Abständen den Zählerstand auslesen und auf 0 setzen.

MfG

Markus

@ cipher

wie möchtest du mit dem timer die impulse "zählen"?

du hängst das sginal an den ICP und bekommst dann nur timerwerte und nen interrupt geliefert, ob man die zeit jetzt aus dem ICR nimmt oder in der ISR aus dem CNT register nimmt, macht jetzt nicht so unbändig viel unterschied, wenn die frequenz zu hoch wird läufst du auch da in einen stacküberlauf ....

das einzige was man noch probieren könnte, wäre einen mux vor das signal zu hängen, sodass er nur alle 8 impulse einen impuls zum controller sendet ..

udn wenn der mux hops geht wegen ner spannungsspitze, kann man den immernoch besser tauschen als den controller (wo man ein neues programm aufspielen müsste ...

am besten vor dem mux noch einen auf GND und VCC versorgten OPAMP in komparatorschaltung als level-converter einsetzen, so bleibt die elektronik länger heile)

Selbst wenn alle 8 ms ein Siganl kommt, ist das für den Controller noch eine recht lange Zeit, es sei denn man arbeitet mit weniger 32 kHz Takt.

Wenn das Signal sauber ist, also kein Prellen oder so, könnte man den externen Zähler Eingagn nutzen. Der externe Counter Eingang ist aber bei schlechtem Signal schnell unbrauchbar, denn da kann man wenige fasche Pulse nicht mal erkennen.

Der ICP Eingang bietet da deutliche Vorteile. Man mißt die Zeit für eine Umdrehung. Und kreigt dadurch besonders auch bei niedrieger Geschwindigkeit ein sehr gute Auflösung. Einige fasche Impulse kann man, wenn es sein muß, auch noch per Software aussortieren.

Eine Impulszählung in einem Timer ist bei so wenigen Impulsen nicht sinnvoll. Andererseits ist auch die maximale Impulsrate nicht sonderlich hoch.
Der Weg von Besserwessi mit der Periodendauermessung ist, auch meiner Meinung nach, der Goldene.
Wenn dein Sensor für eine Umdrehung 2,5 sek braucht, kannst Du nach 0,5sek keinen neuen Wert im Display haben.
Das geht im Idealfall bei einer Geschwindigkeit von 5km/h.
Denn erst ab da kommt auch alle 0,5sek ein Impuls vom Geber.

Eventuell kannst Du das auch so lösen, das die Displayrefreshrate zuerst vom Impuls des Gebers abhängt und dann bei höheren Geschwindigkeiten mit einem Timer auf 0,5 sek eingestellt wird.
Das kann man ja sehr schön über die Werte des Zählers, der für die Periodendauermessung zuständig ist erkennen.

Bei Zeiten über 2,5 sek sollte aber dann eine Overflow Routine zuschlagen, die dann die Geschwindigkeit auf 0 setzt.


Ich lass für solche Zwecke den Timer frei laufen und ziehe den vorherigen Zählerstand vom aktuellen ab.
Da für die Aktion mit ziemlicher Sicherheit ein Überlaufzähler verwendet wird, der in der Timer Overflow Routine hochzählt wird, ist die Benutzung des Input Capture Registers im dazugehörigen Interrupt sinnvoll.
Das hochgezählte Register des Timer Overflow Interrupts wird natürlich in die Berechnung mit einbezogen.

Ja bis jetzt hab ich die Zeit zwischen zwei Impulsen gemessen und ausgewertet. Dabei hab ich den alten Wert mit dem aktuellen verglichen und sobald der aktuelle größer ist wird das neue ergebnis mit dem aktuellen Wert verrechnet. Werde es mal mit dem ICP versuchen. Vielen Dank für eure Antworten

ich dachte es ging hier darum, dass die impulse so schnell sind dass der controller NICHT hinterherkommt ?!

aber wo ich den o-topic lese seh ich es auch grad :p
hab mich mehr an den folgenden antworten orientiert XD

Ja das war meine Anfangsfrage^^. Ich weis nicht ob die LCD- Ausgabe mit den vielen Interrupts kollidiert. Hatte auch schon überlegt zwei Prozessoren zu verwenden...einen zum Auslesen der die Daten dann weitersendet und ein 2ter
Prossesor gibt das aus aber ein AT32 mit 8 bzw. 16mhz sollte das doch schaffen oder?

naja WÄHREND einer LCD ausgabe solltest du unbedingt das tachoauslesen aussetzen, nicht dass während du den wert in einen string konvertierst der interrupt dazwischen kommt!!!

Ja genau das ist mein Problem. Denn wenn ich während der Ausgabe einen Interrupt verpasse wäre das schlecht fürs Ergebnis. Das ist ja das Hauptproblem, die Interrupts nicht zu verpassen, aber diese trotzdem für die Ausgabezeit zu unterbinden

So hab das Signal mal genau unter die Lupe genommen...jetzt weis ich woher das Prellen kommt:


Bild hier  

XDiv = 1µS
YDiv = 2V

Ich glaube ich bleibe doch bei meinem Reed-Kontakt :-D

du schaltest VOR dem schreiben die interrupts aus, die werte bleiben stabil, nach dem schreiben schaltest du wieder ein und ab dem nächsten impuls nach dem schreiben misst du wieder die zeit, bei 8ms wiederholzeit haste alle halbe sekunde mehr als genug werte gemessen um ne neue ausgabe machen zu können ... ich würd sogar auf ne aktualisierung alle 100ms runtergehn, im halbsekundentakt ist die geschwindigkeitsanzeige doch sehr träge

Ja nur es ist ja auch möglich dass nur alle 100ms ein interrupt kommt und wenn ich immer genau in diesem Moment die Displayausgabe mache verpasse ich diesen. ist jetzt sehr theoretisch aber bestimmt möglich

Das signal sieht nicht besonders gut aus. Das Prellen verhindert schon mal das man damit direkt an einen Zähleingang geht. Vermutlich sollte man aber noch einen etwas kleineren Pullup Widerstand nutzen, denn das gezeite Signal ist bei weitem kein digitales Signal, sondern zeigt noch Zwischenwerte. Irgendwie paßt das gezeigte Signal aber nicht zu einem Reed Signal. Das "Prellen" ist viel zu kurz (ca. 1 µs) und das Signal wiederhoht sich zu schnell. Bei den nur 3 µs wäre eine auswertung schon recht schwer (ginge wohl noch gerade in ASM). Wenn das wirklich von einem Reed kontakt stammt sollte die Zeitachse wohl mehr im ms Bereich.

Man kann das (langsamere machanische) Prellen wohl auch in Software berücksichtigen, denn die echten Pausen sind deutlich länger als das Prellen.

Wenn man die Auswertung ganz in den Interrupt verlegt, sollte die Ausgabe auf das LCD nicht weiter stören. Wenn man auch nur einen (veileicht mal 2) Interrupt je Puls hat, bleibt auch genug Rechenzeit für die Ausgabe übrig.

Nein das ist ja nich der Reedkontakt sondern die Welle.Aufgrund dieses Signals wollte ich ja wieder einen Reed nehmen:)

Das Bild vom osziloskop paßt einfach nicht zum Text oben. Das bild zeigt ca. 3 µs zwischen den Flanken. Durch die Überschwinger ist es schwer das signal direkt digital weiterzuverarbeiten.

Kommt das Signal von einem Hall Sensor, der ein sehr feines Zahnrad abfragt ? Sonst kann ich mir die hohe Geschwindigkeit kaum vorstellen.

Ok sry hab mich auch ein bisschen falsch ausgedrückt. Das ist das Signal im Ruhezustand des Sensors. Hatte den Sensor am INT2 angeschlossen und auf "falling" abgefragt...dabei wurde der INT jedoch immer wieder ausgelöst. Bei genauere auflösung kam dann das oben gezeigte Bild zum Vorschein, was erklärt warum ich immer wieder einen INT bekomme

hmmm ... bei dem signal würd ich erstmal dieses sauber machen ...
z.B. über Kondensatoren auf Schmitt Trigger, galvanisch entkoppeln
also und dahinter n Monoflop, damit du dann mal n sauberen
Rechteck bekommst ... dann auf nen Counter-Eingang oder
alternativ auf nen INT Eingang.
Sprich entweder Impulspause messen oder Impulse je Zeiteinheit
zählen, aber wichtig, erstmal sauberes Signal galvanisch entkoppelt.

ich muss meine aussage mit dem komparator korrigieren ... das mit dem pegel auf logiklevel reduzieren geht nur, wenn die spannungsdifferenz zwsichen deinem gedachten mittelpegepl und dem entsprechenden high oder low pegel nicht größer als 15V ist, die meisten verstärker vertragen einfach nicht mehr