BARREL Control Center Specification DocumentMOC/SOC Hardware

The MOC and SOC are connected across two rooms via the UCSC local network. In the

MOC room, there is a collection of five laptop computers running Windows XP. Each computer is intended to run up to four instances of the MOC GSE (see MOC software description, below) simultaneously, and since the maximum number of payloads active is unlikely to exceed 16, this leaves one unused computer that will serve as a backup. Four Iridium modems (NAL research model AL3A-X), one per payload, are connected to these computers via a 4-channel serial/USB converter to allow satellite communication to the payloads. Each modem is connected via an RF cable (type LMR400, less than 40’ long) to an Iridium antenna (NAL research model SAF5350-CX) bolted to a fixture on the roof of the Natural Sciences II building at UCSC (see image above, with 6 of 16 antennas installed).

MOC computers are all networked to a common storage device, the MOC’s network attached storage or MOC-NAS. The connection is made through a though an Ethernet switch which also provides a connection to the school’s network via a hardware firewall. The only connection allowed through the firewall is for the computer SOC1 (see below) to read data form the MOC-NAS. The MOC hardware (MOC-NAS, switch, firewall, laptops, and Iridium modems) are powered through a UPS sized to power them all for at least 3 hours during an outage.

The SOC is based in a server room two floors down from the roof of the Natural Sciences II building. In the SOC room, an Ethernet switch connects SOC1, SOC2, and the SOC-NAS to the school’s network. SOC1 and SOC2 are server-style tower computers running Centos linux. SOC1 is primarily used to process the data found on the MOC-NAS and store it on the SOC-NAS (see the SOC software specification below).. SOC1 also serves a special, password protected version of the web interface that allows some administrative control. The

web server responsible the the bulk of web traffic is hosted on SOC2. This separation ensures that excessive web traffic will not interfere with processing real time data.

BARREL Mission Operations Center (MOC) Ground Station Environment (GSE) Software

The Mission Operations Center (MOC) consists of several Iridium modems connected to a computer. The computer is a PC running Windows XP with the Ground Station Environment (GSE) software installed. There may be more than one MOC computer to support multiple modems, and each MOC computer can support multiple modems and run multiple instances of the GSE software simultaneously. The GSE software is written to store the data received by the modems from the payloads and write it both locally and to a network drive where it can be read by the Science Operations Center (SOC) computer.

Description of the GSE software:

The GSE software is an executable (bmoc.exe) file compiled from C++ code written in the LabWindows environment. Included in the directory with bmoc.exe is a User Interface (*.uir) file which is a binary description of the GUI environment and an initialization file (*.ini) which stores human­readable and ­writable configuration data for bmoc.exe.

Upon opening bmoc.exe the user is prompted with a dialog to select the appropriate initialization file. After doing this the dialog window in bmoc should display the comport, phone number, payload number, and archival directories. Following is a table of the most important functions of BMOC and then a description of the functional sub­panels in BMOC.

Description of Main Panel

Name Type Description

Payload Status Status window Displays GPS date, latitude, longitude, altitude, number of visible GPS satellites, and UTC offset

Instrument HKP Status window Displays X­ray count rates, magnetic field readings, and miscellaneous magnetometer data

Temperature Status window Displays Temperature readings received from payload mounted thermistors

Voltage Status window Displays voltages received from EDI voltage sensors 

Current Status window Displays current received from EDI current sensors 

Command Counters Status window Displays status counters from DPU, ARM, and TERMINATION status. 

Frames Received Status window Displays Frames received and skipped since GSE was started

Messages Status window Displays Status messages

Iridium Connection LED Green when modem is connected (DCD is high), black when modem is disconnected (DCD is low)

Call Button Initiates a Call

Reset Modem Button Reset modem to factory settings and then initialize in ground configuration.

Check Modem Button Checks modem status and queries Received Signal Strength 

FindComErr Button Prints number of bytes in input and output queue

Hangup Modem Button Hangs up a call in progress by cycling DTR line

