Hallo zusammen, ich möchte ein PWM-Signal (28.57Hz, 2.857% Tastgrad) ausgeben, sobald ein Sensor eingeschaltet wird (siehe Abbildung). Bisher habe ich mit Arduino und Tiva C LaunchPad experimentiert. Dass Problem ist, dass die Δt Zeitspanne nicht konstant ist, bei den beiden Mikrocontrollern variieren die Δt-Werte innerhalb eines Taktzyklus, 62,5ns und 12,5ns (etwa wie oben dargestellt). Gibt es eine Möglichkeit, Δt konstant zu halten? Gibt es eine effektivere Lösung für dieses Problem (vielleicht mit analogen ICs)? Vielen Dank im Voraus.
Angehängte Dateien:
-
signal.PNG
4,4 KB -
HEKJs.png
41 KB
:
Bearbeitet durch User
Andrew P. schrieb: > Gibt es eine Möglichkeit, Δt konstant zu halten? Nein, da hatten die Herren Nyquist und Shannon was dagegen. Naja, nicht wirklich. Eigentlich hat da die Physik unseres Universums was dagegen.
Was für ein Arduino soll das sein? Bei den üblichen 16MHz sind die 62,5 ns gerade mal ein CPU Takt. Ein geringerer Jitter geht schon aufgrund der Zeitquantisierung gar nicht. Das Lauchpad hat ne ARM CPU, da gibts noch viel mehr Faktoren die das Zeitverhalten beeinflussen.
:
Bearbeitet durch User
Andreas M. schrieb: > Was für ein Arduino soll das sein? Bei den üblichen 16MHz sind die 62,5 > ns gerade mal ein CPU Takt. Ein geringerer Jitter geht schon aufgrund > der Zeitquantisierung gar nicht. Ganz genau. Falls du es nicht bemerkt hast: das in ein klassischer Traffic-Troll-Thread. Und Leute wie du sorgen dafür, dass er sich wirklich zu eine Thread entwickelt...
Das Diagramm ist arg irreführend: es suggeriert eine PWM-Frequenz von 11.6 MHz. Bei genauerer Betrachtung (und als Physik-Laie) wüsste man gerne den Grund, warum die 62.5 ns bei 28.57 Hz (entspricht 1.8 ppm) stören.
Andrew P. schrieb: > Gibt es eine Möglichkeit, Δt konstant zu halten? Gibt es eine > effektivere Lösung für dieses Problem (vielleicht mit analogen ICs)? Ja sicher. Man muss den Timer passend laden und dann den Timer mit der PWM starten. Analog muss man da gar nichts fummeln. Allerdings kann es auch da Jitter geben, denn der Intzerrupt zum Erkennen der Sensorflanke ist im Normalfall nicht ganz jitterfrei, eben weil das normale Programm ja läuft und unterschiedlich lange BEfehle bearbeitet. GGf. besitz dein Controller ein Eventsysten, wo das alles IN hardware erledigt werden kann, dann wird es besser. Aber selbst mit Jitter könne es ausreichend gut sein, denn die CPU mit sehr hohem Takt läuft. Dein Oszilloskopbild ist reichlich sinnlos, wenn man keine Zeiteinheit sieht. Als Physiker, so du denn wirklich einer bist, ein neudeutsches "FAIL".
Du möchtest den Jitter kleiner als einen CPU-Takt bekommen? Das wird schwierig ... Oder geht es um die Absolutwerte des Jitters? Dann könnte ein schnellerer uC helfen, etwa der auf dem Teensy 4 mit 600MHz ... LG, Sebastian
:
Bearbeitet durch User
Andrew P. schrieb: > Gibt es eine Möglichkeit, Δt konstant zu halten? Nimm einen schnellen µC (Tennsy 4.0 oder 4.1 müsste IMHO gehen) und programmiere ein Hardware Feedback zwischen dem steuernden GPIO und der PWM Ausgabe. Bessere moderne µC als AVR können das inzwischen - grade weil Interrupts eine variable Latenz haben.
S. L. schrieb: > Bei genauerer Betrachtung (und als Physik-Laie) wüsste man gerne den > Grund, warum die 62.5 ns bei 28.57 Hz (entspricht 1.8 ppm) stören. Vermutlich ist die Aufgabenstellung "Es muß ganz genau sein".
Andrew P. schrieb: > Gibt es eine Möglichkeit, Δt konstant zu halten? Nein. Man müsste wenigstens den Prozessortakt synchron halten mit dem möglichen Sensoreinschaltzeitpunkt, per PLL oder so, also als externen Takt einspeisen was auf einem Arduino nicht vorgesehen ist, und selbst dann stört das laufende Programm mit Befehlen die mehr als 1 Takt benötigen und nicht unterbrochen werden können > Gibt es eine > effektivere Lösung für dieses Problem Um etwas xx ns nach Start eines Signals beginnen zu lassen, muss man erst mal dieses Signal auf ns genau erfassen. Was ist der Zeitpunkt, da wo die Signalspannung 10, 50 oder 90% des Nennwertes hat ? Wie schnell steigt die Signalflanke von 10 auf 90%, in 1us oder 1ns ? Wenn man eine analoge PWM Erzeugung mit Beginn der Signalflanke startet, hat man zwar nicht das Problem, dass diese nicht taktsynchron erfolgt, weil es keinen Takt gibt, aber man hat das Problem, dass die analoge Startphase der PWM eventuell nicht nanosekundengenau nach dem Signal beginnt, sei es dass die Versorgungsspannungsabhängig ist, temperaturabhängig oder davon wie lange zuvor Ruhe war. Du müsstest also schon sagen, WIE genau der PWM Startpunkt vom Signal abhängen muss, und wenn das 10ns ist, dann könnte man das mit Digitaltechnik, z.B. einem FPGA mit 200MHz Takt hinbekommen. Ich denke allerdings, 28.5Hz und Nanosekunden passen nicht zusammen, du hast dich um Grössenordnungen vertan.
Ihr denkt mal wieder viel zu kompliziert. Kennt denn keiner mehr das Ei des Columbus? Einfach das PWM-Signal durchlaufen lassen und das Sensor-Signal damit synchronisieren. Mit ein paar Logik-ICs das PWM-Signal dann nach aussen freigeben. Der Jitter zwischen sync. Sensor und PWM sollte je nach verwendeter Logik < 1 ns betragen.
Kannst Du mal erzählen, welches Problem Du eigentlich lösen möchtest? Falls die PWM tatsächlich bei 28.57 Hz läuft brauchst Du Dir über Nanosekunden wirklich keine Gedanken machen. Selbst falls Du kHz gemeint haben solltest, kann das eigentlich kein Problem sein. Wenn das wirklich eine PWM ist, dann hängt dahinter ein Tiefpass um einen DC Pegel zu erzeugen und der ist um Größenordnungen langsamer. Oder benutzt Du die PWM-HW, um spezielle Pulsfolgen zu erzeugen?
Hallo, wenn es nur auf den zeitlichen Abstand zwischen Sensorsignal und PWM Flanke ankommt, dann geht das theoretisch ganz einfach. Praktisch sehe ich erstmal kein Problem. Sensorsignal wird per Interrupt erkannt und in diesen Interrupt wird der Timer gestartet. Weil im Interrupt nichts dazwischen funkt bleibt der zeitliche Abstand immer konstant. Der Timer wird vorher passend konfiguriert mit Hardwareausgang zum "OCRn"/"WO" Pin. Dann kann er unbekümmert und unbeeinflusst vor sich hintakten. Aber ich befürchte c-hater könnte recht haben. Ist bestimmt ein Fake Account, denn einen User "Andrew P". o.ä. gibt es schon und nicht erst sein 15.05.2023. Um das zu entkräften müßte der TO in seinem Thread aktiv mitmachen.
Veit D. schrieb: > Sensorsignal wird per Interrupt erkannt und in diesen Interrupt wird der > Timer gestartet. Weil im Interrupt nichts dazwischen funkt bleibt der > zeitliche Abstand immer konstant. Die Anzahl der CPU-Takte zwischen Interrupt und Ausführung der Interruptroutine kann je nach unterbrochenem Befehl schwanken. Außerdem möchte der TO ja sogar genauer als ein CPU-Takt sein. LG, Sebastian
an Veit Devil: Das Problem ist: das Sensorsignal trifft irgendwo innerhalb eines uC-Taktes ein, und die Reaktion (in Gestalt des PWM-Beginns) kann frühestens mit dem nächsten Takt erfolgen. Folglich haben wir prinzipiell eine Unbestimmtheit von der Dauer eines uC-Taktes. Und wie, umgekehrt, der Sensor auf den uC synchronisiert werden soll, muss uns Mi N. erstmal erklären, ohne ihn zu kennen. Es könnte sich ja auch z.B. um einen analogen Sensor handeln.
S. L. schrieb: > Das Diagramm ist arg irreführend: es suggeriert eine PWM-Frequenz von > 11.6 MHz. Ja, ich weiß. Ist nur eine grobe Darstellung, damit man vom Problem irgendeine Ahnung hat. > Bei genauerer Betrachtung (und als Physik-Laie) wüsste man gerne den > Grund, warum die 62.5 ns bei 28.57 Hz (entspricht 1.8 ppm) stören. Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss immer gleich groß sein (egal ob ns oder μs), damit sie die Messergebnisse nicht verfälscht.
Falk B. schrieb: > Dein Oszilloskopbild ist reichlich sinnlos, wenn man keine Zeiteinheit > sieht. Als Physiker, so du denn wirklich einer bist, ein neudeutsches > "FAIL". Ist nicht mal mein Oszibild, habe es irgendwo im Internet gefunden. Ist nur eine Darstellung über den Jitter. Aber hast völlig Recht, es ist echt irreführend. Sorry.
Andrew P. schrieb: > Das Signal ist Triggersignal für einen Radar. Also war deine Frage Unsinn. Du musst gar nicht vom Signal aus eine PWM starten. Du kannst das (Radarimpuls-Sende-)Signal genau so wie deine PWM von derselben Zeitbasis aus starten, und WEISST damit deren Zeitversatz.
Andrew P. schrieb: > Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss > immer gleich groß sein (egal ob ns oder μs), damit sie die > Messergebnisse nicht verfälscht. Mensch Meier, lies mal was über Netiquette!! Und fasse dein Ziel man in Zahlen! Kleiner Tipp. 0ps Jitter sind nicht möglich! Wenn man alle Register der Digitaltechnik zieht, kommt man vielleicht auf +0/-1 Takt. Und wenn der hoch genug ist (100MHz++), reicht es dann vermutlich auch praktisch aus.
:
Bearbeitet durch User
> Die Interrupt-Latenz muss immer gleich groß sein (egal ob ns oder μs)
Reicht dann nicht ein Jitter von, sagen wir, 2 ns (es wurde ein "Teensy
4 mit 600 MHz" vorgeschlagen)? Ich meine, die anschließende
PWM-Impulsfolge auf 2e-9 genau zu halten, stelle ich mir auch etwas
aufwändig vor.
Andrew P. schrieb: > Das Signal ist Triggersignal für einen Radar. Die Interrupt-Latenz muss > immer gleich groß sein (egal ob ns oder μs), damit sie die > Messergebnisse nicht verfälscht. Dann nimm einen Draht und keine getaktete Logik. Kommt dein Sensorsignal überhaupt synchronisiert zum CPU-Takt ?
Sebastian W. schrieb: > Die Anzahl der CPU-Takte zwischen Interrupt und Ausführung der > Interruptroutine kann je nach unterbrochenem Befehl schwanken. Außerdem > möchte der TO ja sogar genauer als ein CPU-Takt sein. S. L. schrieb: > Das Problem ist: das Sensorsignal trifft irgendwo innerhalb eines > uC-Taktes ein, und die Reaktion (in Gestalt des PWM-Beginns) kann > frühestens mit dem nächsten Takt erfolgen. Folglich haben wir > prinzipiell eine Unbestimmtheit von der Dauer eines uC-Taktes. > Und wie, umgekehrt, der Sensor auf den uC synchronisiert werden soll, > muss uns Mi N. erstmal erklären, ohne ihn zu kennen. Es könnte sich ja > auch z.B. um einen analogen Sensor handeln. Hallo, ja stimmt, ihr habt wie immer recht. Ich hatte völlig außer acht gelassen das die Takte unbestimmt sind wann die zugehörige ISR überhaupt aufgerufen wird. Das ist die Unbekannte in der Betrachtung. Aber da das vom TO nur theoretische Betrachtung ist und alle Bilder von ihm aus dem Internet sind, seine Hardware nicht bekannt ist, ist das für mich uninteressant geworden.
Wenn ich das Timing im Griff haben will (und es sich nicht um einen einfachen Timer handelt), dann greife ich zu einem FPGA. Und bei Radar, wo jede Zeitungenauigkeit einen direkten Fehler in die Ortsbestimmung o.ä. bringt will man das Timing komplett im Griff haben...
Andrew P. schrieb: > Bisher habe ich mit > Arduino und Tiva C LaunchPad experimentiert. Dass Problem ist, dass die > Δt Zeitspanne nicht konstant ist, bei den beiden Mikrocontrollern > variieren die Δt-Werte innerhalb eines Taktzyklus, 62,5ns und 12,5ns Wie hast du eigentlich den Δt-Jitter auf einem Atmega328P auf nur einen Taktzyklus beschränkt? Der Atmega328P hat doch gar keinen Eingang der einen Timer zurücksetzt. Was übersehe ich? LG, Sebastian
Sebastian W. schrieb: > Wie hast du eigentlich den Δt-Jitter auf einem Atmega328P auf nur einen > Taktzyklus beschränkt? [...] > Was übersehe ich? Du übersiehst genau das, was C-hater schon vor Tagen geschrieben hatte: C-hater schrieb: > Falls du es nicht bemerkt hast: das in ein klassischer > Traffic-Troll-Thread. Und Leute wie du sorgen dafür, dass er sich > wirklich zu eine Thread entwickelt...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.