Datenformat für Aufzeichnung vom Radiometer?

[Michael_Haardt]

Es geht bei mir endlich weiter. Ich habe die Trivialssoftware auf dem Arduino umgeschrieben und bekomme nun fast die volle Samplerate zu sehen: Zeit, sich um die Schnittstelle Gedanken zu machen. Gibt es Standards, wie die Daten von einem Radiometer aufgezeichnet werden? Letztlich muss ich sie mit den Himmelskoordinaten und evtl. dem gewählten Kanal (Dickeswitch) verknüpfen. Andererseits lernte ich, nach Möglichkeit immer Rohdaten aufzuzeichnen, um später die Möglichkeit einer anderen Aggregation zu haben.

Was zeichnet man also auf, wenn man z.B. einen Driftscan macht, und was, wenn man ein 2D Gebiet scannt? Wie scannt man schwache Objekte, wo man pro Position lange Integrationszeiten braucht, wird da nachgeführt oder mehrfach gescannt?

Für meinen bisherigen Driftscan der Sonne aggregierte ich die Rohdaten einer Sekunde im Arduino und gab sie aus. Leicht zu verarbeiten, aber 1 s ist bei einem Driftscan der Sonne schon ziemlich grob und erzeugt damit Diskretisierungsrauschen. Welche Aufzeichnungsraten sind üblich?

Michael

 

[astropeiler]

Hallo Michael,
häufig ist es so dass die Daten erst in einem instrumentenspezifische Format geschrieben werden und dann nach einem ersten Verarbeitungsschritt ein Standardformat gewandelt werden. Bei Kontinuumsmessungen machen wir das so, dass wir folgendes aufzeichnen:
Datum/Uhrzeit (UTC), ggf. auch MJD
Azimuth und Elevation
RA und Dec, gal. Länge und Breite
Je ein Messwert (Power) pro Polarisation
Wenn wir eine Kalibrierungsquelle (Rauschquelle) mitlaufen haben, dann noch zusätzlich je ein Messwert pro Polarisation mit eingeschalteter Rauschquelle
Als Standardformat nutzen wir in aller Regel FITS.
Dann ist es egal, ob man nun einen Driftscan macht oder einen aktiven Scan, zu jedem Messpunkt gehört halt eine definierte Position.

Mit welcher Rate/Integrationszeit man sinvoll aufzeichnet ist sicher abhängig von dem Instrument. Jedenfalls sollte es schnell genug sein um die örtliche Auflösung nicht zu verwaschen. Mehrere Messpunkte aufintegrieren kann man später immer noch.
Was Deine Frage bezüglich Driftscan vs. aktivem Scan angeht: Schau doch mal auf unserer Webseite die Bericht zu den Messungen mit unserem 3-m Spiegel.: https://astropeiler.de/sites/defaul...ckert_Charakterisierung_und_Beobachtungen.pdf
Da habe ich mich über die Vor- und Nachteile beider Methoden näher ausgelassen.
Gruß
Wolfgang

 

[Michael_Haardt]

Hallo Wolfgang,

zeichnet ihr denn direkt in FITS auf, d.h. gibt es eine Software, die gleichzeitig mit allen Instrumenten spricht und deren Daten zusammengeführt aufzeichnet? Wie sieht die Struktur in FITS aus? Ich kenne bisher nur Header und Tabellen eines Datentyps, aber bei Dir klingt es nach einer Tabelle von Datensätzen. Oder ist jeder Messpunkt ein HDU?

Grundsätzlich wäre mir das möglich, aber ich kann auch getrennt aufzeichnen und später anhand der Zeitstempel alles aggregieren. Generell würde ich mich gerne nach dem richten, was üblich ist, weil der Arbeitsablauf vermutlich das Ergebnis langer Erfahrung ist und ich keine habe.

Aus Neugier: Was habt ihr für ein Radiometer und wie sieht die Schnittstelle dazu aus? Wie stellt man die Integrationszeit ein und was kann man noch einstellen?

Die Beschreibung der Scans sind sehr interessant, danke! Das sagt mir also, dass man Scan und Aufzeichnung als zwei getrennte Dinge behandeln kann.

Michael

 

[astropeiler]

