Hi! Ich hatte (mal wieder) so eine Idee ... Es ging darum, einen Sinus abzutasten und dann den per Software auszuwerten. Harmonische, Störungen, Frequenz etc. Dazu hab ich den ADE9103 ausgewählt (wer kommt jetzt drauf welche Art von Sinus das ist?). Ganz entscheident ist, dass der Takt für den ADE9103 exakt die geforderten 16.384 MHz hat. Das wird über einen TCXO realisiert der zusätzlich per DAC fein abgestimmt wird *1). Denn in den Datenstrom werden Zeitmarker eingefügt die synchron mit der realen Zeit (Unix time) sein müssen. Aus den 16.384 MHz wird ein 1 kHz-Signal abgeleitet das ein uC bekommt der somit 1 ms genau die Zeit kennt. Zusätzlich (wenn ich schon dabei bin) braucht der uC einen 8 MHz Takt (per PLL aus den 16.384 MHz abgeleitet). Und einen Reset. Mein erster naiver Gedanke war, das per CPLD zu machen. Enttäuschend war aber, dass das so riesen Dinger sind. Naja, egal. Ich hab dann versucht das per WinCUPL hinzubekommen. Aber mit der Doku konnte ich nichts anfangen. Dumm-dreiste Idee: Ich versuch das mal per ChatGTP. Hahaha! Das war der reine Müll! Das ChatGTP hat sich einfach eine Syntax zusammengebastelt. Schlüsselwörter die nicht existieren. Nach dem Hinweis, dass das so nicht geht, einfach neuer Unsinn und dann wieder neue "innovative" Syntax. Nach 2 Stunden hab ich das dann in die Tonne getreten. Da ich mich ein *wenig* mit Verilog auskenne, dann halt so. Aber die FPGAs die ich kannte waren alle zu mächtig und zu groß. Also hab ich rumgesucht und von Renesas den SLG47910V gefunden. Nach DaBla-Studium hab ich mich entschlossen, dass das der richtige Weg ist. Also das Demo-Board bestellt (wurde letztes Jahr verschenkt) und durch den ganzen Berg durchgeknabbert. Die Seltsamkeiten von Yosys entdeckt und gelöst und ... tataaa! Heute kommen die ersten und erwünschten Signale aus dem FPGA! Einige werden die Nase rümpfen, dass das ja gar kein echter[tm] FPGA ist und nix kann. Aber für die Anwendung kann er mehr als genug. Die Resourcen-Belegung ist aktuell im Bereich von 1 .. 3%. Der Preis ist mit 2,50 € überschaubar. Unangenehm ist lediglich die Programmierung. Entweder im Demoboard das OTP programmieren, einlöten und hoffen, oder per uC den Bitstream beim Start hochladen. Ein externes Flash das in circuit programmierbar ist scheint (meines Wissens nach) nicht zu gehen. Ein Flash geht schon, aber in-circuit??? Die Simulation per GTKWave geht leider nicht mehr (ging zu Anfang), das steigt mit für mich sinnlosen Fehlermeldungen aus. Na, dann halt mit dem Oszi oder mit dem LA. Also ich bin zufrieden. Und der ForgeFPGA ist schon die Lösung für ein anderes Projekt für das ich mehrere Quadratur-Dekoder bis 50 MHz und SPI brauch (mechanisches Messsystem mit 0.5 µm Auflösung). So, ihr könnt losmeckern! 1) Hab so was ähnliches schon mal gemacht für eine RTC. Die hab ich auf 1 Sekunde Abweichung / Monat hinbekommen (das sind dann gut 7 Stellen Genauigkeit). Genauer lies ich der Chip nicht abstimmen. Das ganze wurde per NTP innerhalb weniger Stunden Laufzeit realisiert.
Nick schrieb: > Ganz entscheident ist, dass der Takt für den ADE9103 exakt die > geforderten 16.384 MHz hat. Warum will man das? Nach meiner Erfahrung ist es ein Ding der Unmöglichkeit zwei Taktquellen identisch hinzubekommen. Daher wurde ja auch die PLL erfunden, um eine Taktquelle auf eine andere zu synchronisieren. > ... die synchron mit der realen Zeit (Unix time) > sein müssen. Hast Du mal qualitativ erfasst, wie genau Deine 'reale' Zeit ist? Die billigste Methode um an soetwas wie die reale Zeit zu kommen, ist der Einsatz eines GPSDO: https://de.wikipedia.org/wiki/GPS-synchronisierter_Oszillator
Rick D. schrieb: >> Ganz entscheident ist, dass der Takt für den ADE9103 exakt die >> geforderten 16.384 MHz hat. > Warum will man das? Weil 16384 == 2^14 ist. Damit sind die samples synchron mit dem Sekundentakt. Und ich will nicht, dass das über die Zeit davondriftet. Daher wird DER Takt per NTP immer fein nachgezogen. > Nach meiner Erfahrung ist es ein Ding der Unmöglichkeit zwei Taktquellen > identisch hinzubekommen. Kommt auf as Teilerverhältnis an. Bei den 1 kHz klappt es perfekt. Die 16.384 MHz sind wohl kein Zufall. > Daher wurde ja auch die PLL erfunden, um eine > Taktquelle auf eine andere zu synchronisieren. Daher nehme ich eine PLL für die 8 MHz Prozessortakt her. Wenn der bissl daneben ist, ist es mir egal. Für die Millisekunden im uC verwende ich keinen Timer, sondern die 1 kHz. > Hast Du mal qualitativ erfasst, wie genau Deine 'reale' Zeit ist? Wie ich geschrieben hab, ja. NTP ist recht genau (je nach Strata). Ethernet ist sowieso da, warum also noch GPS (in geschlossenen Räumen, mit Antennenkabel)? Kurzzeitige Schwankungen der NTP-Zeit werden auf die Dauer gemittelt. Der TCXO wird nur langsam in die richtige Richtung gezogen. Über paar Stunden pendelt sich das dann ein. Wie gesagt, hab ich schon mal so gemacht. Entscheidend ist, dass es keine Sprünge in der Zeit gibt. > Die billigste Methode um an soetwas wie die reale Zeit zu kommen, ist > der Einsatz eines GPSDO: Noch billiger ist ein: #include "NTP.h" Stabile lokale Abweichungen kann ich hinnehmen. Ich schau mir die Paketlaufzeit an und kann so die Laufzeit vom NTP-Server zum uC abschätzen. Wenn ein ping 1 ms dauert (tut er), dann kann ich damit leben. Das ist meine Auflösung. Die Sample-Frequenz ist, so meine Erfahrung, auf 7 Stellen genau hinzubekommen. Notfalls heize ich den Oszillator, auch wenn das dann doppelt gemoppelt ist. Die Heizung mach ich aber selber, da brauchts keinen TCXO.
Nick schrieb: > Weil 16384 == 2^14 ist. Damit sind die samples synchron mit dem > Sekundentakt. Sind nicht alle ganzzahligen Samplerates synchron zum Sekundentakt? So wie z.B. 24 MHz?
Niklas G. schrieb: > Sind nicht alle ganzzahligen Samplerates synchron zum Sekundentakt? So > wie z.B. 24 MHz? Der ADC ADE9103 macht mit den 16.384 MHz 32768 (oder 16k, 8k, ..., je nach Auflösung) samples / Sekunde. Und die 16.384 MHz für den ADC sind nicht beliebig wählbar. Lt. DaBla geht das von 15.84 MHz bis 16.547 MHz. Also 500 (1000, 2000, ...) Takte pro Sample. Um synchron mit dem Sekundentakt zu bleiben (das macht die Auswertung einfacher) müssen es also zumindest Vielfache von 500 (1000, 2000, ...) sein. Aber im Prinzip hast Du Recht.
Nick schrieb: > Ich hatte (mal wieder) so eine Idee ... [...] Irgendwie ziemlicher Unsinn. Was soll der FPGA hier (egal ob nun "echt" oder nicht)? Wenn sowieso ein µC involviert ist, kann man den doch gleich aus der 16.384MHz-Quelle mitversorgen und hat schon fertig.
Ich hab die Essenz des Ganzen Blahs mal rausgezogen: Der SLG47910V ist ein kleiner schnuckeliger und günstiger FPGA der wohl auch von yosys unterstützt wird. Sieht nicht ganz uninteressant aus! edit: Solche Stories wie deine erzähle ich jetzt immer einer KI, weil es sonst niemanden interessiert^^ 😂
:
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.