A distributed, real-time data monitoring system as ground support equipment
for balloon-borne astronomy experiments
C. M. Hubert Chena , Wayne H. Baumgartner, Walter R. Cook, Andrew J. Davis and Fiona A. Harrison
California Institute of Technology, Mail Code 292-17, Pasadena, CA 91125, USAahubert@srl.caltech.edu
Context

Display clients

We developed a real-time data-monitoring
software suite for the High Energy Focusing
Telescope (HEFT). HEFT, one of the first
hard X-ray focusing telescopes (20–70 keV),
was launched on a balloon-borne platformfrom southwest USA in 2005. This software
suite was our ground-station equipment formonitoring the focal-plane instruments
during on-site calibration, pre-launch
practice drills, and an observation flightof 25 hours.

Detector maps, in sky coordinates

Network interface

Data server: Data flow

UDP multicast

Serial port buffer

RAID−1 disk array

Input port servicing

Buffer

Raw data logging
Raw data
repository

BufferInput data
decoding/processing

BufferData playback

Buffer

Processed datalogging

Data Repository Object
in memory (locked access)

Data input from file

Processed datarepository

Data requests
TCP/IP Data service• Rotated detector maps show X-ray images
as seen from sky.

Features / Design objectives

Housekeeping sensor readings

Implementation detail• Unified display of housekeeping sensor
readings (of pressure, temperature andvoltages), showing latest readings,
5-minute averages and standard
deviations.
• Near-real-time update, interval adjustable.

• Event selection in time and energy(wavelength) capable.

• Clicking on a cell displays time-series in
new window.

Detector maps, in detector coordinates• Colour and (optional) audio alarms whena value goes out of expected range.

Data requests

Science Data UDP multicast

Spawn

Housekeeping Data UDP multicast

Client request handling
Connection requests
LAN• Multi-threading provides modularity,enables incremental development.
• Task-specific servers (logging, playback)reuse the same code, running only relevant
threads.
• Events from input serial port drives
execution, minimizes risk of data loss.

• Mostly platform-independent: Java(+ 1 perl client), simple UDP datagrams.

Data server: Data structures• Task-specific servers provide dataredundancy.

Housekeeping data
Detector 1A
Detector 1B
Detector 2A• Distributed and scalable: servers + clients.
Main data repository

Time series, light curves and spectra

Data Server

Double linked list in time order

Ethernet LAN

Display Client 2
Display Client 3
Display Client 4• Multiple servers performing dedicatedtasks guarantee the integrity andredundancy of logged data, and reduce
server load.
• UDP multicasting of photon & sensor data
makes possible an unlimited number ofconcurrent display clients, without
increasing server load.
• Separation of data processing and displaymakes code development modular.

• Data server transmits data as UDP
datagrams to designated IP multicast
group address (and port) at 1 Hz;
display clients ‘tune’ into the same group.
• Platform- and languange-independent
protocols make possible separate codedevelopment for server and client, andmodular upgrade/rewrite.
Byte Content
0– 3 Datagram ID: ”HEFT” in ASCII (0x48, 0x45, 0x46, 0x54)
4
Bits 0–4: Detector ID (0x2–0x7) / Housekeeping (0x0)
Bits 5–7: Data type (photon/test pulse/vetoed/baseline)
5
Pixel column ID (0–47)/ sensor type (P/T/V)
6Pixel row ID (0–23)/ sensor ID
7–14 Time tag
15–18 Pulse height/ sensor reading

TCP/IP unicast• User-selected time series, light curves andspectra requires dedicated communicationline.
• Display client sends data requests (datatype, [xmin, xmax], [ymin, ymax], [Emin, Emax],[tmin, tmax] ) to listening port on data server.
• Data server transmits requested data as
serialization of Java objects (as all unicast
clients are currently implemented in Java).

Performance and testing

Display Client 1

Real−time
radio telemetry

Data Logger

Pixel cell / housekeeping item

Balanced tree in energy orderServer-client architecture

EIA−422 serial line

Pixel column / sensor type
Pixel row
/ sensor ID• Allows for both real-time data input andplayback of saved data.

Detector module/ housekeeping data set• Latest science and housekeeping datarequire immediate mass distribution;occasional data loss is unimportant.

• Unified interface for displaying
pixel-specific data: photons, test pulses,
leakage current, baseline voltage, etc.

• Data structures in both time and energy
order allow efficient insertion, retrival andselection.

• Near-real-time update, interval adjustable.

• Data from housekeeping sensors share thesame data structure as pixel-specific datafrom detectors, reducing code complexity.

• Event selection in time and energy(wavelength) capable.
• Resting pointer at a pixel displays pixel
coordinates and value as tooltip.
• Clicking on a pixel or dragging acrosscorners of a group of pixels displays light
curve and spectrum in new window.

• Unified display of time series, light curves
and spectra.
• Near-real-time update, interval adjustable.

Display clients• Event selection in time and energy(wavelength) capable.

• Multi-threading separates timed data
request/input, graphical rendering, anduser interface.

• Zoom in by dragging pointer from top-leftcorner of zoom window to bottom-right;
zoom out by the reverse.

• Shared, common code for TCP/IP
communication with data server for all
Java clients, while graphical front ends
vary.

Acknowledgements: This work is funded by the NASA Space Science “Supporting Research and Technology” (SR&T) programme under award number NAG5-5398.

We ran the system daily over twomonths-long flight campaigns, including
a 110 hr-long continuous calibration run(wired input directly from the focal plane)
and a 25 hr-long balloon flight (input fromradio telemetry with data dropouts).
Changes were made iteratively over thecampaigns until a final code freeze in viewof the balloon launch. The software has since
been functioning, meeting specifications.

Invitation to adopt
This system, and individual ideas of its
implementation, can be adapted for use in
future experiments requiring sophisticatedreal-time monitoring and data display.
We welcome discussions of prospects
for collaboration and code reuse.