Hallo zusammen, ich beschäftige mich gerade mit dem Entwurf eines GPS-Frequenznormals. Dabei bin ich auf den AS6501 gestoßen. Wenn ich den OCXO als „REFCLK“ nutze und den GPS-PPS auf „STOPA“ lege, bekomme ich bei jedem Sekundenimpuls den Phasenversatz als „TSTOP“ ausgegeben. Damit sollte ich eine höhere Auflösung und Genauigkeit erreichen als mit den meisten Methoden, die ich im Internet gesehen habe oder übersehe ich etwas? Der AS6501 kann sowohl CMOS- als auch LVDS-Signale auswerten. Ist es sinnvoller, die Signalflanken von OCXO und GPS mit einem 74HC7014 (CMOS) oder einem DS90LV011A (LVDS) aufzubereiten? Ich komme aus dem Maschinenbau, daher bitte ich um Nachsicht bei einfachen Fragen. Danke für eure Antworten.
Die Genauigkeit der Frequenz erhaelt man als Mittelung, als Mittelung ueber 1000 Sekunden, dh 1/4 Stunde, Ueber 1*10^10 (10G) Perioden. Dazu kommt, dass der 1pps einen Jitter von vielleicht 50ns besitzt. Bedeutet, du musst die Anzahl OCXO Perioden abzaehlen, zB 1*10^7 (10M), und dann alle sekunden die flanke des 1pps dazu messen.
:
Bearbeitet durch User
Christoph T. schrieb: > Hallo zusammen, > > ich beschäftige mich gerade mit dem Entwurf eines GPS-Frequenznormals. > Dabei bin ich auf den AS6501 gestoßen. Wenn ich den OCXO als „REFCLK“ > nutze und den GPS-PPS auf „STOPA“ lege, bekomme ich bei jedem > Sekundenimpuls den Phasenversatz als „TSTOP“ ausgegeben. > > Damit sollte ich eine höhere Auflösung und Genauigkeit erreichen als mit > den meisten Methoden, die ich im Internet gesehen habe oder übersehe ich > etwas? > > Der AS6501 kann sowohl CMOS- als auch LVDS-Signale auswerten. > Ist es sinnvoller, die Signalflanken von OCXO und GPS mit einem 74HC7014 > (CMOS) oder einem DS90LV011A (LVDS) aufzubereiten? > > Ich komme aus dem Maschinenbau, daher bitte ich um Nachsicht bei > einfachen Fragen. > > Danke für eure Antworten. Du musst TStop und TRef auslesen. Das würde nur funktionieren wenn du den AS6501 auch über LVDS ausliest dann kann er bis 1,6s messen (24bit Ref. Zähler). Über die SPI Schnittstelle sind es max. 6,5ms (16Bit Ref.Zähler). Die höhere Auflösung nützt dir nur bedingt weil GPS seine Genauigkeit erst nach Mittelung über Minuten erreicht. Der PPS Ausgang vom GPS Emfänger hat Jitter im 2 stelligen ns Bereich. Da bringt ein guter Empfänger, eine gute Antenne und "saw tooth" correction mehr.
Pandur S. schrieb: > Die Genauigkeit der Frequenz erhaelt man als Mittelung, als Mittelung > ueber 1000 Sekunden, dh 1/4 Stunde, Ueber 1*10^10 (10G) Perioden. Dazu > kommt, dass der 1pps einen Jitter von vielleicht 50ns besitzt. > Bedeutet, du musst die Anzahl OCXO Perioden abzaehlen, zB 1*10^7 (10M), > und dann alle sekunden die flanke des 1pps dazu messen. Was er beschreibt ist das Vermessen der Phasenlage. Das ist für den Betrieb hinterher eigentlich schon der bessere Weg. Beim Start, wenn der OCXO noch kalt oder der GPS-Fix noch jung ist, macht die Mittelung mehr Sinn. Wenn der Fehler dann unter ein bestimmtes Maß gesunken ist, geht man zur Phasenmessung über. Ich würde außerdem empfehlen ein für Timing optimiertes GPS-Modul zu verwenden. Die können meist eine Information ausgeben wie weit der letzte PPS-Impuls vom eigentlichen Sekundenwechsel abwich. Zumindest bei den Timing-Modulen von U-blox wie z.B. M8T ist das so. Diesen Wert dann zu dem per AS6501 gemessenen Signal addieren/subtrahieren. Da die Phasenabweichung dann in den Nanosekunden-Bereich geht, spielt es auch keine Rolle wenn der AS6501 über SPI angesteuert wird und nicht die vollen 24 Bit ausgeben kann.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Über die SPI > Schnittstelle sind es max. 6,5ms (16Bit Ref.Zähler). Danke, das habe ich übersehen. Das heißt, ich muss die Frequenz stattdessen über einen Timer im µC ermitteln und den OCXO zunächst grob voreinstellen. Im zweiten Schritt kann ich dann die Phasenlage über „TStop“ bestimmen. Die PLL sollte anschließend relativ schnell einschwingen, ohne dass ich „TRef“ benötige. Gerd E. schrieb: > Beim Start, wenn der OCXO noch kalt oder der GPS-Fix noch jung ist, > macht die Mittelung mehr Sinn. Wenn der Fehler dann unter ein bestimmtes > Maß gesunken ist, geht man zur Phasenmessung über. > > Ich würde außerdem empfehlen ein für Timing optimiertes GPS-Modul zu > verwenden. Die können meist eine Information ausgeben wie weit der > letzte PPS-Impuls vom eigentlichen Sekundenwechsel abwich. Zumindest bei > den Timing-Modulen von U-blox wie z.B. M8T ist das so. Diesen Wert dann > zu dem per AS6501 gemessenen Signal addieren/subtrahieren. Das entspricht ziemlich genau dem, was ich mir überlegt habe. Ich war nur unsicher, ob mein Ansatz so funktioniert, wie ich es mir gedacht habe.
Christoph T. schrieb: > Hans-Georg L. schrieb: >> Über die SPI >> Schnittstelle sind es max. 6,5ms (16Bit Ref.Zähler). > > Danke, das habe ich übersehen. > Das heißt, ich muss die Frequenz stattdessen über einen Timer im µC > ermitteln und den OCXO zunächst grob voreinstellen. > Im zweiten Schritt kann ich dann die Phasenlage über „TStop“ bestimmen. > Die PLL sollte anschließend relativ schnell einschwingen, ohne dass ich > „TRef“ benötige. Du hast 2 Möglichkeiten entweder du benutzt einen GPS Empfänger der den Takt schneller stellen kann oder du zählst die Referenz mit einem Timer in deinem Controller. Da musst du nur aufpassen weil es nicht auszuschließen ist, das es zu einem Takt unterschied zwischen dem AS6501 Referenz Zähler und deinem MCU Zähler kommen kann. Das musst du in der Software abfangen. Als GPS Empfänger würde ich dir die Huawei Platinen mit einem LEA8 empfehlen. https://de.aliexpress.com/item/1005006846801239.html. Das sind keine Fakes.
Hans-Georg L. schrieb: > Christoph T. schrieb: >> Hans-Georg L. schrieb: >>> Über die SPI >>> Schnittstelle sind es max. 6,5ms (16Bit Ref.Zähler). >> >> Danke, das habe ich übersehen. >> Das heißt, ich muss die Frequenz stattdessen über einen Timer im µC >> ermitteln und den OCXO zunächst grob voreinstellen. >> Im zweiten Schritt kann ich dann die Phasenlage über „TStop“ bestimmen. >> Die PLL sollte anschließend relativ schnell einschwingen, ohne dass ich >> „TRef“ benötige. Du hast 2 Möglichkeiten entweder du benutzt einen GPS Empfänger der den PPS Takt schneller stellen kann oder du zählst die Referenz mit einem Timer in deinem Controller. Da musst du nur aufpassen weil es nicht auszuschließen ist, das es zu einem Takt unterschied zwischen dem AS6501 Referenz Zähler und deinem MCU Zähler kommen kann. Das musst du in der Software abfangen. Als GPS Empfänger würde ich dir die Huawei Platinen mit einem LEA8 empfehlen. https://de.aliexpress.com/item/1005006846801239.html. Das sind keine Fakes.
:
Bearbeitet durch User
Christoph T. schrieb: > Damit sollte ich eine höhere Auflösung und Genauigkeit erreichen als mit > den meisten Methoden, die ich im Internet gesehen habe oder übersehe ich > etwas? Ich weiß nicht, was Du gesehen und welche Ansprüche/Erwartungen Du hast. Vielleicht hift Dir dieser Link weiter, wo zuletzt auch ein AS6501 verwendet wird: https://www.paulvdiyblogs.net/2023/01/a-high-resolution-reciprocal-counter.html Auf keinen Fall möchte ich Dich davon abhalten, eigene Erfahrungen zu machen, aber vielleicht hilft/nutzt Dir die Arbeit von anderen Entwicklern, die man direkt verwenden kann.
Ich würde Dir die timenuts-Liste auf febo.com empfehlen. Die haben auch ein Archiv. Die Liste ist moderiert, deswegen herrscht dort ein gepflegter Umgangston und ein hohes Niveau. Zum AS6501 kann ich nix sagen, habe ihn noch nie benutzt. Bei vielen GPS-Empfängern ist der 1pps gerade mal ein Port des Prozessors. Der wird erst wirklich nützlich wenn man ganz viele 1pps-Pulse auswertet. Es gibt da den sog. Hängebrückeneffekt, dazu findet man viel auf der timenuts-Liste. Gruß, Gerhard DK4XP
Hans-Georg L. schrieb: > Als GPS Empfänger würde ich dir die Huawei Platinen mit einem LEA8 > empfehlen. https://de.aliexpress.com/item/1005006846801239.html. Das > sind keine Fakes. Ich kann zu diesem konkreten Angebot nix sagen, hab aber vor 2 Jahren 2 ähnliche Platinen für einen ähnlichen Preis bestellt. Das waren echte M8T-Module und die funktionieren gut. Die M8T können nicht nur den Offset des PPS-Impulses ausgeben wie ich oben geschrieben habe, sondern man kann auch die Frequenz ändern wie Hans-Georg schrieb. Das können bei U-blox nur die Timing- und Frequenzmodule, nicht die "normalen" Empfänger für Ortsbestimmung. Man hat dann also nicht 1 PPS, sondern statt dessen z.B. 100 kHz. Bei den M8T sollte man es mit der Frequenz des Signals aber nicht übertreiben weil sonst der Jitter hochgeht. Die Hardware und das Konzept dahinter sind halt für 1 PPS gedacht. Auch wenn man da theoretisch direkt 10 MHz ausgeben lassen kann und auch 10 MHz bekommt, hat das Signal dann einen Jitter jenseits von gut und böse und wäre damit für eine PLL ungeeignet. Bei 100 kHz ist das aber noch kein Problem.
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Du hast 2 Möglichkeiten entweder du benutzt einen GPS Empfänger der den > PPS Takt schneller stellen kann oder du zählst die Referenz mit einem > Timer in deinem Controller. Da musst du nur aufpassen weil es nicht > auszuschließen ist, das es zu einem Takt unterschied zwischen dem AS6501 > Referenz Zähler und deinem MCU Zähler kommen kann. Das musst du in der > Software abfangen. Dann ist das Auslesen über LVDS wohl einfacher. Wenn der GPS‑PPS schneller als 1 Hz ist, gibt der Empfänger keine Korrekturdaten aus. Ich plane, einen STM32F103 zu benutzen. Dessen SPI‑Schnittstelle im "slave mode" sollte mit DMA die 10 Mbit/s schaffen. Die LVDS‑Schnittstelle des AS6501 hat einen Mindesttakt von 10 MHz und drei Leitungen (LCLK, FRAME und SDO). Das „FRAME“‑Signal ist pro Block immer 8 Bit lang, unabhängig von der Blocklänge. Deshalb möchte ich mit dem „FRAME“‑Signal ein Flipflop (SN74LVC1G74) setzen, um daraus ein CS‑Signal für die SPI‑Schnittstelle zu erzeugen. Am Blockende setzt der DMA‑Interrupt das Flipflop wieder zurück. Funktioniert dieser Ansatz so, oder gibt es einen einfacheren Weg?
Der UBLOX LEA den ich dir vorgeschlagen habe kann 2 Time Impulse generieren. Der STM32F103 kann max. 16Bit SPI Frames empfangen und du brauchst auch noch Pegelwandler LVDS-> CMOS für die Daten vom AS6501 und einen CMOS-> LVDS für die 10MHz zum AS6501. Beschreibe mal komplett was du vorhast und mit welche Komponenten du verwendest. Blockschaltbild ?
Hans-Georg L. schrieb: > Beschreibe mal komplett was du vorhast > und mit welche Komponenten du verwendest. Blockschaltbild ? Das wäre sehr sinnvoll. Bei niedrigen Abtastraten (< 1 MHz) würde ich auch kein LVDS aktivieren. Es macht nur zusätzlichen Aufwand und bringt keine besseren Daten. Christoph T. schrieb: > Ich plane, einen STM32F103 zu benutzen. Für einen STM32H7xx habe ich unbestückte Leiterplatten (für ein paar Euro), wobei aber CAP1 und CAP2 nicht gesondert herausgeführt sind. Dafür ist der AS6501 mit allen 'lebenswichtigen' Kondensatoren abgeblockt. Ebenfalls habe ich auch noch eine Leiterplatte mit AS6501 und RP2040 (PicoPi-Board). Hier sind CAP1 und CAP2 separat erreichbar, wobei die Programmierung einen Segger J-Link erfordert oder per Arduino-IDE erledigt werden muß.
Christoph T. schrieb: > Ich plane, einen STM32F103 zu benutzen. Ist der nicht mittlerweile ein wenig altbacken? Für ein bestehendes Design kein Problem, aber wenn ich was neues entwickle würde ich auch eine aktuellere Linie nehmen. Beim STM32F103 hat z.B. das Hardware-I2C mehrere ernste Errata und ist daher nicht wirklich zuverlässig nutzbar. Wenn ich schnelles SPI mit DMA machen möchte, sind neuere STM32 mit DMAMUX flexibler. Und neuere STM32, z.B. die von msx genannten STM32H7, sind beim SPI auch flexibler und unterstützen SPI-Frames bis 32 Bit. Mi N. schrieb: > Ebenfalls habe ich auch noch eine Leiterplatte mit AS6501 und RP2040 > (PicoPi-Board). Hier sind CAP1 und CAP2 separat erreichbar, wobei die > Programmierung einen Segger J-Link erfordert oder per Arduino-IDE > erledigt werden muß. Das Raspberry Pi Pico Board hat doch sowohl ein USB-Port über den man mit dem (Hardware-)Bootloader programmieren kann als auch SWD. Und das SWD funktioniert problemlos mit allen möglichen SWD-Dongles, das muss kein J-Link sein und eine Arduino-IDE ist auch nicht erforderlich.
Gerd E. schrieb: > Und das > SWD funktioniert problemlos mit allen möglichen SWD-Dongles, das muss > kein J-Link sein und eine Arduino-IDE ist auch nicht erforderlich. Dafür bin ich zu blöd! Da ich einen passenden J-Link habe, war das der einfachste Weg, ohne zu stolpern. Hast Du einen Tipp, wie man den J-Link bei IAR bzw. Segger ersetzen kann? CMSIS DAP hatte ich erfolglos versucht. GDB Server = Bahnhof.
Mi N. schrieb: > Gerd E. schrieb: >> Und das >> SWD funktioniert problemlos mit allen möglichen SWD-Dongles, das muss >> kein J-Link sein und eine Arduino-IDE ist auch nicht erforderlich. > > Dafür bin ich zu blöd! Da ich einen passenden J-Link habe, war das der > einfachste Weg, ohne zu stolpern. Klar, wenn man den rumliegen und man damit Erfahrung hat spricht ja nix gegen den zu verwenden. > Hast Du einen Tipp, wie man den J-Link bei IAR bzw. Segger ersetzen > kann? > CMSIS DAP hatte ich erfolglos versucht. GDB Server = Bahnhof. Ich hab z.B. neulich nen Test-Jig für die Produktion zusammengestellt und da neben den ganzen Muxen etc. einfach einen fertigen Raspi Pico auf die Platine gepackt. Ging so am schnellsten. Da ist dann die Firmware von der Raspi Debug Probe drauf. Wird per CMSIS DAP über USB von nem Standard-Upstream OpenOCD angesteuert. Zuerst wird per Script geflasht, resettet und dann eine Sitzung mit Segger RTT aufgemacht und darüber mit dem DUT kommuniziert. Wenn das OpenOCD einmal läuft stellt der natürlich auch einen GDB-Server auf einem Port bereit, damit kannst Du dann bequem von eigentlich allen gängigen IDEs aus dich einklinken und debuggen, und das auch übers Netzwerk von nem anderen PC aus. Den GDB musst Du also nicht auf der Kommandozeile bedienen wenn Du nicht willst. Hier ist er Einstig eigentlich ganz gut erklärt: https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html und https://openocd.org/doc-release/html/index.html Aber ich glaube wir schweifen vom Thema TDC/AS6501 ab...
:
Bearbeitet durch User
Gerd E. schrieb: > Hier ist er Einstig eigentlich ganz gut erklärt: Für Linux-Anwender wohl direkt verständlich und bezüglich OpenOCD viele, viele Bäume und kein Wald. Ich sehe es mir noch einmal in Ruhe an. Für den TO (Maschinenbau) vermutlich noch eine Schwierigkeitsstufe höher. > Aber ich glaube wir schweifen vom Thema TDC/AS6501 ab... Das glaube ich nicht. Der TO muß sich schon Gedanken über Debugging machen, sonst tappt er blind im Dunkeln. In der Tat wäre er mit einem modernen STM32 besser bedient. Bezüglich der Kosten ist der AS6501 eh dominierend.
Ich bin auch grad an einem GPSDO. Da ist plus noch etwas dran, sonst wuer's ich's kaufen. Was ich mach ... Ein 10MHz OCXO mit einem Steuereingang, der Steuereingang kann etwas +-2 ppm. Wenn ich damit den den pps sample muss ich durch 10'000'000 teilen. Es geht aber anders. Wegen des Jitters, und ich moechte ein paar Stellen mehr. Ich lasse einen Zahler, mit ein paar mehr bit an diesen 10MHz laufen und latche mir mit dem 1 pps jeweils den aktuellen Wert. Wenn ich nun ueber 1000 Sekunden mittle habe ich 10'000'000'000 Zyklen gemessen. Das ergibt dann 10 dezimale Stellen. Mitteln geht ueber ein Register, nicht ueber einen Ringbuffer. https://www.ibrtses.com/embedded/exponential.html
:
Bearbeitet durch User
Pandur S. schrieb: > Ich lasse > einen Zahler, mit ein paar mehr bit an diesen 10MHz laufen und latche > mir mit dem 1 pps jeweils den aktuellen Wert. Wenn ich nun ueber 1000 > Sekunden mittle habe ich 10'000'000'000 Zyklen gemessen. Das ergibt dann > 10 dezimale Stellen. Das ist ja einfach. Das kann ja jeder, würde man vermuten ;-) Die Probleme werden aber deutlich, sobald man von der Theorie in die reale Welt kommt. Und darum drehen sich dann die ganzen Entwicklungen und Berichte, wie man sie im Netz findet. Christoph T. schrieb: > Damit sollte ich eine höhere Auflösung und Genauigkeit erreichen als mit > den meisten Methoden, die ich im Internet gesehen habe oder übersehe ich > etwas? Wenn sich der TO weiter informiert und erkannt hat, daß man sich ein anspruchsvolleres GPSDSO nicht mal eben so 'zusammenschraubt', hätte ich Verständnis dafür, daß der TO vielleicht von einer eigenen Lösung absieht. Man kann viel lernen, es ist aber auch richtig viel Arbeit!
Gerd E. schrieb: > Ich würde außerdem empfehlen ein für Timing optimiertes GPS-Modul zu > verwenden. Die können meist eine Information ausgeben wie weit der > letzte PPS-Impuls vom eigentlichen Sekundenwechsel abwich. Zumindest bei > den Timing-Modulen von U-blox wie z.B. M8T ist das so. Diesen Wert dann > zu dem per AS6501 gemessenen Signal addieren/subtrahieren. Die Differenz wird VOR dem Puls ausgegeben und nur wenn die Pulsfrequenz < 2Hz ist. Du willst ja die aktuelle UTC/GNSS-Zeit wissen. Beim nächsten Gongschlag ist es ... ;-)
Pandur S. schrieb: > Ich lasse > einen Zahler, mit ein paar mehr bit an diesen 10MHz laufen und latche > mir mit dem 1 pps jeweils den aktuellen Wert. Wenn ich nun ueber 1000 > Sekunden mittle habe ich 10'000'000'000 Zyklen gemessen. Das ergibt dann > 10 dezimale Stellen. Mitteln geht ueber ein Register, nicht ueber einen > Ringbuffer. https://www.ibrtses.com/embedded/exponential.html Ich würde euch beiden empfehlen kauft euch bei Ali für 50€ Neukundenpreis ein fertiges GPSDO. Das ist für euch die schnellste und billigste Lösung. Mit allem anderen verbrennt ihr mehr Geld. Und ob es besser wird steht auch in den Sternen. Das ist nicht bös gemeint ... Nachtrag: Hier wird über Erfahrungen/ Verbesserungen von dem Teil diskutiert: https://www.eevblog.com/forum/testgear/10mhz-gpsdo-by-bh3sap/?topicseen
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Ich würde euch beiden empfehlen kauft euch bei Ali für 50€ > Neukundenpreis ein fertiges GPSDO. Das ist für euch die schnellste und > billigste Lösung. Ralph (Berres) hatte mal ein englisches Gerät verlinkt, was nach dem BREXIT ca. 160 € gekostet hat und wohl recht gut war. Stichwort: SDR Kits https://www.sdr-kits.net/GPS-Disciplined-Reference-Oscillator-for-DG8SAQ-VNWA Risiken und Nebenwirkungen dazu kenne ich nicht.
Gerd E. schrieb: > Ist der nicht mittlerweile ein wenig altbacken? Für ein bestehendes > Design kein Problem, aber wenn ich was neues entwickle würde ich auch > eine aktuellere Linie nehmen. Mi N. schrieb: > Das glaube ich nicht. Der TO muß sich schon Gedanken über Debugging > machen, sonst tappt er blind im Dunkeln. > In der Tat wäre er mit einem modernen STM32 besser bedient. Bezüglich > der Kosten ist der AS6501 eh dominierend. Ich habe ihn nur ausgewählt, weil ich mit einem STM32F103 Nucleo‑64 angefangen habe. Zum Debuggen wollte ich einen ST‑Link und OpenOCD benutzen. Welchen STM32 würdet ihr empfehlen? https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/ Das verlinkte Projekt arbeitet im Prinzip genauso, wie ich es mir selbst überlegt habe. Allerdings wird dort kein TDC‑IC verwendet, sondern ein diskret aufgebauter. Die Impulslänge des HC4046 entspricht bei mir dem Wert „TSTOP“ des AS6501. Der Wert „TREF“ nutze ich nicht; stattdessen verwende ich einen Timer im STM32, sodass ich die SPI‑Schnittstelle nutzen kann.
ES fehlen immer noch die wichtigsten Sachen ... 1. Der OCXO (Typ, Datenblatt wenn du hast) 2. Der GPS Empfänger (Typ, Datenblatt ) Was willst du mit dem GPSDO machen ?
Christoph T. schrieb: > Der Wert „TREF“ nutze ich nicht; stattdessen verwende ich einen > Timer im STM32, sodass ich die SPI‑Schnittstelle nutzen kann. Das lass bitte sein! Der AS6501 liefert bei 10 MHz Referenz TREF/TSTOP-Ergebnisse für bis zu 1,6 s. Das reicht, um ein 1 PPS Signal auf 1 ps aufgelöst zu erhalten. > Welchen STM32 würdet ihr empfehlen? Um µC-seitig vollen Spielraum zu haben, würde ich einen STM32H7xx vorschlagen. Davon wirst Du vielleicht nur 1 % nutzen aber darunter ganz bestimmt die schnelle double-Berechnung in Hardware. Da ich - diesmal ohne Konjunktiv - den STM32H723 in Verbindung mit dem AS6501 eingesetzt hatte, kann ich Dir gerne eine Routine zum Auslesen von TREF und TSTOP geben. Wenn ich mich richtig erinnere, dauert das Auslesen der Gesamtzeit in eine uint64_t Variable rund 2 µs. An anderer Stelle ist hier gerade ein 'hype' um ein günstiges STM32H723 Board: Beitrag "Neues Blackboard mit STM32H723" Dennoch solltest Du ein eigenes Board entwicklen, da der AS6501 dies zwingend erfordert. Noch ein TQFP100 dazuzubauen, ist das kleinere Problem. An anderer Stelle hatte ich mal meinen Aufbau gezeigt, aber nie weiter dokumentiert: Beitrag "Re: 8-stelliger Frequenzzähler, reziprok, STM32F7xx"
Christoph T. schrieb: > Blockschaltbild.pdf (12,1 KB) | anzeigen Wenn ich mich richtig erinnere, kann man beim AS6501 für jeden der Eingänge per Register konfigurieren ob der LVDS oder CMOS ist. Von daher wären die CMOS-zu-LVDS-Wandler unnötig. Außerdem würde ich zumindest vorsehen auch den PPS 2 von den U-Blox Timing-Modulen verwenden zu können. Den dann einfach auf StopB vom AS6501 routen. Dann hast Du zumindest die Option den zu verwenden. Ansonsten schließe ich mich dem an was msx schon geschrieben hat.
:
Bearbeitet durch User
Angehängte Dateien:
-
AS6501_max_time.jpg
120 KB
Mi N. schrieb: > Christoph T. schrieb: >> Der Wert „TREF“ nutze ich nicht; stattdessen verwende ich einen >> Timer im STM32, sodass ich die SPI‑Schnittstelle nutzen kann. > > Das lass bitte sein! > Der AS6501 liefert bei 10 MHz Referenz TREF/TSTOP-Ergebnisse für bis zu > 1,6 s. Das reicht, um ein 1 PPS Signal auf 1 ps aufgelöst zu erhalten. > Siehe Anhang. Ich habe es auch nicht verstanden warum ?. Es sind 3 Register a 8Bit und die sollten sich auch durch SPI auslesen lassen. Kann dann nur daran liegen das das 3te nicht beschrieben wird. Für Spaß werden die das aber auch nicht ins Datenblatt schreiben ... >> Welchen STM32 würdet ihr empfehlen? > > Um µC-seitig vollen Spielraum zu haben, würde ich einen STM32H7xx > vorschlagen. Davon wirst Du vielleicht nur 1 % nutzen aber darunter ganz > bestimmt die schnelle double-Berechnung in Hardware. Ich auch > Wenn ich mich richtig erinnere, dauert das > Auslesen der Gesamtzeit in eine uint64_t Variable rund 2 µs. Wenn man sich auch hier an das Datenblatt hält ;-) und mit max. 50 Mhz SPI Takt arbeitet sind es mehr, aber < 10µs. > An anderer Stelle ist hier gerade ein 'hype' um ein günstiges STM32H723 > Board:. Das preiswerteste STM32H Board ist das STM32H750, würde auch ausreichen.
Mi N. schrieb: > Hans-Georg L. schrieb: >> Ich würde euch beiden empfehlen kauft euch bei Ali für 50€ >> Neukundenpreis ein fertiges GPSDO. Das ist für euch die schnellste und >> billigste Lösung. > > Ralph (Berres) hatte mal ein englisches Gerät verlinkt, was nach dem > BREXIT ca. 160 € gekostet hat und wohl recht gut war. Stichwort: SDR > Kits > https://www.sdr-kits.net/GPS-Disciplined-Reference-Oscillator-for-DG8SAQ-VNWA > Risiken und Nebenwirkungen dazu kenne ich nicht. Mein GPS ist ein UCCM von Samsung, hat mal 32€ gekostet. Wenn du ein UCCM findest, schlag zu ;-)
Mi N. schrieb: > Um µC-seitig vollen Spielraum zu haben, würde ich einen STM32H7xx > vorschlagen. Davon wirst Du vielleicht nur 1 % nutzen aber darunter ganz > bestimmt die schnelle double-Berechnung in Hardware. > Da ich - diesmal ohne Konjunktiv - den STM32H723 Ne der ist zu langsam. Ich würde mindestens nen Intel Core Ultra besser nen Xeon 6 verbauen, da hat man auf jeden Fall noch genügend Reserven um auch mal ne LED ansteuern zu können. Willst du die Leute eigentlich verarschen? Was willst du mit double? Welchen Vorteil soll das hier gegenüber Festkommaarithmetik bringen? Für die Aufgabe hier reicht nen 8 Bitter aus und der langweilt sich noch.
Gerd E. schrieb: > Christoph T. schrieb: >> Blockschaltbild.pdf (12,1 KB) | anzeigen > > Wenn ich mich richtig erinnere, kann man beim AS6501 für jeden der > Eingänge per Register konfigurieren ob der LVDS oder CMOS ist. Von daher > wären die CMOS-zu-LVDS-Wandler unnötig. Ja kann man konfigurieren. Ein HCMOS auf LVDS davor schalten ist relativ sinnlos. Wenn man ein LVDS Receiver für die Sinus Rechteckwandlung benutzt könnte man auch einen mit LVDS Ausgang nehmen. > Außerdem würde ich zumindest vorsehen auch den PPS 2 von den U-Blox > Timing-Modulen verwenden zu können. Den dann einfach auf StopB vom > AS6501 routen. Dann hast Du zumindest die Option den zu verwenden. > Der AS6501 hat 2 Kanäle, jeweils mit FIFO und der Interrupt Ausgang geht auf 1 wenn irgendein Stop eintrifft bleibt solange auf 1 bis alle FIFOS leer sind. Routen ja, würde es aber dann über Steckbrücke abschaltbar machen.
Andreas M. schrieb: > Willst du die Leute eigentlich verarschen? Was willst du mit double? > Welchen Vorteil soll das hier gegenüber Festkommaarithmetik bringen? Für > die Aufgabe hier reicht nen 8 Bitter aus und der langweilt sich noch. Du hast die Posts bezüglich der 32 Bit SPI-Frames, SPI-Takt und Abfragezeit oben gelesen und verstanden?
:
Bearbeitet durch User
@ Christoph, Gerd, Hans-Georg Ich hänge Euch mal die Versionen für H750 (723, 730) und RP2040 an. Dann muß ich nicht soviel schreiben ;-) Die Verwendung von Timer4 beim H750 war testweise und nicht zu gebrauchen: Wackelpudding. Beim RP2040 werden 6 + 1 Bytes eines Kanals in einem Rutsch gelesen. Da zeigt sich die Entwicklungsgeschichte. Der RP2040 ist als Pico-Board günstig und schnell, der eingebaute Bootloader kann aber nerven. Die Version mit H7xx liefert die leicht besseren Ergebnisse, was (bei mir) vielleicht auch vom Layout der Platine abhängt. Zudem sind die H7xx viel flexibler sind nicht auf einen 12 MHz Referenztakt festgenagelt.
Hans-Georg L. schrieb: > ES fehlen immer noch die wichtigsten Sachen ... > 1. Der OCXO (Typ, Datenblatt wenn du hast) > 2. Der GPS Empfänger (Typ, Datenblatt ) > > Was willst du mit dem GPSDO machen ? Beim OCXO steht der genaue Typ noch nicht fest, und beim GPS‑Empfänger möchte ich einen u‑blox verwenden, der speziell für Timing‑Anwendungen ausgelegt ist. Einen konkreten Anwendungszweck habe ich für das GPSDO nicht. Ich baue es hauptsächlich aus Interesse an der Technik. Gerd E. schrieb: > Wenn ich mich richtig erinnere, kann man beim AS6501 für jeden der > Eingänge per Register konfigurieren ob der LVDS oder CMOS ist. Von daher > wären die CMOS-zu-LVDS-Wandler unnötig. In einem ähnlichen Projekt wurde vor den Eingang eines TDC7200 ein Komparator mit hoher Flankensteilheit gesetzt, um das Rauschen der Messwerte zu reduzieren. Ich habe mir gedacht, dass ich mit den CMOS‑zu‑LVDS‑Wandlern das selbe erreichen kann. Hans-Georg L. schrieb: > Siehe Anhang. Ich habe es auch nicht verstanden warum ?. Es sind 3 > Register a 8Bit und die sollten sich auch durch SPI auslesen lassen. > Kann dann nur daran liegen das das 3te nicht beschrieben wird. Für Spaß > werden die das aber auch nicht ins Datenblatt schreiben ... Das habe ich mir am Anfang auch überlegt, aber über SPI können nur maximal 20 Bit für „TREF“ ausgelesen werden. In der Tabelle (Figure 56: LSB Configuration) steht das in der letzten Zeile, und die dritte Fußnote lautet: "With SPI read-out the four upper bits are unused". Ich suche derzeit eine möglichst einfache Möglichkeit, wie ich diese Einschränkung umgehen kann. Mi N. schrieb: > Ich hänge Euch mal die Versionen für H750 (723, 730) und RP2040 an. Dann > muß ich nicht soviel schreiben ;-) Soweit ich sehen kann, liest du „TREF“ über SPI aus. Werden dabei die vollen 24 Bit genutzt oder nur 20 Bit, wie im Datenblatt beschrieben?
Christoph T. schrieb: >> Wenn ich mich richtig erinnere, kann man beim AS6501 für jeden der >> Eingänge per Register konfigurieren ob der LVDS oder CMOS ist. Von daher >> wären die CMOS-zu-LVDS-Wandler unnötig. > > In einem ähnlichen Projekt wurde vor den Eingang eines TDC7200 ein > Komparator mit hoher Flankensteilheit gesetzt, um das Rauschen der > Messwerte zu reduzieren. > Ich habe mir gedacht, dass ich mit den CMOS‑zu‑LVDS‑Wandlern das selbe > erreichen kann. War bei diesem Projekt denn evtl. der OCXO einer mit Sinusausgang? Wenn ja, dann brauchst Du natürlich einen Komparator um daraus ein Digitalsignal zu bekommen, ob nun CMOS oder LVDS. Wenn man das Gerät als Universalzähler vorsieht bei dem man den Eingang auf eine freie Buchse führt, würde ich auch ein Komparator vorsehen um mit verschiedenen Signalformen umgehen zu können. Wenn das Ganze aber auf einer Platine ist und der Oszillator ein CMOS-Ausgang hat sehe ich da kein Bedarf für zusätzliche Wandler oder Komparatoren.
Christoph T. schrieb: > Soweit ich sehen kann, liest du „TREF“ über SPI aus. Werden dabei die > vollen 24 Bit genutzt oder nur 20 Bit, wie im Datenblatt beschrieben? Nach der langen Zeit muß ich mich im Datenblatt erst einmal neu orientieren. Du meinst nicht TREF sondern TSTOP. Und davon nutze ich nur 16 Bits, wie in der RP2040 Quelldatei zu sehen ist: Zeile 221. Die Auflösung beträgt damit rund 1,6 ps (100 ns / 65536), liegt schon voll im Rauschen des AS6501 und spart eine weitere Berechnung. Figure 57 im Datenblatt V1.00 2018-05-11 müsste beim 24 Bit Mode ebenfalls "LVDS/SPI" zeigen. Mi N. schrieb: > Der AS6501 liefert bei 10 MHz Referenz TREF/TSTOP-Ergebnisse für bis zu > 1,6 s. Das reicht, um ein 1 PPS Signal auf 1 ps aufgelöst zu erhalten. Christoph T. schrieb: > In einem ähnlichen Projekt wurde vor den Eingang eines TDC7200 ein > Komparator mit hoher Flankensteilheit gesetzt, um das Rauschen der > Messwerte zu reduzieren. Das war wohl gut gemeint, aber der TDC7200 rauscht trotzdem deutlich ;-)
Gerd E. schrieb: > Du hast die Posts bezüglich der 32 Bit SPI-Frames, SPI-Takt und > Abfragezeit oben gelesen und verstanden? In welchem der obige Posts hat der TO den etwas zu seinen Anforderungen bezüglich SPI Taktes geschrieben? Und jetzt komm mir nicht mit den 10 Mhz, die stammen von dem Plan das LVDS Signal per SPI zu samplen. (Was überhaupt nicht nötigt ist) Ein AVR8 kann im übrigen problemlos 32 Bit SPI Frames, ein PIC auch, eigentlich kann das sogar jeder Mikrocontroller, man muss Ihn nur bedienen zu wissen.
Andreas M. schrieb: > In welchem der obige Posts hat der TO Der TO weiß noch garnicht, wohin seine Entwicklung laufen könnte. Vielleicht stellt er fest, daß ein 10 kHz Signal eines GPS-Empfängers wegen der höheren Datenrate viel besser handzuhaben wäre. Das Platinenlayout erfordert zunächst den meisten Aufwand, wobei wegen der verschiedenen AGND und DGND ein 4-lagiges Layout sinnvoll sein kann. Hierbei jetzt beim µC sparen zu wollen ist völlig albern! Du kannst ja gerne einen fliegenden Aufbau mit ATmega328 machen. Zeig mal ein Foto :-)
Mi N. schrieb: > Du kannst ja gerne einen fliegenden Aufbau mit ATmega328 machen. > Zeig mal ein Foto :-) Aha, und was willst du mit dem Vergleich von einem "Schrottlayout" mit ATmega und guten Layout mit STM32H7 zeigen? Dem OP zu erzählen ein F103 würde für ein bisl PLL nicht reichen ist einfach nur Käse. Auch die Verwendung von Fließkomma für die Berechnungen ist komplett sinnfrei. Fließkomma verwendet man wenn Signale mit weitem Dynamikbereich zu verarbeiten sind. Das ist hier aber gar nicht der Fall. Und bei Fließkomma ist auch einiges zu beachten sonst schießt man sich ganz schnell ins Knie wenn die Wertebereiche bei Addition/Subtraktion zu weit außeinander liegen.
Andreas M. schrieb: > Dem OP zu erzählen ein F103 würde für ein bisl PLL nicht reichen ist > einfach nur Käse. Der würde schon reichen wenn man sich Mühe gibt. Aber Du machst Dir halt mit so nem alten Ding das Leben unnötig schwer und schränkst Dich bei den möglichen Umsetzungsvarianten wie z.B. höheren Auslesegeschwindigkeiten und -Latenzen unnötig ein. Der AS6501 kostet über 20 EUR, ein OCXO noch mehr, da macht es keinen Sinn sich wegen 5 am Mikrocontroller gesparten EUR sich so selbst ein Bein zu stellen.
Andreas M. schrieb: > Aha, und was willst du mit dem Vergleich von einem "Schrottlayout" mit > ATmega und guten Layout mit STM32H7 zeigen? Daß Du ein Schwätzer bist, der nur dicke Backe hat.
Mi N. schrieb: > Andreas M. schrieb: >> Aha, und was willst du mit dem Vergleich von einem "Schrottlayout" mit >> ATmega und guten Layout mit STM32H7 zeigen? > > Daß Du ein Schwätzer bist, der nur dicke Backe hat. Ah, du hast also keine Argumente. Alles klar.
Gerd E. schrieb: > da macht es keinen Sinn sich wegen 5 am Mikrocontroller gesparten EUR > sich so selbst ein Bein zu stellen. Es geht nicht um den Preis. Das Problem bei diesen Dickschiffen ist, das die zwar schnell sind, aber nicht mehr wirklich deterministisch arbeiten wenn man nicht weis was man tut. Cache misses, asynchrone Buszugriffe (AXI ist ein Message basierter Bus), FPU locks, DMA Transfers etc. Das führt zu einem nicht unerheblichen Jitter bei der Ausführung und das will man bei einer Software PLL eher nicht. Umso komplexer das System umso aufwändiger sind die Maßnahmen das zu bändigen.
Andreas M. schrieb: > Es geht nicht um den Preis. Das Problem bei diesen Dickschiffen ist, das > die zwar schnell sind, aber nicht mehr wirklich deterministisch arbeiten Tja, genau deswegen das Konzept mit dem AS6501. Der hat den OCXO als Referenztakt und liefert exakte Timestamps aller Pulse an seinen A- und B-Eingängen in Bezug auf diesen Referenztakt. Jitter im Picosekundenbereich, siehe Datenblatt. In diesen Bereich kommst Du auch mit dem deterministischsten 8-Bitter und handgezählten Assembler-Taktzählungen niemals. Jetzt kommt es nur darauf an dass man diese Daten schnell genug und in voller Auflösung vom AS6501 abruft. Dazu möchte man kein Bitbang-gebastel, Assember-Taktgezähle etc., sondern eine zuverlässige und schnelle Hardware-SPI-Einheit, DMA und schnelles RAM. Ob der Mikrocontroller das jetzt ein paar Takte früher oder später abruft ist egal - solange er nur schnell genug ist.
:
Bearbeitet durch User
Gerd E. schrieb: > Wenn das Ganze aber auf einer Platine ist und der Oszillator ein > CMOS-Ausgang hat sehe ich da kein Bedarf für zusätzliche Wandler oder > Komparatoren. Der OCXO wäre auf derselben Platine. Der GPS‑Empfänger ist ein eigenständiges Modul und wäre über ein kurzes Kabel angebunden. Wäre es in diesem Fall sinnvoll, den CMOS‑zu‑LVDS‑Wandler beizubehalten, oder ist der Einfluss des Kabels vernachlässigbar? Mi N. schrieb: > Figure 57 im Datenblatt V1.00 2018-05-11 müsste beim 24 Bit Mode > ebenfalls "LVDS/SPI" zeigen. Das wurde anscheinend in der Version 3.00 des Datenblatts geändert. Ich gehe stark davon aus, dass sich das Verhalten des AS6501 nicht so verändert hat, dass er zu früheren Versionen inkompatibel wäre. Zur Sicherheit werde ich, wie in meinem Blockschaltbild vorgesehen, den OCXO und das GPS‑PPS‑Signal mit einem Timer im STM32 verbinden, sodass ich einen Ersatz habe, falls sich „TREF“ nicht mit 24 Bit auslesen lässt. Andreas M. schrieb: > Es geht nicht um den Preis. Das Problem bei diesen Dickschiffen ist, das > die zwar schnell sind, aber nicht mehr wirklich deterministisch arbeiten > wenn man nicht weis was man tut. Cache misses, asynchrone Buszugriffe > (AXI ist ein Message basierter Bus), FPU locks, DMA Transfers etc. Das > führt zu einem nicht unerheblichen Jitter bei der Ausführung und das > will man bei einer Software PLL eher nicht. Ich überlege tatsächlich, ob ich einen leistungsfähigeren Mikrocontroller wie den STM32F405RG einsetzen soll. Der Jitter sollte unproblematisch sein, da die gesamte Messung in Hardware umgesetzt ist und nur ein Messwert pro Sekunde eintrifft.
Gerd E. schrieb: > Dazu möchte man kein > Bitbang-gebastel, Assember-Taktgezähle etc., sondern eine zuverlässige > und schnelle Hardware-SPI-Einheit, DMA und schnelles RAM. > > Ob der Mikrocontroller das jetzt ein paar Takte früher oder später > abruft ist egal - solange er nur schnell genug ist. Ah, und die Werte für den DAC für die CV werden komplett jitterfrei angesteuert. Und die Berechnungen davor natürlich auch.
Christoph T. schrieb: > Der GPS‑Empfänger ist ein eigenständiges Modul und wäre über ein kurzes > Kabel angebunden. > Wäre es in diesem Fall sinnvoll, den CMOS‑zu‑LVDS‑Wandler beizubehalten, > oder ist der Einfluss des Kabels vernachlässigbar? Bei wenigen Zentimetern an Kabel ist das vernachlässigbar. Und wenn nicht, dann müsste der CMOS-zu-LVDS-Wandler auf der Platine des GPS-Empfängers sitzen und das LVDS übers Kabel laufen. Auf der Platine des AS6501 wäre es zu spät. Der CMOS-Eingang des AS6501 ist da nicht besser oder schlechter als der CMOS-Eingang eines CMOS‑zu‑LVDS‑Wandlers. > Ich überlege tatsächlich, ob ich einen leistungsfähigeren > Mikrocontroller wie den STM32F405RG einsetzen soll. Der ist zwar schneller, aber fast ähnlich alt wie der STM32F103. Es hat schon seinen Sinn warum wir statt dessen den H7 vorschlagen.
Andreas M. schrieb: > Ah, und die Werte für den DAC für die CV werden komplett jitterfrei > angesteuert. Und die Berechnungen davor natürlich auch. Und was spielt das für eine Rolle? Hast Du Dich mal mit den Eigenschaften von GPS und der Allan-Varianz auseinandergesetzt? Wenn das Ding einmal gelockt ist, machst Du Änderungen am DAC für die Control Voltage des OCXO wenn überhaupt nötig in der Größenordnung von Minuten. Da würden selbst ein paar Mikrosekunden Jitter keinerlei Rolle spielen.
:
Bearbeitet durch User
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.