STO Control Interfaces ● Gondola command and control interface ● Instrument and data acquisition interface ● Limitations of both and how they affect observing ● Schedule and Responsibilities

Commands & Control Overview 4 Computers: Command & Control Computer (CCC) “Direct link” to ground Commands high level gondola operation Actuators Control Computer (MAX3) Responsible to acquire housekeeping information Responsible to pointing control Science Control Computer (SCC) or Data Acquisition Computer (DAC) Controls the FFT spectrometer, data flow, storage, processing Instrument Control Computer (ICC) Controls Instrument hardware operations STO relies entirely on CSBF’s Support Instrument Package (SIP) for communications with ground Fort Sumner Configuration: Use Mini SIP Exclusively LOS UHF communications Simulates TDRSS & IRIDIUM channels Antarctica Configuration: LOS UHF for first ~ 24 hours and at turn around (~ 15 days later) Main channel: TDRSS: 6Kb/sec downlink, commanding every ~15 minutes Secondary channel: IRIDIUM: 255 bytes/15minutes

CDR 10/09/054 Command & Control Computer ● Runs two processes in parallel communicating via pipe ● Autonomous Control Executive (ACE): – Written in C language – Schedule balloon operations: telescope deployment, sets track state, sets telescope focus, filter settings,... – Carry out science mission objectives: autonomous scheduling of observing sequence. – Handles DAC and detector operations. – Main interface between ground operator and payload subsystems. ● Instrument Control Interface (ICI): – Written in C++ language. – Simple continuous loop process. – Interfaces the ACE process with the payload subsystems. – Handles all communications: ● Receives ground commands from SIP ● Collects & transmits housekeeping data to SIP ● Handles I/O with all instrument controllers

CDR 10/09/055 ACE ● Uses the POSIX p_threads library. To generate multiple sub-processes sharing the same resources. ● Use of SWIG (Simplified Wrapper & Interface Generator) to create a module for the scripting language PYTHON. – SWIG is a compiler that takes ANSI C declarations and turns them into a file containing the C code for binding C functions, variables, and constants to a scripting language (PYTHON). – The generated C code is converted by the C compiler into a module that can be imported from PYTHON.