Termination Panel Panel Button Opens Termination Panel

File IO Panel Button Opens File IO Panel

Raw Data Panel Button Opens Raw Data Panel

Test Only Panel Button Opens Test Only Panel

Handshaking Toggle Turns handshaking on or off

Autodial Toggle Turns Autodial on or off

Periodic Calls Toggle Sets periodic calling (Calls once every user defined period, collects data for a short while, then hangs up and waits until next period).

Quit Button Quits program

Functional Sub Panels:

File IO: This panel allows the user to select an .ini file, turn archiving of incoming data or byteswapping when reading from a file on or off.   Archiving is on by default.  It also allows the user to select an already created data file to read frames from.  Reading from a file is used mostly for diagnostic purposes and should never be used during an active call or, indeed, with an incidence of the BMOC software that is being used to support an active payload at all.

Raw Data: This panel displays the contents of the current frame in Hex format. It should not be needed in flight unless a problem is suspected with the payload.

Test Only: This panel is for TESTING only. The Data switch will turn the DPU data stream on or off by mimicking the behavior of a flight modem when a call comes through and sending the commands that trigger the DPU to send data. The Modem Reset button will send a command to the DPU that power cycles the flight modem.

Termination:  See below.

Normal Operation:

After the GSE is started and properly initialized, the user should press the Modem Reset button and wait until the process finishes. This ensures that the modem is properly configured for ground operation. Then the modem should be checked with Check Modem to ensure that a good signal is being received and the modem is functioning.

To initiate a call, press the Call button. The status window will display the number that was called and then count off the time since the number was dialed. After about ~30 seconds or so a connection should be established and the green Iridium Connection light on the GUI should illuminate, indicating a successful connection. If successful, data transmission should begin within 10 seconds. If data are not received or the connection was not made within 45 seconds, the data queue in the modem will be cleared. If Autodial is selected, the program will automatically repeat the Call sequence until a connection is established. Once a payload has been launched and the field team has handed control off to the MOC, the Autodial switch should be set to ON at all times unless in Periodic Calling Mode (see 

below).

Once a connection has been made and data are being received, the Data LED will illuminate when a frame is received. The various status windows will display data as they are received.   The data are refreshed at different intervals ranging from one second to 40 seconds depending on the subcommutation of that data type in the BARREL data frame. While a call is in progress and data are being received, no action should be necessary by the user and any action may have the effect of interfering with the data stream or disconnecting the call, so no actions should be taken unless necessary.  

Periodic Calling:

If it is deemed necessary to conserve power on a payload, periodic calling can be used for this purpose. Periodic calling only calls the payload for a short, user­defined interval after a much longer user­defined period has elapsed (for example, connecting for 5 minutes every hour). To turn on Periodic Calling, simply flip the Periodic Calling Switch. This may be done while a call is in progress, but it will not affect the current call. If immediate conservation is necessary, hang up the call first, then switch to periodic calling mode.

Termination:

If a termination is necessary the following steps must be undertaken. The termination panel button on the main panel should be clicked to open the Termination Panel. The user then enters the passcode in the box and clicks the Enable Termination Panel button. The Termination functions are then revealed. Click Arm to send the Arm command and Disarm to send the Disarm command. After the Arm command is send, the Arm light will illuminate once the GSE receives confirmation of arming from the payload (this could take up to 40 seconds). While the payload is armed, the Terminate command may be sent and the payload should be cut down.  Note that sending the Terminate command while the payload is not armed will have no effect. If the Terminate command is not received within a set time, the payload will automatically disarm.

After the Terminate command is successfully received the payload should separate from the balloon and begin to descend with the parachute deployed. Altitude should be monitored from the main panel until the payload has landed.

Closing the Terminate panel will not affect the status of the payload or termination sequence in any way, but if the user wishes to open it again, the passcode must again be entered.

Quitting:

To Quit, simply press the quit button and confirm. The program should not be exited during a call in progress or especially during a dial attempt unless a fault is suspected. If the user presses Call, 

