Hallo, jetzt ist es eh schon so heiß, und nun raucht mein Kopf nochmehr:-) wer kann mir Abkühlung in folgender Sache verschaffen: Ich habe an meinem uC (AtMega) eine Sinuswelle als Signal, aus der ich verlässlich die einzelnen Pulse herausrechnen möchte. Zunächst dachte ich an eine reine Software-version, indem ich ein paar Samples in einem bestimmten Zeitfenster miteinander vergleiche. Das Problem ist aber, dass der Frequenzbereich nicht immer gleich ist. Besser gesagt: innerhalb einer "Messperiode" schon, aber es gibt unterschiedliche Signale, die untersucht werden sollen. Manche bewegen sich im 100Hz-Bereich, manche im höheren KHz-Bereich. Die Samplerate meines linearen Inputs ist max. 615KHz. Wenn ich die Welle ganz grob (mit 6 Samples) auflöse, könnte ich immerhin bis zu 100Hz analysieren. (Welchen Raster braucht es wirklich für ein verlässliches Ergebnis??) Der Vorteil der Softwarelösung wäre, dass mir die Grundparameter der unterschiedlichen Wellen vorab jeweils bekannt sind, ich könnte die Pulsberechnung also anpassen. Der Haken ist aber, dass die Software bei hohen Geschwindigkeiten nicht mehr mitkommt (ein Loop dauert schon etwas länger als die theoretische Samplerate am Analogeingang!). Ich dachte also an den Einsatz eines Interrupts, den der AtMega bietet. Der Haken dabei wiederum: Ich bräuchte das Signal digital aufbereitet. Dies wäre ja mit einem Schmitt-Trigger möglich. Allerdings ist der wiederum, soweit ich weiss, auf einen bestimmten Frequenzgang beschränkt. Wer kann mir Tipps geben, in welcher Richtung ich mich hier orientieren sollte? Gibt es vielleicht so etwas wie einen "programmierbaren Schmitt-Trigger" oder einen mit Referenz-Signal-Eingängen (einen für Vref und einmal Vin relativ zur zu untersuchenden Frequenz)? Ich fantasiere mal so dahin;-) Meine Wellen haben folgende Charakteristiken: 0-5V, Amplitude steigt mit höherer Frequenz, d.h. im Bereich von 100Hz habe ich nur 0-20mV, bei hohen Frequenzen den vollen Umfang von 5V. Danke!
Wenn ich das richtig verstanden habe, willst du die Frequenz bestimmen, oder?! - Wenn du am Eingang einen Schmitt-Trigger schaltest, dann könntest du aus dem Sinus ein Rechteck-Signal machen und mit den Timern arbeiten. Ein Timer zählt hoch, bis eine Sekunde erreicht ist und der zweite zählt immer dann hoch, wenn er eine steigende (wahlweise fallende) Taktflanke am Pin erhält. Such mal hier nach "Frequenzzähler Atmega" (ich meine, es war ein ATMega8)
Ja, das hast du richtig verstanden. Das Problem ist aber, der Schmitt-Trigger nur eine bestimmte Frequenz/Amplitude verarbeiten kann. Oder liege ich da falsch? Ich bräuchte eben eine Möglichkeit, die mit unterschiedlichen Frequenzen/Amplituden zurecht kommt... ChiefEinherjar schrieb: > Wenn ich das richtig verstanden habe, willst du die Frequenz bestimmen, > oder?! - Wenn du am Eingang einen Schmitt-Trigger schaltest, dann > könntest du aus dem Sinus ein Rechteck-Signal machen und mit den Timern > arbeiten.
Dann nimm doch einen Präzisions-Schmitt-Trigger, den kannst Du einstellen. Zwei Komps und ein FF und variable Spannung die Du z.B. auch via PWM mit Tiefpass dynamisch erzeugen kannst.
Da du das Signal (mir) nicht erklären kannst, hilft vielleicht eine Grafik. Sonst wär's kein Helfen, sondern Raten und Stochern.
Jan schrieb: > Das Problem ist aber, der Schmitt-Trigger nur eine bestimmte > Frequenz/Amplitude verarbeiten kann. Ein Schmitt-Trigger weiß von Frequenzen überhaupt nichts, es sei denn, er ist so schnarch langsam, dass er bei der Signalfrequenz nicht mehr richtig arbeitet.
Du hast ja geschrieben, dass die mindeste Amplitude bei ca. 20mV liegt... Mit einem entsprechenden OPV (R2R, mit kleinem Offset) sollte sich das wohl machen lassen... Es reicht ja, dass die Flanken gezählt werden - das Tastverhältnis ist für eine reine Frequenzzählung (weitestgehend) irrelevant. Mit einer AGC (Automatic Gain Control) ließe sich sogar das Eingangssignal um ein gewisses Maß verstärken um dann einen Schmitt-Trigger mit festen Schwellen verwenden zu können...
Nachtrag - die Hitze brät mir so langsam das Hirn weg...: Vergiss die AGC; verstärk das Signal doch einfach um beispielsweise Faktor 100 - die Signalform ist ja völlig irrelevant... Daraus ergibt sich automatisch ein Rechtecksignal, welches du auswerten kannst. Ob du das nun mit nem OPV oder Transistor(en) machst ist erstmal egal.
Hans H. schrieb: > Der Haken ist aber, dass die Software bei > hohen Geschwindigkeiten nicht mehr mitkommt (ein Loop dauert schon etwas > länger als die theoretische Samplerate am Analogeingang!). > Ich dachte also an den Einsatz eines Interrupts, den der AtMega bietet. Genau. Für Frequenzmessungen gibt es den Capture Interrupt des Timers. Auf steigende oder fallende Flanke einstellen und der Capture sagt dir, wie viel Zeit zwischen zwei Flanken vergangen ist.
Hört sich nach Rundsteuersignal an...?! Mit der Vorverstärkung müsstest du dann natürlich etwas vorsichtig sein, um nicht die ausgefilterten 50 Hz wieder reinzubekommen.
Wäre es ein Rundsteuersignal, hätte der TO von einem "Rundsteuersignal" gesprochen. Etwa in der Art: "Hey Leute, ich muss ein Rundsteuersignal auswerten. Das Signal liegt aber blöd - mit nur geringer Amplitude - auf der Netzhalbwelle. Was kann ich tun, um dieses Signal sicher auszuwerten?" Hatta abba nich
http://www.rundsteuerung.de/html/frequenzen.html Müsste man mitm Görtzelfilter oder einer Schnellen FFT messen/auswerten.
Axel R. schrieb: > Wäre es ein Rundsteuersignal, hätte der TO von einem > "Rundsteuersignal" gesprochen. Meine Erfahrung ist, viele TOs sprechen von einer "Sinuswelle als Signal, aus der ich verlässlich die einzelnen Pulse herausrechnen möchte" und meinen ein Rundsteuersignal ;-) Nachfragen wird wohl noch erlaubt sein.
:
Bearbeitet durch User
Ok,ok, ihr habt Recht, es dürfte sich also um ein Rundsteuersignal handeln. In der angehängten Datei finden sich Beispielwerte, die genau von einem Wellenberg bis zum nächsten reichen. Der obere Wert von 490 entspricht dabei 1226mV, der untere Wert (206) entspricht 428mV. Die Wellenberge entsprechen einer Frequenz von 160Hz, also 160 Wellenberge/Min. Wie würdet ihr aufgrund dieser Charakteristik ansetzen? Einfache Verstärkung gibt in diesem Fall ja kein verlässliches Signal, oder? Joe F. schrieb: > Axel R. schrieb: >> Wäre es ein Rundsteuersignal, hätte der TO von einem >> "Rundsteuersignal" gesprochen. > > Meine Erfahrung ist, viele TOs sprechen von einer "Sinuswelle als > Signal, aus der ich verlässlich die einzelnen Pulse herausrechnen > möchte" und meinen ein Rundsteuersignal ;-) > > Nachfragen wird wohl noch erlaubt sein.
>Die Wellenberge entsprechen einer Frequenz von 160Hz, >also 160 Wellenberge/Min. Echt?
Naja, ich habs nur dazu gesagt, um sicher zu gehen, dass ich nicht die Frequenz der Halbwelle meine, weil ich ja zuvor nicht den Unterschied zwischen Rundsteuersignal und Sinuswelle gecheckt habe;-) frequenz schrieb: >>Die Wellenberge entsprechen einer Frequenz von 160Hz, >>also 160 Wellenberge/Min. > > Echt?
Hans H. schrieb: > Einfache Verstärkung gibt in diesem Fall ja kein verlässliches Signal, > oder? Ich sehe da kräftige Sprünge von mehreren hundert mV. Was möchtet du denn überhaupt von dem Signal wissen?
Hans H. schrieb: > Ok,ok, ihr habt Recht, es dürfte sich also um ein Rundsteuersignal > handeln. Warum schreibst du das dann nicht gleich (und idealerweise auch gleich noch, welche Signalfrequenz verwendet wird)? > Die Wellenberge entsprechen einer Frequenz von 160Hz, > also 160 Wellenberge/Min. OMG. 160Hz sind nicht 160 Wellenberge pro Minute, sondern 160 Wellenberge pro Sekunde. Habe sie dir in der Baumschule (eine andere kann es ja wohl nach Lage der Dinge kaum gewesen sein) denn überhaupt nichts beigebracht? Wie auch immer, 50Hz und 160Hz lassen sich jedenfall nur relativ schwer voneinander trennen. Am aussichtsreichsten dürfte ein sehr gutes digitales Notch-Filter für die 50 Hz sein (das läßt sich dann auch für andere Signalfrequenzen wiederverwenden) und zusätzlich ein (weniger kritisches) Peak-Filter für die Signalfrequenz. Bist du in der Lage, digitale Filter zu designen? Wenn ja, dann tue es einfach, wenn nicht, dann lerne es. Aber vorher bitte erstmal das Einheitensystem, sonst wird das mit Sicherheit nix...
c-hater schrieb: > OMG. 160Hz sind nicht 160 Wellenberge pro Minute, sondern 160 > Wellenberge pro Sekunde. Habe sie dir in der Baumschule (eine andere > kann es ja wohl nach Lage der Dinge kaum gewesen sein) denn überhaupt > nichts beigebracht? Spreche ihn doch einfach an, wenn du morgen in die Klasse kommst.
hallo Wolfgang, danke für die nette Grafik:-) Ich möchte aus dem Signal (es sind tatsächlich 160Hz also Schwingungen/s)vom uController die einzelnen Peaks verlässlich herausrechnen lassen. Bei dieser Geschwindigkeit dürfte das alleine softwaremäßig machbar sein, bei höheren Geschwindigkeiten sehe ich da allerdings ein Problem (siehe Top-Posting). Ich dachte daran, bei höheren Geschwindigkeiten einen Interrupt zu verwenden, doch dieser braucht ein HIGH/LOW - Signal. Ich müsste meines also irgendwie aufbereiten. Das Problem: Die Aufbereitung muss sich per Software an die Gegebenheiten anpassen können, um auf zur jeweilig zu analysierende Frequenz/Amplitude zu passen. Wie gesagt: Amplitude ist bei manchen Signalen nur wenige mV, manchmal bis zu 5V, Frequenz zw. 100Hz und einigen kHz... Wolfgang schrieb: > Hans H. schrieb: >> Einfache Verstärkung gibt in diesem Fall ja kein verlässliches Signal, >> oder? > > Ich sehe da kräftige Sprünge von mehreren hundert mV. Was möchtet du > denn überhaupt von dem Signal wissen?
Hallo, danke für die Idee. Mein Problem: Es handelt sich wie ich belehrt wurde, um ein Rundsteuersignal, und es dürfte also nicht einfach verstärkbar sein wie eine Sinuswelle, weil ja der untere Wert mitverstärkt werden würde, da es keinen verlässlichen Nulldurchgang gibt. Wie kann ich vielleicht dennoch verstärken, bzw. womit?? ChiefEinherjar schrieb: > Nachtrag - die Hitze brät mir so langsam das Hirn weg...: Vergiss die > AGC; verstärk das Signal doch einfach um beispielsweise Faktor 100 - die > Signalform ist ja völlig irrelevant... Daraus ergibt sich automatisch > ein Rechtecksignal, welches du auswerten kannst. Ob du das nun mit nem > OPV oder Transistor(en) machst ist erstmal egal.
Hans H. schrieb: > Es handelt sich wie ich belehrt > wurde, um ein Rundsteuersignal Das war eine Vermutung und Frage von mir. Ein Rundsteuersignal ist ein auf die Netzspannung aufmoduliertes Steuersignal. Darum handelt es sich wohl doch nicht, deinen Angaben nach zu urteilen. Ich kann in deinem Signal keinen Sinus erkennen. Es scheint eine Art Rechteck mit 160 Hz + Überlagerung eines Rechteckes mit 2*160=320 Hz und eines weiteren Rechteckes mit 16*160=2560 Hz zu sein. Wo kommt denn das Signal her?
Beschreib mal dein Setup Klingt ja recht interssant... Immer wieder FFT drüber und über die Zeit das Auftreten der einzelnen frequenzanteile zum Telegramm zurück basteln.
Uff, das klingt kompliziert:-(. Wie liest du denn eigentlich die Frequenzen aus meinen Werten heraus? Ist das Intuition, oder gibts da ein Tool dafür? Ich beschreibe mal mein Setup: Das Signal kommt vom sog. "SLA"-Pin dieses Schrittmotor-Treibers: https://www.pololu.com/product/2970 Im Anhang befindet sich das Datenblatt des Treibers und eine weitere Datei mit Anmerkungen zur Handhabung und Charakteristik dieses SLA-Signals. Es gibt hier auch einen Screenshot einer Oszilloskop-Messung des Signals. Mein Signal-Beispiel entstand am Treiber bei einer Step-Frequenz von 640Hz, bei 2-fach Microstepping-Modus. Ich denke, das 160Hz - Signal müsste die Vollschritte, und das 320Hz-Signal die Microsteps darstellen. Mir geht es darum, verlässlich die Vollschritte herauszurechnen (was ja der Sinn dieses SLA-Ausgangs ist)... Joe F. schrieb: > Ich kann in deinem Signal keinen Sinus erkennen. > Es scheint eine Art Rechteck mit 160 Hz + Überlagerung eines Rechteckes > mit 2*160=320 Hz und eines weiteren Rechteckes mit 16*160=2560 Hz zu > sein.
Es sieht so aus, als ob dein Controller den "transparent mode" für SLA eingeschaltet hat. Versuche mal, eine Messung zu machen, wenn der transparent mode ausgeschaltet ist. <SLAT> bit auf 0 setzen. (bit 4, Register CR2 (03h) AMIS−30543-D.pdf S.34/35 Evtl. sieht das Signal dann wesentlich brauchbarer aus. Hans H. schrieb: > Wie liest du denn eigentlich die > Frequenzen aus meinen Werten heraus? Ist das Intuition, oder gibts da > ein Tool dafür? Die Angabe, dass die Grundfrequenz 160Hz ist, kommt ja von dir. Und dann siehst du Sprünge im Abstand von 1/4 (nicht 1/2, wie ich ursprünglich behauptete...) und 1/16 der Wellenlänge...
:
Bearbeitet durch User
hallo, > Versuche mal, eine Messung zu machen, wenn der transparent mode > ausgeschaltet ist. > ist transparency war eigentlich ausgeschaltet. ich habe jetzt nochmal eine Messung gemacht und die gesamten werte einer 1/10s als Datei angehängt- einmal mit transparency on, einmal mit off. > Die Angabe, dass die Grundfrequenz 160Hz ist, kommt ja von dir. > Und dann siehst du Sprünge im Abstand von 1/4 (nicht 1/2, wie ich > ursprünglich behauptete...) und 1/16 der Wellenlänge... also ich tu mir da mit freiem Auge schwer, die Regelmäßigkeiten zu erkennen, außer natürlich die Grundfrequenz;-). siehst du da jetzt einen großen Unterschied zwischen transparency-on bzw -off?
:
Bearbeitet durch User
Du könntest uns noch den kleinen Service liefern, deine Rohdaten in anschauliche Plots zu übersetzten, das ist mit Excel oder OpenOffice auch gar nicht so furchtbar schwer... Die Messreihen sehen tatsächlich nicht besonders verschieden aus. Die Frage wäre natürlich, hat das Setzen bzw. Löschen des Bits auch wirklich funktioniert... Anyhow, das ist jetzt das Signal bei ca. 160 Hz. Wie sieht das denn bei der langsamsten und bei der schnellsten Drehgeschwindigkeit aus? Momentan würde ich vorschlagen, triggere auf die stark abfallende Flanke, also immer wenn neuer-ADC-Wert < (vorheriger-ADC-Wert - threshold) ist. Bei 160 Hz wäre eine sinnvolle Threshold so bei 50-70. Da die Amplitude des Signals aber vermutlich drehzahlabhängig ist, müsste man sich das mal angucken, und die Threshold entsprechend dynamisch der Amplitude anpassen. Irgendwas stimmt auch mit deiner Frequenzberechnung nicht. Wenn du sagst, das waren 0.1s, und es passen ca. 8 Wellen rein, dann sind das 80 Hz und nicht 160 Hz. Die Samplerate müsste dann ca 8.88 KHz gewesen sein, wenn in 0.1s 888 Messwerte zustande kommen. Stimmt das?
:
Bearbeitet durch User
Bin ich jetzt im falschen Thread? eben war noch von Rundsteuersignalen die Rede... Jetzt ists der Back-EMF-Pin vom Schrittmotortreiber. Bin raus - viel Spaß noch.
Danke für deine Expertise, Joe. Das Problem ist, das das Verhalten dieses Signals eigentlich je nach Frequenz sehr unterschiedlich ist - nicht nur durch in Form der geänderten Amplitude, sondern auch, ob es hinauf oder hinunter geht. Die einzige Gemeinsamkeit scheint mir, dass es bei jedem Puls, den ich herausfiltern möchte, eine Treppenhafte Änderung gibt. Manchmal allerdings nach oben, und manchmal nach unten, und in der Amplitude unterschiedlich stark. Ich habe jetzt mal 4 Beispielwellen in eine Grafik gepackt. Der Ausschnitt bildet wieder eine 1/10 Sek. ab, bei folgenden Frequenzen: Welle | Microstep- | Micro- | Vollschritt- | Steps pro 1/10-Sek. | Frequenz | stepping | Frequenz | -------------------------------------------------------------------- | | | | A | 2560Hz | 16-fach | 160Hz | 16 B | 2560Hz | 4-fach | 640Hz | 64 c | 640Hz | 16-fach | 40Hz | 4 D | 640Hz | 4-fach | 160Hz | 16 zusätzlich habe ich noch zum Vergleich die Welle "E"(dunkelrot) hinzugefügt. Sie entstand mit gleichen Parametern wie Welle "A" (blau), allerdings bei blockiertem Motorschaft. Bei Welle A wäre also z.B. das gewünschte Ergebnis, das ich zurückgeliefert bekommen möchte "16", bei Welle E sollte der Zähler "0" ergeben. Das könnte ich mir auch noch vorstellen zu unterscheiden, aber wenn ich mir dann Welle E und Welle C vergleiche?? Welle C sollte ja "4" zurückliefern, E aber "0", und die sehen sich in der Abfall- bzw. Anstiegscharakteristik aber verdammt ähnlich! Damit komme ich wieder ganz zum Anfang meiner Frage zurück (wobei ich inzwischen auch einiges dazugelernt habe;-). Was bleibt ist die Frage, welche art von Mechanismus zum Triggern solch unterschiedlicher Wellen in der Lage ist. Ich fürchte, für eine reine Software-Lösung ist mein 16MHz - Controller, wenn ich dan noch andere Aufgaben im loop habe, nur beschränkt in der Lage, oder? Eine reine Hardware-Lösung, also z.B. Signal Verstärken und am Interrupt-Pin triggern lassen, schaut aber auch nicht einfach aus bei den unterschiedlichen Signalen. Die Signale dürften aber so korrekt sein, wenn man sie mit der SLA-Anleitung on Onsemi vergleicht, oder was meinst Du? Um ein sinnvolles Ergebnis zu bekommen, dürfte ich dem Zähler das Triggern nur erlauben, wenn sich der Treiber gerade in der Vollschritt-Position der Microstep-Tabelle befindet. Das würde auch zusätzlich Rechenzeit sparen. Aber wie triggere ich diesen Zustand? Ich muss dann vielleicht die Frequenz selbst weniger oft analysieren, also nicht bei jedem Microstep, aber dafür muss ich die Microstep-Tabelle "im Auge behalten". Ich hoffe, mein Gedankengang ist nicht allzu doof, ich hab sowas halt noch nie gemacht und hoffe, dass es für so etwas vielleicht schon Ansätze gibt, die erprobt bzw zu Ende gedacht sind, von denen ich lernen könnte, wie man so etwas macht... Danke, danke, danke! Joe F. schrieb: > Da die Amplitude des Signals aber vermutlich drehzahlabhängig ist, > müsste man sich das mal angucken, und die Threshold entsprechend > dynamisch der Amplitude anpassen.
:
Bearbeitet durch User
Also ich sehe ja momentan nicht wirklich, wie man aus diesem Signal die einzelnen Steps extrahieren will. Letztlich ist das Back EMF Signal ja ein Geschwindigkeitsindikator. Daher ist der Wert auch sehr niedrig, wenn du die Welle blockierst. Die Information, wie viele Steps dein Controller machen soll, hat ja dein Mikrocontroller sowieso (er steuert ja den Motor). Insofern würde es glaube ich Sinn machen, die Positionsbestimmung aus diesen Daten zu machen, und mit der Back EMF Information lediglich zu überprüfen, ob die Geschwindigkeit des Motors im erwarteten Bereich liegt. Da deine Daten immer danach aussehen, dass bei jedem Microstep gesampled wurde, gehe ich davon aus, dass das <SLAT> bit immer auf 1 gesetzt ist. Vielleicht versuchst du als erstes mal, nachdem du Register 0x03 beschrieben hast, es auch wieder auszulesen, um zu prüfen, ob sich das Bit wie gewünscht geändert hat. Mit <SLAT> = 0 sollten die Daten wesentlich weniger aufgeregt tanzen... Hast du vor den ADC eigentlich einen Tiefpass gesetzt? Wenn ja, mit welcher Zeitkonstante (bzw. Widerstands + Kapazitätswert)? Alternative: Absolute Rotary Encoder an die Motorwelle setzen.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.