T-DAQ-P: a portable tablet-form multi-stream data acquisition and contextual telemetry platform based on COTS modules and a custom integration layer

Der Artikel stellt T-DAQ-P vor, eine tragbare, auf COTS-Modulen basierende Datenakquisitionsplattform, die Raspberry Pi 5 und Arduino UNO R4 WiFi integriert, um in Labor- und Feldumgebungen robuste Event-Streaming-, Telemetrie- und Kommissionswerkzeuge für Detektoren in einem einzigen System zu vereinen.

Das Wesentliche

Das T-DAQ-P: Ein „Schweizer Taschenmesser" für wissenschaftliche Messungen

Stellen Sie sich vor, Sie sind ein Wissenschaftler, der in der Wildnis steht, vielleicht auf einem Berg oder in einer Höhle. Sie wollen ein Experiment durchführen, um Teilchen zu zählen oder das Wetter zu messen. Normalerweise bräuchten Sie dafür riesige Laborgeräte, viele Kabel und einen ganzen Stab von Technikern.

Das T-DAQ-P ist wie ein hochmodernes, tragbares „Mess-Labor im Rucksack". Es ist ein kleines Gerät (etwa so groß wie ein Tablet), das alles in sich vereint, was man braucht, um Daten zu sammeln, zu überwachen und zu speichern – und das alles ohne externe Hilfe.

Hier ist, wie es funktioniert, aufgeteilt in drei einfache Teile:

1. Das Gehirn und der Handwerker (Die Hardware)

Das Gerät besteht aus zwei Hauptteilen, die perfekt zusammenarbeiten:

• Der Chef (Raspberry Pi 5): Das ist der starke Computer im Inneren. Er ist wie der Koch in einer Küche. Er nimmt die fertigen Gerichte (die wissenschaftlichen Daten) entgegen, serviert sie auf einem Bildschirm (einem 7-Zoll-Display, das direkt am Gerät ist) und legt sie in den Kühlschrank (die Festplatte) zum Aufbewahren. Er sorgt auch dafür, dass das Licht an bleibt und die Lüfter laufen, damit es nicht zu heiß wird.
• Der Handwerker (Arduino UNO R4): Das ist ein kleiner, robuster Mikrocontroller. Er ist wie ein fleißiger Assistent, der sich nur um die Details kümmert. Er prüft ständig: „Ist es warm? Ist es feucht? Wo sind wir genau? Wie viel Strom haben wir noch?" Er sammelt diese kleinen Informationen (Telemetrie) und meldet sie sofort dem Chef.

Das besondere Kabel: Zwischen diesen beiden und der Außenwelt gibt es eine spezielle Steckdose (ein DB-37-Stecker). Stellen Sie sich das wie eine universelle Steckdose vor. Egal, ob Sie einen neuen Temperatursensor oder ein GPS-Modul anschließen wollen – Sie stecken es einfach dort ein. Das Gerät weiß sofort, wie es damit umgehen muss, ohne dass man das ganze Labor umbauen muss.

2. Die Sprache der Geräte (Die Software & Protokolle)

Damit der Chef und der Handwerker sich nicht missverstehen, sprechen sie eine sehr klare Sprache.

• Der „NMEA"-Code: Der Handwerker sendet seine Nachrichten nicht als wirres Geplapper, sondern als gut strukturierte Sätze, ähnlich wie ein Schiffskapitän, der per Funk meldet: „Position: 50 Grad Nord, Geschwindigkeit: 10 Knoten, Status: Alles OK." Jede Nachricht hat einen Sicherheitsstempel (eine Art Prüfsumme), damit der Chef weiß, ob die Nachricht auf dem Weg beschädigt wurde.
• Der Sicherheits-Notfallplan: Was passiert, wenn ein Sensor ausfällt oder das GPS-Signal in einer Höhle abbricht? Das System ist darauf vorbereitet. Es hat einen Notfall-Modus. Wenn ein Teil ausfällt, versucht es automatisch, es neu zu starten. Wenn das nicht klappt, meldet es dem Chef: „Sensor X ist weg, aber wir machen weiter mit dem Rest." Das verhindert, dass das ganze System abstürzt, nur weil ein kleines Teilchen fehlt.
• Der „Simulations-Modus": Bevor man in die Wildnis fährt, kann man das Gerät im Labor testen. Man schaltet einen „Simulations-Modus" ein. Dann tut das Gerät so, als würde es echte Daten von Sensoren empfangen, obwohl keine da sind. So kann man prüfen, ob der Chef (der Computer) die Daten auch wirklich versteht und richtig aufzeichnet, bevor man überhaupt losfährt.