CDR 10/09/056 ACE (2) ● From the PYTHON shell the operator can access all the routines written for the ACE. Examples below: ● devUnstow()Unstow the telescope ● devStow()Stow the telescope ● devTrackOn()Turn on tracking ● devTrackOff()Turn off tracking ● centerCalib()Start Sun center seeking procedure ● gotoHelio(lat,long) Point telescope at heliographic location ● camRec(#frames)Save #frames on disk and log recording ● … ● A set of the most commonly used commands can be transmitted as discrete commands via a pull-down menu (or push-button) from the GSE console  more reliable transmission of command.

Communications: Fort Sumner Configuration

Communications: Antarctica Configuration

Ground Support Use GSEOS software Developed for APL spacecraft missions: Messenger, New Horizons Used previously with FGE and SBI STO Protocol decoding done in Python. Easily extensible graphical display interface. Uplink command handler in C ++ module. Currently a basic interface with separate up and down windows. Can be extended to include history, editing, if desired. Provides “direct” access to SBI Python interface. Interface with CSBF Command & Control for Fort Sumner: RS232 connection with Fort Sumner CSBF GSE LOS UHF communications with ballooncraft Internet connection to other STO GSEs in Arizona, Maryland, … Interface with CSBF Command & Control for Antarctica: RS232 connection with Williams Field CSBF GSE for LOS UHF communication with ballooncraft Internet connection to STO GSE computer at OCC in Palestine (TX) for TDRSS & IRIDIUM communication with ballooncraft

GSE Station LOS videoGSEOS main telem. console GSEOS command window

GSEOS main telemetry console

Let's expand this block

Test Flight Block and Cabling Diagram

Control Computers ● Embedded systems are robust and simple solutions. 1-2 watt, 200 MHz ARM board: CF & USB storage, ethernet, serial, ADC, digital I/O, PC/104 bus (Linux and BSD) 3-4 watt, 500 MHz ARM board: SD & USB storage, programmable FPGA, ethernet, serial, digital IO, PC/104 bus (Linux and BSD) CF storage available in industrial-grade up to 32 GB, SDHC to 16 GB.

Two TS-ARM boards flew on the STO test flight without a hitch Cold testing in the (UNSW) lab Controls the Pre-HEAT 20cm tipper telescope and FFT spectrometer at Dome A Antarctica

STO System Software ● NetBSD – Open Source BSD UNIX – Small, simple, emphasis on portability, correctness, and clean design – Port to the TS-7200 took a weekend – Cleanly abstracted hardware interfaces, kernel debugging – Almost magical cross-building toolkit – Recognition that developer time is non-infinite – Best system software is the one you didn't know you were using

Potential dual-string control system One computer manages data system, the other acts as instrument controller. Careful design of digital bus generation on the digital I/O lines and ADCs allow the two ARM computers to swap roles on-the-fly if needed. Only serial subsystems are hard-wired to a specific computer; neither is particularly critical.

Instrument & Data Mgmt. System ● Items to control: – Receiver subsystems (mixer bias, LO, synthesizer, etc...). (RS232, DIO, I 2 C, SPI interfaces) – Flip mirror (direct DIO through SSR) – Spectrometer and Data system (ethernet) ● Interplay of these items with “gondola systems” – data system needs TCS header (timestamp, RA/DEC, etc.) – need synchronization with telescope for OTF

Control Software ● Each hardware component has a separate TCP/IP socket server associated with it. The server listens on that socket's port for ASCII text commands to perform. ● Watchdog timers allow software and hardware to be automatically reset should they become unresponsive. ● Low-level server code is written in C; client code for observing programs is written in object-based higher level languages; e.g. perl, ruby or python. ● Instrument and control interfaces can be performed through a standalone GUI or a web browser on the ground, and through GSEOS in flight (via python scripts) ● We (C. Kulesa and C. Martin) have downloaded the SBI control code/simulator from Pietro and Harry, and have dovetailed the instrument control software into the APL system. ● The OTF mapping scheme, modifications to the SBI scheduler, and integration of the STO data server are the principal changes.

simplified view of socket servers

Example of control flow implemented on the STO test flight ● Observer issues a GSEOS position switch script ● Telescope is moved into position for on-source integration (ACE+MAX3) ● Once on-source, the DAC is commanded to begin a timed integration. DAC acknowledges the command request. ● DAC notifies the ICC and spectrometer to see if everything is ready, on OK, it commands the FFT spectrometer to integrate ● After integration, FFT spectrometer uses anon-FTP service to move the level 0 data to a ramdisk on the DAC ● DAC scoops up level 0 data and splats a FITS header on it based on pointing data from MAX3 and instrument housekeeping from the ICC ● Once integration is complete, DAC spools the data to the CCC for downlink, if requested and tells ACE that it is done. An error code is reported otherwise. ● The same process is repeated for off-source integrations until the position-switched sequence is complete. ● Tony Stark accessed the downlinked data via a Samba share and wrote an interface to the Bell Labs COM software to examine the data

On-board data processing ● We are generalizing FCRAO's OTFtool and OTFmap software for use with STO, both for online and offline reductions ● This takes the level 0/1 data to level 2 ● (i.e. to baselined, regridded OTF spectral cubes)

Data Selection

Data Assessment

Regridding

Output Modules ● FITS-compliant data cubes are default – Only interfaces needed for HIPE and Miriad – Need to ensure that all header tags and keys are supplied ● GILDAS files (gdf and class) – 2001 interface is already supported, needs updating for GILDAS 2009

Limitations ● Pointing and scheduling ● Data taking cadence (< 5 Hz) ● On board data storage ● HEB mixer, IF, FFTS stability – Can we get away with the combination of load chopping and position-switched OTF? – Frequency-switching?

Pointing Limitations The sky viewed from 80 o S

Galactic Center STO Survey Region Upper Elevation Limit (Balloon Avoidance Zone)

Survey Feasibility / Optimization Not all of the STO survey area is visible at all times of the mission, due to pointing constraints. l = -20 o is visible 90% of the time l = -40 o is visible 45% of the time l = -60 o is visible 20% of the time This places a restriction on the amount of time we will be able to observe at high Galactic longitude.

On-The-Fly Mapping Strategy ● ~30 second OTF scans as per Allan variance measurements ● Normally, we would position the secondary or the telescope off- source for a reference scan. For STO, this may not be practical. Instead, we will use internal cold load(s) for immediate reference. ● Off-source reference scans and cals to be performed at regular intervals.

Optimization spreadsheet – 2 examples 1 second spectrometer dumps scan 15”/s 2 second spectrometer dumps scan 10”/s