Der Takt eines projektfremden Moduls kommt aufgrund EMV oder anderer Schwierigkeiten sehr unsauber an. Mit diesem müssen aber die Daten übernommen werden, weil er jittert und die Daten mit ihm. Das Problem ist die Schaltschwelle im FPGA, die aus dem Taktsignal das tut, was in der Grafik zu sehen ist: Wenn ich die Spannung von 2,5V auf 1,8V umstelle, kann ich den Pegel ändern, bekomme dafür aber Einbrüche der 1, statt Einbrüche der Null. Wie kann ich das am besten wegfiltern?
Angehängte Dateien:
Bandpass? Schwingkreis? PLL? Wie sieht die Störung denn im Frequenzbereich aus?
Meiner Meinung nach wirst du hiert am FPGA nur sehr wenig machen können. Man sollte genau solche Probleme immer am Kern anpacken, also rausfinden, warum das Signal so aussieht. Leider fehlen die Frequenzinformationen. Aber vom Bauch raus kann es nicht allzu schnell sein, da ein "Rechteck" erkennbar ist. Insofern ist es schon sehr interessant wie ein Signal so gestört werden kann. Zuletzt habe ich das in meinem Commodore C64 so gesehen... Btw. Wo konntest du das Signal abgreifen? Ist das direkt am Eingang des FPGAs? Du sagtest auch was, dass die Daten mit dem Takt übernommen werden. Sind das Daten synchron zu diesem Takt vom externen Modul, oder kommen die Daten woanders her? 1) Ich würde als den ersten und einfachsten Versuch einen seriellen Terminierungswiderstand ausprobieren. Ca. 10-100 Ohm - einfach mal ausprobieren ob es besser wird. 2) Evtl. Irgendeine parallele Terminierung mit Block-Kondensator verwenden 3) Schmitt-Trigger mit Hysterese, wobei ich aber nicht glaube hier einen einigermaßen guten "Jitter-freien" Takt zu bekommen 4) Externe PLL Beschaltung, um den Clock zu recovern - hier wird es aufwendig. Aber wenn die Daten auch so aussehen, dann wird dir das auch nichts bringen. Grüße
high tec ing schrieb: > Das Problem > ist die Schaltschwelle im FPGA, die aus dem Taktsignal das tut, was in > der Grafik zu sehen ist Die Schaltschwelle ist nicht Dein Problem, dass Eingangssignal ist es, oder ? Kannst Du mal ein paar Details von Dir geben ? Z.B: Welche Frequenz sehen wir da ? Wie ist die Clkleitung terminiert ? Wie ist der Ausgang des Clock-Signals (des externen Moduls) mit eurem Modul verbunden. Welche Frequenzen können tummeln sich im System ausser der Clock noch rum ? Sonst wird das mit der Ferndiagnose schwierig. Grüße Andreas
Und außerdem: Sehen die Daten genauso schlimm aus? Dann kann man sich überlegen den Takt aus den Daten zu rekonstruieren.
Was ist denn da überhaupt Takt und was Daten? Oder ist das der Takt vor und nach dem Eingang? Die glitches müssen mit einem Unterdrückungsfilter rausgefiltert werden, dann müsste das gehen.
Dargestellt ist nur der Takt und zwar der Analogwert und das, was der Eingang daraus macht. Leider habe ich keine Möglichkeit, da viel umzubauen. Wenn gäbe das ein redesign. Ich kriege den Takt direkt über einen Stecker. Er hatte 500kHz und wurde nun auf 2MHz hochgesetzt. Jetzt soll getestet werden, ob man das zum Laufen kriegen kann. Aber wie ich sehe ist das chancenlos. Mit einem RC-Glied sieht es aber schon besser aus. Allerdings sind die Flanken dann verschliffen und ich muss prüfen, ob das dann noch ein echter Takt sein darf oder gesampelt werden muss.
Andreas H. schrieb: > Wie ist der Ausgang des Clock-Signals (des externen Moduls) mit eurem > Modul verbunden. high tec ing schrieb: > Ich kriege den Takt direkt über > einen Stecker. Schön, dass das wenigstens mal klar ist. Und wenn wir jetzt noch herauskriegen, was das für ein Stecker ist, welches Kabel und welche Länge und wer die Clk da rein treibt, dann könnte man das mit einer gewissen Wahrscheinlichkeit noch hinkriegen. Bei 2MHz ist das ja noch fast DC^^ Grüße Andreas
Evtl. wird es auch besser, wenn man mal eine harte Parallelterminierung am Ende einbaut. Also sowas in der Gegend 25-100R gegen GND oder VIO/2. Es könnte sein, dass das Nutzsignal deutlich weniger gedämpft ist als die Störungen.
Georg A. schrieb: > Also sowas in der Gegend 25-100R gegen GND oder VIO/2. > Es könnte sein, dass das Nutzsignal deutlich weniger gedämpft ist als > die Störungen. Mein heisser Favorit ist ja eher eine lausige Masseverbindung zwischen den Boards. Aber evtl. erfahren wird ja irgendwann noch die restlichen "unwichtigen" Details. Grüße Andreas
Ich habe ja keine Ahnung, aber bei der niedrigen Frequenz könnte man das ja auch digital samplen. So habe ich das schon mit einer 1MBaud RS232 gemacht. Also mit einem deutlich höheren Takt den langsamen Takt abtasten und in ein Schieberegister schieben, das von der Länge her genau der halben Periodendauer das langsamen Taktes entspricht. Wenn du also deine 2MHz hast und die jetzt mit 100MHz samplest, dann bekommst du je Taktperiode 50 Werte die 1 oder 0 sind. Jetzt ist das Schieberegister nur 50 Bits lang. Du kannst also klar erkennen wenn der Takt auf High und wenn er auf Low ist. Da High aber nicht 50 mal die 1 ist musst du Schwellwerte setzen. Dazu kannst du ja mal eine volle Taktperiode samplen oder auch mehrere und die das Ergebnis angucken, also wieviele Bits trotz High-Phase auf 0 sind und anders herum. Das Kannst du auch mit den Datenleitungen machen und dann über mehrere Samplewerte entscheiden ob das jetzt High oder Low ist.
Das ist kein Takt, das ist Weißes Rauschen! Im Ernst. Probleme löst man am besten an der Quelle. Dazu muss man den Signalweg dieses "Taktes" mal verfolgen und schauen was passiert. Rumdoktern an Symtomen ist selten langfristig erfolgreich.
Wie lange ist denn die Leitung zwischen Sender und Empfänger? Hast du schon mal am Sender gemessen (ohne Verbindung zu deinem Board)? Wenn da nicht gerade x Meter Kabel dazwischen sind oder ne schlampige Masse, kann ich mir nicht vorstellen, was das Signal so zerstören soll....
Naja, scheint auch nicht unbedingt ein Oszi aus der Qualitätsschublade zu sein.
Andreas H. schrieb: > Georg A. schrieb: >> Also sowas in der Gegend 25-100R gegen GND oder VIO/2. >> Es könnte sein, dass das Nutzsignal deutlich weniger gedämpft ist als >> die Störungen. > > Mein heisser Favorit ist ja eher eine lausige Masseverbindung zwischen > den Boards. > Aber evtl. erfahren wird ja irgendwann noch die restlichen "unwichtigen" > Details. > > Grüße > Andreas Mein Favorit ist ebenfalls, miese bis gar keine Masseverbindung, ein sehr ähnliches Phänomen hab ich damals auch beobachtet!! genau die gleichen lustig aussehenden "Berge".
Omega schrieb: > Wo konntest du das Signal abgreifen? Ist das direkt am Eingang des FPGAs? Und wo ist die zum Signal gehörige Masseklemme des Oszilloskops angebracht? Und was ist denn das eigentliche Problem? Wie äussert sich der Fehler? Wird mit diesem "Takt" im FPGA direkt was getaktet? high tec ing schrieb: > Dargestellt ist nur der Takt und zwar der Analogwert und das, was der > Eingang daraus macht. Und woher hast du das Signal, das "der Eingang daraus macht"? Ist das wirklich vom FPGA eingelesen und wieder ausgegeben? > Leider habe ich keine Möglichkeit, da viel > umzubauen. Wenn gäbe das ein redesign. Ich kriege den Takt direkt über > einen Stecker. Er hatte 500kHz und wurde nun auf 2MHz hochgesetzt. > Jetzt soll getestet werden, ob man das zum Laufen kriegen kann. Und mit 500kHz hat das noch funktioniert?
Angehängte Dateien:
-
digitale_takt-filterung.gif
4,9 KB
Da scheint aber so einiges Kurioses auf den Leitungen zu geschehen. Sind das Streueinflüsse von Aussen oder wo kommt das her? Die Umschaltschwelle ist vor allem dann ein Problem, wenn da zuviel DC drauf ist. Der müsste erstmal weg. Eine Möglichkeit ist ein differentieller Eingang mit Bezug zum NF-Anteil dieses "Taktes". Wenn Du dem Thema analog nicht beikommst, kannst Du eine Taktrekonstruktion versuchen: Dabei wird über eine ausreichend lange Zeit der Quelltakt mit dem Solltakt multipliziert. Das Ergebnis ist ein verrauschter, dreicksförmig schwankender Korrellationswert, der selber wieder ein Takt ist. Du kannst das diskret machen, wie Gustel das schon angedeutet hat oder mit einem schmalbandigen Filter direkt auf der gesuchten Frequenz arbeiten (was ebenfalls den DC killt). Dies am Besten gleich über mehrere Perioden. Man muss nur genügend hoch sampeln. Bei 2 MHz solltest Du mit etwa 20MHz-40MHz arbeiten. Weniger wird zu ungenau und viel mehr macht keinen Sinn, weil der Filter zu lang und ineffektiv wird. So wie die Daten aussehen, kommst Du mit einem 16er Filter über 4-8 Takte sicher aus aus. Für die Daten würde ich jeweils ein IIR-Filter nehmen und entsprechend spät abtasten. Wenn Du genügend Reserven im FPGA hast, kannst Du natürlich auch da FIRs instanziieren.
high tec ing schrieb: > Mit einem RC-Glied sieht es aber schon besser aus. Allerdings sind die > Flanken dann verschliffen und ich muss prüfen, ob das dann noch ein > echter Takt sein darf oder gesampelt werden muss. Naja, wenn du mit einem Filter was brauchbares zaubern kannst, dann spendiere noch einen Schmitt-Trigger danach und du hast wieder ordentliche Flanken. Bei 2MHz Frequenz sollten die Laufzeiten in Filter und Schmitt-Trigger nicht das große Problem darstellen. Die Ursachen aus meiner Sicht: - zu lange Leitung - zu wenig Masseleitungen (schlechte Masse wurde bereits genannt, auch meine starke Vermutung) - aktuelle FPGAs sind nun mal sehr schnell und reagieren natürlich auf jeden 'Dreck' - auch auf solchen, die du u.U. mit deinem Skope gar nicht mehr siehst. Abhilfemöglichkeiten, teilweise schon genannt: - Serienterminierung bei der Quelle - max. 3...4 Daten-/Taktleitungen benötigen eine Masseader - Parallelterminierung oder RC-Terminierung am Ende könnte eine Verbesserung bringen. Daran glaube ich aber weniger, wenn auf der Sendeseite keine Terminierung vorhanden ist.
@jürgen schumacher Was du vorschlägst macht mit dem Digitalsignal aus dem FPGA Eingangspuffer keinen Sinn mehr, es sei denn man beschränkte das Störspektrum auf deutlich höhere Freqenzen als den gesuchten Takt. Zudem sollte die Störung spektral gleichverteilt sein um durch die Nichtlinearität des Eingangspuffers keine störenden Mischprodukte zu bekommen. Wenn du von einem "Solltakt" redest, so meinst du wohl eine PLL. Diese müsste aber einen analogen Multiplizierer als Phasenvergleicher haben um etwas zu bringen. Stichwort "pll tracking filter". @HildeK Ein Schmitt-trigger hilft wohl nicht, vor allem nicht wenn sich Störspektrum und Nutzspektrum (Takt) überlappen.
Dogbert schrieb: > Was du vorschlägst macht mit dem Digitalsignal aus dem FPGA > Eingangspuffer keinen Sinn mehr, es sei denn man beschränkte das > Störspektrum auf deutlich höhere Freqenzen als den gesuchten Takt. Thereoretisch hast Du recht, aber wenn ich mir das Taktdiagramm des TE ansehe, ist es jeweils der HF Anteil der den Peak verursacht nachdem der NF-Anteil den Pegel so verschiebt, dass der Peak das jeweils kann. Im einen Bild sind es daher Einbrüche von untern und im anderen Bild Einbrüche von oben, zudem gibt es Gezitter im Bereich des Taktübergangs. Das ist typisch für langsame verrauschte Takte bei schnellen Eingangsbuffern. Das Problem wird aber durch den Filter erledigt. Der ist nämlich ebenfalls nichtlinear und hat für kleine Amplituden hoher Freuquenzen eine unendliche Dämpfung. Daher ist dies > Zudem sollte die Störung spektral gleichverteilt sein um durch die > Nichtlinearität des Eingangspuffers keine störenden Mischprodukte zu > bekommen. auch kein Problem. Bei der Taktrekonstruktion geht es ja darum die Mitte des Taktes zu erwischen. Dieser darf dabei durchaus mitjittern. Selbstredend hast Du grundsätzlich Recht: Es wird irgendwann einen Pegel der niederfrequenten Störungen geben, die das Signal so lange tot machen, dass die Rekonstruktion versagt. Aber dazu muss das Signal schon extrem versaut sein. Dem käme man dann mit der Methode 1 bei, die ich erwähnt habe, erfordert aber eine HW-Änderung. Der nächste Schritt wäre allerdings zunächst eine diskrete PLL mit Taktvorausschau zu verwenden. > Wenn du von einem "Solltakt" redest, so meinst du wohl eine PLL. Gemeint war die Frequenz des Zieltaktes. Die muss bekannt sein, um den Filter zu definieren. Eine echte PLL wird hier nicht lange arbeiten.
Falk Brunner schrieb: > Das ist kein Takt, das ist Weißes Rauschen! > Im Ernst. Probleme löst man am besten an der Quelle. Tja, aber ich kann an der Hardware wenig tun. Kommt alles aus dem Fremdbaugruppe. Ist wohl nicht auf >500kHz designed worden. Masse und Abschirmung habe ich etwas rumprobiert, tut nicht viel. Am Liebsten wäre mir eine Softwarelösung. Jürgen Schuhmacher schrieb: > Das Problem wird aber durch den Filter erledigt Das klingt ja vielversprechend. Aber: > Dabei wird über eine ausreichend lange Zeit der Quelltakt mit dem > Solltakt multipliziert. Wie multipliziere ich jetzt genau? Ich hätte das Eingangs-bit umgeschrieben auf einen 16 bit-Wert und einfach einen Filter drangehängt, der auf 2MHz filtert. Als Takt könnte ich 50MHz hernehmen. > Das Ergebnis ist ein verrauschter, dreicksförmig > schwankender Korrellationswert, der selber wieder ein Takt ist. Kommt da nicht ein Sinus raus?
Bei 50KHz sah das Signal aber garantiert auch schon bescheiden aus! Mit einer analogen PLL sollte es noch machbar sein den Takt wiederzuerstellen. Laufzeiten durch diese PLL-Baugruppe könnten noch ein Problem sein. Geht natürlich nur, wenn das Nutzsignal wirklich schmalbandig ist, also nicht irgendwie moduliert wird z.B. abundzu ausgeschaltet ist. Bevor du damit anfängst, erstmal korrekt terminieren und Masse klären. Notfalls empirisch durch Probieren mit verschiedenen R und C. Vielleicht möchte der Sender auch ein bestimmtes Bezugspotential/Strom sehen!
Eine nahezu digitale Lösung hätte ich anzubieten: Man müsste zumindest eine art analoge Abtastung des Taktes mit dem FPGA machen. Z.B. ein Rauschsignal (weißes Rauschen am besten) zu dem Taktsignal addieren so dass sich die Schwelle des Eingangspuffers damit verschiebt. Dessen Amplitude sollte ähnlich groß wie die Taktamplitude sein. Dieses Signal dann über den FPGA-Eingangspufer mit den 50Mhz abtasten, es mit einem NCO multiplizieren und das tiefpassfiltern (in den Schleifenfilter) und als Steuersignal auf den NCO. (0 am Eingang = -1, 1 am Eingang +1 Multiplikation) Der NCO muss natürlich einen Sinus Ausgang haben. Die Genauigkeitsanforderung an die Sinus-Tabelle ist gering. Im Schleifenfilter steckt hier mehr als gesagt. Die Schleifenbandbreite ziemlich niedrig im Bereich 100Hz, allzu schnell muss es ja den Quelltakt nicht tracken, oder? Der I-Anteil des Schleifenfilter sollte gleichzeitig auf die Mittenfrequenz des NCO +- zu erwartende Toleranz des Takts begrenzt sein. Das ist dann wie eine analoge PLL, digital nachgebildet. Und fertig ist der rekonstruierte "jitter gefilterte" Takt. Das Rauschsignal ließe sich auch mit dem FPGA als pseudozufällige Sequenz erzeugen die mit R2R aus Widerständen gewandelt wird. Ich denke 4 Bit bei 50Mhz Samplefrequenz reichen. So wie ich es vermute wird aber keiner den Aufwand diese Lösng zu entwickeln bezahlen wollen.
Hört sich nach richtig Aufwand an. Ok, mal schauen ...
@ high tec ing (Gast) Jaja . . . >> Im Ernst. Probleme löst man am besten an der Quelle. >Tja, aber ich kann an der Hardware wenig tun. Kommt alles aus dem >Fremdbaugruppe. Klar, es sind immer die anderen Schuld. Und selbst wenn, DU musst das Problem lösen. >Ist wohl nicht auf >500kHz designed worden. Kann sein, spielt hier aber keine Rolle. Das Signal leidet nicht an Bandnrietenmangel sondern ist massiv gestört, das kann alles mögliche Sein. Masseproblem, Einkopplung, schlechte Stromversogung am Sender (Entkoppelkondensatoren) etc. > Masse und >Abschirmung habe ich etwas rumprobiert, tut nicht viel. Du meinst, du hast mal am Stecker gewackelt und weil damit das Problem nicht verschwunden ist, geht nix mehr. Aha. Mensch, man muss die Signalkette Punkt für Punkt durchmessen! Siehe Fehlersuche. Aber jemanden mit dem Nickname muss man sowas eigentlich nicht sagen. > Am Liebsten wäre mir eine Softwarelösung. Klar, Updates sind Zeitgeist und lösen jedes Problem dieser Welt.
Bei diesem Signal löst eine Software-Lösung nur 99.9999% der Fälle, wenn es gut geht. Dann wünsch ich dir sehr viel Spaß, und zwar so richtig sauviel Spaß beim suchen und finden eines sporadischen Fehlers, der alle heiligen Zeit mal auftritt, wegen dem Restfehler von 0.0001% Falls wirklich die anderen Schuld sind, dann würde ich - das Board reklamieren, da unbrauchbar - etwas anderes Verwenden - 2MBaud ist nun wirklich mal nicht schnell für einen FPGA oder µC. Das Signal muss unter allen Umständen einfach besser aussehen. Ich denke, auf Grund des beratungsresisten High-Tech-Ing sollte man mit der Fehlersuche aufhören - da keinen Sinn! Btw.: mich hätte die Ursache schon interessiert. Weil nur dann lernt man aus Fehlern! Und: Ich hoffe du hast einen besseren Arzt als du Ing. bist, sonst behandelt er dir auch nur die Symptome, aber nicht die Krankheit!
high tec ing schrieb: > Ist wohl nicht auf >500kHz designed worden Genau, die Entwickler dieser Baugruppe haben das genau so eingebaut: bei 500kHz ist das Signal astrein und bei 2 MHz total versemmelt. Wenn du dir das Signal mal anschaust und dir kurz übelegst, was das für das Frequenzspektrum bedeutet, dann würdest du schnell draufkommen, dass das Signal bei 500kHz genauso beschissen aussehen wird. Relevant sind nicht die Pegel, sondern die Flanken. Entweder ist die Baugruppe defekt, oder in deiner Verkabelung ist was im Argen.. Das kann man entweder bereinigen, oder an den Symptomen rumpfuschen.. Du scheinst der Meinung zu sein, dass zweiteres zielführender sei.. dann hast auf jeden Fall ein gutes Stück Arbeit vor dir..
Warum denn so negativ? Ich sehe es als Herausforderung an aus dem stark gestörten Signal wieder zuverlässig Takt/Daten zu extrahieren. Nachrichtentechnik die wir ale verwenden GSM, OFDM u.s.w. macht ja genau das gleiche. Sicher, es wäre wohl einfacher gegangen und scheinbar hat hier jemand eine ziemliche Scheiße gebaut, trotzdem ist es interessant was man noch machen kann. OK, ich tippe aber das dieses Projekt den Gang vieler anderer ähnlich versemmelter Projekte gehen wird, denn es findet sich Niemand der fähig genug ist eine "minimalinvasive" Lösung zu schaffen, sonst wäre es ja kaum zu so einem Mist gekommen. Was wollte jemand der so fähig ist an Orten wo so was "gebaut" wird? Gesucht: eine Lösung bei der niemand sein Gesicht verliert und Schuld auf sich nehmen muss, die nichts kostet, total Einfach und in 5 Minuten fertig ist. Neues Projekt neues Glück.
Dogbert schrieb: > Nachrichtentechnik die wir ale verwenden GSM, OFDM u.s.w. macht ja genau > das gleiche. Klar, aber die, die das entwickeln, sind High-Tech-Ingenieure, die sicher nicht auf Mikrocontroller.net fragen, wie sie einen versemmelten "Quasi-DC" wieder beruhigen können ;-) Ich verneige mich ehrfurchtsvoll vor denen, die aus einem total verrauschten zig-Gigaherz-Signal noch mit einer recht hohen Trefferquote vernünftige Daten rausoperieren. Doch dazu bedarf es mehr, als nur Grundkenntnisse der Elektrotechnik. Wenn es unserem High-Tech-Ingenieur darum geht, das ganze jetzt sportlich zu sehen und aus dem vermurksten Signal wieder was Brauchbares zu machen, dann ist das das eine. Wenn es aber darum geht, eine praktische Lösung zu finden, dann würde ich vielleicht mal meine Massen überprüfen etc..
Dieser Versuch alles irgendwie digital zu lösen, ist schon irgendwie ergreifend! Man muß richtig die Tränen unterdrücken. Im Allgemeinen ist die analoge Welt einfacher, wenn man was analoges fixen will. Es irgendwie digital hinbiegen zu wollen, erfordert meist erheblich mehr Aufwand. Da ist selbst der geschenkte Aufwand äh Platz in Form eines fast leeren FPGA nicht ausreichend ;-) Fang mal mit einem 4046 oder einer spezialisierten jitter-fixer PLL an. Und was GSM angeht: Da ist alles erstmal analog optimiert und dann kommt die digitale Welt obendrüber aufsetzend um (1) Speicherung, (2) Route-Switching und (3) Verzögerung realisieren zu können. Genau diese drei Punkte sind eigentlich auch das einzige was Digital besser geht! Die Welt ist analog.
Abdul K. schrieb: > Die Welt ist analog. Max Planck z.B. sah das anders und arbeitete an der Quantentheorie. Es sind scheinbar einzelne Lichtquanten und Elektronen in der Welt der kleinsten Energien. Die mathematische Idealisierung des Analogen scheint es praktisch nicht zu geben. Welch Überraschung, hat das Analoge doch auch immer irgendwie mit seiner Imperfektion, dem Rauschen zu kämpfen. Für den, der aus der "Analogen" Welt kommt ist das "Digitale" meist Aufwand. Praktisch is zu sehen dass immer mehr vom Analogen in das Digitale wandert. Das geschieht oft nicht durch 1:1 Nachbildungen sondern geht auch mit grundlegend neuen Ansätzen einher. Analog baute keiner einen direct conversion receiver, das wird ja nie was! Großteils digitalisiert haben wir es im WLAN chip, Bluetooth und Tri-Band Lowcost Handy chipset. Für den old-school Analogkämpfer ist das Digitale natürlich total umständlich, denn da gibt es noch nicht so ein breites Angebot (und breite Bekanntheit) an IP was es jedoch an verschiedensten Analogbausteinen schon ewig gibt. Letztenendes ist das Problem hier wohl ein soziales. Jemand oder eine Gruppe von Leuten hat ziemlichen Mist gebaut. Jetzt wollen die wieder irgendwie aus der Klemme kommen. Wie ich sagte, das ist wohl das Problem und deswegen die monatelange Suche nach der 5-Minuten Lösung. Da ist eine Lösung im freien Platz eines FPGAs nicht schlecht, so lange einer die Entwicklung bezahlt. Äußerlich betrachtet ist sie sogar einfach, kein verkorkstes System muss revidiert werden, nur ein bisschen mehr Programm ins FPGA.
Ich habe nichts gegen die Quantentheorie, aber sie hebt jedwedes menschliches Denken und Handeln auf. Oder wie willst du eine Schaltung realisieren, die keine Ursache-Wirkung-Relation kennt? Also knick diesen Blödsinn. Die Haupttriebfeder für die Digitalisierung ist das es billiger ist. Wen hätte es auch gewundert. Man bekommt Transistoren quasi geschenkt, wenn man nur genug von denen in einem Chip integriert. Nur leider eben nur die Transistoren bei einem FPGA oder ASIC. Widerstände, Kondis oder gar Spulen müsssen draußen bleiben. Auch mit der Linearität ist mit zunehmender Sub-mikron-Technik ziemlich ernüchternd Schluß. Es ist also immer ein Abwägen im Rahmen der momentanen technischen und persönlichen Möglichkeiten. Jedenfalls haben die Altvorderen die Meßlatte ziemlich hoch gehängt!
Abdul K. schrieb: > Ich habe nichts gegen die Quantentheorie, aber sie hebt jedwedes > menschliches Denken und Handeln auf. Seltsame Vorstellungen von der Quantentheorie. Wie kommst du dazu? Ich glaube viel eher die Quantentheorie hat halt das Potential manch gewohnte, populäre Weltsichten herauszufordern. Außerdem wird eine Menge reißerischer Quatsch erzählt. Wer nichts weiss muss alles glauben, das nutzen Medienschaffende halt gerne schamlos aus, ist deren Job und Werbung kauft deren Brot.
Worauf willst du hinaus? Bislang war für mich Quantentheorie gleich keine Ursache-Wirkung-Kopplung. Vielleicht falsch, wenn ja liegts einfach daran, daß ich meine Schaltungen zwar mit Quanten betreibe aber nicht entwickle. Und es war nicht ich, der mit QT anfing! Und mit der Presse habe ich privat mehr als genug zu tun. Was ist denn nun mit dem Takt? Irgendwo saß da ein Idiot.
Na, der thread sich ja nun weiss Gott entwickelt: Von den Grundlagen der Signalverarbeitung zur Quantentheorie und deren Bedeutung im Bezug auf die Digitalisierung. Wäre fast schon dissertationswürdig. Bevor es jetzt aber völlig philosphisch wird, nochmals kurz zum eigentlichen Thema: Ich verstehe die ganze Aufregung nicht. Ich habe schon wirklich Schlechteres an Signalen gesehen. Von Optokopplern kommen oft ziemlich dürfig aufgearbeitete Signale oder von extrem langen Leitungen, die nicht gut abgeschirmt sind. Ok, das Signal ist sicher kein vernüftiger Takt mehr, weil total verrauscht, aber zu prozessieren ist der ohne Weiteres. Spätestens nach einer einfachen FFT hat man ein sauberes Signal. Ich würde das in jedem Fall erst mal so probieren, bevor ich die Hardware umbaue. Terminieren dürfte hier z.B. kaum die Lösung sein. Dafür sind die Störungen viel zu niederfrequent. Das sind keine Reflexionen. Sieht mir mehr nach Industrielandschaft aus mit Hochspannung oder Magnetfeldern in der Nähe. Wenn da richtig was reinpfeifft, kann man den Eingang nicht niederohmig genug bekommen. Eigentlich geht es hier doch nur darum, die Aussetzer zu behandeln, damit es zu keinen Mehrfachschaltungen kommt. Im Grunde funktioniert das wie das Entprellen wobei wir hier noch den Vorteil haben, zu wissen, um welche Frequenz es sich handelt. >Taktflanken Die Taktflanken können so schlecht aussehen, wie sie wollen, sie werden ja gesampelt und müssen selber nichts mehr schalten. Im Prinzp tut der Eingang schon selbiges und generiert eigentlich einen ganz passablen Takt, bis auf eben die peaks. Solche Effekte können auf seriellen Leitungen immer mal vorkommen, wenngleich vielleicht nicht mit der Häufung. Im Grunde ist es eigentlich aber auch ganz egal, wie oft es passiert- Wegrechnen funktioniert immer, wenn es richtig gemacht wird. Benötigt wird einfach ein diskretes Tiefpassfilter. Das lässt sich am Einfachsten digital aufbauen. Dogberts Vorschlag ... Dogbert schrieb: > Eine nahezu digitale Lösung hätte ich anzubieten: > Man müsste zumindest eine art analoge Abtastung des Taktes mit dem > FPGA machen. Ein Rauschsignal (weißes Rauschen am besten) zu dem > Taktsignal addieren so dass sich die Schwelle des Eingangspuffers > damit verschiebt. ... geht zwar auch und hatte ich hier bereits auch einmal ähnlich beschrieben, als es um einen AD-Wandler mit einem Digital-Pin ging: Analog-IO mit digitalen Bausteinen ... und liefe letztlich auf das [[Dithern] des Eingangs hinaus. Ich halte das aber hier in diesem Fall nicht für nötig. Das Entmischen der Zielfrequenz erforderte zudem auch wieder einen Filter, der wiederum nicht so effektv arbeitet, wenn er nur klassisch analog realisiert ist. high tec ing schrieb: > Wie multipliziere ich jetzt genau? Mit einem Und-Gatter! Samplen, Verunden = Multiplizieren = Falten und dann Aufsummieren. > Ich hätte das Eingangs-bit umgeschrieben auf einen 16 bit-Wert Du musst das nicht "umschreiben" und pseud analog machen, es reicht ein FIR-mit 100%-0% Eingang = 1/0. Du multiplizerst einfach mit dem Zieltakt: 0000000111111110000000011111111 als "analoger" FIR-filter eben -1,-1, ... 1,1,1,1, etc. Die Summe wird dann einfach addiert = integriert. Damit interferieren die Quelle und das Soll. Die Folge muss halt zu den 2MHz und den 50 MHz passen, also 25 Werte. Du kannst dann einen weglassen, um symmetrisch zu bleiben (wegen 12:13) oder nimmst 48 MHz. Wenn nicht, musst Du aufpassen, dass das Signal über eine gerade Anzahl von Perioden summiert wird, sodass sich eine symmetrische Summe ergibt. Du kannst auch einen DC-Remover hinzufügen, der das Sigal künstlich symmetriert und am Weglaufen hindert, wenn Du immer am Ende eines Integrales einen Teil des Überbleibsels abziehst.
Noch was Grundsätzliches:
> Kommt da nicht ein Sinus raus?
Nein, nur mit einem echten FIR-Filter mit entsprechender Bandbegrenzung,
einem guten Fenster und wenn ein 100%iger Sinus reinginge, dann ja.
Allgemein gehen immer die Spektralanteile durch, die im Signal
drinstecken und die der Filter eben noch durchlässt, oder aufprägt. Mit
einer einfachen Taktmultiplikation appliziert man letztlich ja ein
Rechteck, also ein Signal mit Oberwellen. Die tauchen dann im Signal
logischerweise auch wieder auf. Daher ist es am Ende ein Dreieck -
nämlich das Integral des Rechtecks, das von/aus dem Filter kommt.
Diesen "Entscheider", der das Dreieck ansieht und angibt, ob als 1 oder
0 interpretiert werden muss, formuliert man sinnvollerweise mit einer
Hysterese. Tut man das nicht und dfferenziert das Dreieick einfach stur,
bekommt man de facto ein klassisches Hogenauer-Filter (CIC). Dieses wird
dann einfach in klassischer Weise einen bandbegrenzten Takt aus.
Wenn die einfache Variante nicht reicht, z.B. weil ein zu gosse DC oder
sonstige niederfrequenten Stärungen drauf sind, wäre der nächste Schritt
dann in der Tat die Übersetzung des Signals in einen virtuellen
Analogwert und Prozessierung mit einem "analogen" FIR mit
Bandausschnitt. Du solltest dann auch ein Fenster drüberlegen und zwar
eins, das ganzzahlig zum Takt passt. Allerdings wird die Geschichte dann
ziemlich gross, wenn man mit voller Taktfrequenz arbeiten will. Der
Filter müsste komplett gepipelined werden! Angesichts der Resourcen ist
meine binäre Variante die definitiv bessere, weil man mit deutlich
weniger resourcen viel mehr Takte erwischt.
Dies ist der massgebeliche Vorteil bei der Technik. Die
taktübergreifende Interpretation löst einiges an spike- und
Jitterproblemen.
Falls das alleine nicht geht, weil der Takt zu lange aussetzt, muss eine
diskrete PLL dahinter - keine quasi analoge, weil sie einen Ausfall
verkraften muss. Diese realisiert man mit einem Zähler der nur in einem
validen Zeitfenster, auf die Sollflanke schaut und sich weich
nachstellt. Das ist digital super einfach zu machen und äusserst
effektiv. Eine Taktreko mit CIC o.ä. habe ich noch nie gebraucht.
Abdul K. schrieb: > Im Allgemeinen ist die analoge Welt einfacher, wenn man was > analoges fixen will. Das klingt einfach und logisch - stimmt aber pauschal so nicht. Im "Allgemeinen" ist SW durchaus praktikabler und nicht selten auch technisch überlegen. Beispiele sind neben den o.g. diskreten Filtern auch manche Typen klassischer FIR-Filter, die analog praktisch überhaupt nicht nachzubauen sind. Selbiges gilt für die skizzierte diskrete PLL. Analog vielleicht noch möglich, aber definitiv aufwändiger. > Es irgendwie digital hinbiegen zu wollen, erfordert meist > erheblich mehr Aufwand. Da erhebe ich ebenfalls Widerspruch! Es gibt natürlich genügend Beispiele, wo man mit einem lumpigen RC-Glied elegant eine ganze Menge wegbekommt, ganz klar (und hier wäre dies sogar der Fall! :D ) Aber redesign ist eben redesign. Wenn man ein Problem in SW lösen kann, warum nicht? Ich hatte selber schon solche Fälle: Da hätte eine bessere Abschirmung auch das Problem gelöst, aber grosse Kosten verursacht, weil es auf eine MU-Metall-Ummantelung hinausgelaufen wäre, um magnetische Einstreueungen loszuwerden. In einem anderen Fall waren es Ionenstrahlen, die digitale Signale verunzierten. Eine Abschirmung war kaum und nur unter enormem Aufwand mit x-Multilagenboard und Bor-Beschichtung zu machen. Wie oben schon angedeutet ist gerade bei der seriellen Übertragung viel zu machen. Wenn man die Bitrate weiss, bekommt man mit simplen addierenden FIR-Filtern allerhand an spikes weg und kann schon deshalb viel höhere Datenraten fahren, weil weniger Redundanz benötigt wird um kaputte Daten zu wiederholen. Was ich schon gemacht habe, ist das Bitmuster vorauszuberechnen, den Flankenverschliff durch die begrenzte Bandbreite des Übertragungsweges zu berechnen und das gesampelte Pattern zu vergleichen, um das Originalmuster zu erraten. Mit jedem erkannten Bit wird der pattern estimator neu justiert. Geht vorzüglich. Das Ganze klappte so gut, dass Bitfolgen korrekt rekonstruiert werden konnen, die auf dem Oszilloskop nur noch mit grösster Mühe zu interpretieren waren. Bandbreitengewinn Faktor 12. Das baust Du in Analoger Hardware nicht nach. > Da ist selbst der geschenkte Aufwand äh Platz in > Form eines fast leeren FPGA nicht ausreichend ;-) Nun, Platzbedarf haben analoge Bauteile auch und sie können zudem kaputt gehen, sowie beim Löten einen Fehler verursachen. Es hat schon seinen Grund, warum heute nur noch billige Tastaturen ohne Cs eingesetzt werden und die Entprellung in Software gehandhabt wird. Um zu beurteilen, was man womit bekämpft, bzw. eine SW oder eine HW das Mittel der Wahl ist, muss man schon etwas genauer hinsehen, denke ich. Mich würden jetzt aber wirklich mal Messungen interessieren, die zeigen, woher die Probleme kommen und was die Ursache für diese miese Signalform ist. Wirklich alles EMV? - Nicht, dass da nicht vielleicht doch nur irgendeine Masse nicht angeschlossen ist :- Jetzt weiter mit der Quantentheorie:
Ich sehe bei dem o.g. Problem und den Lösungsansätzen durchaus Analogien zu dem Komplex Quanten <-> Analoges. Eine klassische Filterlösung oder eine virtualisierte mit digitalem FIR / Mischer wäre ja nichts anderes, als ein kontinuierliches Unterdrücken, wobei die Dämpfung über die Frequenz und das Ausmass der Störung hinweg immer stetig ist. Bei der Nutzung diskreter Filter besteht die Möglichkeit, unstetig und in quantisierten Informationspaketen zu arbeiten und Fehler, die sich digital verhalten (also auftreten oder nicht auftreten) auch in dieser Schwarz-Weiss-Arbeitsweise rauszuwerfen in dem man Methoden benutzt, die schlagartig einsetzen und nicht einsetzen - als quantisiert agieren. Diese Fehlerklasse müsste demnach schon vom Prinzip her mit diskreten Methoden besser bekämpft werden können. ?
Jürgen Schuhmacher schrieb: Mir ist nicht klar was du sagst, alles sieht für mich nach einem "Glitch Filter" aus. Mach doch mal ein eindeutiges Diagramm. Übrigens ginge mein Vorschlag auch mit 1-Bit Quantisierung des Taktes, das reduziert natürlich die Schleifenbandbreite. Eine Frage wie Niederfrequent die Störer sind. Der Nachteil dann ist längere Einschwingzeit auf den Takt, diese wird von der Schleifenbandbreite und die von dem niederfrequentesten Störer bestimmt. Mein Beispiel ist die klassische analoge PLL mit Multiplizierer als Phasenvergleicher zeitdiskret digital nachgebildet. Der konkrete Aufwand ist "peanuts" für zeitgemäße FPGAs, geschickte Implementation natürlich vorausgesetzt. Ich schätze mal 100-300 LUTS für: NCO, Sinus ROM, "Multiplizierer" der ein Multiplexer ist, ein IIR Schleifenfilter dass wohl ohne Multiplizierer auskommt, denn man ist ja etwas flexibel was die Schleifenbandbreite und den Dämpfungsfaktor angeht. Evtl. noch ein noch simpleres zweites IIR Filter dass Störungen und Mischprodukte durch die Quantisierung bei der Abtastung deutlich oberhalb der Schleifenfreqenz herausfiltert um den rekonstruierten Takt etwas sauberer zu machen.
Klingt alles sehr interessant, ist mir aber leider zu hoch schnell mal ne FFT im FPGA. Wenn das alles so einfach wäre, dann versteh ich nicht wieso ich nicht schon längst ne praktische FFT-FPGA-Soundkarte für Messungen hätte. Alles in Echtzeit und direkt in die Windoof-Soundarchitektur eingehangen. Ich spiele gerne mit dem Übergang zwischen Analog und Digital. Freue mich also über deinen obigen Beitrag. Bleibe aber hier in diesem Fall bei meiner Meinung! Und da ist der erste Punkt eine saubere Terminierung!!!!! Was am S/N weg ist, ist weg! Keinerlei irgendwie geartete Signalverarbeitung kann das wiederholen. Man kann höchstens überlegen, ob der gleiche Aufwand wie eine Terminierung nicht irgendwo anders reingesteckt, ein höhere Effektivität (Preis, Platz, Entwicklungskosten) bringen könnte - was ich bezweifele angesicht von max. 3 Widerständen und vielleicht einem C und zwei Spulen.
Dogbert schrieb: > Mir ist nicht klar was du sagst, alles sieht für mich nach einem "Glitch > Filter" aus. Könnte man so nennen, ja, er arbeitet aber auch als Jitter-Unterdrücker, da er über mehrere Takte arbeitet. Ob das gut ist oder schlecht, hängt vom Einzelfall ab. Den scheinbaren Jitter, der durch die Aufintegration durch die Störungen kommt, bekommt man durch die Länge des Fensters gut weg. Wird es zu gross, wird die Stabilität des Taktes besser, folgt aber wie eine PLL dem echten Jitter nicht mehr rasch genug. Ist am Ende eine Frage des optimalen Kompromisses. Unterstellt man, dass Takte nur in der Grössenordnung von 10% der Periode jittern, kann man ohne Weiteres 10 Takte aufintegrieren. > Mach doch mal ein eindeutiges Diagramm. Hab es doch beschrieben: Takt draufmultiplizieren und addieren. Dann entsteht das Dreieck , das man interpretieren kann. Z.B. wenn >0,1 -> 1 wenn <-0,1 dann "0" wenn dazwischen dann unverändert (Hysterese). Grafik hier: Beitrag "Re: Takt sieht schlimm aus - FPGA-Eingang optimieren?" Dort sind es 4 Takte. Alle glitches weg, Takt automatisch schön stabil in der Mitte. Dogbert schrieb: > Mein Beispiel ist die klassische analoge PLL mit Multiplizierer als > Phasenvergleicher zeitdiskret digital nachgebildet. Kann man noch draufsetzen, wenn nötigt, ja. Wie schon erwähnt muss sie aber in einem Fenster sensitiv gemacht werden, das zum Takt passt: Dann fällt sie auch nicht aus, wenn der analoge Takt infolge niederfrequenter Störungen längere Zeit zu einer Seite ausschlägt und damit nicht taktet. Im Fenster wird ermittelt, ob eine Taktänderung stattgefunden hat und wann und gfs die Taktperiode aktualisiert. Wird kein Flankelwechsel erkannt, läuft der Takt blind weiter. Natürlich gibt es dafür Grenzen, aber wenn die Periode bekannt ist, kann man etliche Takte wirksam überspringen. Allerdings sind wir dann schon in dem Bereich wo auch die Daten mutmasslich zu kaputt sind. Abdul K. schrieb: > ist mir aber leider zu hoch schnell mal ne FFT im FPGA. Kann man einfach instanziieren. Aber eine FFT brauchen wir ja nicht, sondern nur die eine Frequenz. Beim digitalen Multiplizieren nimmt man eben nur keinen Sinus sondern ein Rechteck (0,1,0). Das Ergebnis ist damit nicht das Integral vom Sinus, also etwa ein Cosinus, sondern das Integral eines Rechtwecks, nämlich ein Dreieck. > Wenn das alles so einfach wäre, dann versteh ich nicht > wieso ich nicht schon längst ne praktische FFT-FPGA-Soundkarte für > Messungen hätte. Ich kann Dir nicht beantworten, warum DU das nicht hast. :-) Ich habe das durchaus: http://www.96khz.org/htm/spectrumanalyzer.htm Den Core dafür habe ich sogar hier im Forum gepostet: Projekt VGA Core in VHDL Man sollte halt nur ein moderneres FPGA nehmen. In den Spartan 3 geht ja fast nichts rein. In einen Spartan6 hingegen bekommst Du ohne Weiteres eine komplette FFT mit 64k samples und mehr. Wenn Du es für Sound bauen willst, fasst Du am Besten die Frequenzen einer Oktave in Gruppen zusammen, um einen logarithmischen Verlauf der Achse zu bekommen. http://www.96khz.org/htm/cyclone4platform.htm (Bild ganz unten)
Interessant, werde ich mir näher ansehen. Entschuldige, aber ich kann mir nicht jeden Thread hier ansehen - auch wenn ich schon 8000x irgendwas schrieb. Das alleine sind ja schon einige Wochen Arbeitszeit. Vieles ist ja auch Müll oder wurde 100x schon beantwortet. Meine EMU0202 ist für sowas schon ein geiles Spielzeug. Man sieht 90KHz direkt in einer FFT. Aber die Bandbreite müßte mehr sein. Eine 384KHz Soundkarte sah ich bislang noch nie und reine Meßkarten sind entweder irre teuer oder klinken sich eben nicht in die Win-Soundarchitektur ein. Daher Stillstand mangels FGPA- und Treiber-Kenntnisse :-(
Wäre es möglich, daß du deine Website mal etwas aufräumst? Wo ist z.B. der GEMA-Artikel zu finden? Gibt nur einen Server-Error.
Angehängte Dateien:
-
overview.GIF
74 KB -
detail.GIF
80 KB
Da mich interessiert hat was in solchen Fällen mit einfachen Mitteln noch zu machen ist habe ich eine Lösung entwickelt. Keine externe Änderung, der gestörte Takt geht in den Eingangspuffer, nur das Tastverhältnis sollte nicht zu extrem sein also 50%+-15%, denn das wird zu einem Phasenfehler, den man natürlich statisch kompensieren könnte wenn das Tastverhältnis bekannt ist. Braucht z.B. im Cyclone 3 251 LE und läuft mit 80Mhz, ist also vom Ressourcenbedarf unerheblich. Simulieren kann man alles einfach mit Modelsim von Quartus web. Im 2. Screenshot 'in' ist der digitale Takt nach einem Eingangspuffer, man sieht wie gestört dieser ist. "phasediff" ist die Phasendifferenz auf eine Periode normiert vom idealen Takt zum Rekonstruierten. Simuliert habe ich mit der einem idealen Takt der 500ppm von der idealen Frequenz abweicht und einem Tastverhältnis !=50%, diesem weißes Rauschen (random Funktion) addiert was sich spektral gleichmäßig verteilt und dieses auf 1 Bit quantisiert (Eingangspuffer). Das weiße Rauschen hat eine pp Amplitude fünf mal größer als das pp des Rechtektakts! Natürlich ist bei der realen Störung diese nicht Spektral gleichmäßig verteilt was solch extreme S/N wohl praktisch nicht erreichbar macht. Reduzierte man den Fangbereich also die zulässige Toleranz von Rekonstruiertem zum Sampletakt wäre noch eine extremere Störung rekonstruierbar. Wollte man das Beispiel etwas adaptieren ist ein Verständnis von Signalverarbeitung und PLL, second order feedback loops sinnvoll. Das "high tec" Projekt ist gerettet.
Dogbert schrieb: > 50%+-15%, denn > das wird zu einem Phasenfehler, Warum brauchst Du die Kenntnis / die Beschräkung des Tastverhältnisses? Eigentlich sollte die Rekonstruktion das doch liefern. - abgesehen von den Verzerrungen durch die einstreuenden Fehler. Meine Additionsmethode wirf das TV aus. Für eine PLL würde ich diskret auf eine Flanke setzen. Für ein variables TV eben zwei PLLs. Eine agiert auf steigend, die andere auf fallend. Was macht Deine PLL im Fall des Ausfalls des Taktes? Dogbert schrieb: > Braucht z.B. im Cyclone 3 251 LE und läuft mit 80Mhz, ist also vom > Ressourcenbedarf unerheblich. Bei mir wären es zwei Addierer für z.B. 16 Bits/LUT-Eingänge pro Takt, also z.B. 64 Bits für 4 Takte. Dann ein Subtrahierer für die beiden Werte (zwischen 0... 64) plus einige Register. Geschätzt <150 LEs. Das wäre aber schon die Luxusversion :-) Die Urversion läuft in einem Micki-PLD der 4000er Serie.
Was mir (abseits der Wiederherstellungsversuche) zu denken gibt: wenn das schon "nur" der Takt ist, wie sehen dann die zugehörigen Daten aus? Denn high tec ing schrieb: >>>> Mit diesem müssen aber die Daten übernommen werden
Jürgen Schuhmacher schrieb: > Warum brauchst Du die Kenntnis / die Beschräkung des Tastverhältnisses? Ich brauche es nicht, Tastverhältnis führt zu Phasenverschiebung. Das ließe sich kompensieren, geht man davon aus dass die Störsignale kein DC enthalten. Jürgen Schuhmacher schrieb: > Was macht Deine PLL im Fall des Ausfalls des Taktes? Erzeugt eine Frequenz im Bereich des spezifizierten Solltakts +- der spezifizierten Toleranz. Wenn ich richtig verstehe was du zu beschreiben versuchst dann ist was du meinst eine Art synchroner Glitch-Filter. Dieser braucht einen zum Rekonstruktionstakt synchronen Takt und filtert Störungen aus wenn diese spektral weit genug oberhalb des Rekonstruktionstakts liegen. Wenn deine Lösung so einfach ist, sollte es ja ein leichtes sein diese wie ich auch zu modellieren so dass man mal über konkrete Dinge sprechen könnte. Lothar Miller schrieb: > Was mir (abseits der Wiederherstellungsversuche) zu denken gibt: wenn > das schon "nur" der Takt ist, wie sehen dann die zugehörigen Daten aus? > Denn high tec ing schrieb: Auch hier ist evtl. mehr machbar. Zwischen den hochfrequenten Anteilen von rekonstruiertem Takt und Daten könnte man korrelieren, hier macht evtl. eine genauere Abtastung als mit einem Bit Sinn.
Dogbert schrieb: > Wenn deine Lösung so einfach ist, sollte es ja ein leichtes sein diese > wie ich auch zu modellieren so dass man mal über konkrete Dinge sprechen > könnte. Hab ich doch. Oben habe ich ein Diagramm gepostet und beschrieben, wie es funktioniert. Es kommt jetzt nur auf die Implementierungswünsche an: Voll sequenziell ist das das UND-Gatter mit Addierer, vollparallel der Wert selbst. Für den o.g. Fall nehme ich jetzt mal 16 MHz Abtastfrequenz, damit es einfacher wird. Der Eingangsport kommt auf ein Schieberegister mit 16 Bits. Da die Zielfrequenz 2 MHz sein soll, gibt es 4 Bits je Halbtaktphase. Man addiert folglich die Bits 1,2,3,4,9,10,11,12 und zieht die anderen 8 der lo-Phase ab. Das entspicht der Multiplikation mit dem Takt über 2 Perioden. Wenn der Takt optimal passt, erhält man den Wert 8, bei totaler Opposition den Wert -8. Das ergibt das orange Dreieck. Fertig ist die Laube. Das ist doch nichts anderes, als was bei FFT und FIR-Filterung (COS-Multiplikation) auch passiert. Nur eben digital, statt analog. Je nach Taktrelation kann man das nun sequenzialisieren.
Lothar Miller schrieb: > Was mir (abseits der Wiederherstellungsversuche) zu denken gibt: wenn > das schon "nur" der Takt ist, wie sehen dann die zugehörigen Daten aus? > Denn high tec ing schrieb: >>>>> Mit diesem müssen aber die Daten übernommen werden Vermutlich genau so, nehme ich an. Die prozessiert man sinnvollerweise mit einer ähnlichen Methode, wobei die Datenrekonstruktion nur über 1 Bit gehen darf. Auch hier wird wieder ein (schlechtes) Dreieck entstehen, das man mit dem vorgegebenen Flankenwechsel abtastet - ja nachdem, ob es edge aligned oder centre aligned ist etc.
Angehängte Dateien:
-
freq.GIF
7,6 KB
@Jürgen Schuhmacher Aha, ein Kammfilter als Glitch-Filter. Bei dem Frequenzgang, der Bandbreite und dem Nebenmaximun unterhalb der Nutzfreqzenz kann man nur von einer schwachen Störunterdrückung, bestimmt keiner Breitbandigen sprechen. Erst ab ca 3MHz oder unter 200Khz hat es eine nennenswerte Unterdrückung von 10Db. Zudem braucht es eine Hysterese am Ausgang zur Unterdrückung der Störungen. Störungen / Störfrequenzen im riesigen Durchlaßbereich können die Phase empfindlich verschieben, Jitter produzieren. Eigentlich ein Glitch-Filter der erst für Störungen ab ca. 4Mhz werwendet werden sollte. Nein danke, ich leiste mir gerne meine 250 LE "Luxus" wenn ich mal ein solches Problem lösen will. Dann weiss ich ziemlich sicher dass außerhalb 50Khz um den Takt Störungen sicher unterdrückt werden und die Phase nicht ändern. Auch weiss ich dass selbst im Durchlassbereich der Takt nur ca. 10Db über dem Rauschen sein müsste.
Danke, dass ihr euch alle so viele Sorgen um mein Projekt macht, aber das Problem ist schon gelöst. Ich habe einen normalen Filter auf die Signale gelegt, der oberhalb von 2 MHz und unterhalb von 2kHz bandbegrenzend wirkt. Benutzt werden 8 Bit - klappt prima! Jürgen's Variante werde ich bei Gelegenheit probieren. Vielleicht kann ich etwas Platz sparen für die Kanäle.
high tec ingenieur schrieb: > Danke, dass ihr euch alle so viele Sorgen um mein Projekt macht, Es geht ja auch mal darum einen generelleren Ansatz für solche Problematiken durchzudenken. Wie schlimm kann es werden, bis wirklich nichts mehr zu machen ist? Ich habe dann auch mal die "FIR" Kammfiltervariante in die Länge gesteigert bis sie ähnlich zur "IIR" PLL-Taktrekonstruktion funktionieren könnte. So ca. 4096 Taps müssten es dann schon sein. Das wäre ein erheblicher Aufwand. Die leichte Wahl der Durchlassfrequenz ist bei Verzicht auf Multiplizierer dahin, die Abtastfrequenz muss geradzahliges Vielfaches sein. Und je länger das Kammfilter, desto genauer muss diese stimmen.
Dogbert schrieb: > Bei dem Frequenzgang, der Bandbreite und dem Nebenmaximun unterhalb der > Nutzfreqzenz kann man nur von einer schwachen Störunterdrückung, > bestimmt keiner Breitbandigen sprechen. Erst ab ca 3MHz oder unter > 200Khz hat es eine nennenswerte Unterdrückung von 10Db. > > Zudem braucht es eine Hysterese am Ausgang zur Unterdrückung der > Störungen. Die Argumentation ist genau anders herum: WEIL ich in der digitalen Domain ein Hysteresefilter mit diskreten Grenzen einsetzen kann, habe ich die Möglichkeit, auf eine einfachere Signalvorarbeitung zurückzugreifen. Und davon sollte man Gebrauch machen. > Erst ab ca 3MHz oder unter > 200Khz hat es eine nennenswerte Unterdrückung von 10Db. 10dB ist bereits extrem viel! Du darst nicht vergessen, dass es um die Trennung von nur 3 diskreten Signalleveln geht: high, low und undefined. Es ist daher nicht nötig, die Taktfrequenz als solche in der analogen Betrachtung genügend genau herauszufiltern, damit sie ein Takt werden kann, sondern es reicht die glitch-Unterdrückung. Ich beziehe mich dabei auf das Diagram des TE und meine eigenen Untersuchungen: Zwar wird ein "ordentliches" Filter den Takt wesentlich besser rekonstruieren, aber ein deratiges Filter wäre nicht auf die Daten anwendbar, da hier keine Annahmen über die Frequenz gemacht werden können. Schon ein 10 Bit Datenstrom bedürfte ein sehr breitbandiges Filter, das offen wäre für allerlei Störungen. Damit macht es keinerlei Sinn, Takte sehr viel genauer rekonstruieren zu wollen - da es an den verschmutzten Daten scheitern wird. Überdies haben wir aber einfache Methode, den Takt besser zu rekonstruieren, weit über das bestehende/geforderte Niveau hinaus: Gerade weil ich so einfach arbeite, bekomme ich mit derselben Fläche im FPGA viel mehr Takte überdeckt, die mir die Probleme wegglätten. Dies ist erheblich effektiver, als den qualitativ besseren FIR-Filter. Ich habe das genauestens untersucht und nicht umsonst arbeite ich so. Zudem muss es ja nicht bei der Dreieicksbildung bleiben: Man kann dort die Geraden eininterpretieren und sogar die Maxima der Schnittpunkte festlegen, da diese ja bekannt sind: Damit werden sehr präzise Phasenmessungen in einfachster Weise möglich. Und möglich wird es durch die Bildung der Dreieicke: Mit Sinuswellen wird der fit umständlicher und genau deshalb ist der Rechteckfilter genau der Richtige- WEIL er genau die richtigen "Mängel" im Sperrbereich hat, die als Durchlass für die LaPlace'schen Oberwellen des Dreieicks agieren.
Jürgen Schuhmacher schrieb: > Zwar wird ein "ordentliches" Filter den Takt wesentlich besser > rekonstruieren, aber ein deratiges Filter wäre nicht auf die Daten > anwendbar, da hier keine Annahmen über die Frequenz gemacht werden > können. Du scheinst zu vergessen dass ein instabiler rekonstruierter Takt die Fehlerrate bei der Datenrekonstruktion mit Glitch-Filter steigert.
Angehängte Dateien:
-
clock-regen1.PNG
14 KB -
clock-regen2.PNG
11 KB -
clock-regen3.PNG
11 KB
Sodele, es gibt Neues: Durch die Störungen kommen eigentlich zwei Bereiche zustande, wo es keinen sauberen Takt gibt: Einmal links im Bild wo der Pegel zu hoch ist und recht wo der zu gering ist. Dort sorgt das Rauschen jeweils für glitches. Zusätzlich sind in der Simulation einige händische glitches eingebaut. Ich habe Jürgen's Variante ausprobiert und in der Tat entsteht ein eindeutiger Takt ohne glitches. Er hat nur noch ziemlich viel jitter. D.h. die Flanken sind nicht sauber in der Mitte. Die Entscheidung ob low oder high mache ich mit >2 und <-2. Das scheint zu funzen!
Jürgen Schuhmacher schrieb: > Mich würden jetzt aber wirklich mal Messungen interessieren, die zeigen, > woher die Probleme kommen und was die Ursache für diese miese Signalform > ist. Wirklich alles EMV? Es sind wirklich Einflüsse von Aussen, die auf die Leitungen wirken. Vorwiegend magnetische. Die Massen sind alle angeschlossen. Mit dem Filter das ich nun habe, bekomme ich den Takt gut genug hin. Ich habe einfach die Daten mit 2,5MHz angesetzt, damit es besser zu dem 50 MHz Takt passt. Nochmals danke für den Tipp. Nach anfänglichen Verständnisproblemen, habe ich nun auch das Prinzip verstanden. Eigentlich simpel. Ich habe es als Test in einen Chip gebracht: Es sind 117 slices. Bei einem Register von 80 Takten. Ich hatte auch 100 probiert, aber das war schlechter. Dogbert schrieb: > Wollte man das Beispiel etwas adaptieren ist ein Verständnis von > Signalverarbeitung und PLL, second order feedback loops sinnvoll. Hab mir das ebenfalls mal angesehen, komme damit aber noch nicht ganz klar. Könntest Du das beschreiben, wie Du das machst?
Dogbert schrieb: > Du scheinst zu vergessen dass scheint nur so, richtig :-) Wie bereits mehrfach ausgeführt habe ich das untersucht und bin nicht umsonst auf diese Lösung gekommen. > ein instabiler rekonstruierter Takt die > Fehlerrate bei der Datenrekonstruktion mit Glitch-Filter steigert Den Satz verstehe ich nicht. Wir haben keinen rekonstruierten Takt der in in glitch Filter geht sonder nutzen einen Filter um einen Takt wiederherzustellen ... und zwar einen, wie er oben dargestellt ist. Ich möchte nochmals herausstellen, dass bei dem hier gegebenen Problem zunächst ein Samplen durch den Eingang / den Pin erfolgt. Damit werden Störungen, die in Summe kleiner sind, als Pegel minus Schaltschwelle vollständig unterdrückt. Da kommt gar nichts durch - im anderen Fall bekommt man einen falschen peak einer Länge, die dem Integral des Signals auf der anderen Seite der Schwelle entspricht. Dieses Filter ist ein gänzlich nichtlineares und damit gestaltet sich die klassische analoge Betrachtung des Frequenzganges nicht so einfach, wie Du es oben andenkst. Ich gehe daher vom IST-Zustand des Problem aus und der ist offenkundig dadurch gekennzeichnet, dass der Takt im Grossen und Ganzen passt und lediglich einzelne Aussetzer hat, die es zu behandeln gilt. Diese Aussetzer sind im Frequenzspektrum gerade jenige mit hohen Frequenzen, da sie kurz und steilflankig sind. Wären sie niederfrequenz und energetisch bedeutsam genug, eliminierten sie den Takt über mehrere Perioden. Dies ist offenbar nicht der Fall, daher kam ich mit meinem einfachen Lösungsverschlag. Für den Fall, dass es dennoch Aussetzer gibt, kommt die digitale PLL zum Einsatz. Dort bewegen wr uns aber schon in einem anderen Fall: Ein Takt, der solch einer Behandlung bedürfte, liesse auf viel massivere Störungen schließen, die gleichsam implizierten, dass die zugehörigen Daten ebenfalls zerstört wären. Damit ist eine noch bessere und funktionable(re) Taktrekonstruktion zwar fein - aber leider nutzlos. Dogbert schrieb: > Es geht ja auch mal darum einen generelleren Ansatz für solche > Problematiken durchzudenken. Das ist ein lobenswertes Vorgehen, das aber akademisch bleibt - bzw. auf andere Fälle applizierbar wäre. Der Ingenieur sucht immer nach der einfachsten und billigsten Lösung. :-) Und sie scheint ja auch zu fruchten, wie ich hier lese:
high tec ing schrieb: > in der Tat entsteht ein eindeutiger Takt ohne glitches. klingt schon mal gut, wobei zu hinterfragen ist, ob Dein Simulationsbeispiel die Realität genügend erfasst. > Er hat nur noch ziemlich viel jitter. Das ist sehr viel für meinen Geschmack. Von der Anschauung her kann da was nicht ganz passen. > D.h. die Flanken sind nicht sauber in der Mitte. Wo die Flanken stehen, hängt von der Phase des Musters ab, mit dem Du den Takt verundest. Das kann man schieben. > Die Entscheidung ob low oder high mache ich mit >2 und <-2. Das ist zu wenig. 10% von der Taktamplitude wären gut. Mit fällt aber gerade etwas auf: In dem einen Bild rechts mit dem Cursor erkenne ich als Maximalpegel für die Amplitude des Dreiecks gerade mal den Wert 8. Das ist viel zu wenig. Wenn Du 80 Register genommen hast, pendelt der Wert zwischen -40 und 40! high tec ing schrieb: > Ich hatte auch 100 probiert, aber das war schlechter. Das kann gar nicht sein. Das ist ein deutliches Zeichen für ein mismatch. Bist Du sicher, dass der Takt zu dem Taktmuster passt?
Angehängte Dateien:
-
rekonstruierter-takt1.PNG
13 KB -
rekonstruierter-takt2.PNG
10 KB
Ja, leider. In der test bench hatte ich noch den alten Takt von 2,0 MHz. Jetzt stimmt es und ich muss sagen: WOW!!! Hätte ich nicht gedacht, daß das so gut funzt! Ich kann sogar die Störungen weit über das Ausmaß der realen Effekte hochdrehen und dennoch wird der Takt stabil überbrückt, obwohl er eigentlich komplett ausfällt. Jetzt sind es so 130 FFs in der Synthese. Angeschaut werden 5 Takte, es geht aber auch bei 4 und mit realen Störungen auch bei 3. Ich lasse es jetzt aber so und kümmere mich um die Daten. Mittelfristig werde ich probieren, 3 MHz zu testen, muss allerdings zuvor auf 60 MHz abtasten, damit das Muster reinpasst.
Angehängte Dateien:
-
overview.GIF
140 KB
Jürgen Schuhmacher schrieb: > Den Satz verstehe ich nicht. Wir haben keinen rekonstruierten Takt der > in in glitch Filter geht sonder nutzen einen Filter um einen Takt > wiederherzustellen ... Das Glitchfilter für die Daten braucht einen Sample-Zeitpunkt oder Takt, den Rekonstruierten. Ansonsten lasse ich Fakten Sprechen. Meine Jitter-Filter PLL braucht nach Optimierungen 103 Register in Quartus, nicht 130 Register und ist was die Peformance angeht stark überlegen. Auch die Anwendbarkeit. Die Arbeitsfrequenz und der Fangbereich ist einfach Parametrisiert, das Glitch-FIR kann nur bestimmte geradzahlige Verhältnisse Samplefrequenz/Takt, vor allem wenn es länger wird oder falls man eine höhere Ordnung benutzen würde, was dann im Endeffekt auf eine ähnliche Leistungsfähigkeit hinauslaufen würde. Da es aber mit 26x4 Taps schon deutlich mehr Ressourcen als meine Jitter-Filter-PLL braucht ist da wohl keine Diskussion mehr nötig, denn der Ingenieur sucht ja immer nach der einfachsten Lösung, nicht? Am Screenshot sieht man dass die Rekonstruktions-PLL klar überlegen ist. "analog_fir" ist das modell des gestörten Analogsignals. "phasediff" ist die Phasenverschiebung idealer Takt zu Rekonstruiertem, normiert auf eine Periode. "phasediff2" das gleiche für das FIR Glitchfilter. Kein Wunder, entspricht sie doch etwa einem Glitch-FIR mit Tausenden von Taps, ist quasi die "IIR Alternative", hat eine wesentlich stärkere Störunterdrückung. Zudem bleibt die PLL auf ihrer Frequenz unbegrenzt lange stehen wenn der Takt ganz ausfällt. Am besten mit Modelsim selbst simulieren und anschauen. high tec ing schrieb: > Hab mir das ebenfalls mal angesehen, komme damit aber noch nicht ganz > klar. Könntest Du das beschreiben, wie Du das machst? Testfixture und jitterfilter hängen an. Sollte halbwegs selbsterklärend sein.
Mensch Dogbert, Du hast Dich jetzt echt daran festgebissen, die ideale Taktrekonstruktion bauen zu wollen, aber die Lösung geht nach meiner Meinung schon irgendwie an der Aufgabe vorbei. So gestört ist der Takt nicht, den Bildern zufolge und wenn er es wäre, sodass eine afwändigere Reko nöig wäre, gäbe es keine Chance, die Daten sinnvoll zu kriegen. Das hatte ich bereits geschrieben. Die PLL generiert Dir zwar den perfekten Takt und für andere Applikationen mag das seine Berechtigung haben, aber ich sehe den Bedarf dafür nicht. Im Gegenteil, es gibt ein grundsätzliches Problem: Wenn die Taktfrequenz "zu stabil" ist, kann sie dem Jitter des eigentlichen Taktes nicht mehr folgen und generiert einen künstlichen Phasenversatz zu dem optimalen Samplezeitpunkt. Die Daten werden ja mit genau diesem jitternden Takt rausgegeben - z.B. von einem FPGA mit spread spectrum setting für die PLLs (und auch ohne jittern FPGAs nicht unerheblich). Daher muss die Taktreko ein Kompromiss zwischen dynamischer Anpassung an denselben und pauschaler Störunterdrückung sein und der Kompromiss ist eben jener eines einfachen digitalen Taktfilters ausreichender Länge und genügender Kürze. Daher machen 4096 TAPs, bzw eine äquivalente Schaltung dazu, so oder so schon keinen Sinn mehr. Variiere mal die Taktperiode und schau Dir an, wie "hart" Du Deine PLL einstellen musst, um einen sinnvollen primären Jitter, den man bei den 2MHz ansetzen müsste, handhaben zu können. >130 taps Und selbst die braucht man nicht. Man muss auch nicht immer automatisch mit der vollen Taktfrequenz sampeln, wenn der Systemtakt sehr viel höher sein sollte. Das ist nur bautechnisch vereinfachend. So, wie die Daten aussehen, reicht ein 16er Filter, wie oben angedeutet - vielleicht 32, wenn es hoch kommt. Vorausgesetzt, man rechnet richtig. Wenn Ich Deinen Verilog-Code grob überfliege, hat der noch 2 Mängel: Die Hysteresegrenzen sind zu weit für die erzielte Amplitude der Filtersumme und selbige scheint mir auch nicht optimal gebildet. Sieht so aus, als ob Du die Gegensumme mit den Nullen des Signals bildest. Wenn man mit komplementärer Summe arbeitet, sollte auch das Signal symmetrisch sein. Diesen Schritt finde ich nirgends im Code. hi tec ing schrieb: > Jetzt sind es so 130 FFs in der Synthese. FlipFlops oder slices? Welcher FPGA? Ich weiss nicht, was ihr da nachbaut, aber die erste Summe in meinem Diagram oben wird über 16x2 samples gebildet und bringt kein 1/10 Takt an Fehler gegenüber der Taktmitte, trotz extremerer Störungen, als in den Bildern des TE. Das reicht locker aus. Als nächsten Schritt müsste man sich erst mal um eine intelligente Datenrekonstruktion kümmern.
Jürgen Schuhmacher schrieb: > Variiere mal die Taktperiode und schau Dir an, wie "hart" Du Deine PLL > einstellen musst, um einen sinnvollen primären Jitter, den man bei den > 2MHz ansetzen müsste, handhaben zu können. Noch besser, ich hab mal mit 30Khz Dreieck-Modulation und +0.5% Spread simuliert was bei Spread Spectrum für EMI üblich ist. Ergebnis: Der zusätzliche Jitter zum Spread Spektrum Takt nur ca. 20ns, unter der Auflösung durch die 50Mhz Abtastung der PLL. Der Jitter des 2MHz SS Takts zu einem Idealen ist bei 30Khz Modulation und 0.5% Spread eh nur ca 42ns. Werden FPGAs und die PLLs darin normal verwendet, dann jittern die deutlich weniger als ein SS Takt, sonst machte SS ja keinen Sinn und würde nicht als schaltbares Feature angeboten. Wollte man trotzdem die Schleifenbandbreite der Rekonstruktionspll von hier ca. 20Khz vergrößern, dann wäre das durch Änderung eines Parameters getan. Jürgen Schuhmacher schrieb: > Wenn Ich Deinen > Verilog-Code grob überfliege, hat der noch 2 Mängel: > > Die Hysteresegrenzen sind zu weit für die erzielte Amplitude der > Filtersumme und selbige scheint mir auch nicht optimal gebildet. Sieht > so aus, als ob Du die Gegensumme mit den Nullen des Signals bildest. > Wenn man mit komplementärer Summe arbeitet, sollte auch das Signal > symmetrisch sein. Diesen Schritt finde ich nirgends im Code. Verständnismängel? Ich verstehe nicht. Da gibt es keine Hysterese. Was funktioniert denn praktisch nicht richtig?
Dogbert schrieb: > Verständnismängel? Ich verstehe nicht. Da gibt es keine Hysterese. Was macht denn dann der Konstrukt mit der Abfrage nach der 15? Tja, das wäre dann schon ein potentielles Problem Deiner Version der Schaltung. Meine hat eine und dies aus gutem Grund: Ein eintretender spike würde zu einem kurzen Auf- und Abwärtszählen bei der Integration führen. Tritt dies im Umschaltpunkt auf, geht er durch. Die Hysteresespannweite bedingt ja die Amplitude unterhalb unterdrückt wird. Dogbert schrieb: > Noch besser, ich hab mal mit 30Khz Dreieck-Modulation und +0.5% Spread > simuliert was bei Spread Spectrum für EMI üblich ist. Das allein ist noch kein jitter. Vielleicht hätte ich das Thema SS als Beispiel lieber nicht einwerfen sollen, denn diese Art der Modulation besitzt eine sehr geringe - um es genau zu sagen - die nahzu kleinste denkbare Beschleunigung der Frequenz (nur der Sinus wäre homogener) und dem kann eine PLL sehr gut und leicht folgen. Das ist für unser Problem kein anspruchsvoller Testfall. Dogbert schrieb: > Ergebnis: Der zusätzliche Jitter zum Spread Spektrum Takt nur ca. 20ns, > unter der Auflösung durch die 50Mhz Abtastung der PLL. q.e.d - Wenn man zufälligen jitter simuiert, dürfte das anders aussehen. Dogbert schrieb: > dann jittern die deutlich weniger als ein SS Takt, sonst machte > SS ja keinen Sinn und würde nicht als schaltbares Feature angeboten. Das ist richtig, was Du sagst, schneidetaber wieder ein anderes Thema an: Der Jitter, auf den ich mich beziehe und den wir unterstellen müssen, ist ein zufälliger, der auch und besonders bei bei FPGAs mehr mit Schalteffekten zu tun hat, als mit dem, was die PLL netto abgibt. Aber wir kommen vom Hundersten in Tausendste. Nochmal konkret zum Problem: Die Bilder des TE zeigen einen analog schlechten Takt, da ist mit einigem zu rechnen, woher es auch immer kommen mag. FPGA war ja nur eine Vermutung. Wer weiss, wie der Originaltakt aussieht, der das Gemüse produziert. Am Ende ist es ein Controller mit Schiebregister oder eine SPS.
Jürgen Schuhmacher schrieb: > Was macht denn dann der Konstrukt mit der Abfrage nach der 15? > > Tja, das wäre dann schon ein potentielles Problem Deiner Version der > Schaltung. 15? Ich glaube du hast auf
1 | if (rslt>15'sd3) |
2 | sro[0]=1; |
geschaut. Weisst du wie eine PLL funktioniert? Das war die Glitch-Filter Variante, also deine Lösung, also dein "potentielles Problem". Du kannst auch einfach zugeben dass deine Lösung bei mehr Aufwand schlechter ist anstatt hier immer mehr scheinbare Mängel und "potentielle Probleme" zu erfinden. Jürgen Schuhmacher schrieb: > q.e.d - Wenn man zufälligen jitter simuiert, dürfte das anders aussehen. Das ist in meiner Testfixture doch drin. Es wird weißes Rauschen auf den Rekonstruktionstakt addiert der zu einem Jitter wird. Kein Problem. Überlegen wir uns doch mal die Jitterquellen in Digitalschaltungen, FPGAs und PLLs. Diese sind hochfrequente Störungen, Phasenmodulationen auf das Nutzsignal, also mit zunehmender Freqenz an Amplitude zunehmend. Daher spielen diese sich praktisch unter ca. 0.05UI (unitinterval) auf Boardebene und unter Bauteilen ab. Logisch, sonst müssten zu große Abstriche bei der maximalen Betriebsfrequenz bei allgegenwärtiger PLL-Nutzung in fast jedem Digitalbauteil heute gemacht werden. Diser Jitter ist also hochfrequent aber hat eine kleine Amplitude. Dann der Jitter von Spread Spectrum. Er erreicht 0.1UI da seine Frequenz niedriger ist. Dann wäre da noch der Jitter aus PLLs. Tendenziell eine Frequenzmodulation durch Störungen auf den VCO, also mit hohem Problempotential. Praktisch aber nicht, denn die niedrigen Frequenzen unterhalb der Schleifenfrequenz einer typischen PLL in einem FPGA von ca 100KHz-1MHz werden von der Referenz bestimmt und diese ist i.d.r. ein Quarzoszillator / Resonator etc. mit Jitter-Werten die hier auch Irrelevant sind. Und selbst wenn der Jitter der Quelle schon extrem wäre, was wohl sehr unwahrscheinlich ist, dann könnte man die Rekonstruktionspll mit einer höheren Schleifenbandbreite parametrisieren, hätte noch weniger Ressourcenbedarf (weniger Bits für Schleifenfilter und NCO) und trotzdem eine überlegene Taktrekonstruktion die nicht auf Amplituden und mit Hysterese versucht ihr Ziel zu erreichen, sondern auf Flanken und Frequenzen geht. Das Problem auf Amplituden zu arbeiten ist die Nichtlinearität des Eingangspuffers, er macht alles zu 1 oder 0. Die Glitch-Filter Lösung versagt wenn die Störung länger als das Filter ist total und da der Eingangspuffer nichtlinear ist also der Takt quasi mit der Störung unterdrückt wird ist das die denkbar schlechteste Lösung.
Dogbert schrieb: > Das war die Glitch-Filter Variante, also deine Lösung, also dein > "potentielles Problem". Nein eben nicht. Du hast meinen Einwand nicht verstanden. Wenn Du keine Hysterese eingebaut hast, wie Du oben sagst, oder eine mit falschen Grenzen, dann hast Du meine Schaltung nicht richtig nachgebaut und rennst bei dem gesamten Vergleich der Verfahren dem falschen Hasen hinterher. Kein Wunder, dass bei Deiner Variante nichts Gescheites rauskommt oder meine Lösung angeblich grösser ist. Dogbert schrieb: > Das ist in meiner Testfixture doch drin. Es wird weißes Rauschen auf den > Rekonstruktionstakt addiert der zu einem Jitter wird. > Kein Problem. Leider nochmal falsch gedacht. Dieses Rauschen repräsentiert Dir eine zufällige Störung, die Du erfolgreich wegrechnest und unterdrückst. Das ist aber nicht das Problem: Die Jitterproblematik ist hier die, dass der von der Quelle "systematische" Jitter mitgegangen werden muss, weil er die validen Zeiten der Daten anzeigt. Das war jedenfalls die Aussage im ersten Beitrag. Wer sagt Dir denn, dass die 100% äquidistant kommen? Auszugleichen sind lediglich die zufällign Fehler = glitches = Scheintakte = Sekundärjitter. Wenn Du das alles wegbügelst, gleich mit welcher Methode, wird Dein Zeitpunkt diesbezüglich immer falscher. Warum wohl nimmt man Daten aus einigen Quellen mit deren eigenen Takt an und schaltet i.d.R. keine PLL im FPGA dazwischen? Richtig - mit etwas Pech glättet die ZU GUT. Daher ist Deine Gütebetrachtung hinsichtlich der PLLs im Ansatz richtig, in diesem Fall aber kontraindizierend. Dogbert schrieb: > Die Glitch-Filter Lösung versagt wenn die Störung länger als das Filter > ist total Ich wiederhole mich: Du löst mit Deiner Schaltung ein theoretisches Problem, dass hier praktisch nicht vorliegt. Ohne einen genügend guten Takt (mit nur kurzen Ausfällen der Information), gibt es keine ausreichende Aussage über die tatsächliche Flanke des Taktes und damit den Zeitpunkt valider Daten im Jitterfall. Da nützt ein noch so gut rekonstruierter Takt überhaupt nichts, weil er genau diese Information nicht mehr in sich trägt. Wenn Du Dir mal ganz sachlich die realen Fälle und Randbedingungen des Problemfeldes aufzeichnest, findest Du keinen Fallausschnitt, wo Deine überlegene Taktreko benötigt wird: Hat man ein System, wo es auf den Primärjitter nicht ankäme, reichte das simpelste glitch-Filter, weil es einen genügend guten Taktzeitpunkt generiert. Es ist mit wenigen TAPs realisierbar und definitiv kleiner, als Deine Lösung. Vor allem müssen die TAPs nicht so weit ausgedehtn werden, um an Deine Lösung heran zu reichen. Hat man hingegen ein System, bei dem es auf den Primärjitter ankommt bzw. die Störungen zu gross sind, hilft keine isolierte Taktrekonstruktion, sondern man könnte (bzw. müsste!) über die Datenrekonstruktion arbeiten. Das ist wesentlich genauer und auch einfacher, da man schon mit der Faltung weniger Datenleitungen zielsicher den Jitter des Taktes von dem zufällig eingehandelten Jitter infolge der Störungen trennen und damit die Zeitpunkte valider Daten ermitteln kann. Irgendwo zwischen Fall 2 und Fall 3 haben wir noch den Totalausfall der Daten, die nicht direkt rekonstruiert werden könnten, wenn man Störungen in einer Grössenordnung unterstellt, die es nötig machten, auf Deine Lösung zurückzugreifen, um zu einem Takt zu gelangen. Fazit: Bei dem hier in diesem thread beschriebenen Problemfeld gibt es entweder einen einfach rekonstruierten Takt mit einfach rekonstruierbaren Daten, die direkt gesampelt werden können, wobei die Taktreko grössere Störungen tolerieren kann, als das Filter für die Datenreko, da diese nicht einfach über mehrere Takte antizipieren kann, weil das Datenmuster unbekannt ist. Oder, es gibt mehr Störungen und damit einen weniger genau rekonstruierten Takt, der zwar noch reichen würde, der aber keine samplebaren Daten mehr sieht, die folglich einer analytischen Reko bedürfen. Führt man diese aber durch, hat man auch wieder einen Takt! Und zwar einen wesentlich besseren, als bei der pauschalen PLL, die nicht zwischen primärem Jitter und Zufall unterscheiden kann. Sind die Störungen gänzlich zu stark, um die Daten wieder zu erkennen, gibt es auch keinen rekonstrierten Takt, oder aber er nutzt nix. So schade das für Dich und deinen über mehrere ausgefallene Perioden stabil vor sich hin rödelnden Takt ist: Er hat nichts zu tun. :-) Die Daten sind in jedem Fall der vulnerable Punkt - nicht der Takt. Du hast eine schicke Lösung, aber hier keinen Anwendungsfall.
Jürgen Schuhmacher schrieb: > Die Daten sind in jedem Fall der vulnerable Punkt - nicht der Takt. Das leuchtet mir auch ein, daher stellt sich für mich die Frage: Wie geht man diesbezüglich vor? >über die Datenrekonstruktion arbeiten. Das ist wesentlich genauer >und auch einfacher, da man schon mit der Faltung weniger >Datenleitungen zielsicher den Jitter des Taktes von dem zufällig >eingehandelten Jitter infolge der Störungen trennen und damit >die Zeitpunkte valider Daten ermitteln kann. Hättest Du da einen Lösungsansatz? >Du hast eine schicke Lösung, aber hier keinen Anwendungsfall. Die Bestimmung eines jitterarmen Taktes im FPGA hätte für mich schon einen gewissen Reiz, finde ich.
Jürgen Schuhmacher schrieb: > Nein eben nicht. Du scheinst nicht zu verstehen. Das deinem Vorschlag nach von mir realisierte und simulierte "Glitch-fir" hat eine Hysterese, sonst wäre es ja völlig unbrauchbar. Du rennst einem falschen Hasen hinterher. Deine Lösung ist auch bei Phasenjitter unterlegen. Ich habe mal die Schleifenbandbreite der PLL stark vergrößert mit nco_bits auf 13, also auch den Registerbedarf(und dammit Flächenbedarf) auf ca 50 reduziert, ein weißes Rauschen als Phasenmodulation also Phasenjitter simuliert und die RMS-Werte der Phasenfehler verglichen, Ergebnis: Der von der PLL rekonstruierte Takt hat ca 3.3Db weniger Phasenjitter relativ zum Eingangsjitter verglichen mit dem Glitch Filter. Das ist nicht Verwunderlich, denn das Glitch Filter hat den breiten Frequenzgang wie bereits von mir gezeigt mit diesem hohen "Nebenberg" in Richtung DC. Dieser "Nebenberg" oder diese Asymmetrie hat keinen Nutzen für die Bandbreite der Taktrekonstruktion, sondern lässt nur mehr tieffrequente Störungen (auch Phasenjitter wird zu Amplitudenfehlern) durch die auch wegen der notwendigen Hysterese noch etwas mehr Jitter relativ zum Eingangsjitter erzeugen. Die PLL dagegen hat eine symmetrische und wählbare Bandbreite um den Rekonstruktionstakt herum, was näher am Optimum liegt einerseits eine Frequenz zu tracken aber andererseits ungewollte Störungen zu unterdrücken. Und auch gegen stark gestörte Daten, die quasi den Eingangspuffer mit 1-Bit Quantisierung "übersteuern" gäbe es ein Mittel: Mehr als ein Bit bei der Abtastung. Man könnte mit einem FPGA leicht einen delta-sigma Wandler 2. Ordnung mit 200MHz realisieren der zumindest ca. 20Db S/N bei 10-Fach Dezimierung bringt. Dann kann man die hochfrequente Datenflanke mit dem möglichst genau rekonstruierten Takt korrelieren und diese auch in den von dir beschriebenen Fällen rekonstruieren und damit die Störempfindlichkeit der Daten deutlich steigern. Das profitiert natürlich auch von einer besseren Taktrekonstruktion. Ich frage mich ob du jetzt weiter versuchst dagegen zu polemisieren oder einfach deinen Irrtum zugibst.
Wo liegt denn der angebliche Irrtum, den Du ständig in den Raum stellst? In meiner Aussage, dass meine Schaltung für das Problem taugt? - Sie löst das Problem! In meiner Aussage, dass sie kleiner ist? - Sie ist kleiner, solange man sie nicht unnötig aufbläht! Ich habe im Beitrag vorher mehr als ausführlich (und auch mehr, als nötig sein sollte!) das Problem analysiert und aufgezeigt, dass es in keinem Fall nötig ist, den Takt wesentlich genauer zu rekonstruieren, als die Daten. Kein Mensch macht das! Bei dem vorliegenden Problem, geht es einfach um das Samplen eines Datenstroms und das geht im FPGA typisch asynchron gegenüber den eingehenden Daten mit einem auseichend höheren Takt. Der Takt muss nur so grob abgesampelt werden, dass man die Daten als solche stabil erwischt. Das eigentliche Problem ist daher, die Daten zu filtern. Da dies nicht über mehrere Takte erfolgen kann, ist dies der show stopper des Problems. high tech ing schrieb: > Jürgen Schuhmacher schrieb: >>Du hast eine schicke Lösung, aber hier keinen Anwendungsfall. > Die Bestimmung eines jitterarmen Taktes im FPGA hätte für mich schon > einen gewissen Reiz, finde ich. Welchen? FPGAs sind infolge ihres diskreten Systemtaktes aus analoger Sicht ausnahmslos IMMER asynchron zur Aussenwelt. Selbst, wenn sie sich auf einen externen Takt synchen, der ganzzahlig passt und eine PLL immer logged, ist die Zeit im FPGA immer eine etwas andere. Es wird ein neuer Takt erzeugt, der nur in der Grobbetrachtung der verwendeten Periode quasi synchron ist. Letztlich wirst Du in der digitalen Domain mit den Zeitpunkten der Taktverarbeitung immer ungenauer sein, als die Zeitvorgabe von Aussen. Die Vorstellung, man könne da etwas glätten und damit verbessern, ist ein Trugschluss: Der Takt wird sozusagen neu erfunden und selbst, wenn er dem ideal näher käme und gänzlich clean wäre, so wäre er dennoch falscher. Zudem bleibt er in der Genauigkeit auf die Rasterung der Systemfrequenz beschränkt. Hier sind das 20ns + Systemjitter. Wenn Du genauer werden willst, brauchst Du eine virtuell analoge DDS und aussen irgendwo ein Analoges Filter. Wenn Du es noch genauer haben willst, kann ich Dir eine App zeigen, die es auf 20ps genau macht. Das ist aber bei dieser Anwendung alles unnötig. Aus Datenfrequenzsicht haben wir hier eine (sehr grobe) 2 MHz-Rasterung und die gilt es, zu verarbeiten. Dafür reicht bei idealen Verhältnissen eine Abtastfrequenz von 4MHz+ immer aus. Höhere Systemfrequenzen sind reine (Will-)Kür und bieten nur Reserve für miese Verhältnisse wie bei Dir. Und egal, wie Du es machst und wie optimal der Takt am Ende scheinbar ist- die Granularität der Daten beträgt 2MHz. Ob die im 50er Raster des FPGA 5 Takte früher oder später verarbeitet werden, ist ziemlich Wurscht. Und ja, das ist ein gewaltiger Jitter. Aber das ist der Normalfall der asynchronen Datenverarbeitung. Natürlich kannst Du versuchen, die Flankenzeitpunkte super genau zu rekonsturieren, um die Daten dann auch wieder äquidistant auszugeben, aber die 50MHz sind das limit und dieses würde man sowieso am Leichtesten dadurch ausreizen, indem man die 50MHz intern auf 2MHz runterteilt und die Daten über ein Fifo gepuffert ausgibt. Dann hast Du die bestmögliche Zeitabbildung, die bei 50 MHz möglich ist. Quasi die ideale Taktrekonstruktion. Die hat dann nur etwas im Bereich des FPGA-jitters, Daten und Takt sind total synchron. In Anwendungen, wo es drauf ankommt, einen auch aus analoger Sicht hochpräzisen Datenstrom mit exakten Taktflanken zu erzeugen, wird man darüber hinaus den Zieltakt von Aussen zuführen und die Daten wie oben per FiFo darauf synchen. Eine Taktverbesserung im FPGA reicht da nicht heran und ist unnötig und unterlegen. Wenn Du Deine Daten im FPGA aber einfach nur überhaupt annehmen und verarbeiten willst, reicht Dir eine Systemfrequenz von vielleicht 10MHz, um das zu filtern und zu verarbeiten, was Du oben gezeigt hast. Das erzeugt Dir eine grobe Auflösung von 100ns, die schon deutlich gröber ist, als der Taktjitter, der nach meiner Methode bei 50MHz entsteht - aber es leicht locker, um die Daten zu sampeln und zu verarbeiten. Und ja, sie ist um ein Vielfaches grober und grösser, als die superfeine Taktreko von Dogbert. Und? Wen juckts? Ich habe schon vor 15 Jahren mit einem Mikrocontroller pollend (= softwarejitternd) serielle Daten mit gerade Faktor 5+ aufgefasst und hatte zwischen 5 und 7 samples pro bit, die es zu rekonstruieren galt. Der Datenstrom kam gepulst, also mit eigenem Jitter und mehr als instabilem Takt, und war durch EMI stärker verhunzt, als Deiner. Zudem war die Frequenz nicht exakt bekannt. Schwankte um bis zu 20%. Ist aber trotzdem kein Hexenwerk. Dogberts Methode ist eine isolierte Lösung für einen Anwendungsfall, den es noch zu definieren gälte. Ich schliesse nicht aus, dass man das verwenden kann, aber ich habe nun in mehreren Beiträgen die unterschiedlichsten Fälle und deren klassische und erprobte Lösung aufgezeigt. Und diese sind jeweils angemessener, als die Dogbertrekonstruktion. Sie sind entweder kleiner, einfacher, oder - speziell bei Neugeneration des Taktes einfach besser. Auch bezüglich des absolut tolerierbaren Störpegels geht es besser: Das Problem - ich glaube, ich schreibe das jetzt zum 4.mal - ist die ausreichende Stabilität der Dateninterpretation. Wenn man die analytisch ansetzt, fällt der Takt als Abfallprodukt an. Und das funktioniert noch weit oberhalb des Störlevels, ab dem der Dogberttakt nichts mehr zum sampeln hat.
Dogbert schrieb: > Du scheinst nicht zu verstehen. > Das deinem Vorschlag nach von mir realisierte und simulierte > "Glitch-fir" hat eine Hysterese, sonst wäre es ja völlig unbrauchbar. Aber die FALSCHE :-) Du musst schon lesen, was ich schreibe: Beitrag "Re: Takt sieht schlimm aus - FPGA-Eingang optimieren?" Ausserdem ist die Amplitude nur halb zu gross, weil Du mit 1/0 zu multiplizieren scheinst. > dem möglichst genau > rekonstruierten Takt korrelieren Nein, nicht möglichst genau. Ausreichend genau ist gefragt. > Man könnte mit einem FPGA leicht einen delta-sigma Wandler 2. Ordnung > mit 200MHz realisieren Den FPGA von 50 auf 200MHz hochziehen, um eine Schaltung zu etablieren, die dann einen Bus abtasten kann, der auf vollen 2 MHz läuft? Du hast noch im Gedächtnis, dass die Grundidee des TE war, zu probieren, ein einfaches Problem mit einfacher SW zu erledigen? HW-Änderung war verboten. Wenn wir die zulassen, wäre ich für ein RC-Filter am Eingang. high tech ing schrieb: >>über die Datenrekonstruktion arbeiten. Das ist wesentlich genauer >>und auch einfacher, da man schon mit der Faltung weniger >>Datenleitungen zielsicher den Jitter des Taktes von dem zufällig >>eingehandelten Jitter infolge der Störungen trennen und damit >>die Zeitpunkte valider Daten ermitteln kann. > Hättest Du da einen Lösungsansatz? ja
Jürgen Schuhmacher schrieb: > Ausserdem ist die Amplitude nur halb zu gross, weil Du mit 1/0 zu > multiplizieren scheinst. Zugegeben. Signed arithmetik sieht oft übel aus in Verilog, ist jetzt nicht gerade glücklich formuliert.
1 | multiplied=(pipeline?-'sd1:'sd1)*(in?'sd1:-'sd1); |
Jürgen Schuhmacher schrieb: > Den FPGA von 50 auf 200MHz hochziehen, um eine Schaltung zu etablieren, > die dann einen Bus abtasten kann, der auf vollen 2 MHz läuft? Nicht der ganze FPGA, nur die Eingangsregister und den Dezimierungsfilter für den delta-sigma A/D. Komisch, ich dachte deswegen geht die Welt nicht unter. Kein FPGA Anbieter würde sich mit lowest cost Bausteinen auf den Markt trauen die das nicht spielend könnten. Der OP frage doch nach einer Lösung/Verbesserung des Daten-Problems, oder? Da nunmal bei tiefen Störfrequenzen der Eingangspuffer das Nutzsignal komplett unterdrückt ist da halt nichts mehr zu machen, zumindest in der realen Welt. Jürgen Schuhmacher schrieb: > Du hast noch im Gedächtnis, dass die Grundidee des TE war, zu probieren, > ein einfaches Problem mit einfacher SW zu erledigen? HW-Änderung war > verboten. Wenn wir die zulassen, wäre ich für ein RC-Filter am Eingang. Ist doch einfach, vergleichsweise. Ein paar Prozent der Ressourcen eines low-cost FPGAs. OK, wohl nicht einfach verständlich. Jetzt solltest du dein Verbot der HW-Änderung dem OP klarmachen, der sagte nämlich etwas davon eine Art Bandpass in die Taktleitung eingebaut zu haben. Also ein delta sigma zweiter Ordnung sind auch nur ein paar Widerstände und Kondensatoren, vielleicht setzt sich der OP auch da über dein Verbot hinweg.
Dogbert schrieb: > Nicht der ganze FPGA, nur die Eingangsregister und den > Dezimierungsfilter für den delta-sigma A/D. WOZU DENN? Wer taktet denn bitte seinen FPGA um Faktor 100 höher, als den zu sampelnden Takt? Und ändert dafür auch noch das Design? Ich würde, wenn möglich auf 20 MHz rnter gehen, geht auch noch. > Der OP frage doch nach einer Lösung/Verbesserung des Daten-Problems, > oder? Nach einer einfachen, ja. > Da nunmal bei tiefen Störfrequenzen der Eingangspuffer das Nutzsignal > komplett unterdrückt ist da halt nichts mehr zu machen, zumindest in der > realen Welt. Sieh Dir die Screenshots an und zeige mir, wo das zu sehen ist. Du scheinst mehr Infos über das Design zu haben, als ich. Das Signal hat ein paar spikes, mehr nicht. Dogbert schrieb: > Jetzt solltest du dein Verbot der HW-Änderung dem OP klarmachen, Nein, Du solltest meine Beiträge und seine nochmal lesen und vorfinden, dass das "Verbot" von ihm stammt: high tec ing schrieb: > Leider habe ich keine Möglichkeit, da viel > umzubauen. Wenn gäbe das ein redesign. Es geht darum, das redesign mit einer SW zu verhindern, wenn möglich. "Umbauen" geht dann bestenfalls im Zuge der Entwicklung. Dogbert schrieb: > vielleicht setzt sich der OP auch da über dein Verbot > hinweg. Lies bitte die Beiträge richtig und interpretiere nicht mehr hinein, als drin stand.
Jürgen Schuhmacher schrieb: > WOZU DENN? Wer taktet denn bitte seinen FPGA um Faktor 100 höher, als > den zu sampelnden Takt? Und ändert dafür auch noch das Design? Ich > würde, wenn möglich auf 20 MHz rnter gehen, geht auch noch. Du hast wohl recht, die aus der Halbleiterei müssen Idioten sein, reden die doch da auch von so Sachen wie "speed/area product". Du solltest die Dilettanten dort mit deiner Kompetenz in Grund und Boden stampfen. Ich sehe blühende Wiesen und eine neue, weltdominierende deutsche Halbleiterindustrie. Jürgen Schuhmacher schrieb: > Nach einer einfachen, ja. Nur weil es nicht dein Vorschlag ist und du ja demonstriert hast dass du meinen nicht verstehst ist er nicht kompliziert. Jürgen Schuhmacher schrieb: > Sieh Dir die Screenshots an und zeige mir, wo das zu sehen ist. Du > scheinst mehr Infos über das Design zu haben, als ich. Das Signal hat > ein paar spikes, mehr nicht. Hat der OP da nicht angedeutet dass es doch manchmal schlimmer kommt? Auf einer Taktperiode sieht man halt die tiefen Frequenzen nicht so gut. Jürgen Schuhmacher schrieb: > Nein, Du solltest meine Beiträge und seine nochmal lesen und vorfinden, > dass das "Verbot" von ihm stammt: Nun, wie ich schon sagte hat er sich ja scheinbar nicht daran gehalten und einen externen Filter angebaut. Jürgen Schuhmacher schrieb: > Lies bitte die Beiträge richtig und interpretiere nicht mehr hinein, als > drin stand. Fang du doch damit an. Wer etwas anfängt kann es auch beenden. Willst du nicht auch langsam damit aufhören dich zu blamieren?
Ich komme jetzt nicht mehr mit. Warum muss man sich da um die optimale Lösung streiten und einen Glaubenskrieg entfachen? Ich hatte bereits vor einer Woche gepostet, dass das Takten nun prima geht und nur noch eine gute Lösung für die Daten brauche. Ich summiere sie im Moment einfach über eine Bitperiode und entscheide bei mehr als 50% auf 1. Das funktioniert soweit problemlos. Frage: Gibt es etwas Besseres? > RC-Filter am Eingang Das RC-Filter hat deutliche Verbesserungen gebracht, wie bereits erwähnt, wäre aber eine reine Problemlösung auf meiner Seite, was ich möglichst vermeiden will. Solange das in Software geht, ändere ich nichts. Momentan ist die SW ohne Filter ausreichend. Danke an Jürgen für den Tipp. > Sigma-Delta-Wandler Nichts für ungut, aber ich brauche etwas, was ich auch verstehe und sich schnell hinschreiben lässt. Ich brauche im Grunde nur eine Lösung für jetzt, um Messen und Weiterarbeiten zu können. Eine Hardwareänderung wird es langfristig mit Sicherheit geben, um die Nadeln zu beseitigen. Ich gehe davon aus, dass sich der Hersteller schon etwas überlegen wird, um das zu lösen. Wahrscheinlich braucht man einfach nur mehr Pegel und einen niederohmigeren Ausgang. Nur, wenn es gar nicht anders geht, baue ich auch meine HW um. Ich werde in jedem Fall höchstens eine minimale und einfach überschaubare Filterlösung in SW drin lassen, weil wenn sie zusätzliche Sicherheit bringt. Eine aufwändige Lösung scheidet aus, weil sie neben dem Mehraufwand bei der Implementierung auch eine Validierung und Risikobetrachtung erfordert.
high tech ing schrieb: > Frage: Gibt es etwas Besseres? Wohl schon, aber es gefällt dir nicht, weil du es nicht verstehst. So musst du auf einen Vorschlag warten den du verstehst, wobei dein Verständnispotential ja ausgeschöpft ist und deine Weigerung dich damit zu beschäftigen dir nur eine plausibel scheinende Problemlösung übrig lässt. Goethe hätte und hat das bestimmt irgendwo schöner und kürzer formuliert, sollte ich mal lesen.
Dogbert schrieb: > Goethe hätte und hat das bestimmt irgendwo schöner und kürzer > formuliert, sollte ich mal lesen. Goethe hätte sich zumindest einer anderen Wortwahl befleissigt. Wenn ich dass hier lese: Dogbert schrieb: > Du hast wohl recht, die aus der Halbleiterei müssen Idioten sein, reden > die doch da auch von so Sachen wie "speed/area product". > > Du solltest die Dilettanten dort mit deiner Kompetenz in Grund und Boden > stampfen Scheinst Du irgend ein Problem zu haben. Dogbert schrieb: > Wohl schon, aber es gefällt dir nicht, weil du es nicht verstehst. Ich habe nicht alle Beiträge gelesen, aber der Frager scheint zumindest eines verstanden zu haben, nämlich das, was ihm schon zu Beginn der Diskussion von einigen Mitschreibern verdeutlicht wurde: Das Problem muss an der Wurzel gepackt werden und nicht mit Softwaretricksereien abgearbeitet werden. Alles, was nicht mit wenigen Handgriffen filterbar ist, verdient den Namen Takt nicht. Ich möchte in keinem meiner Designs eine übermässige Signalverarbeitung installieren, nur um ein paar läppische Daten einzulesen. high tech ing schrieb: > Frage: Gibt es etwas Besseres? Schon einen IIR-Filter probiert?
E. M. schrieb: > Scheinst Du irgend ein Problem zu haben. Sorry, ich bin an eine Grenze gestoßen. Die Grenze der Dummheit. E. M. schrieb: > Ich möchte in keinem meiner Designs > eine übermässige Signalverarbeitung installieren, nur um ein paar > läppische Daten einzulesen. Wirf DSL, DOCSIS, WLAN, GSM, DVB, UMTS und 10G Ethernet weg. Teufelszeug!
Bleiben wir mal bei leitungsgebundenen Systemen wie DSL. Da ist der Treiber auch an die Telefonleitung analog angepaßt und zwar hochgradig. Darauf kommt dann ne FFT und noch digitalere Sachen oben drauf. Wenn eine Kette ein schwächstes Glied hat, wird man dieses Glied bearbeiten und nicht versuchen die Kette durch dickere Glieder an sowieso schon dicken Stellen zu verstärken. Naja, bleibt bei der FPGA-Lösung. Scheint ja jetzt zu funzen. Wenn die Störung taktsynchron und regelmäßig ist, könnte man auch einen Korrelator bauen und die Phasenverschiebung einmal definieren und beibehalten. Sollte das Design die gleiche Schlechtheit bei den Datenleitungen haben wie beim Takt, wird es aber eng. Phasensynchrone Integration wurde oben genannt und gilt auch als optimal. Meine Meinung bleibt: Ein paar Abschlußwiderstände!! Kommen eh nur 50 Ohm (Koax-Struktur) oder 100 Ohm (symmetrische Leitung) in Frage. Bei Platinen eben Design-Z0 der Leiterbahnen.
Dogbert schrieb: > high tech ing schrieb: >> Frage: Gibt es etwas Besseres? > Wohl schon, aber es gefällt dir nicht, weil du es nicht verstehst. Du hast noch nichts in Richtung Datenwiederherstellung geschrieben. Die Lösung, die zum Takt passt, dürfte es kaum sein. > So musst du auf einen Vorschlag warten den du verstehst, wobei dein > Verständnispotential ja ausgeschöpft ist und deine Weigerung dich damit > zu beschäftigen dir nur eine plausibel scheinende Problemlösung übrig > lässt. Du scheinst sehr von Dir überzeugt zu sein, so wie Du Dich hier gibts. Nur, weil ich Deine Lösung nicht in Erwägung gezogen habe, musst Du nicht von Verweigerung reden. E. M. schrieb: > Ich möchte in keinem meiner Designs eine übermässige Signalverarbeitung > installieren, nur um ein paar läppische Daten einzulesen. Ich hatte nach einer simplen Möglichkeit gesucht, ein paar Signale zu filtern und verdeutlicht, dass ich zunächst probieren wollte, dies in Software zu tun, wie es naheliegend wäre, bevor ich Hardware umbaue der umbauen lasse. Das scheinen einige aber nicht verstanden zu haben. Stattdessen kommt man mir mit Kritik an dem Vorgehen, empfiehlt Hardware umzubauen und offeriert gewaltigen Verfahren, die mit der Aufgabenstellung nicht zusammenpassen. Schon irgendwie seltsam.
high tec ing schrieb: > E. M. schrieb: >> Ich möchte in keinem meiner Designs eine übermässige Signalverarbeitung >> installieren, nur um ein paar läppische Daten einzulesen. > Ich hatte nach einer simplen Möglichkeit gesucht, > Das scheinen einige aber nicht verstanden zu haben. Ich für meinen Teil habe das schon verstanden. Allerdings schreibst Du: > Takt sieht schlimm aus - FPGA-Eingang optimieren Am Eingang selber lässt sich nur etwas mit harten Wahrheiten reparieren und optimieren. Was dahinter kommt, nenne ich "prozessieren". Dogbert schrieb: > Wirf DSL, DOCSIS, WLAN, GSM, DVB, UMTS und 10G Ethernet weg. Warum? Und was hat das mit dem Thema zu tun? Die angeführten Beispiele sind sicherlich ein Ziel für komplizierte digitale Signalverarbeitung, Echokompensation, Messen im Rauschen und vielem mehr, spielen sich aber um 3 Grössenordnungen höher ab im Takt. Komplett andere Baustelle. Mit dicker Signalverarbeitung schiesst Du mit Kanonen auch Spatzen. FPGA-Fläche kostet in Stückzahlen auch ganz schon Geld. > Teufelszeug! Du liest zuviel mephistiöse Literatur. Deine zur Schau gestellte Affinität zu Goethe ist mir ehrlich gesagt auch äuserst suspekt.
Abdul K. schrieb: > Meine Meinung bleibt: Ein paar Abschlußwiderstände!! Kommen eh nur 50 > Ohm (Koax-Struktur) oder 100 Ohm (symmetrische Leitung) in Frage. Bei > Platinen eben Design-Z0 der Leiterbahnen. Ist ja drauf und die Leiterbahnführung der Platine ist nicht das Problem. Die Sigs kommen über Kabel. Dort erfolgt auch die Einstreuung. E. M. schrieb: >> Takt sieht schlimm aus - FPGA-Eingang optimieren > Am Eingang selber lässt sich nur etwas mit harten Wahrheiten > reparieren und optimieren. Was dahinter kommt, nenne ich "prozessieren". ok, nennen wir es also "prozessieren". Ändert aber nichts. Als Datenfilter verwende ich jetzt ein FIR-Filter mit harter Bandbreitenbegrenzung bei 2MHz, was sehr gut klappt. Dauertests erfolgreich. Lösung langfristig erfolgt durch Pegelerhöhung am Ausgang.
Also DOCH eine HW-Änderung. Sag' ich doch! ;-)
Deine Scope-Bilder zeigen zu 90% einfach eine unterminierte Leitung. Vergleich sie mal mit anderen Probanden: http://drsvanhay.de/lange-leitung-experimente-mit-einem-langen-kabel/ Bild 5 Fällts dir auf?! Hab den Link vor Tagen zwischengespeichert, da ich schon wußte was kommen würde. Ja ja, langweilig wirds mit 50 - wenn man schon fast alles kennt. Ne andere Kabelbelegung würde vermutlich schon Wunder bewirken.
Abdul K. schrieb: > Deine Scope-Bilder zeigen zu 90% einfach eine unterminierte Leitung. Dann gehört mein Fall eben zu den anderen 10% > Vergleich sie mal mit anderen Probanden: > http://drsvanhay.de/lange-leitung-experimente-mit-einem-langen-kabel/ > Bild 5 Verglichen. Sieht komplett anders aus. Die Störungen kommen von extern und sind nur mit einem Kurzschluss zu terminieren. > Ja ja, langweilig wirds mit 50 - wenn man schon fast alles kennt. ... wenn man nicht mehr offen ist für Neues und daher alles in die bekannten Schemata einzufügen geneigt ist, wolltest Du sagen.
hitec ing schrieb: > Abdul K. schrieb: >> Deine Scope-Bilder zeigen zu 90% einfach eine unterminierte Leitung. > Dann gehört mein Fall eben zu den anderen 10% > Lesen lernen. 90% bezieht sich auf die Signalform, nicht auf den Fall. >> Vergleich sie mal mit anderen Probanden: >> http://drsvanhay.de/lange-leitung-experimente-mit-einem-langen-kabel/ >> Bild 5 > Verglichen. Sieht komplett anders aus. > > Die Störungen kommen von extern und sind nur mit einem Kurzschluss zu > terminieren. > Du meinst, du machst einen Kurzschluß und mißt den Strom durch den? Ja, kann man machen, aber nicht mit einem FPGA-Pin möglich. > >> Ja ja, langweilig wirds mit 50 - wenn man schon fast alles kennt. > ... wenn man nicht mehr offen ist für Neues und daher alles in die > bekannten Schemata einzufügen geneigt ist, wolltest Du sagen. Naja. Du lebst von deinen Vorurteilen anscheinend. 1992 erste programmierbare Logik verwendet. Nur um das klarzustellen.
Abdul K. schrieb: > Lesen lernen. 90% bezieht sich auf die Signalform, nicht auf den Fall. Das könnte ich jetzt auch sagen, denn ich habe mehr als einmal erwähnt, dass die Signal-de-form durch äussere Einflüsse kommt. Nimmt man die Störer weg, ist das Signal sehr gut. Reflektionen o.ä. sind keine sichtbar. > Du meinst, du machst einen Kurzschluß und mißt den Strom durch den? Ja, > kann man machen, aber nicht mit einem FPGA-Pin möglich. Das war ironisch gemeint. Selbst die denkbar geringsten Abschlusswiderstände nutzen da nichts, war die Aussage. Spannungsinkopplung != Stromeinkopplung. >> ... wenn man nicht mehr offen ist für Neues und daher alles in die >> bekannten Schemata einzufügen geneigt ist, wolltest Du sagen. > Naja. Du lebst von deinen Vorurteilen anscheinend. Nein, nicht Ich, sondern Du vorurteilst. Ich bezog mich auf genau Deine "telemetrische" Beurteilung, nämlich ein Fehlerbild in Deine Dir bekannten Kategorien einzusortieren und nicht davon wegzukommen. > 1992 erste > programmierbare Logik verwendet. Das hat mir programmierbarer Logik nichts zu tun. Das Problem wäre dasselbe, wenn es ein anderer Baustein mit irgendeinem Eingang wäre. Das Problem ist ein Analogproblem. Eines , das sich digital lösen oder mindern lässt, wobei Du ja gerade der bist, der nicht "nichtprogrammierbare" Lösung favorisiert. Dein Argument ist also in 2-facher Hinsicht keines. > Nur um das klarzustellen. Du hast Das eher unklar gestellt.
hi tec ing schrieb: > Das war ironisch gemeint. Selbst die denkbar geringsten > Abschlusswiderstände nutzen da nichts, war die Aussage. > Spannungsinkopplung != Stromeinkopplung. Die Abschlüsse senken den Pegel aber soweit wie möglich ab, weil sie gerade für die Störungen wie ein Kurzschluss wirken. Wenn Du trotz niederohmiger Abschlüsse noch solche grossen Einstreuungen hast, müssen das gigantische Störquellen sein. Da möchte ich ehrlich gesagt nicht wissen, wie sich das Gerät dann in der EMV Praxis benimmt, ganz ungeachtet der Tatsache, ob sich die Takte und Daten genügend gut glätten lassen.
Der Abschlußwiderstand muß für die Störquelle angepaßt sein, was dann auch automatisch die Wellenform optimiert. Kurzschluß und Leerlauf sind die denkbar ungünstigsten Anpassungen. Ob man am empfangenden Ende dann Spannung oder Strom mißt, ist bei dem hohen S/N ziemlich egal. Für die Strommessung bräuchte man aber bei einem FPGA einen externen OpAmp o.ä. . Naja, "hi tec" ing. eben und auch noch Gast. Ich schrieb mal, ich würde Gästen nicht mehr antworten. Hätte ich mich daran gehalten, wäre das nicht passiert.
Auf die Gefahr hin, dass ich als minderwertiger Forenbesucher zweiter Klasse (da nur "Gast") keine Antwort bekomme: Abdul K. schrieb: > Der Abschlußwiderstand muß für die Störquelle angepaßt sein, was dann > auch automatisch die Wellenform optimiert. 1. Mein Professor hat in der Grundlagenvorlesung klargestellt, dass R=Z sein muss. Der Abschlusswiderstand muss dem Wellenwiderstand angepasst sein. Stimmt das nicht (mehr)? Bez welchen Bezug hat dies hier (noch)? 2. Wie will man einen solchen Widerstand definieren, wenn man die Störung nicht kennt? Eine Störung kann sich ja auch mal ändern. Falls Abdul nicht antwortet, findet sich vielleicht ein anderer Analogexperte, der das kann.
Eigentlich muß die komplexe Impedanz maximiert gleich sein, aber
Betrag(Z1)=Betrag(Z2) resp. R1=R2 ist schonmal ein Anfang. Alles andere
verschlechtert den Störabstand und die Dämpfung. Schlechte Dämpfung
bedeutet längeres 'Nachklingeln'.
Hier hat man vier Impedanzen:
1. Treiber ("unbekannt")
2. Kabel ("unbekannt")
3. Empfänger
4. einfallende Strahlung (EM-Welle, E- oder H-Störung) (Kopplung im
Nahfeld sehr komplex)
(5. abgestrahlte Störung kann man energetisch vergessen)
Daher schrieb ich ganz weit ooooooooooben, daß man am einfachsten
verschiedene Abschlußwiderstände durchprobiert, bis man das beste Bild
am Scope hat. Das ist kein großer Akt. Irgendwas zwischen 30 und 200
Ohm, denn die Theorie ergibt für praktische Verkabelungen keinen anderen
Wertebereich. Auch das hatte ich wohl schon erwähnt.
Ist natürlich ein praktischer Kompromiß.
Eventuell möchte der Sender auch einen bestimmten Spannungspegel (z.B.
LVDS) oder 'Strompegel' sehen , a la CML. Ergäbe einen Spannungsteiler
passender Impedanz.
Das wars analogtechnisch eigentlich schon. Was damit weiters nicht
erzielbar ist, macht man algorithmisch im FPGA.
Ok,ok, beantwortet aber noch nicht meine Frage, was passiert, wenn sich die Störung ändert? Sie ist ja mal da und mal nicht da. Und kalkulierbar sind sie i.d.R. auch nicht. Also doch nur Schätzerei?
Je nach Art der Änderung muß man diverse Strategien fahren. Das würde jetzt zu weit führen. Kabelbewegung und -belegung, Störsender positionieren sich woanders usw.
E. M. schrieb: > Wenn Du trotz niederohmiger Abschlüsse noch solche grossen > Einstreuungen hast, müssen das gigantische Störquellen sein. So sieht's aus. > Da möchte ich ehrlich gesagt nicht wissen, wie sich das Gerät dann > in der EMV Praxis benimmt Wir sind neutral. Wir werden gestört.
hi tec ing schrieb: > E. M. schrieb: >> Wenn Du trotz niederohmiger Abschlüsse noch solche grossen >> Einstreuungen hast, müssen das gigantische Störquellen sein. > > So sieht's aus. Wurde denn schon mal gezielt ausprobiert, die Störquellen abzuschalten? Wenn es in der Tat daran liegt dass dort unvermeidbare Einstreuungen diesen Ausmaßes vorliegen, muss in jedem Fall auf eine symmetrische Übertragung zurückgegriffen werden. Dogbert schrieb: > Jürgen Schuhmacher schrieb: > Du hast wohl recht, die aus der Halbleiterei müssen Idioten sein, reden > die doch da auch von so Sachen wie "speed/area product". Wenn Du schon derart abstrakte Betrachtungen heranziehst, musst Du sie auch korekt anwenden. Der Grundtenor dabei ist ja der, Fläche in Zeit zuverwandeln, bei konstantem Produkt. Was Du vorschlägst, nämlich möglichst hoch abzutasten, um genauer zu werden, erhöht aber das Produkt und dies auch noch unnötig. Praktisch wird man eher gegenteilig verfahren und mit einer herabgesetzen Abtastrate, die gerade hoch genug ist, arbeiten, um die Filter-TAP-Zahl gering zu halten. Konkret müssten ja die Daten, die man sampeln will ebenfalls so hoch abgetastet und gespeichert werden, um genügend Zeitpunkte für die retrospektive Betrachtung der richtigen Samples zu haben. Sie einfach nur durchrauschen zu lassen, und nach Flankenentscheid das aktuelle zu nehmen, führt genau zu dem Problem, dass man Daten nicht mit dem aktuellen Takt ihrer Zeitebene erfasst sondern dem gemittelten des PLL-Konstruktes wodurch der natürlich Jitter unterdrückt wird. Damit wären z.B. asynchron gepulste Daten nicht richtig erfassbar.
Thread beobachten
Seitenaufteilung abschalten
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.