Modem Reset, or Check Modem while the modem_waitOK() routine is running, the program can get stuck in an infinite loop. Should this happen, it will be necessary to kill the bmoc.exe process using taskmgr.

Control Center Specification Document SOC Software

I. Introduction

The BARREL SOC software package is used to collect, archive, and disseminate the information in the MOC’s raw data files. Local and remote users can see a live feed of the raw data files as they are written and use a number of visualization tools to analyze past data. This is done by providing three main functions: near real-time conversion of incoming binary data files into ASCII archive files; data monitoring and duty scientist notification of values that exceed maximum limits; and a web interface for viewing live and archived data in a number of different ways.

As raw binary files are written by the MOC, the SOC detects the newest data, converts them into ASCII format, and saves them in a number of different files. These files are then read by an alert generator that will update a status file indicating any values that are out of range. The alert generator is set so that if certain values are out of range for too long, a duty scientist will be notified via text message or email. The alert generator’s status file, as well as the various ASCII data files, are used by the web interface to display information about payload health, quick look and archive plots, maps, and a live feed of data values as they are being extracted.

The SOC web-interface software runs in two modes, each of which is set to govern the

operations of an entire SOC computer: in mode 1, which is always run under password protection, the user viewing the web interface has control over parameters related to yellow and red data limits and when warnings are produced. Mode 1 is used by the duty scientists only. Mode 2 is read-only with respect to these parameters, and is run on a public web interface for the use of mission monitors and the general public. II. Configuration Files

There are two types of configuration files in the SOC: a system configuration file and data limit configuration files. The limit configuration files can be viewed and edited in the Configurator which is part of the web interface. These limits are used by alerter.pl and the various data viewing tools and will be discussed in the appropriate sections.

Many of the SOC’s functions are controlled by the system configuration file, SOC.pm. This is a Perl module and must reside in one of the shared Perl library directories on the SOC machine. Important values contained in this file are: a list of payload names and reference indices; SOC mode; directory locations; alerter.pl and updater.pl behaviors (see below); and scaling information for housekeeping data. In addition to holding configuration values, this file also holds common Perl subroutines that can be exported to various programs. III. Data Files, Status Files, and Directory Structure

The SOC relies on being able to find raw data collected by the MOC, so it is very important that these binary files are stored in a specific way. When the MOC starts a call to its payload, it creates a new data file saved both locally and on a network-attached storage device (herein called the MOC-NAS). For both copies, the binary file is saved as MOUNT_POINT/payloadX/YYMMDD/YYMMDD_HHMMSS.bar, where X is the payload name, and YYMMDD and HHMMSS are the UTC date and time of all initiation. This file will grow with each frame the MOC collects until the the call is dropped and the file is closed.

As the files from the MOC-NAS are processed, the SOC will generate a number of important output files stored in the a directory named for the payload on the SOC’s network attached storage device

(SOC-NAS/payloadX/). These files fall into two categories: data files and status files. Data files are the ASCII representations of the binary frames collected by the MOC. They are in CSV format and can easily be read by most data analysis software or be viewed directly by humans. Status files are very small and are overwritten quickly as the SOC works its way through the MOC-NAS binary files. Operators may use them to see what the SOC is working on and, more importantly, the various SOC components that must be synchronized use them to stay synchronized.

There are two types of data files, day-long archives and recent data files. The day-long archives contain a concatenation of every frame translated from the raw data files found in a single date directory. The two day-long data formats are in files named .datasciYYMMDD and .datahouseYYMMDD. The latter contains the voltage, current, and temperature measurements, which appear subcommutated over each 40 data frames from the payload, one per frame. The former files, .datasciYYMMDD, contain the scientific and GPS measurements which are either every frame or subcommutated over 4 frames. The recent data files are .newdata and .newhex. A comma-separated list of the most recently translated values for each data type is stored in .newdata. Each value in this list is updated only if the translated frame is of the correct subcom. For values that do not come in in that particular frame, the previous value is saved and marked with an asterisk to indicate it is an old value. Also, as each frame is translated, a hex dump is saved in .newhex.