Hallo Michael,
ich will mal versuchen unsere Vorgehensweise grob zu schildern:
Alle unsere Telescope haben eine weitgehend einheitliche Schnittstelle über die alle relevanten Informationen abgefragt werden können und über die die Teleskope gesteuert werden können. Diese Schnittstelle ist als TCP Server ausgelegt.
Die Messprogramme, d.h. die Programme die die Backends bedienen, können somit jederzeit die aktuelle Position etc. abfragen und den Messwerten hinzufügen. Ob die Steuerung separat oder über das Messprogramm erfolgt, hängt von den jeweiligen Umständen ab. In den meisten Fällen jedoch ist es separat. Die Messungen sind in der Regel Punktmessungen (eine Stelle am Himmel mit langer Integrationszeit) oder Transit Scans.
Wir unterscheiden zwischen Kontinuumsmessungen (Gesamtintensität bei geringer bis gar keiner Zeitauflösung), Spektrale Messungen (spektral aufgelöst, geringe bis gar keine Zeitauflösung) und Pulsarmessungen (spektral aufgelöst, hohe Zeitauflösung). Dazu ist allerdings zu sagen, dass Kontinuumsmessungen bei uns nur eine recht geringe Rolle spielen. Dennoch fange ich damit mal an:
Mit Ausnahme von unserem großen 25-m Teleskop benutzen wir hier in aller Regel SDRs, d.h. wir verwenden kein klassisches Radiometer. Um eine einheitliche Schnittstelle zu verschiedenen SDRs zu haben, verwenden wir SoapySDR in Verbindung mit SoapyPower. Bei Kontinuumsmessungen stellen wir die gewüschte Frequenz und Bandbreite ein und messen die Gesamtleistung in der Bandbreite. Aufgezeichnet wird das als csv File mit den Inhalten wie oben schon einmal beschrieben. Die maximale Bandbreite wird durch das verwendete SDR bestimmt. Ein wichtiges Thema hierbei ist die Stabiltät der SDRs. Die meisten brauchen eine lange Einlaufzeit um einigermaßen stabile Ergebnisse zu liefern.
Beim 25-m Spiegel haben wir zusätzlich ein klassisches Radiometer mit einem Diodendetektor und A/D Wandlung. Der Diodendetektor ist hier einsetzbar weil wir hier einen recht hohen Gesamtpegel (um die -10dBm in 100 MHz Bandbreite) haben. Dieser Detektor ist allerdings ein "Altbestand" ohne Dokumentation, wir können also über den inneren Aufbau nicht viel sagen. Die A/D Wandlung erfoglt über ein sogenanntes "Pocket-Backend", eine Entwicklung des MPIfR. Dieses Backend hat eine TCP Schnittstelle für die Steuerung und Datenausgabe. Normalerweise verwenden wir 1 sec. Zeitauflösung, das Ding kann jedoch auch schneller wenn man es haben möchte. Das Datenformat welches wir schreiben ist dann wieder das gleiche wie schon erwähnt.
Spektrale Messungen werden an den kleinen Spiegeln ebenfalls mit SDRs gemacht. Die Vorgehensweise (SoapySDR, SoapyPower) ist grundsätzlich die gleiche, nur dass eben spekatral aufgelöst gemessen wird. Das Ergebnis wird dann als FITS file gespeichert, wobei wir PyFits für das Schreiben der Datei verwenden.
Zusätzlich haben wir ein Spektrometer bei dem die Fourier-Transformation nicht im Rechner, sondern direkt in der Maschine in einem FPGA gemacht wird. Auch hier schreiben wir FITS Files.
Pulsarmessungen sind hier vielleicht erst mal nicht so von Interesse, deshalbe nur kurz. Als Hardware verwenden wir SDRs (dann in der Regel ein Lime SDR) mit maximaler Bandbreite von 50 MHz (ein Kanal), ein FPGA basiertes Spektrometer mit 2x 100MHz Bandbreite sowie seit kurzem (noch in der Testphase) ein FPGA basiertes Spetrometer mit 16x400 MHz Bandbreite. Bei den beiden ersten Optionen schreiben wir im "filterbank" Format, bei den letzten im VDIF Format. Beides sind standardisierte Formate für Pulsaraufzeichnungen.