3. Die Organisation im Chaos (Die Datenverwaltung)

In der Wildnis kommen viele Datenströme gleichzeitig an:

1. Die eigentlichen Messdaten vom Detektor.
2. Die Umweltdaten vom Handwerker (Temperatur, Druck).
3. Kommandos, um Dinge zu steuern.

Normalerweise würde das zu einem Durcheinander führen. Aber das T-DAQ-P nutzt eine intelligente Poststelle. Es gibt verschiedene „Briefkästen" (Prozesse), in die die Daten fallen. Der Chef liest diese Briefkästen ab, sortiert sie nach Zeitstempel und legt sie in ordentliche Ordner. Selbst wenn das Internet ausfällt oder ein Kabel wackelt, gehen die Daten nicht verloren, sondern warten geduldig im Briefkasten.

Warum ist das so wichtig?

Früher musste man für jedes neue Experiment ein ganz neues, teures Labor bauen. Mit dem T-DAQ-P ist es anders:

• Es ist modular: Wenn der Computer (der Chef) veraltet ist, kann man ihn gegen einen neuen, schnelleren tauschen, ohne das ganze Gerät neu zu erfinden. Der Handwerker und die Steckdosen bleiben gleich.
• Es ist robust: Es wurde für den Einsatz im Dreck, bei Regen und ohne Laborinfrastruktur gebaut.
• Es ist einfach: Man braucht keine Spezialisten vor Ort. Das Gerät zeigt auf seinem eigenen Bildschirm genau an, ob alles funktioniert.

Zusammenfassung

Das T-DAQ-P ist wie ein selbstständiger, robuster Roboter-Assistent, den man in die Hand nimmt und mit in die Natur nimmt. Er kümmert sich selbst um die Stromversorgung, überwacht seine eigene Gesundheit, sammelt Daten von verschiedenen Sensoren und sorgt dafür, dass nichts verloren geht – selbst wenn die Bedingungen nicht perfekt sind. Es ist ein Werkzeug, das Wissenschaftlern erlaubt, sich auf ihre Entdeckungen zu konzentrieren, statt sich Sorgen um die Technik machen zu müssen.

Technische Zusammenfassung

1. Problemstellung

Der Einsatz von Detektoren im Feld oder in mobilen Laborumgebungen erfordert mehr als nur die reine Erfassung von Ereignisdaten. Der stabile Betrieb hängt entscheidend von kontextueller Telemetrie (Umgebungsparameter wie Temperatur, Luftfeuchtigkeit, Position/Höhe, Stromversorgungszustand) sowie von Werkzeugen ab, die die Inbetriebnahme (Commissioning), Diagnose und reproduzierbare Protokollierung unterstützen, ohne dass zusätzliche Laborinfrastruktur vorhanden ist.

Herausforderungen bei mobilen Messkampagnen sind:

• Begrenzte Verfügbarkeit von Peripheriegeräten oder instabile Verbindungen (z. B. GNSS-Empfang).
• Notwendigkeit einer robusten Fehlerbehandlung und Wiederherstellung ohne externe Werkzeuge.
• Die Anforderung, verschiedene Datenströme (Detektor-Ereignisse, Sensor-Telemetrie, Steuerbefehle) synchron und konsistent zu erfassen und zu protokollieren.