There are two status files that are regularly written by the SOC: .currentdate and .lastRead. The date code (YYMMDD) of the MOC-NAS directory the SOC is currently working on is saved in .currentdate. The file name and last modify time (in seconds since epoch) of the binary file being translated is saved in .lastRead and are separated by a newline character. IV. Binary File Extraction

One of the most important functions of the SOC is to continuously monitor the MOC-NAS for new binary data, process it as soon as it is found, and store it in a format that is readily available for people and the other SOC components to use. updater.pl is the program that performs this task by watching for changes in the modification date of the most recent file in the MOC-NAS data directory, and translates each new frame into ASCII format. This ASCII frame is then added to the end of the .datasci and .datahouse files and overwrites the appropriate values of the .newdata file. Each time updater.pl enters the directory for a new date or opens a new binary file, it updates .currentdate and .lastRead, respectively.

IV-A. updater.pl Startup and Initial Run

When starting updater.pl, the user need only input the start date and payload name (each payload needs a unique instance of updater.pl running). Optionally, an end date and output mode can be specified; the default values of both of these are “none”. Using these starting values, updater.pl opens the appropriate date directory on the MOC-NAS and generates a list of files. The only files in this directory should be the previously mentioned .bar files. Because of the data file naming convention, sorting the list numerically also sorts it chronologically. This chronological list is then worked through from start to finish, with updater.pl opening each file, translating it, and moving to the next. At the end of the list, updater.pl gets a list of date directories (again we assume that the only directories in MOC-NAS/payloadX/ are date directories as described above) and finds the current date’s place in the list. If there are more recent date directories, it changes directories to the next, gets a new file list, and repeats. This is continued until the end of the file list of the newest date directory. By having a user input the starting date, we can reprocess any old files easily if a change has been made to the configuration file or if new binary files copied from a remote GSE have been added to the MOC-NAS. IV-B. MOC-NAS Monitoring

When the last file of the newest date directory has been processed, we need to start watching for

new data. The program starts checking every five seconds for changes. There are three possible changes that will present new data: the last file on the list gets updated, a new file is added to the list, or a new date directory is created. This is checked by first getting the last modification time of the file listed in .lastRead and comparing it to the stored last modification time. If the file has been modified, it is reopened, and the newest frames are processed. Then a file list is taken from the current date directory to find the place of the last read file. Finally a directory list is generated to see if there are newer date directories to enter. If there are, the date is changed and the process starts over; if not, the program sleeps for another five seconds before checking for data again. IV-C. Binary File Translation

When updater.pl determines it needs to extract frames form a binary file, a few things need to happen. First the file is opened and scanned through two bytes at a time, looking for the sync word (0xEB90). Once the sync word is found, each two-byte word is added to an array until another sync word is found. The length of the array is checked against the frame length as set in SOC.pm to see if we have a complete frame. If the frame is too long, it is assumed that two frames got stuck together because of a corrupt sync word and the data are discarded. However, if the frame is too short, it is possible that the 0xEB90 we found was a data point rather than a sync word, so a second array is started and filled until another sync word is found. If the sum of these two arrays is the correct length, it is processed, but if it is still too short this is repeated until it is either the right length or too long.

Upon finding a frame that is the correct length, the hex values are dumped into .newhex. Then, the the check sum is verified (if it fails, the frame is discarded) and the frame number is extracted to determine what subcom the frame is; then each word is translated as prescribed by the frame layout. As each value is translated, it is added to two data structures, one for most recent data, and one for the archive. When writing to the “most recent” data structure, values that are not updated in a the current frame are still saved, but with an asterisk to denote that they are from a previous frame. The “archive” data structure has ascii dashes (“---”) in place of values that were not part of the current frame. These data structures then have any conversions or scaling factors applied as indicated by the frame layout or set in SOC.pm. When the data structures are complete, the “archive” structure is appended to the end of the appropriate file and the “most recent” data structure is used to overwrite .newdata.