Noch ein Wort zum FITS Format. Letzlich ist es ein unverselles Format für die Abspeichung von 1 bis mehrdimensionale Tabellen. Die Interpretation der Daten ergibt sich jeweils aus dem Header. Direkt schreiben wir FITS Dateien nur bei spektralen Messungen. Dies ist dann letzlich eine eindimesionale Tabelle (Intensität über Frequenz). Bei den Kontinuumsmessungen wäre ein Nachverarbeitunsschritt erforderlich um zu einer FITS Datei zu kommen. Nach meinem Verständnis müssten die Messpunkte äquidistant sein, was nicht immer gewährleistet ist. Da wir kaum mit Kontinuumsdaten im zweidimensionalen Raum arbeiten, haben wir uns das bisher erspart.
Gruß
Wolfgang

 

[Michael_Haardt]

Hallo Wolfgang,

die Sache ist also vielfältig: Wenn hohe Bandbreite gefragt ist, schreibt ihr direkt die Daten in einem effizienten Standardformat für den Zweck und ich vermute die Metadaten sind da als Header mit drin oder externe Metadaten referenzieren die aufgezeichneten Streams. Bei niedriger Bandbreite schreibt ihr FITS, wenn es geht, und CSV, wenn FITS nicht hergibt, was ihr habt (äquidistante Messwerte). So oder so zeichnet ihr direkt alles auf, was zusammen gehört, und aggregiert das nicht erst nachgelagert.

Demnach fragte ich nach dem Fall, wo ihr CSV schreibt. Wenn ich äquidistante Daten erzeuge, könnte ich auch direkt FITS machen, wo dann 1D/2D Tabellen der Leistung geschrieben würden, vermutlich mit einem Header, der den Ursprung und die Schrittweite definiert. Es würde mich allerdings einschränken, das direkt zu tun, und ich könnte immer noch äquidistante CSVs in FITS konvertieren, wenn ich solche aufzeichne.

Danke, das hilft mir schon mal sehr weiter, das konzeptuell zu verstehen.

Geschieht die Datenaufzeichnung nur auf Wunsch oder gibt es im Hintergrund noch ein kontinuierliches Logging der einzelnen Daten? Ich las mal von einer Einrichtung, wo grundsätzlich alles aufgezeichnet und eine Zeit lang aufbewahrt wurde, um den Verlauf rekonstruieren zu können, falls etwas Unerwartetes außerhalb des geplanten Messbetriebs passiert.

Mein Traum wäre immer noch die Einbindung meiner Hardware in EPICS als portabler Schicht, die von Steuerung und Aufzeichnung benutzt wird, quasi statt Eures TCP Servers oder statt INDI. Die Dokumentation von EPICS ist aber nicht so amateurfreundlich und ich sah noch nie ein Beispiel einer Montierung mit Koordinaten.

Michael

 

[astropeiler]

Ja, wenn du äquidistante Daten hast dann könntest Du diese direkt als eine 2D FITS Tabelle schreiben. Ich denke es ginge auch, nicht-äquidistante Daten zu schreiben wenn man die Koordinaten eben in eine weitere Dimension einer Tabelle schreibt. Auch das sollte FITS konform möglich sein. Ob dann die Standardprogramme für die Darstellung von FITS Dateien als Bilder damit zurecht kommen, weiß ich allerdings nicht.
Generell haben wir die Metadaten immer dabei, und zwar in einem Header. Dieser entspricht dann dem jeweiligen Standard.
Eine Besonderheit gibt es noch bei der Aufzeichnung im VDIF Format. Bei dem Backend sind die Datenraten extrem hoch (bis zu 80 GBit/s). Das kann keine Platte wegschreiben, daher wird in unserem Fall auf 10 Platten gleichzeitig geschrieben (in einem round-robin Verfahren). Daher müssen nacher in der Verarbeitung die Daten aus den Dateien zusammengesammelt werden.
Generell zeichnen wir Messdaten gezielt auf. Es gibt zwar grundsätzlich die Möglichkeit, Pulsardaten in einen Ringbuffer zu schreiben und dann nur beim Auftreten von bestimmten Events aufzuzeichnen. In der Praxis hat uns das aber nichts gebracht. Einfach alles mitzuschreiben würde zum Einen gar nicht mehr auswertbar sein, zum Anderen unsere Speicherkapazität schnell überschreiten (obwohl wir immerhin ~300 TB haben....).
MIt EPICS habe ich mich nicht näher beschäftigt. Ein paar Verwandschaften zu unserem Konzept scheinen zu bestehen, z.B. die Client/Server Architektur und die Existenz eines zentralen Informationsbrokers.
Gruß
Wolfgang