2. Methodik und Systemarchitektur

Das vorgestellte System T-DAQ-P ist eine kompakte, tragbare Plattform, die als „Acquisition Tablet" konzipiert ist. Es trennt die Aufgaben in zwei Ebenen, die über eine benutzerdefinierte Integrationsplatine verbunden sind:

A. Hardware-Architektur

• Host-Ebene: Ein Raspberry Pi 5 dient als Rechenzentrum für die Multi-Stream-Erfassung, Visualisierung und Speicherung. Er verfügt über eine integrierte 7-Zoll-LCD-Bedienoberfläche (HMI) für den Stand-alone-Betrieb im Feld sowie HDMI-Ausgang für externe Monitore. Die Stromversorgung erfolgt über USB-C (Power Delivery).
• Slow-Control-Ebene: Ein Arduino UNO R4 WiFi übernimmt die deterministische Abfrage von Sensoren und die Erzeugung der Telemetrie. Dies entkoppelt die zeitkritische Sensorerfassung von der rechenintensiven Host-Software.
• Integrations- und Erweiterungs-Board: Eine maßgeschneiderte Leiterplatte (Custom Integration Board) verbindet die Module. Sie bietet:
  • Geschützte Stromverteilung mit separaten Sicherungen für interne und externe Lasten.
  • Logikpegel-Anpassung (3,3 V für den Pi, 5 V für Arduino/Sensoren) mittels MOSFET-Übersetzern (BSS138).
  • Einen DB-37-Stecker als standardisierte Schnittstelle für externe Instrumentierung (Zugriff auf Strom, I2C, SPI, ADC-Kanäle).
  • Thermomanagement durch integrierte Lüfter.

B. Firmware und Protokolle (Arduino)

• Zustandsmaschine: Die Firmware arbeitet in einem endlichen Zustandsmodell (STOP, RUN, SIM, INIT).
• Robustheit:
  • Automatische Entdeckung: I2C-Scanner identifizieren vorhandene Sensoren zur Laufzeit; fehlende Sensoren führen nicht zum Absturz, sondern zu einer „graceful degradation".
  • Wiederherstellung: Bei GNSS-Ausfall oder Sensorfehlern werden automatische Reset-Sequenzen oder Neustarts der Sensorkette ausgelöst.