This extraction process is repeated for each frame until the end of the file is reached. At this point, if the output is set to “full”, the number of discarded vs accepted frames is sent to stdout and the number of bytes read for this file is saved. This byte count is important as indicates how far ahead we should skip before looking for new frames if we need to reprocess this file. Once this is complete, the process as indicated in section III-B is resumed. IV-D. GPS Clock Supplementation

It is worth noting that the GPS time is a mod4 value. This is very inconvenient for most of the other SOC components that would like to use the GPS time stamping for all data types. This is overcome by replacing each missing GPS time data point with the last transmitted GPS time (in seconds) plus the number of frames that have past since the that last transmitted time (generally 1, 2, or 3 seconds unless there is a data gap). . Using this method, we effectively transform GPT time into a mod1 data type that can be used for indexing or time stamping any data point. V. Alert Generation

The alert generator, alerter.pl, is run as one instance for all active payloads as determined by SOC-NAS/datafiles/enablelist. As it cycles through each payload on the list, it first checks to make sure that it is not on the “ignored payload” list (SOC-NAS/datafiles/ignoredPayloads). If it is not on the list, the latest data (the number of frames is set in SOC.pm) are pulled from the .datahouse and .datasci files and organized into a data structure.

V-A. Yellow Limits

Yellow limits are values that will alert the mission monitor to possibly interesting activity, or to a temperature, voltage or current going out of range. To check for them, each data type is has its collected values checked, starting with the most recent, by comparing it to the appropriate limits set in the Configurator files SOC-NAS/datafiles/.genConfig, .../.ampConfig, .../.voltConfig, and .../.tempConfig. If one of the values is found to exceed a limit, it is noted in a specially formatted file, SOC-NAS/datafiles/errorlist, with a time stamp. Once a limit has been exceeded for a particular data type, no more values are checked and alerter.pl begins checking for errors in the next type. This continues until the data structure has been exhausted.

V-B Red Limits

In addition to the Yellow Limits, we have Red Limits set for Low Altitude, High Sink Rate and Payload Timeout which, if exceeded, will alert both the Mission Monitor and Duty Scientist. These are the only out-of-range parameters that need the immediate attention of the DS, considering that cutdown is the only command available to us. Payload Timeout is checked by comparing current system time to the last modified time of the current date MOC-NAS folder (as indicated by the .currentdate file for a particular payload). If the allotted time set in SOC.pm has been exceeded, it is noted in the errorlist file. Similarly to the Yellow Limits, Altitude is checked and Sink Rate is calculated from the GPS Altitude portion of the data structure. If either of these values exceed the setting in SOC.pm a note is made in the errorlist file. When the Red limits are added to errorlist, they are preceded by a “!” to separate them from yellow limits.

Each time alerter.pl cycles through a payload it checks to see if there was already a red limit set. If so a counter is incremented. If the counter reaches a point set in SOC.pm, it is reset to zero and the Linux utility sendmail is called and used to email or text message the Duty Scientist indicated in SOC.pm.

V-C Ignored Payloads

There are times when we may want to see a payload’s incoming data but not be alerted to exceeded limits. This will usually occur when a payload is on the ground being tested or after being cut down. For these situations the payload name can be added to the file SOC-NAS/datafiles/ignoredPayloads so the payload can be active and viewable on the web interface, but none of its incoming data will be checked and no unnecessary alerts sent. VI. Web Interface

The web interface provides a convenient way for anyone to easily monitor incoming data from the payload. It displays data as a payload status bar that is always at the top of the screen, a live feed of translated values, recent quick-look plots, daylong archive plots, maps of entire flight paths, and maps of payload locations at specific event times. In addition to data displays, the web interface includes a tool for setting the limits used by alerter.pl called the Configurator, has a link to the BARREL Wiki, and displays important system messages to users.

Fig. 1: SOC in mode 1 showing a Status Bar with three payloads

activated and quick-look plot. Cursors hovering over a payload

box in the Status Bar bring up a description of any alerts,

