Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung messen und anschließend in einer Software weiterverrechnen und numerisch anzeigen. Ich dachte evtl. daran einen einfachen USB Logikanalysator zu verwenden, oder vielleicht auch einen Raspberry PI Pico. Python und C Programmierkenntnisse wären vorhanden. Gibt es hier irgendwelche Tools oder Beispielprojekte auf die ich zurückgreifen könnte? Danke und Gruß Christian
Chris S. schrieb: > Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung messen Du willst also die Pulslänge mit +-50ns Genauigkeit erfassen?
Chris S. schrieb: > oder vielleicht auch einen Raspberry PI Pico. Einen Timer so programmieren, dass er die Länge des Impulses auf einem IO misst. Achtung die IOs des Rasp PI haben wahrscheinlich 3,3V, TTL hat 5V Pegel. Also Pegelanpassung. Am besten geht das natürlich mit einem Oszi, falls vorhanden.
:
Bearbeitet durch User
Ja, genau, einfach die Zeitdauer messen und dann diese Impulszeit weiterverarbeiten und am PC darstellen. Pegelwandlung ist klar und kein Problem.
:
Bearbeitet durch User
Udo S. schrieb: > Achtung die IOs des Rasp PI haben wahrscheinlich 3,3V, TTL hat 5V Pegel. Das ist nicht ganz korrekt. Der TTL-Ausgangspegel für High liegt bei 2,4 V bis 5 V. Ein CMOS-Eingang für 5V-Logik hat einen High-Eingangpegel von 3,5 V bis 5 V. Somit besteht durchaus die Möglichkeit, dass ein gültiges TTL-High nicht als CMOS-High erkannt wird. Bei 3,3V-CMOS-Logik wird hingegen der Eingang bei mehr als 3,3 V übersteuert; immerhin gibt es einige 5V-tolerante Eingänge bei 3,3V-Bausteinen, z.B. einigen Mikrocontrollern. Ich vermute mal, dass der TE in Wirklichkeit gar kein Signal mit TTL-Pegeln hat, sondern 5V-CMOS. > Also Pegelanpassung. Das ist korrekt.
Chris S. schrieb: > Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung messen Ein Pulsdauer hat gewöhnlich die Dimension einer Zeit und wird in Einheiten von Sekunden gemessen. In welchem Zeitbereich liegt denn deine Pulsdauer und ist das eine einmalige Messung (Labortest) oder suchst du nach einem Verfahren, dass irgendwo integriert werden soll? Muss die Darstellung Online erfolgen oder darf es in einer Nachbearbeitung von aufgezeichneten Daten sein?
:
Bearbeitet durch User
Chris S. schrieb: > Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung > messen und anschließend in einer Software weiterverrechnen und numerisch > anzeigen. https://www.ascel-electronic.de/bausaetze/13/ae20401-5.8-ghz-frequenzzaehler/rf-power-meter?
:
Bearbeitet durch User
Schon etwas älter und mit ATmega, sodaß es auch auf einem Arduino UNO/nano laufen kann: http://mino-elektronik.de/fmeter/fm_software.htm#bsp6 Legt man das Signal an beide Eingänge, wird je nach Einstellung der Flanken die aktive oder passive Zeit des Impulses gemessen. Als Anzeige ist ein 16 x 2 LCD vorgesehen, serielle Datenausgabe zum PC ist kein Problem. 10-fach höhere Auflösung kann man mit einem RP2040 (RPi Pico) erreichen. Das kannst Du Dir ja zu Weihnachten wünschen ;-) Ich habe noch eine Schaltung mit STM32F407 gefunden: http://mino-elektronik.de/FM_407/fmeter_407.htm#a5
:
Bearbeitet durch User
Periodendauer misst ein Frequenzzähler wie der relativ günstige TF960 https://at.rs-online.com/web/p/frequenzzahler/6654919 Mit dem USB/RS232 Interface kannst du die Kommandos in ein Terminal in 1-2 Zeilen hinschreiben, oder du erstellst ein Skript in Python/Bash/C... Das zum Laufen zu bringen sollte nicht länger als 1-2 Stunden dauern.
Angehängte Dateien:
-
100ns.PNG
49 KB
Chris S. schrieb: > Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung > messen.. 10MHz ist eine Frequenz, keine Auflösung. Und was willst du messen, die komplette Periode oder nur den H bzw. L Anteil? Mit welcher Genauigkeit soll gemessen werden? https://www.mikrocontroller.net/attachment/685494/100ns.PNG Und wenn die Frage erlaubt ist, wofür das Ganze?
:
Bearbeitet durch User
Udo K. schrieb: > ein Frequenzzähler wie der relativ günstige TF960 Oh, das ist günstig? Letzlich bietet er nur 20 ns Auflösung bei der Pulsweite.
Chris S. schrieb: > Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung messen > und anschließend in einer Software weiterverrechnen und numerisch > anzeigen. Wie oft MUSST Du das messen. Nur mal nächste Woche oder so, einmal in der Stunde oder 1000 mal in der Sekunde? Hast du schon jemanden der dir den Messwert vorliest oder soll der per Morsecode übergeben werden? Ist die Messstelle auch die Auswertestelle, oder hast du den Postweg geplant? Wie soll das verrechnet werden? Auf dem PC des Chefs, dem Smartphone deiner Freundin oder dem Taschenrechner vom Aldi? Ist es egal was das ganze kostet oder ist des ein Staatsauftrag der dann durch Nachträge vergoldet wird? Oder sammelst du jetzt erst mal Ideen für das Pflichtenheft?
Nicht jeder Versuch lustig zu sein endet erfolgreich.
Norbert schrieb: > Nicht jeder Versuch lustig zu sein endet erfolgreich. Lachen muss da kein einziger drüber. Es genügt, wenn der TO nochmal über seine Fragestellung nachdenkt. Du kannst in der Zwischenzeit wieder im Keller verschwinden.
Udo S. schrieb: > Am besten geht das natürlich mit einem Oszi, falls vorhanden. Womit das am einfachsten geht, hängt auch davon ab, wie lang die einzelnen Impulse sind.
Chris S. schrieb: > Ja, genau, einfach die Zeitdauer messen und dann diese Impulszeit > weiterverarbeiten und am PC darstellen. > Pegelwandlung ist klar und kein Problem. Am einfachsten scheint mit eine Lösung auf Arduino-Basis. Die Atmega328P haben einen sogenannten ICP (input capture pin), dessen Flanken innerhalb eines Taktes eine Kopie des Zählerstands eines Hardwarezählers anlegen, bei 16MHz CPU-Takt also mit einer Auflösung von auch bis zu 16 MHz. Die gemessenen Taktlängen können dann über USB seriell an den PC übermittelt werden. Ein Arduino Nano (z.B. https://www.reichelt.de/de/de/shop/produkt/arduino_kompatibles_nano_board_atmega328pb_usb-c_extra_io-372078, der Atmega328PB hat sogar drei solcher ICP-Eingänge), etwas C++, etwas Python, fertig. LG, Sebastian
:
Bearbeitet durch User
Angehängte Dateien:
-
tinyGTC_20251218_202623.png
5,2 KB
M.A. S. schrieb: > Udo S. schrieb: >> Am besten geht das natürlich mit einem Oszi, falls vorhanden. > > Womit das am einfachsten geht, hängt auch davon ab, wie lang die > einzelnen Impulse sind. Wie lang die Impulse sind erkennt man am einfachsten mit einem Oszilloskop. Lothar M. schrieb: > Chris S. schrieb: >> Ich müsste die Länge eines TTL Impulses mit ca. 10MHz Auflösung messen > Du willst also die Pulslänge mit +-50ns Genauigkeit erfassen? Dafür würde dann fast jeder beliebige Mikrocontroller reichen. Falls es sich aber um Impulses mit ca. 10MHz Frequenz handeln sollte deren Pulslänge gemessen werden soll müsste der Mikrocontroller schon etwas schneller sein. Mit einem Oszilloskop oder einem geeigneten Zähler/Timer ginge es einfacher. Der noch recht neue tinyGTC hat laut Wiki eine Auflösung von 40ps. Er lässt sich direkt über das Touch-Display bedienen oder remote vom PC aus oder über SCPI. Für das angehängte Bild habe ich ein 10MHz Rechtecksignal an Eingang A meines tinyGTC angeschlossen. In der obersten Zeile sind die Zustände des Gerätes und der Ein- und Ausgänge dargestellt. Die zweite Zeile habe ich zur Anzeige der Frequenz mit Statistik eingestellt und die dritte Zeile für die Pulslänge mit Statistik. Unten ist ein Histogramm der Pulslänge mit 80 Bins. Über SCPI geht eine Messung der Pulslänge im einfachsten Fall so:
1 | > meas1:pwid? |
2 | 5.03300000000000e-08 |
Wenn da keine Rückmeldung vom TO kommt dann darf man annehmen dass am Mittwoch dem 17.12. schon der Freitag begonnen hat. Einfach ein bisschen Frage ins Forum rotzen und sich dann amüsieren wie sich die Leute hier gegeseitig verbal prügeln und hilfeschreiend nach zusätzlichen Informationen fragen. Chris S. schrieb: > Gibt es hier irgendwelche Tools oder Beispielprojekte auf die ich > zurückgreifen könnte? Mann darf annehmen dass der TO bei Null anfängt ....
Stefan K. schrieb: > Falls es > sich aber um Impulses mit ca. 10MHz Frequenz handeln sollte deren > Pulslänge gemessen werden soll müsste der Mikrocontroller schon etwas > schneller sein. Mit einem Oszilloskop oder einem geeigneten Zähler/Timer > ginge es einfacher. > Der noch recht neue tinyGTC hat laut Wiki eine Auflösung von 40ps. Das ist vermutlich die kostengünstgte Lösung ;-) Für den ps-Bereich hätte ich noch Schaltungen/Platinen mit AS6501 und RP2040: http://mino-elektronik.de/fmeter/fm_software.htm#bsp_RP2040b CAP1 und CAP2 (siehe Schaltplan) können entsprechend verwendet werden. Wastl schrieb: > Mann darf annehmen dass der TO bei Null anfängt .... Frau darf das auch und vermutlich bleibt der TO auch da.
Stefan K. schrieb: > ... Unten ist ein Histogramm der Pulslänge mit 80 Bins. Ist das normal, dass das Histogramm beim vermutlichen Mittelwert eine "Nullstelle" hat? Oder wird da das Maximum "ausgeblended"? Oder ist das 10 MHz Normal so schlecht? ☺
:
Bearbeitet durch User
Zwei Null-"Nebenlinien" sieht man auch noch... Regelmäßiger Abstand, hm.
Es wird nur der belegte Teil in 80 Bins aufgeteilt dargestellt. Bei 370ps Gesamtbreite und Messwerten mit 10ps Auflösung ergibt das "Lücken" mit unterschiedlicher Breite. Signalquelle war ein LBE-1421 mit vermutlich etwas aber nicht wesentlich besseren Eigenschaften als der GPSDO im tinyGTC.
Stefan K. schrieb: > Bei 370ps Gesamtbreite und Messwerten mit 10ps Auflösung ergibt das > "Lücken" mit unterschiedlicher Breite. Das ist eine ganz üble, irreführende Datenaufbereitung bzw. Darstellung. Die Darstellung darf nicht durch Aliasing auf Grund von Quantisierung und Klassenbreiten verzerrt werden. Da hat wohl jemand ohne Sinn und Verstand gearbeitet, sorry. Für eine aussagekräftige Darstellung müssen die Klassen unter Berücksichtigung der Quantisierung gleich breit sein.
:
Bearbeitet durch User
Der tinyGTC ist ein kleines, von Erik bewusst preiswert gehaltenes, Gerät mit beschränkter Rechenleistung, kleinem Speicher und kleinem Display. Für eine bessere Darstellung kann man die Daten zu einem PC streamen und dort aufbereiten.
Stefan K. schrieb: > Der tinyGTC ist ein kleines, von Erik bewusst preiswert gehaltenes, > Gerät mit beschränkter Rechenleistung, kleinem Speicher und kleinem > Display Das ist kein Grund, so einen Mist in der Anzeige darzustellen. Für eine vernünftige Darstellung müsste nur dafür gesorgt werden, dass die Klassenbreite ein GANZZAHLIGES Vielfaches der Zeitauflösung beträgt. Statt einer Gesamtbreite von in diesem Fall 370 ps müssten sich die 80 Klassen auf ein Intervall von 400 ps verteilen, d.h. eine Klassenbreite von dem 5-fache der Auflösung und nicht dem 4,6-fachen. Vom Rechenaufwand ist das weniger, als das, was dort jetzt getrieben wird. Mit Speicherbedarf und Displaygröße hat das wenig zu tun oder wo siehst du da einen nennenswerten Einfluss? Kannst du einmal die so einem Histogramm zugrunde liegenden Rohdaten (gemessene Pulsbreiten) hochladen?
:
Bearbeitet durch User
Rainer W. schrieb: > Stefan K. schrieb: >> Der tinyGTC ist ein kleines, von Erik bewusst preiswert gehaltenes, >> Gerät mit beschränkter Rechenleistung, kleinem Speicher und kleinem >> Display > > Das ist kein Grund, so einen Mist in der Anzeige darzustellen. Für eine > vernünftige Darstellung müsste nur dafür gesorgt werden, dass die > Klassenbreite ein GANZZAHLIGES Vielfaches der Zeitauflösung beträgt. > Anstelle hier wieder mal den Meinungs-Rambo über etwas das nix mit der Frage des TO zu tun hat zu machen und damit den Thread zuzumüllen... wie wäre es wenn Du Deine mehr oder weniger sinnvollen und stilvollen Anmerkungen dem Produktentwickler um die Ohren pfefferst.
Mi. W. schrieb: > Anstelle hier wieder mal den Meinungs-Rambo über etwas das nix mit der > Frage des TO zu tun hat zu machen und damit den Thread zuzumüllen... Unterscheide doch bitte zwischen Meinung und Fakten. Der Einwurf mit der Werbung für den tinyGTC stammt nicht von mir. Falls der TO in Erwägung ziehen sollte, den für seine Messaufgabe einzusetzen, ist es seinem Problem nur zuträglich, wenn er sich der von mir beschriebenen und von anderen ebenso bemerkten Schwachstellen bewusst wird.
:
Bearbeitet durch User
Rainer W. schrieb: > Mi. W. schrieb: >> Anstelle hier wieder mal den Meinungs-Rambo über etwas das nix mit der >> Frage des TO zu tun hat zu machen und damit den Thread zuzumüllen... > > Unterscheide doch bitte zwischen Meinung und Fakten. > > Der Einwurf mit der Werbung für den tinyGTC stammt nicht von mir. > > Falls der TO in Erwägung ziehen sollte, den für seine Messaufgabe > einzusetzen, ist es seinem Problem nur zuträglich, wenn er sich der von > mir beschriebenen und von anderen ebenso bemerkten Schwachstellen > bewusst wird. Fakten brauchen keine verbale Entgleisung. Meinung lebt von verbaler Entgleisung. Für mich EOD
:
Bearbeitet durch User
Angehängte Dateien:
-
tinyGTC_20251219_163157.png
4,8 KB
Rainer W. schrieb: > Kannst du einmal die so einem Histogramm zugrunde liegenden Rohdaten > (gemessene Pulsbreiten) hochladen? Bitte sehr, Messdaten über etwa eine halbe Stunde und Screenshot. Die Pulsbreitenmessung ist etwas was der tinyGTC zwar auch kann, aber dies längst nicht so gut wie Frequenz- oder Periodenmessungen. Bei einer Gatezeit von einer Sekunde wird pro Sekunde nur ein einziger Puls vermessen. Was das Gerät perfekt kann, unterbrechungsfrei Zählen, wird bei der Pulsbreitenmessung also gar nicht genutzt.
Sebastian W. schrieb: > Lösung auf Arduino-Basis > (...) > Die Atmega328P haben einen sogenannten ICP (input capture pin), dessen > Flanken innerhalb eines Taktes eine Kopie des Zählerstands eines > Hardwarezählers anlegen, bei 16MHz CPU-Takt also mit einer Auflösung von > auch bis zu 16 MHz. Der Hardwarezähler läuft aber maximal mit dem CPU-Takt. Und: Man muss den kopierten Zählerstand per Software sichern, bevor er sich möglicherweise ändert – das braucht etliche CPU-Zyklen. Am Ende kann man also nur die Längen solcher Impulse ermitteln, die erheblich länger sind, als es die Zahl 16 MHz suggeriert. BTW: Was soll hier "Auflösung in MHz" überhaupt bedeuten? Von Frequenzen im zu messenden Signal ist nichts zu lesen. Entweder meint der OP die Abtastrate oder die Genauigkeit des Messergebnisses.
Rolf schrieb: > Der Hardwarezähler läuft aber maximal mit dem CPU-Takt. Und: Man muss > den kopierten Zählerstand per Software sichern, bevor er sich > möglicherweise ändert – das braucht etliche CPU-Zyklen. > Am Ende kann man also nur die Längen solcher Impulse ermitteln, die > erheblich länger sind, als es die Zahl 16 MHz suggeriert. Das ist doch kein reales Problem, wenn man die capture-Funktion verwendet und sofern die Pulsbreite größer als 2 - 3 µs ist. Nach der 1. Flanke an ICP wird die Polarität invertiert und der Zählerstand ausgelesen. Bei der 2. Flanke ebenso und abschließend die Differenz errechnet. Überläufe des Zählers müssen selbstverständlich berücksichtigt werden. > BTW: Was soll hier "Auflösung in MHz" überhaupt bedeuten? Von Frequenzen > im zu messenden Signal ist nichts zu lesen. Entweder meint der OP die > Abtastrate oder die Genauigkeit des Messergebnisses. Das geht ja garnicht! Der TO muß natürlich schreiben, daß er eine Auflösung von mindestens 100 ns braucht, sonst wollen wir das nicht verstehen :-( Die angefragten Beispielprojekte hat er bekommen. Ob er damit etwas anfangen kann, sagt er nicht. Er muß es ja auch nicht sondern "müßte" es nur.
Angehängte Dateien:
-
4_000ps.png
13 KB -
4_1609ps.png
13 KB -
5_000ps.png
13 KB -
8_000ps.png
13 KB -
10_000ps.png
13 KB
Stefan K. schrieb: > Bitte sehr, Messdaten über etwa eine halbe Stunde und Screenshot. Damit kann man was anfangen - vielen Dank. Mi. W. muss jetzt mal ganz tapfer sein. Die Bilder stellen aus den Daten erzeugte Histogramme für verschiedenen Klassenbreiten dar. Die Klassenbreite 4,1609 ps entspricht etwa dem Histogramm im Display (Klassengrenzen entsprechen wohl nicht ganz denen im tinyGTC). Der Anfangswert des Darstellungsbereiches ist überall gleich. Zu jeder absoluten Häufigkeit (Y-Achse) wurde ein Offset von 5 addiert, damit alle 80 Klassen als Balken auftauchen. Erst bei einer Klassenbreite von 10 ps treten keine leeren Klassen, die durch Aliasing zwischen Klassenbreite und Auflösung entstehen, mehr auf. Bei allen Klassenbreiten unter 10 ps gibt es immer leere Klassen (Y-Wert 5 wegen Offset) dazwischen, weil die Klassenbreite kein ganzzahlig Vielfaches der Auflösung ist. q.e.d. p.s. Auffällig bleibt, dass bei der Breite von 10 ps im zentralen Bereich des Histogramms die Häufigkeit in jeder zweiten Klasse viel zu niedrig ist, als ob da irgendeine Asymmetrie vorliegt. Das fällt auch auf, wenn man direkt die Zeitserie plottet (ohne Statistikrechnerei). Ungradzahlige Vielfache von 10 ps sind unterrepräsentiert. Die Anzahl der Punkte sollte eigentlich ausreichen, um das als signifikant zu bezeichnen.
:
Bearbeitet durch User
Mi N. schrieb: > Nach der 1. > Flanke an ICP wird die Polarität invertiert und der Zählerstand > ausgelesen. Bei der 2. Flanke ebenso und abschließend die Differenz > errechnet. Viel einfacher: https://www.mikrocontroller.net/attachment/666147/AVR_TCB_Input_Capture_Pulse-Width_Measurement.png
Georg M. schrieb: > Viel einfacher: Auch gut, wenn der +Impuls kleiner ist und kein OVF stattfindet. Sonst müßte man sich die Situation näher ansehen. Sehr bequem ginge es mit einem 32 Bit Zähler (TIM2 zum Beispiel) in einem STM32F/G/Hxyz: Hohe Auflösung und lange Zeiten.
Mi N. schrieb im Beitrag #7982268
> und kein OVF stattfindet
Ein Overflow darf sein, wenn man mit unsigned rechnet. Ist ein kleines
Geheimnis von uint.
uint8: 0x02 - 0xff = 0x03
Rainer W. schrieb: > Damit kann man was anfangen - vielen Dank. Mit genügend Abstand betrachtet sehen alle Bilder gleich aus. Irgendwelche Strukturen in 10ps Raster finde ich bei einer spezifizierten Auflösung von 40ps pro Timer und zwei beteiligten Timern uninteressant. Ich habe keine Ahnung wie daraus überhaupt eine Dauer mit 10ps Auflösung berechnet wird und will das auch gar nicht so genau wissen. Der größte Teil der Messwerte liegt in einem Breich von 200ps Breite und das finde ich schon ganz ordentlich.
Angehängte Dateien:
-
13_000ps.png
10 KB
> Ich habe keine Ahnung wie daraus überhaupt eine Dauer mit > 10ps Auflösung berechnet wird und will das auch gar nicht so genau > wissen. Das scheint ja auch nur so halb zu klappen. Am Maximum der Verteilung sollten die Häufigkeiten in benachbarten Klassen bei halbwegs normalverteilten Pulslängen ähnlich sein, statt dessen liegt dort bis zu einem Faktor vier zwischen. https://www.mikrocontroller.net/attachment/685658/10_000ps.png > Mit genügend Abstand betrachtet sehen alle Bilder gleich aus. Solange die Klassenbreite kleiner als die Auflösung ist, kommen nur unbelegten Klassen dazwischen und wie viele leere dazwischen sind, fällt aus der Entfernung nicht so auf. Ändert tut sich das, wenn die Klassenbreite größer als die Auflösung wird, z.B. bei 13 ps (sonst alles wie vorher) ;-)
:
Bearbeitet durch User
Stefan K. schrieb: > M.A. S. schrieb: >> Udo S. schrieb: >>> Am besten geht das natürlich mit einem Oszi, falls vorhanden. >> >> Womit das am einfachsten geht, hängt auch davon ab, wie lang die >> einzelnen Impulse sind. > Wie lang die Impulse sind erkennt man am einfachsten mit einem > Oszilloskop. Die Ausgangsfrage geht um Messung mit einer Auflösung von 100ns. Wenn die Impulse relativ lang sind, ist ein Oszilloskop die schlechteste Möglichkeit zur Messung.
Chris S. schrieb: > oder vielleicht auch einen Raspberry PI Pico. > Python und C Programmierkenntnisse wären vorhanden. Die Antwort steckt bereits in der Frage! Mit einem 4€ Pico(2) kann man mit bequem auf 8ns bestimmen (5ns bei gemächlichen 200MHz). Wenn man eine längere Pulsfolge bekommt, ist auch eine Sub-ns Auflösung nicht weit entfernt. Da braucht man noch nicht einmal einen Compiler.
Norbert schrieb: > Die Antwort steckt bereits in der Frage! > Mit einem 4€ Pico(2) kann man mit bequem auf 8ns bestimmen (5ns bei > gemächlichen 200MHz). Jetzt enttäuschst Du mich aber. Ich dachte, Du zeigst gleich das fertige Programm ;-) P.S.: ich warte noch darauf, daß garantiert die A4 Version bestückt ist, bevor ich ein neues Spielzeug besorge.
M.A. S. schrieb: > Die Ausgangsfrage geht um Messung mit einer Auflösung von 100ns. Wenn > die Impulse relativ lang sind, ist ein Oszilloskop die schlechteste > Möglichkeit zur Messung. Das hängt entscheidend von den Möglichkeiten des Oszilloskops ab. ☺ Einem HP5308A/HP5300A fehlt leider der Datenausgang. :( Macht aber nichts. Norbert schrieb: > Wenn man eine längere Pulsfolge bekommt, ist auch eine Sub-ns Auflösung > nicht weit entfernt. Da braucht man noch nicht einmal einen Compiler. Dazu müsste das "Messgerät" auch eine "Sub-ns" jitterfreie Zeitbasis haben. Hat es das? Rainer W. schrieb: >> Ich habe keine Ahnung wie daraus überhaupt eine Dauer mit >> 10ps Auflösung berechnet wird und will das auch gar nicht so genau >> wissen. > > Das scheint ja auch nur so halb zu klappen. > Am Maximum der Verteilung sollten die Häufigkeiten in benachbarten > Klassen bei halbwegs normalverteilten Pulslängen ähnlich sein, statt > dessen liegt dort bis zu einem Faktor vier zwischen. Möglicherweise ist einer (oder beide) der beteiligten OCXOs, am Ende seiner Lebensdauer. Dann werden manche komisch. ☺
Cartman E. schrieb: > Möglicherweise ist einer (oder beide) der beteiligten OCXOs, > am Ende seiner Lebensdauer. Dann werden manche komisch. ☺ Was auch immer ein "komischer OCXO" für ein Signal liefert ... Mir kommt das so vor, als ob beide Flanken der Zeitbasis für die Pulsdauermessung genutzt werden, aber irgendetwas mit der Symmetrie nicht stimmt (Tastverhältnis, Laufzeiten).
Cartman E. schrieb: > Dazu müsste das "Messgerät" auch eine "Sub-ns" jitterfreie Zeitbasis > haben. Hat es das? Norbert schrieb: > Wenn man eine längere Pulsfolge bekommt, Längere Pulsfolge suggeriert bereits, dass man mit vielen Samples und ein wenig Statistik darauf herum arbeitet. Das mittelt einen möglichen Jitter-Anteil schön heraus. Richtig Klasse ist das, wenn man beim Messvorgang absichtlich einen definierten Jitter hinzu fügt. Beim Pico zB. CPU Speed 200 MHz, Abtastung 192.481203 MHz (ja, für diesen Wert gibt es einen Grund. Einen Guten sogar) Einfach mal ausprobieren (im Kopf oder/und im µC) hilft enorm.
Angehängte Dateien:
-
LBE-1421.png
4,6 KB -
tinyGTC.png
4,8 KB
Cartman E. schrieb: > Möglicherweise ist einer (oder beide) der beteiligten OCXOs, > am Ende seiner Lebensdauer. Dann werden manche komisch. ☺ In keinem der beiden Geräte ist ein OCXO und keins ist alt, im LBE-4121 und im tinyGTC sind nur TCXOs. Ich habe jetzt einmal 10MHz vom LBE-4121 über ein SMA-T mit dem Referenz- und Messeingang des TinyGTC verbunden und einmal 10MHz vom Ausgang des tinyGTC sebst an den Eingang angelegt. Die Gesamtbreite des Histogramms ist nahezu identisch die Verteilung beim LBE-1421 ist allerdings auffällig.
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.