• Telemetrie-Format: Die Daten werden als gerahmter, zeilenorientierter ASCII-Stream („NMEA-ähnlich") übertragen.
  • Startmarker (MEASURE_START), Datenzeilen mit XOR-Prüfsumme (*-Trennzeichen) und Endmarker (END_OF_MESSAGE).
  • Dies ermöglicht eine atomare Verarbeitung und Fehlererkennung auf Host-Seite.
• Simulationsmodus (SIM): Generiert syntaktisch korrekte Telemetriedaten ohne physische Sensoren, um die gesamte Pipeline (Erfassung, Parsing, GUI, Logging) vor der Feldnutzung zu validieren.

C. Host-Software (Python)

• Architektur: Multi-Prozess-Architektur mit multiprocessing. Jeder Datenstrom (Detektor, Telemetrie, Aktor) wird von einem separaten Prozess erfasst.
• Dispatcher: Ein „Serial Stream Virtualization"-Layer (basierend auf tty0tty) erlaubt es, einen physischen seriellen Port auf mehrere virtuelle Ports zu spiegeln. So können mehrere Anwendungen (z. B. Visualisierung und Logging) gleichzeitig auf denselben Datenstrom zugreifen, ohne Konflikte.
• Synchronisation: Jeder Datensatz erhält einen Host-Zeitstempel. GNSS-Daten dienen zur Konsistenzprüfung und als absolute Zeitreferenz.
• GUI: Basierend auf Tkinter mit eingebetteten Matplotlib-Diagrammen für Echtzeit-Monitoring (z. B. Myonen-Zählrate).

3. Wichtige Beiträge

1. Hybrides Design-Paradigma: Kombination von kostengünstigen, kommerziellen Standardmodulen (COTS) mit einer benutzerdefinierten Integrations-Schicht. Diese Schicht formalisiert die elektrischen Domänen, den Schutz und die Schnittstellen, wodurch COTS-Komponenten zu instrumententauglichen Systemen werden.
2. Robuste Telemetrie-Protokolle: Einführung eines gerahmten Protokolls mit Prüfsummen und expliziten Blockgrenzen, das eine zuverlässige Parsing- und Synchronisationslogik auch bei instabilen Verbindungen ermöglicht.
3. Resilienz-Mechanismen: Implementierung von Wiederherstellungsstrategien auf Firmware-Ebene (Sensor-Reset, GNSS-Reset) und Software-Ebene (Prozess-Isolierung), um den Betrieb auch bei Teilausfällen aufrechtzuerhalten.
4. Virtualisierung von Datenströmen: Lösung des Problems der gleichzeitigen Nutzung serieller Schnittstellen durch einen Dispatcher, der die Entkopplung von Erfassung und Analyse ermöglicht.
5. Reproduzierbare Inbetriebnahme: Der Simulationsmodus und die integrierten Kommandokanäle erlauben eine vollständige End-to-End-Validierung der Pipeline, bevor physische Sensoren angeschlossen sind.

4. Ergebnisse (Vorläufige)

Die Ergebnisse basieren auf laufenden Inbetriebnahmeaktivitäten und gelten als vorläufig:

• Präzision: Die relative Übereinstimmung der Temperaturkanäle liegt bei 0,7–1,1 %, die relative Luftfeuchtigkeit bei 0,9–1,6 %. Der Druckkanal zeigt die beste Kurzzeit-Reproduzierbarkeit mit 5–10 × 10⁻³ %.
• Höhenbestimmung: Die GPS-basierte Höhenmessung (median-gefiltert) zeigt eine Reproduzierbarkeit von 1–2 % und korreliert konsistent mit der barometrischen Höhenmessung.
• Energieeffizienz: Bei Betrieb mit einem 12 V / 60 Ah-Akku wurde eine autonome Laufzeit von ca. 24 Stunden erreicht (entspricht einem durchschnittlichen Stromverbrauch von ca. 2,5 A auf Batterieebene).
• Systemstabilität: Die Architektur bewies sich in der Lage, verschiedene Datenströme synchron zu protokollieren und Fehler in einzelnen Peripheriegeräten zu isolieren, ohne den gesamten Betrieb zu unterbrechen.

5. Bedeutung und Ausblick

T-DAQ-P stellt ein reproduzierbares Blaupause-Modell für mobile Instrumentierung dar. Der entscheidende Wert liegt nicht nur in der Hardware, sondern in der Systemphilosophie:

• Lebenszyklus-Management: Durch die Trennung der „stabilen" Integrations-Schicht (Schutz, Strom, Schnittstellen) von den „evolvierenden" COTS-Modulen (Rechner, Mikrocontroller) kann das System leicht aktualisiert werden, ohne die gesamte Hardware neu zu designen.
• Feldtauglichkeit: Das System adressiert spezifische Probleme des Feldeinsatzes (instabile Netze, fehlende Peripherie, Notwendigkeit schneller Diagnose) durch Software-Resilienz und Simulation.
• Wissenschaftlicher Nutzen: Es ermöglicht die Erfassung von Kontextdaten, die für die korrekte Interpretation von Detektoreventen unerlässlich sind, und stellt sicher, dass diese Daten konsistent und zeitlich synchronisiert protokolliert werden.

Das System ist bereits als integriertes, tragbares Gerät realisiert und wird derzeit im Rahmen des INFN OCRA-Projekts für kosmische Strahlungsmessungen (Cosmic Ray Cube) eingesetzt.