while hovering over a point on the quick-look plot colors it green

and displays it coordinate in the box above the plot.

VI-A. ConfiguratorIn order to set the limits used by alerter.pl and the quick-plot generator, there is an online

interface called the Configurator (Figure 2). Opening this interface will call either genConfig.pl, ampConfig.pl, tempConfig.pl, or voltConfig.pl depending on the particular set of limits that are to be configured. These programs will read their configuration files (genConfig, ampConfig, tempConfig, and voltConfig) stored in the SOC-NAS/datafiles/ directory. The CSV formatted text is read from the files and placed into a large HTML table with each cell being a text input element prepopulated with the appropriate configuration value.

If the Configurator is being accessed from a SOC in mode 1, as set in SOC.pm, the values can be changed and saved. Values are saved by sending the contents of the HTML table to configWriter.pl. This program simple double checks that SOC is in mode 1, and overwrites the appropriate configuration file with the incoming table information.

Fig. 2: Limiting values are set for each data type in the

configurator. In SOC mode 1 (password protected, for duty

scientists), the tables are changeable whereas in SOC mode 2

(open, for mission monitors and the public) they can only be

viewed.

VI-B. Status BarThe Status Bar, shown at top of Figure 1, displays color-coded boxes and is generated every 30

seconds by calling statsBan.pl. This provides the Mission Monitor with a quick way of seeing the UTC time and determining if any data have gone out of range. When SOC.pm is set to SOC mode 1, each payload will also have a check box used to activate the payload so its data can be viewed and alerts will be generated.

Each time statsBan.pl is called, assuming there are no input arguments, the list of enabled payloads (SOC-NAS/datafiles/enablelist) is read. A line with a “1” indicates that payload is active, while a “0” indicates inactive. SOC.pm contains a list that is used to reference line numbers to payload names which is used for the text inside. Next SOC-NAS/datafiles/errorlist is read, again with one payload per line. If there is anything on the line, the payload is flagged to have a yellow box unless an exclamation point is found, in which case the box will be red. If there is nothing on a line, it is marked to be green. Once errorlist has been read, the table is generated with green, yellow or red boxes for active payloads and grey boxes for inactive payloads.

If statsBan.pl is being run on a machine where SOC.pm is set to SOC mode 1, it will check for input arguments before doing anything. This input argument is used to activate and deactivate payloads. When the activating check box is clicked on the web interface, statsBan.pl is called with an input argument “Payload=X” where X is 1 or 0 indicating that payload is to be activated or deactivated. If an input argument is found, enablelist has the appropriate line changed then statsBan.pl runs as normal. VI-C. Live Data Viewer

One of the easiest way of monitoring incoming data is through use of the Live Data Viewer (Fig. 2)which can be accesses by clicking on the “Live Data” button. When activated, newData.pl, located in the web server’s CGI directory, will accept input in the form of a payload name. If none was sent, it starts with the first payload indicated in the SOC.pm list. Once the payload has been determined, the limits are gathered from the Configurator files and a JavaScript page is generated. The JavaScript will download the .newdata and .newhex files every four seconds. The frame stored in .newdata is split up and each value checked against the Configurator limits and is displayed in color coded boxes organized to appear similar to the MOC terminal. If any value exceeds its limit, the text field will turn yellow, with the exception of altitude, which will trigger a red field. The entire .newhex file is dumped into a large text field at the bottom of the screen so people can look at the hex format of the most recent frame. It should be noted that the hex data may not correspond to all of the translated values. This is because .newdata is only updated with the values transmitted in a frame. For example, because GPS data is mod4, at any time only one of GPS_LAT, GPS_LON, GPS_ALT, or GPS_TIME will be current. Anything that is not current will have its previous value retained, but have an * appended to it as an indication that it comes from a prior frame.

By default, the viewer is in “Play” mode, which means it will update every four seconds. However, a particular data frame can be frozen by clicking the Play/Pause button which will put the viewer into “Pause” mode. Clicking the button again will start showing the most recent frames again. Next to the Play/Pause button there is a series of radio buttons that indicate which payload is being viewed. Clicking one of these buttons will reload newData.pl and generate a new JavaScript page with the correct limits.

