Guten Abend alle Mann, da ich basierend auf einem externen Triggersignal eine phasen- und frequenzgleichen Sinuschwingung erzeugen soll, nun jedoch mit der Phasenverschiebung nicht zurech komme wende ich mich mal an euch. Bisher funktioniert das ganze ganz gut. Zwischen den externen Triggersignalen wird der Takt mittels counter gezählt. des Ergebnis fließt als Divisor in eine Division ein. Hierbei gillt der Wertebereich der genutzten Sinustabelle als Dividend. Das ergebnis dient mir als Schrittweite für die Sinustabelle. Funktioniert einwandfrei. Die Berechnunsdauer der Division fällt hierbei auch nicht ins Gewicht. Jedoch bekomme ich die Phase der Schwingung nicht an das Triggersignal angepasst. Starte ich die Tabelle bei jedem Trigger neu kommt es zu kleinen periodischen Sprüngen im Sinus. Messe ich über einen Counter die vergangenen Clockzyklen zwischen dem Eingangstrigger und dem generierten Trigger der Sinusschwingung liefert mir dies ein Anhaltspunkt über die Phasenverschiebung. Beim korrigieren des Tabellenwertes um die entsprechende schrittweite kommt es aber immer wieder zu starken sprüngen, das Signal ist weider nicht sauber. Habt ihr hierzu vllt. noch eine Idee oder Denkanstöße? Alle Werte über ein Shiftregister zu werfen wäre mit sicherheit nicht die Ressourcenschonendste Version.. Dem Anhang liegt mein bisheriges Simulationsergebnis bei. Hier sind die erzeugte Schwingung, beide Trigger (extern wie intern) der Zählwert zwischen den externen Triggern und die daraus berechnete neue Schrittweite für die Sinustabelle dargestellt. Besten Gruß
Ich bin nicht sicher, ob Ich verstanden habe, was Du überhaupt möchtest. Was soll das sein, eine frequenz und phasengleiche Schwingung? "gleich" wozu? Willst du ein Rechteck in einen Sinus verwandeln?
Nicht ganz, wir haben lediglich einen Impuls am Eingang anliegen, welcher in seiner Frequenz variable ist und kleinerem Schwankungen unterliegt. Zu diesem Eingangssignal soll nun eine entsprechende Sinusschwingung generiert werden. Genau so schnell und immer in Phase mit dem Eingangssignal. Die automatische Anpassung an die geschwindigkeit der Schwingng habe ich ja bereits realisiert. Nur bei der Phasengleichheit komme ich einfach nicht weiter. Gruß
Stephan K. schrieb: > Nicht ganz, wir haben lediglich einen Impuls am Eingang anliegen, > welcher in seiner Frequenz variable ist und kleinerem Schwankungen > unterliegt. Weil das signal jittert, weißt du nicht, wann der nächste Triggerimpuls kommt. Du kannst deshalb eigentlich prinzipiell nicht "phasengleich" sein. > Nur bei der Phasengleichheit komme ich einfach nicht weiter. Woran kann man diese "Ungleichheit"in deinem Screenshot sehen? An den den Signalen "trigger" und "internal trigger"? Müssten die aufeinander liegen? Falls ja, warum verschiebst du nicht einfach deinen "internal trigger" bis zum folgenden "trigger"? > Die automatische Anpassung an die geschwindigkeit der Schwingng habe ich > ja bereits realisiert. Dort liegt auch das Problem: du passt die Geschwindigkeit sprunghaft an (und hast dort schon jeweils beim abrupten Übergang der "calculated stepwidth" einen Phasensprung). Hier müsste eine langsamere Nachregelung der Frequenz erfolgen. Solange, bis der Phasenversatz wieder 0 ist.
Eigentlich ist es nur möglich, die Periode von mal zu mal zu messen und
dann exakt alles zu berechnen. Aber dann ist man immer eine Perioden
hintendran. Wozu soll das eigentlich gut sein?
Warum wird der Wert nicht vorgeladen und dann einfach ausgelöst?
Woher kommen die Trigger?
>Getrigerte
schreibt sich glaube Ich mit zwei "G"s :-)
Lothar M. schrieb: > Weil das signal jittert [...] prinzipiell nicht "phasengleich" Das ist korrekt, darüber hatte ich gerstern auch noch was recherchiert. Aber ich kann das erzeugte Signal möglichst dem Jjitterbehaftete Signal nachführen, soweit ich es verstanden habe. Lothar M. schrieb: > Woran kann man diese "Ungleichheit"in deinem Screenshot sehen? Genau, der extern anliegende Trigger ist als eingang deklariert, wohingegen der interne trigger durch den Nulldurchgang der Sinusschwingung erzeugt wird. Da es sich hierbei um einen Sinus mit Offset handelt liegt der "Nulldurchgang" bei [math] \fract{2^n}{2} [\math] Lothar M. schrieb: > Müssten die aufeinander > liegen? Falls ja, warum verschiebst du nicht einfach deinen "internal > trigger" bis zum folgenden "trigger"? Wie ist das mit dem einfachen verschieben gemeint? Immerhin ist der interne Trigger ja an die Sinustabelle gebunden. ich müsste also weider die Schrittweite ändern, bzw. an den Zählwert/Index für die Sinustabelle. Lothar M. schrieb: > Dort liegt auch das Problem: du passt die Geschwindigkeit sprunghaft an > (und hast dort schon jeweils beim abrupten Übergang der "calculated > stepwidth" einen Phasensprung). Hier müsste eine langsamere Nachregelung > der Frequenz erfolgen. Solange, bis der Phasenversatz wieder 0 ist. Also über Signalvergleiche und eine FSM solange die Schrittweite nach oben, bzw. nach unten korrigieren, bis das zwei Bedingungen erfüllt sind: 1.: Frequenzgleich, sprich der Wert triggerrange = 0 (idealfall). 2.: Phasengleich, sprich der Wert calculated shiftclk = 0 (idealfall). Ich denke hier wäre am sinvollsten eine dynaisch anpassung zu realisieren, sodass bei große, versatz etwas stärker geregelt wird.
WS schrieb: > Eigentlich ist es nur möglich, die Periode von mal zu mal zu messen und > dann exakt alles zu berechnen. So wird es zur Zeit ja gemacht, wie Lothar schon schrieb passiert hier die Anpassung jedoch sprunghaft. WS schrieb: >Aber dann ist man immer eine Perioden hintendran. Wozu soll das eigentlich gut sein? Leider wahr. Wir möchten ein moduliertes aperiodisches Signal mit einem Lockinverstärker (realisiert auf einem FPGA) filtern. Dies geht nur mit einer Phasengleichen Referenzschwingung zum modulierten Signal. Da dieses jedoch aperiodisch ist bleibt uns nur die Schwingung zu betrachten, die zur Modulation des Messsignals Verwendet wurde. Diese gibt periodisch ein Triggersignal ab, welches wir für die generierte Referenzschwingun verwenden wollen. WS schrieb: > Warum wird der Wert nicht vorgeladen und dann einfach ausgelöst? Aufgrund des Jitters habe ich dann immer wieder Sprünge in der erzeugten Schwinung und damit Fehler in meinem Messergebnis. WS schrieb: > schreibt sich glaube Ich mit zwei "G"s :-) =) ups, danke!!
Wenn man ein wenig Zeit zum Nachregeln hat (Einige zig Perioden) könnte man evtl eine PLL benutzen.
Stephan K. schrieb: > bleibt uns nur die Schwingung zu > betrachten, die zur Modulation des Messsignals Verwendet wurde. das ist der Normalfall bei deiner Anwendung. Stephan K. schrieb: > Aufgrund des Jitters habe ich dann immer wieder Sprünge in der erzeugten > Schwinung und damit Fehler in meinem Messergebnis. Lass mich versuchen, das zu vestehen. Glaubst du wirklich, dass die Modulation deines Messsignals verjittert ist und willst versuchen, diesen Jitter eins zu eins auf dem Lock-In nachzubauen? Dann wäre dein aktueller Ansatz richtig, und man kann sich Gedanken machen, wie der Regelkreis zum Ausregeln der Phasendifferenz gestaltet werden muss, damit man der Störung durch das Jittern schnell genug folgen kann. Dann würde mich aber ehrlich gesagt interessieren, was für eine Quelle dein Modulationssignal ist und woher der Jitter tatsächlich kommt. Es klingt für mich ein wenig nach Funktionsgenerator nach DDS-Prinzip. Zu dem muss man wissen, dass dessen Triggersignal funktionsbedingt immer um einen internen Taktzyklus hin und her Jittern kann. (typisch ein paar ns). Der erzeugte Sinus, den du wahrscheinlich zur Modulation einsetzt, hat diesen Jitter allerdings nicht (zumindest nicht, wenn der Hersteller des Funktionsgenerators die Ausgangsfilter richtig designed hat). In dem Fall wäre es kontraproduktiv, dem Jitter mit dem Lock-In möglichst schnell folgen zu wollen. Besser wäre es, die PLL möglichst gemütlich nachzuregeln, so dass sie immer die mittlere Frequenz und Phase abgibt - auch wenn der externe Trigger mal ein Stück vor und zurück springt. WS schrieb: > Getrigerte > schreibt sich glaube Ich mit zwei "G"s :-) Na ja, eigentlich mit einem "G" und zwei "g" :-)
Achim S. schrieb: > Glaubst du wirklich, dass die Modulation deines Messsignals verjittert > ist und willst versuchen, diesen Jitter eins zu eins auf dem Lock-In > nachzubauen? Das die Modulation verjittert ist glaube ich nicht. Viel mehr glaube ich,dass der interne Taktzyklus eben wie gesagt um einige ns jittert. Achim S. schrieb: > Dann würde mich aber ehrlich gesagt interessieren, was für eine Quelle > dein Modulationssignal ist und woher der Jitter tatsächlich kommt. Der externe Trigger kommt von einem Signalgenerator der eine optischne Linse anregt dies osziliert daraufhin und erzeugt mit einem Laserstrahl unsere Trägerschwingung aufgrund des Abstandes zwischen der Linse und einem zu messenden Objekt wird das vom Messobjekt reflektierte Licht durch eine Photodiode erfasst. Somit ist das Messsignal Abstandsmoduliert und einzige referenz bildet das Triggersignal, welches ebenfalls für die Anregung der Lins zuständig ist. Achim S. schrieb: > klingt für mich ein wenig nach Funktionsgenerator nach DDS-Prinzip. > Besser wäre es, die PLL möglichst gemütlich nachzuregeln, so dass sie > immer die mittlere Frequenz und Phase abgibt - auch wenn der externe > Trigger mal ein Stück vor und zurück springt. Also verstehe ich das richtig, dass hier das externe Triggersignal zur Taktgenerierung für die Sinustabelle erzeugt werden soll? Die internen PLLs im Cyclöone IV habe ich so verstanden, als dass sie nur zur Frequenzsynthese genutzt werden können um höhere Takte zu generieren, ist das korrekt?
Stephan K. schrieb: > Also verstehe ich das richtig, dass hier das externe Triggersignal zur > Taktgenerierung für die Sinustabelle erzeugt werden soll? Nö, eigentlich hatte ich es anders gemeint ;-) In jedem Fall würde ich eine DDFS bauen, und die Regelung über eine Änderung des Phasenadders durchführen. Damit baust du letztlich eine eigene PLL. Auf die FPGA-internen PLLs im Clockpfad wollte ich nicht abzielen, sorry für das Missverständnis. Mein eigentlicher Punkt war: - wenn das Modulationssignal selbst verjittert ist und der externe Trigger diesen Jitter des Modulationssignals exakt wiedergibt, dann würde ich die Nachregelung der eigenen DDFS so abstimmen, dass sie dem externen Jitter möglichst schnell folgt. Das schien mir dein aktuelles Anliegen zu sein. - aber wenn zwar die Triggersignal jittern, das Modulationssignal selbst aber diesen Jitter nicht aufweist, dann wäre es unsinnig, den Jitter mit deiner DDFS nachregeln zu wollen. Dann brauchst du zwar immer noch eine Nachregelung, um langsame Drifts der Phase auszugleichen. Die Nachregelung sollte aber eben langsam sein und nicht dem einzelnen verjitterten Triggerimpuls nachhecheln. Ziel wäre stattdessen, dass im zeitlichen Mittel über viele Triggerimpulse die Phasenlage von internem und externem Trigger passt. Der grundsätzliche Ansatz wäre für beide Fälle: du betrachtest jeweils die Zeitdifferenz zwischen externem Trigger und internem Trigger deiner DDFS als Fehlersignal für die Phase. Dieses Fehlersignal fütterst in einen Regler, der sich auf den Phasenadder deiner DDFS auswirkt. Der Unterschied zwischen beiden Fällen ist, wie du den Regler auslegst.
Achim S. schrieb: > du betrachtest jeweils die Zeitdifferenz zwischen externem Trigger und internem Trigger deiner DDFS.... Genau das macht den Phasendiskriminator einer PLL aus. Ich weiß nicht auf welchem Wissensstand der TO ist, aber ein Grundlagenbuch zum Thema PLL könnte helfen. Ich fand damals das PLL-Buch von Roland E. Best hilfreich. Stephan K. schrieb: > basierend auf einem externen Triggersignal eine phasen- und > frequenzgleichen Sinuschwingung erzeugen soll Letztendlich soll er doch auch nur eine PLL bauen. Duke
Achim S. schrieb: > Nö, eigentlich hatte ich es anders gemeint ;-) > > In jedem Fall würde ich eine DDFS bauen, und die Regelung über eine > Änderung des Phasenadders durchführen. Ja genau so läufts derzeit, der Phasenadder wird durch die Regelung (noch sprunghaft) geändert. Achim S. schrieb: > Ziel wäre stattdessen, dass im > zeitlichen Mittel über viele Triggerimpulse die Phasenlage von internem > und externem Trigger passt. Diese Phasenlage habe ich mittels zweier Counter bestimmt. Somit weiß ich wie viele Clockzyklen meine Signale auseinander leigen und kann auf die Phasnelage referenzieren. Achim S. schrieb: > Dieses Fehlersignal fütterst in einen Regler, der sich auf den Phasenadder > deiner DDFS auswirkt. > Der Unterschied zwischen beiden Fällen ist, wie du den Regler auslegst. Dann liegt genau hier der Hund begraben. Duke Scarring schrieb: > Genau das macht den Phasendiskriminator einer PLL aus. Ich weiß nicht > auf welchem Wissensstand der TO ist, aber ein Grundlagenbuch zum Thema > PLL könnte helfen. Ich fand damals das PLL-Buch von Roland E. Best > hilfreich. Mein Wissensstand zu einer PLL sind wahrlich nicht sehr ausgereift, ich beschäftige mich generell erst seit 6 Monaten mit der Digitaltechnik und programmierbarer Logik. Ich werde mich deinem Buchvorschlag mal annehmen, sobald ich dazu komme. Danke für den Tipp!!
du könnstest dein Problem natürlich auch andersrum lösen und die Modulationsspannung aus deinem FPGA-internen DDS-Signal ableiten. Wenn man sich die Arbeit mit DAC, Filter und Analogteil sparen will kannst du ggf. auch deinen Signalgenerator auf den Takt deines Lock-In synchonisieren. Damit gäbe es kein Problem mit auseinanderlaufenden Phasen mehr. Viele digitale Signalgeneratoren können von außen mit einer Ref-Clock versorgt werden. In jedem Fall solltest du aber darauf achten, dass das Taktsignal deines FPGA-Designs für Lock-In und DDFS selbst stabil und jitterarm ist. Also direkt aus einem Quarzstabilen Oszillator getrieben, und ohne einen FPGA-internen Clock-Manager oder eine FPGA-Takt-PLL zwischenzuschalten. Diese Clockmanager sind zwar praktisch um z.B. die Taktfrequenz zu verändern. Aber wenn der Takt für dein FPGA-Design über so einen Clock-Manager gelaufen ist, dann kann es leicht sein, dass dessen Regelverhalten die Hauptquelle für Phasenfluktuationen in deinem Lock-In Aufbau ist.
Achim S. schrieb: > Viele digitale Signalgeneratoren können von außen mit einer > Ref-Clock versorgt werden. Vorsicht! Ich sehe da regelmäßig Pferde ko****. Erzeuge mal 10 MHz (am Besten Rechteck) und schau die zusammen mit dem Refout auf einem Oszi an. Dann einen Screenshot machen und nach ein paar Stunden nochmal gucken... Duke
Duke Scarring schrieb: > Erzeuge mal 10 MHz (am Besten Rechteck) und schau die zusammen mit dem > Refout auf einem Oszi an. Die laufen in der Phase auseinander. Das ist aber nicht unbedingt Zeichen dafür, dass "Taktflanken verloren gehen" und die Synchronität verloren geht. Sondern es ergibt sich im Normalfall einfach daraus, dass man mit dem DDS-Generator nicht exakt 10MHz erzeugen kann. Mit entsprechend hochauflösendem Phasenakkuulator kommt man zwar sehr nahe an den exakten Wert ran. Aber auch ein paar mHz daneben führen im Lauf der Zeit zu Abweichungen zwischen dem Ref-10MHz und dem DDS-erzeugten 10MHz. Um das zu vermeiden dürfte der Phasenakkumulator wohl nicht binär rechnen oder der Ref-Clock müsste einen genau passenden Wert haben, so dass der Phasenakkumulator bei jedem Überlauf genau auf Null springt (der Phasenadder also genau den Wert einer Zweierpotenz hat). Trotzdem kann ich zwei DDS-Kurven mit exakt der gleichen Frequenz erzeugen, wenn die Taktfrequenz beider Systeme synchron läuft. Aber zugegeben: es ist nicht selbstverständlich, dass das funktioniert. Man müsste z.B. bei der DDFS einen Phaseadder-Wert nehmen, der auch mit der DDS des Signalgenerators genau darstellbar ist (also ggf. auf Frequenzauflösung der eigenen DDFS verzichten). Und wenn man es aufgebaut hat, sicherheitshalber nochmal nachmessen, ob es wirklich funktioniert. (Und nicht zu sehr enttäuscht sein, wenn es doch nicht klappt.)
Stephan K. schrieb: > Nicht ganz, wir haben lediglich einen Impuls am Eingang anliegen, > welcher in seiner Frequenz variable ist und kleinerem Schwankungen > unterliegt. Ok, dann musst Du Ich entscheiden, ob Du die Spünge willst oder ob Du einen glatten Übergang bekommst. Beides geht nicht. Wenn du das machst, was die anderen hier raten, nämlich eine PLL bauen, hast Du komplett verloren, weil Du a) Jitter bekommst und b) nie in Ohase bist. Du hast also keinen guten Sinus und triffst obendrein Deine Nulldurchgänge nicht.
Edi M. schrieb: > nämlich eine PLL bauen, hast Du komplett > verloren, weil Du a) Jitter bekommst und b) nie in Ohase bist. Hast Du schonmal eine PLL gebaut? Kannst Du das Phasenrauschdiagramm einer PLL interpretieren? Hast Du schonmal was von der Bandbreite des Loop-Filters gehört? Zu b): Du weißt was der Begriff PLL bedeutet? Wie die PLL in diesem Fall ausgelegt werden muß, hängt entscheidend von den Anforderungen ab. Die kennt hier außer dem TO niemand so richtig. Und klar kann ich mit einer PLL den Jitter veringern. Nicht zwingend und nicht in allen Frequenzbereichen, aber je nach Anwendung in dem Bereich, wo der Jitter am meisten stört. Sonst könnte ich gleich auf die PLL in den meisten High-Speed-Receivern verzichten... Duke
Jou, so werde ich es dann mal versuchen, nachregelung der Phase über eine PID und keine Sprunghafte Änderung der Frequenz mittels gleitendem Mittelwert. Besten Dank!
Beides zusammen geht nicht... Ich würde evtl. den Ausgang des PLL-Filters(Regler) als Schrittweite für die Sinustabelle nutzen... Dann ergibt sich die Frequenz automatisch... Und Du mußt nur den PLL-Regler richtig auslegen.
Es gibt auch noch die "digitale PLL" wie z.B. den 74HC297 oder auch 74LS297, dazu hat TI Applikationen. Die Costas-Loop könnte noch interessant sein https://en.wikipedia.org/wiki/Costas_loop eigentlich zur Demodulation phasenmodulierter Signale gedacht.
Duke Scarring schrieb: > Hast Du schonmal eine PLL gebaut? Yepp! Und keine PLL der Welt kann gleichzeitig den Jitter im Trigger beseitigen und trotzdem exakt auf den Flanken des Triggers sitzen, weil sich das grundsätzlich widerspricht. Entweder Du glättest das, oder nicht. Glätten heisst: Über mehrere Perioden hinweg die Periode mitteln und bei Änderungen langsam mitgehen und dadurch das Phasenrauschen beseitigen. Es läuft auf einen Kompromiss zwischen schnell folgen und Jittertoleranz hinaus. Triggern heisst: Die Flanke exakt zu nehmen und brutal da zu starten, um hintenraus mit einer zufälligen Phase den nächsten Trigger abzubekommen. Dann heisst es Springen oder später triggern. Resultat: Sprünge in der Amplitude oder Start zu einem falschen Phasenzeitpunkt. Das sind die Fakten.
Die einzige Möglichkeit, Phasenpunkt UND Amplitude zu treffen und damit stetig zu sein, ist eine kontiuierliche Glättung zwischen den Triggerpunkten. Dann brauchst Du aber 3 Punkte und eine Interpolation der Phase. Das erzeugt perfekte Bögen zwischen den Punkten, also Phasenverläufe ohne Sprünge mit stetigen Ableitungen und somit gleichmässigem Durchlauf in den Triggerpunkten. Dann wäre die Amplitude stetig, es gäbe keine abrupten Phasenbeschleunigungen und man produziert minimale Oberwellen ... aber: Man ist immer einen Triggerpunkt hinterher, weil man das Ende der Periode wissen muss. Das hatte Ich aber oben schon erklärt. So sieht es aus.
Edi M. schrieb: > Und keine PLL der Welt kann gleichzeitig den Jitter im Trigger > beseitigen und trotzdem exakt auf den Flanken des Triggers sitzen, weil > sich das grundsätzlich widerspricht. Ok, dann hatte ich Dich falsch verstanden. Durch Mittelung bzw. Tiefpassfilterung kann die Flanke des erzeugten Signals natürlich trotzdem dort sitzen, wo die des verjitterten Eingangssignales hätte sitzen sollen ;-) Duke
Duke Scarring schrieb: > Durch Mittelung bzw. Tiefpassfilterung kann die Flanke was allerdings auf Raterei hinausläuft. Kann gut sein, oder nicht. Der TE hat sicher einen Grund, warum er exakt Triggern möchte.
Also ich habe es mittlerweile einigermaßen passabel hinbekommen. Die Frequenz wird ja seit jeh her schon über die Schrittweite für die Sinustabelle bestimmt und über den zeitlichen Abstand zwischen den jeweils eingehenden Triggersignalen ermittelt. Zum jedem Triggerzeitpunkt speichere ich nun den Akkumulator wert zwischen. Aus diesem ziehe ich die Informationen für die Phasenverschiebung. Gefiltert gibt es nur noch kleine Schwankungen, die durch die Phasenauflösung der Sinustabelle und dem Jitter des externen Signals verursacht werden. Im Anhang befindet sich übrigens dieses externe Triggersignal.. Es ist wirklich kein sehr schönes, aber mehr haben wir nicht zur Verfügung. Über einen geeigneten Spannungsteiler speisen wir dieses Signal mit 3,3 V über einen GPIO Pin in den FPGA. Was haltet Ihr davon?
Stephan K. schrieb: > Was haltet Ihr davon? Was das unschöne Triggersignal angeht: da tippe ich zunächst mal drauf, dass das einfach "unschön gemessen" wurde. Wenn das Nachschwingen kein Messartefakt sein sollte sondern "echt", dann terminiere deine Triggerleitung mal sinnvoll. Evtl. erspart dir das auch gleich den derzeit genutzten Spannungsteiler.
Achim S. schrieb: > terminiere deine Triggerleitung mal sinnvoll Wie ist das nun zu verstehen? E. M. schrieb: > Wurde die Tabelle interpoliert? Wurde sie nicht. Lediglich über die mit der library ieee.math_real zur hilfe gestellten Funktionen berechnet.
Stephan K. schrieb: > Wie ist das nun zu verstehen? Stephan K. schrieb: > Wie ist das nun zu verstehen? So: https://www.mikrocontroller.net/articles/Wellenwiderstand#Terminierung Aber wie gesagt: ich glaube eher, dass es sich hier um einen Messfehler handelt. Stelle erst sicher, dass du richtig misst, bevor du versuchst, die Auswirkung einer Terminierung auf die "Nachschwinger" zu bewerten. Zum Stichwort "richtig messen": https://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen
Stephan K. schrieb: > Im Anhang befindet sich übrigens dieses externe Triggersignal.. Es ist > wirklich kein sehr schönes, aber mehr haben wir nicht zur Verfügung. Woher kommt denn so ein wohlgeformtes "Klingelsignal"? Was geht am Anfang der Leitung rein? Achim S. schrieb: > Aber wie gesagt: ich glaube eher, dass es sich hier um einen Messfehler > handelt. Oder eben ein Anpassungsproblem wie im Beitrag "Re: Signalproblem bei langem Kabel" und im Beitrag "Re: Serienwiderstand bei Hochfrequenz"
Stephan K. schrieb: > Wurde sie nicht. Lediglich über die mit der library ieee.math_real zur > hilfe gestellten Funktionen berechnet. Gemeint war eigentlich, ob sie beim Auslesen interpoliert wird? Bei den Tabellen ist die Adresse ja nicht immer ganzzahlig. Oder ist das bei Dir so?
Lothar M. schrieb: > Woher kommt denn so ein wohlgeformtes "Klingelsignal"? > Was geht am Anfang der Leitung rein? Das Signal kommt vom Signalgenerator einer Flüssigkeitslinse, die dadurch in Schwingung versetzt wird. Die Leitung war beim messsen recht kurz, 30 cm ca. Und es geht nur das Anregungssignal vom Signalgenerator für die Linse rein. E. M. schrieb: > ist die Adresse ja nicht immer ganzzahlig. Oder ist das bei Dir > so? Ja, so habe ich das zumindest verstanden. Hatte mich an dem DDFS Besipiel von Lothar Miller orientiert.
Stephan K. schrieb: > Das Signal kommt vom Signalgenerator einer Flüssigkeitslinse, die > dadurch in Schwingung versetzt wird. Sieht man deren (Ober-)Schwingungen auf dem Signal? Oder ist das wirklich nur ein rein elektrisches Klingeln?
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.