Ich möchte folgendes entwickeln: Es gibt zwei Signale. Einen Startpuls, der alle 10µs kommen kann und einen Trigger darstellt. Ein weiteres Signal liefert Pulse in einer Messperiode. Ich möchte den zeitlichen Abstand aller Pulse vom Startpuls messen und das mit einer Auflösung von unter einer Nanosekunde, besser 100ps. Meine erste Recherche hat ergeben, dass es dazu schon Lösungen gibt und sich das Time to Digital Konverter nennt. Die können allerdings meist nur bis zu 5 Ereignisse wegspeichern, was in meinem Fall zu wenig ist. Ich brauche in einer Periode eher so 10-100 Ereignisse. Wie kann ich hier ansetzen zu recherchieren und wie kann man das geschickt lösen?
Willst du einen Chip/Schaltung oder ein fertiges Gerät?
Auflösung 100ps das sind schon mal 10 GHz ohne Abtasttheorem. Na, dann mach mal! Bin gespannt! Alleine die Aufbereiten und Zuführung des Signals in deinen „Impulslogger“ wird ne Aufgabe sein. Meine erste Idee: Datenstrom parallelisieren z.b. 128 Bit und dann in einen schnellen Speicher damit. Aber sicher gibt es noch viele andere Möglichkeiten.
David S. schrieb: > Time to Digital Konverter nennt. Die können allerdings meist > nur bis zu 5 Ereignisse wegspeichern, was in meinem Fall zu wenig ist. Dann hast Du offenbar Deine Suche nach dem Fund des TDC7200 von Texas Instruments beendet. Ich habe bei einer kurzen Recherche deutlich mehr Ausführungen gefunden, darunter auch solche mit einer unbegrenzten Folge von Stop-Ereignissen. > Ich brauche in einer Periode eher so 10-100 Ereignisse. Dann solltest Du mal wesentlich genauer spezifizieren, um welche Art von Signalen es sich handelt, welches die besonderen zeitlichen Anforderungen sind und wie das ganze weiterverarbeitet werden soll. > Wie kann ich hier ansetzen zu recherchieren und wie kann man das > geschickt lösen? Keiner von uns hat eine Ahnung von der Rahmenbedinungen, die ausschließlich Du kennen könntest, aber natürlich in bester Salamitaktik nicht verrätst. Ja, wir wissen natürlich auch, dass es sich um ein streng geheimes Raketenprojekt handelt, über das Du nicht reden darfst...
Clemens S. schrieb: > Willst du einen Chip/Schaltung oder ein fertiges Gerät? Im besten Fall einen Chip mit etwas analoger Vorarbeit. Ove M. schrieb: > Auflösung 100ps das sind schon mal 10 GHz ohne Abtasttheorem. > Na, dann mach mal! > Bin gespannt! Ich will zählen und nicht mit einem ADC abtasten. Mit Frequenzen in dem Bereich habe ich schon gearbeitet von daher bin ich mir bewusst, dass es nicht völlig trivial ist. Ich mache mal, richtig.
Andreas S. schrieb: > Keiner von uns hat eine Ahnung von der Rahmenbedinungen, die > ausschließlich Du kennen könntest, aber natürlich in bester Salamitaktik > nicht verrätst. Ja, wir wissen natürlich auch, dass es sich um ein > streng geheimes Raketenprojekt handelt, über das Du nicht reden > darfst... Tja .... .... der Freitag naht, und David ist erst seit heute angemeldet.
Sowas kann man als Chip kaufen, z. B. von TI als THS788. Braucht 3,3V, externe 200 MHz mit möglichst wenig Jitter und hat ein LVDS Interface für Ein- und Ausgänge. Die zu messenden Pulse lassen sich mit Any2LVDS Komparatoren passend konvertieren. Damit gehen dann 4 Messkanäle plus Startpuls mit 13 ps Auflösung und 5 ns Doppelpulsabstand. Durchsatz bis ca. 12 Mio Events pro Kanal pro Sekunde. Der Chip hat auch einen kleinen Fifo mit 15 Einträgen, der sich auch per SPI auslesen ließe, falls man nur einzelne Startevents mit ein paar Stops hat. Alternativ selber bauen mit einem FPGA der Gigabit Transceiver hat. Mit einem PCIe Gen. 3 tauglichen FPGA bist du bei unter 100 ps pro Bin. Mit ein bisschen tricksen und lassen sich in AMD FPGAs auch mehrere ISERDES pro differenziertem Pinpaar interleaven. Damit kommt man dann auf auf eine effektive Auflösung unter 200 ps. Das Tricksen ist allerdings schon mit HDL und Kalibrieraufwand verbunden. Falls es dir aber nicht ums Selberbauen geht, gibt's etliche Angebote für fertige TDCs mit PCIe oder USB Interface mit ausreichend Zeitauflösung und Datenrate. Da kann man sich dann ganz auf die Softwareauswertung konzentrieren.
David S. schrieb: > Meine erste Recherche hat ergeben, dass es dazu schon Lösungen gibt und > sich das Time to Digital Konverter nennt. Die können allerdings meist > nur bis zu 5 Ereignisse wegspeichern, was in meinem Fall zu wenig ist. > Ich brauche in einer Periode eher so 10-100 Ereignisse. Dann reichen ja 100 TDCs aus :-) Sieh Dir den AS6501 an, ob er für die gewünschte Pulsfrequenz schnell genug ist. Wenn nicht, rechne aus, wieviel Du von diesen Teilen brauchst. Der Rest ist Fleißarbeit.
David S. schrieb: > Ich möchte folgendes entwickeln: Es gibt zwei Signale. Einen Startpuls, > der alle 10µs kommen kann und einen Trigger darstellt. Ein weiteres > Signal liefert Pulse in einer Messperiode. Ich möchte den zeitlichen > Abstand aller Pulse vom Startpuls messen und das mit einer Auflösung von > unter einer Nanosekunde, besser 100ps. > Es gibt den AS6501, kostet so um die 25€, der hat Fifo und kann das mit <100ps (Single Shot) Auflösung. Ausgelesen wird er über SPI (50Mhz). Ich messe damit kontinuierlich die Periode eines 100KHz (10µs) Signals. Jetzt kommt es darauf an wie der längste Abstand zwischen 2 Pulsen ist, das ist die andere Grenze.
> Wie kann ich hier ansetzen zu recherchieren und wie kann man das > geschickt lösen? Mal die Applikation genauer benennen, dann könnte man auch der Stand der technik benennen. Die Wahnsinns-Auflösung von 100 picosekunden klingt nach Laser oder ähnlichen, vielleicht Radar. Da könnte man unter ToF (Time of Flight) nachschlagen. Manche Messungen beruhen auch auf Doppler und/oder Phasen-Vergleich. Das wäre dann eher ein Mixed-Signal-Ansatz. Rein Digital wird man an FPGA/CPLD nicht vorbeikommen, insbesonders wenn es um eine Dateninsive Zeitreihe geht. * https://tf.nist.gov/general/pdf/78.pdf
:
Bearbeitet durch User
Mi N. schrieb: > Dann reichen ja 100 TDCs aus :-) > Sieh Dir den AS6501 an, ob er für die gewünschte Pulsfrequenz schnell > genug ist. Wenn nicht, rechne aus, wieviel Du von diesen Teilen > brauchst. Der Rest ist Fleißarbeit. Michael war mal wieder schneller ;-) Ich denke es reicht ein Chip und 1 Kanal dafür. Der AS kennt nur Stop und liefert für jeden Stop einen Timestamp. Dein Startsignal wäre der erste "stamp" die Impulse alle weiteren. Du misst also immer den Abstand zum vorherigen Impuls. wenn der nicht zu lang ist und der Referenztakt Zähler dazwischen überläuft oder der summierte Fehler der Abstände (der sollte sich aber mitteln) stört sollte das funktionieren. Durch das Fifo misst er ja weiter während du das vorherige Ergebnis ausliest. Einen Überlauf über mehrere Abstände lässt sich erkennen und korrigieren. Du musst halt nur die gelesenen Daten in 10µs verarbeiten oder speichern. Kommen deine Impulse im Abstand schneller als 10µs, funktioniert das natürlich nicht. Dann kannst du noch den AS über LVDS auslesen aber auch da brauchst du Zeit zum Auslesen, das Fifo ist begrenzt. Suchst du etwas käufliches, suche nach "Time Interval Analyzer".
:
Bearbeitet durch User
David S. schrieb: > Ich möchte folgendes entwickeln: Es gibt zwei Signale. Einen Startpuls, > der alle 10µs kommen kann und einen Trigger darstellt. Ein weiteres > Signal liefert Pulse in einer Messperiode. Ich möchte den zeitlichen > Abstand aller Pulse vom Startpuls messen und das mit einer Auflösung von > unter einer Nanosekunde, besser 100ps. Minimalen Abstand der Impulse ? Impulsbreite ? Pegel? Der AS6501 hat Minimum pulse-to-pulse spacing 20ns. Minimum pulse width: LVDS Eingang 2ns CMOS Eingang 10ns. Der Eingangstrigger ist schon mal das Erste Kriterium.
Hans-Georg L. schrieb: > Kommen deine Impulse im Abstand schneller als 10µs Kleine Korrektur: Du meinst ns. Bei der Kopplung von zwei Kanälen verdoppelt sich auch die FIFO-Größe auf 32 Einträge, die womöglich mit SPI hinreichend schnell ausgelesen werden können. Da nur 2-3 Byte pro Stopp ausgegeben werden müssen, schafft man beim Auslesen mit 50 Mbit/s rund 10 Mbyte Nutzdaten, was bei 10 µs Intervall die geforderten max. 100 Ereignisse liefert. Den Rest muß der TO mit seinen Anforderungen klären.
Mi N. schrieb: > Hans-Georg L. schrieb: >> Kommen deine Impulse im Abstand schneller als 10µs > > Kleine Korrektur: Du meinst ns. > Bei der Kopplung von zwei Kanälen verdoppelt sich auch die FIFO-Größe > auf 32 Einträge, die womöglich mit SPI hinreichend schnell ausgelesen > werden können. Da nur 2-3 Byte pro Stopp ausgegeben werden müssen, > schafft man beim Auslesen mit 50 Mbit/s rund 10 Mbyte Nutzdaten, was bei > 10 µs Intervall die geforderten max. 100 Ereignisse liefert. > Den Rest muß der TO mit seinen Anforderungen klären. Ja, die 10µs sind für diesem Fall falsch, das war das Kriterium für meine 100Khz. Die Auslesezeit bestimmt den Durchsatz, denn jedes Fifo wird irgendwann voll wenn nicht schnell genug ausgelesen wird. Die Conversion Time ist 20ns (HIRES OFF). Du kannst mit 2 Kanälen nur eine kürzere Doppel-Messung machen danach musst du doch wieder eine 20ns Pause einhalten. Mit LVDS kannst beide Kanäle gleichzeitig auslesen mit jeweils eigenem Frame. Mit SPI musst du sie nacheinander auslesen und da gibt es das Problem, das du nur einen Interrupt hast, der dir anzeigt das Daten da sind aber nicht in welchem Kanal. Die 24 Bit Stop Kanäle zählen bis eine Periode der Referenzfrequenz und machen dann wieder bei 0 weiter. Bei einem leeren Fifo oder einem Fehler liefert der Kanal 0xFFFFFF zurück. 2Byte (0xFFFF) könnte ein gültiger Messwert oder ein Fehler sein. Die Registeradressen der beiden Kanäle liegen nicht hintereinander deshalb musst du 2 x ein cmd-byte senden und alle 3 byte zurücklesen. Wenn ein Interrupt kommt weisst du erst einmal nicht welcher Kanal es war. Das du den falschen Kanal erwischt hast sieht du erst wenn du ihn gelesen hast und 0xFFFFFF darin steht und der Interrupt nicht gelöscht wurde. Jetzt kann man sich darauf verlassen das die 1 Messung, nach einem Reset in Kanal 1 steht, dann in 2 usw. und niemals ein Fehler auftritt dann kann man abwechselnd beide Kanäle mit 2 byte Ergebnisse lesen. Ich habe mich wegen der Problematik für single Kanal Messungen entschieden Es gibt von dieser Firma noch den TDC-GPX2 das ist ein 4 Kanal TDC mit LVDS Ausgang für jeden Kanal. Der wäre für den TE besser geeignet ...
Hans-Georg L. schrieb: > Jetzt kann man sich darauf verlassen das die 1 Messung, nach einem Reset > in Kanal 1 steht, dann in 2 usw. und niemals ein Fehler auftritt dann > kann man abwechselnd beide Kanäle mit 2 byte Ergebnisse lesen. Wir machen doch keine Fehler ;-) > Ich habe > mich wegen der Problematik für single Kanal Messungen entschieden Ist ja auch kein Problem. 100 Ereignisse in 10 µs wären im Durchschnitt 100 ns / Ereignis. Das würde passen. Ein einzelner Kanal hat eine FIFO-Tiefe von 16, was das Timing sehr entspannt. Üblicherweise werden hier keine Datails zu Anfragen verraten. Da muß der TO zusehen, ob er damit klar kommt. Die LVDS-Leitungen sind schon speziell, selber werde ich sie nie brauchen. Deshalb lasse die zugehörigen Pins einer Seite komplett in der Luft baumeln.
Mi N. schrieb: > Die LVDS-Leitungen sind schon speziell, selber werde ich sie nie > brauchen. Deshalb lasse die zugehörigen Pins einer Seite komplett in der > Luft baumeln. Unused inputs has to be tied to VDD33 meint das Datenblatt dazu ....
Hans-Georg L. schrieb: > Unused inputs has to be tied to VDD33 meint das Datenblatt dazu .... Guten Morgen Hans-Georg, ich meinte die Ausgänge an den Pins 1 - 12. Aber bei meinen Rechnungen habe ich locker MBit und Mbyte durcheinander gebracht, was ein optimistisches Ergebnis brachte. Solange der TO keine konkrete Angaben macht, kann man nur vage bleiben. Um noch einmal auf LVDS zu kommen: die Schnittstelle ist schön schnell, wird nur leider nicht direkt von 'üblichen' Controllern unterstützt. Der Aufwand, den Du an anderer Stelle beschreibst, lenkt sehr vom eigentlichen Problem ab. Mir wäre er zu groß. Da würde ich eher mehrere TDCs verwenden und bequem per SPI auslesen. Praktisch wäre eine QSPI-Schnittstelle, die von neueren µCs direkt unterstützt wird.
Hans-Georg L. schrieb: > Minimalen Abstand der Impulse ? > Impulsbreite ? > Pegel? Da liegt das Problem bei den fertigen Bauteilen. Minimaler Abstand der Pulse kann schon bis auf 1ns herunter gehen. Der Pegel ist klein, wird aber durch einen Vorverstärker angehoben werden können oder einen diskreten Komparator für diese Frequenzen. Die gibt es fertig zu kaufen.
David S. schrieb: > Die gibt es fertig zu kaufen. Fix und fertig gibt es auch zu kaufen: Beitrag "[V] Rigol MSO8204 2 GHz 10 GSa/s"
David S. schrieb: > Hans-Georg L. schrieb: >> Minimalen Abstand der Impulse ? >> Impulsbreite ? >> Pegel? > > Da liegt das Problem bei den fertigen Bauteilen. Minimaler Abstand der > Pulse kann schon bis auf 1ns herunter gehen. Der Pegel ist klein, wird > aber durch einen Vorverstärker angehoben werden können oder einen > diskreten Komparator für diese Frequenzen. Die gibt es fertig zu kaufen. Sagen wir mal du nimmst 5 TDC-GPX2 das wären 20 Kanäle. Baust davor einen Multiplexer der deine Impulse auf die Kanäle verteilt und die Impulse auf die minimale Impulsbreite verlängert. Dahinter ein FPGA, welches die LVDS Kanäle de-serialisiert und speichert. Damit könntest du theoretisch deine Impulse im 1ns Abstand verarbeiten. Aber wie immer steckt der Teufel im Detail...
Abenteuerliche Idee mit dem (De)Multiplexer. Da müsste man den Impuls erkennen und auf den nächsten messbereiten TDC umschalten, bevor der nächste Impuls dann am entsprechenden TDC ankommt. Das in weniger als 1 ns zu schaffen, ist schon sehr sportlich. Das hier sind schnelle Komparatoren mit Latch-Enable: https://www.analog.com/media/en/technical-documentation/data-sheets/ADCMP572_573.pdf Da gibt's aber das Problem, dass beim Latch-Enable keine falsche Flanke erzeugt werden darf. Bei (hypotetischen) negativen zu messenden Pulsen darf also erst nach der steigenden Flanke des letzten und vor der fallenden des nächsten Pulses das Latch-Enable zum nächsten TDC umschalten.
Ein Gedanke von mir noch, dass man durchaus das SerDes Interface eine FPGA nehmen könnte oder ein SerDes Chip. Eine Suche dazu war allerdings nicht ganz erfolgreich. Die haben alle immer irgendein Protokoll und brauchen Daten zur Synchronisierung. Im Grunde brauche ich doch "nur" ein Schieberegister wo ich bei Bit N einmal ein Latch Enable mache und das kann ich dann parallel im FPGA einlesen. Der Eingang am ersten Register wäre eben der Ausgang meines Komparators. Schieberegister mit der Geschwindigkeit gibt es nicht fertig. Einzelflipflop MAX9381 kostet pro Stück schon mehr.
FPGA MGTs sind genau das. Die Protokollschichten lassen sich normalerweise deaktivieren um an die Rohdaten zukommen. Es könnte nur ein Problem geben, mehrere Serdes zu synchronisieren. Dafür ist eigentlich das darüberliegende Protokoll zuständig.
Andreas H. schrieb: > FPGA MGTs sind genau das. Die Protokollschichten lassen sich > normalerweise deaktivieren um an die Rohdaten zukommen. Es könnte nur > ein Problem geben, mehrere Serdes zu synchronisieren. Dafür ist > eigentlich das darüberliegende Protokoll zuständig. Die frage wäre ja ob ich mehrere brauche. Andreas H. schrieb: > Es könnte nur > ein Problem geben, mehrere Serdes zu synchronisieren. Dafür ist > eigentlich das darüberliegende Protokoll zuständig. Die Clock des Receivers kann ich doch extern vorgeben oder nicht?
Du brauchst mindestens zwei Serdes, da Du Start und Stop messen willst. Die Receiver erhalten üblicherweise einen Referenztakt, der ein Bruchteil des Bittaktes ist. Bei PCIe ist der Referenztakt z. B. 100 MHz. Die Serdes haben interne PLLs um Vielfache des Referenztakts zu erzeugen. Selbst wenn sich der PLL-Takt an mehrere Serdes verteilen lässt, bleibt immer noch das Problem, dass der Deserializer jedes Serdes eine andere Flanke des PLL-Taktes als Startpunkt nehmen könnte. Dafür gibt es bei PCIe bestimmte Wörter (Comma) im Datenstrom um diesen Bitslip auszugleichen. Stichwort "Comma Alignment" https://www.xilinx.com/support/documents/ip_documentation/gtwizard_ultrascale/v1_7/pg182-gtwizard-ultrascale.pdf Sowas willst Du für deine TDC ausschalten, musst aber trotzdem das gleiche Problem lösen, oder mit dem Jiter von +/- 1, 2, 3, ... Bins leben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.