Note: Changing limits in the Configurator will not immediately change them in the Live Data Viewer. Because the limits are gathered only once and written into the JavaScript page, the payload must be reloaded for the new limits to take effect.

VI-D. Graphing

The SOC provides quick-look data plots and maps. Both of these are generated using a JavaScript graphing library, grapher.js (located in the web server’s root directory), which relies on the HTML5 Canvas tag. Because of this requirement, Internet Explorer (as of version 8) is not supported. Recent versions of Google Chrome, FireFox, Opera, and Safari have all been tested and shown to work well. VI-D-1 Quick-Look Plots

The most recent data can be viewed in a quick-look plot with a length of one or six hours. Clicking on the “Quick-Look” button, quickplot.pl is loaded, which generates a JavaScript page containing one chart by default. Drop-down menus are used to select payload, data type, plot length, x-axis label, and whether or not to use the Configurator limits as graph limits. Additional plots can also be stacked each with their own set controls.

When generating a plot, the information set in the controls is sent to getData.php, which reads the archive file into memory and retrieves either one or six hours worth of frames from the archive files (.datahouseYYMMDD or .datasciYYMMDD). This process assumes no data gaps and counts one frame as being equivalent to one second. If not enough lines exist in the archive files for the current date, as set by .currentdate, lines are pulled from the previous day’s archive files. If there are still not enough lines to create a plot of desired length, lines with “NODATA” as the frame number and GPS time with no data are created. Once all of the frames have been collected, the fields of the requested data type, frame number, and GPS time are all sent back to quickplot.pl via the XMLHttpRequest JavaScript API.

In order to keep plots from looking compressed, quicklook.pl scans the incoming data for gaps by looking for sequential frame numbers. Missing frames are replaced with lines with “GAP” as the frame number and GPS time with all data fields are left blank. The data are converted to a log scale and

Configurator limits are applied if set by the user. Finally, the data are organized into arrays as part of a JavaScript object and sent to grapher.js where the canvas image is generated.

In order to identify exact data point values, plots are generated with a JavaScript event listener that monitors the mouse position relative to the canvas. The mouse’s X coordinate is converted into an array index for the displayed data. The data point that is located at the array index is highlighted on the plot and has its value shown in a box above the canvas. VI-D-2 Maps

Balloon flight trajectory maps are generated by maps.pl, which is located in the web server’s CGI folder. With no input, it generates map controls and an HTML5 Canvas element with a blank map of Antarctica with latitude and longitude grid lines; this is a static image previously generated in IDL. The map controls include starting date and ending date of the flight, payload and color. The default is one payload, but any number of payloads can be added by clicking the “Add Payload” button. When all of the controls are set, clicking “Draw Map” sends the control settings as an input to maps.pl which then collects the appropriate GPS data from the archive files (.datahouseYYMMDD or .datasciYYMMDD). Using the input dates, each archive file has its GPS data pulled and formed into matching latitude/longitude pairs by checking frame numbers. Because plotting every data point would be excessive, the GPS time is used to skip 30 minutes of flight time between collected data points. Once the data are collected for each payload, a JavaScript page is generated containing an objected that is sent to grapher.js.

When grapher.js plots a map, it converts the longitude to an angle and the latitude to the radial distance from the pole to the farthest plotted latitude. The points are then plotted as on a polar coordinate system that uses the blank image of Antarctica as a background. VI-E. Other Tools

The SOC provides links to other useful tools including a wiki and an archive file viewer. The wiki is used to collect mission monitor reports and balloon/flight status reports. The wiki is hosted by a 3rd party and can be accessed by invitation or requesting an account. The archive viewer is a set of tools for working with ASCII CSV files such as the daily archive files. While the tool is hosted on the SOC for convenience, it is not part of the SOC software package and is not necessarily intended for use during the flights (although it can be).