This chapter describes the real-time visualization sub-systems currently employed during geophysical surveying in Antarctica. Each of the three equipment operators aboard the aircraft monitors a real-time display visualizing a different aspect of the data acquisition process. Four independently running display programs request data packets from the acquisition system and extract and filter the data they wish to visualize. Three independently running QNX processes manage the routing of data packets from the acquisition computer to the display computers via an Ethernet. The RTQC visualization program, my contribution, was designed to monitor the acquisition of geophysical data in real time. Problems with packet routing and possible solutions are also discussed.
As the data acquisition system proceeds to collect instrument readings, the real-time visualization sub-systems monitor instrument action and long-term data trends(Figure 3.1). The three instrument operators watch data acquisition progress on flat-panel display monitors arranged within the instrument racks. Four display sub-systems are used on the aircraft. Each sub-system is a 233 MHz Pentium computer and LCD flat panel monitor. A certain amount of redundancy is desired in case a computer should fail. The fCAM (fore Control and Monitoring) display system and aCAM (aft Control and Monitoring) display system control data acquisition and monitor aircraft attitude and navigation. The dRAD (device-level RADar) display system visualizes the acquisition of radar data. The RTQC (Real-Time Quality Control) system monitors magnetometer, gravity, laser altimeter, pressure transducer, and GPS clock serial data streams and the current counter value from the CTM05 Counter-Timer board.
All display computers request packets from the data acquisition system by sending a 'PING' message to the spool process running on the acquisition computer. When spool receives a 'PING' message it enables packet routing. This means that the next packet received by spool will be sent as a reply to the sender of the 'PING' message. There are two additional processes running on the acquisition system that help to distribute packets to the display computers.
The processes, grouper and router, were created to allow spool to send packets to the display processes and not spend much time in a reply-blocked state. By requesting all packets from spool and buffering them until a packet request comes from router, grouper bears the weight of being reply-blocked. The buffer is needed in the event that spool acquires packets faster than router disperses them to the displays. The RTQC program reveals the strengths and weaknesses of this spool-to-grouper-to-router-to-display packet routing scheme as discussed in the next section.
A graphical display is a visual tool for evaluating quantitative information [Tufte 1983]. The display sub-system was designed to replace a system provided the United States Geological Survey and retired in 1993. The original plan included five independently executing visualization stations. fCAM and aCAM, the fore and aft Control And Monitoring stations, were designed to verify the serial and navigational data being acquired and to control the acquisition system. dRAD and eRAD, the device-level and experiment-level RADar displays, were designed as quality control image stations for radar data. dRAD was to display digitized radar samples, highlighting jitter, sweep consistency, the main pulse, and some of the surface. eRAD was designed to filter the radar data to display data trends over time with the focus being on ice thickness and internal ice layering. The final display (my RTQC display) was designed to be a quality control screen for the geophysical instrumentation, minus the radar. Currently, a simple fCAM/aCAM control screen is used to control data acquisition, the dRAD display shows radar sweeps as a low-level gray-scale pixel image, and the RTQC display is the newest addition to the onboard real-time display system.
The purposes of the RTQC display are to provide an in-flight, real-time, quality control system for the aircraft personnel and to reveal some geophysical interpretation of the collected data. The main display window is divided into a device-oriented visualization and an experiment-oriented visualization. The device-oriented portion of the display monitors the health of the in-flight geophysical instrumentation by displaying actual data values being recorded by these systems. The experiment-oriented portion of the display attempts to unfold long-term data trends and act as a quality control window for the geophysical data that has already been received by the acquisition system.
The design goal of the RTQC display is to give clear visual access to a large quantity of complex information. By combining points, lines, a coordinate system, numbers, symbols, words, shading, and color, the RTQC display is able to visualize measured quantities in a practical way. The RTQC display gathers measured and sampled instrument data and visually reveals the values. The quantities being measured include the intensity of the earth's magnetic field measured by the magnetometer, the vertical acceleration of the aircraft (i.e. gravity) measured by the inertial navigation system and by the gravity meter, atmospheric pressure outside the aircraft recorded by the pressure transducer, and aircraft height above the ice measured by the laser altimeter. Quantities being inspected are GMT time from the GPS time code generator, and the counter value from the CTM05 Counter-Timer board. Moving strip-charts plot the measured quantities verses time. Inspected values are displayed as numerical text.
Figure 3.2 shows the display as seen on a computer screen during flight operations. Along the bottom of the screen, 5 device-level strip-charts continuously display data values in a vertical pattern and keep track of time, comparatively, by scrolling at a rate controlled by a device's data collection rate. For example, the chart that is plotting magnetometer data, scrolls one pixel per plotted data value to accommodate a 10 Hz collection rate of the magnetometer sensor. The chart plotting gravity data scrolls 10 pixels per plotted data value to accommodate a 1 Hz data collection rate of the gravity meter. Because the plotted data are normalized by sample rate, it is easy for the operator to scan across the display and compare instrument values that were collected simultaneously.
Each strip-chart is labeled at the top with a data stream name, minimum and maximum value, most current value acquired, unit of measurement, and the number of units (+/-) represented by a point halfway between the center of the chart and its max/min edges. The charts are vertically partitioned to facilitate assessment of data variation. The scale shown for each instrument remains constant during acquisition. Range values are updated when new data values are greater than the maximum or less than the minimum. In a sense, the strip-chart 'shifts' to accommodate increasing or decreasing data trends. Data stream values are plotted as vertically connected points so strip-chart 'shifts' appear as horizontal data lines within the chart window.
The experiment-level section resides above the device-level section and consists of four, horizontally-scrolling strip-charts. Since the vertical acceleration of the plane is measured both by the gravity meter and the inertial navigation system, these two data streams are plotted on the same chart in contrasting colors. Each data stream is identified by a unique color that remains consistent between the device-level and the experiment-level sections of the window. Values from each device-level data stream are collected for a user-defined interval of time, filtered, and then plotted on the stream's experiment-level strip-chart. Vertical grid lines divide the chart into half-hour data collection intervals. These charts are labeled on the left with data stream names and the number of units (+/-) represented by a point halfway between the center of the chart and its max/min edges. A chart's unit of measurement, minimum value and maximum value are labeled on the right. The experiment-level charts encompass a larger scale than their corresponding device-level charts, but do not 'shift' during data acquisition. Off-scale data values do not get plotted. The reason for keeping static ranges on the experiment-level charts was to present a data trend as a continuous line across the chart. The problems with this strategy will be discussed later.
After booting up, the RTQC computer screen automatically displays and waits for the operator to press the key to initiate packet acquisition. The device-level charts immediately begin to plot data from the received packets, the CTM05 counter is displayed to ensure an increase in value, and the GMT time display allows the operator to time-stamp personal written observations recorded within a log book. At this time it is possible to change the time interval used for data filtering. During a long flight, a longer time interval will ensure that a complete transect line appears on the experiment-level strip-charts. A short flight can display more data if a shorter time interval is used. This step is not necessary since a default value of 30 seconds is provided.
When the aircraft is positioned near the first way-point of the survey, another key press commences data filtering for the experiment-level strip-charts. Since the scales on these charts remain constant and middle values are determined from the data when data filtering begins, it is wise to start data filtering when the aircraft is stable and at survey elevation. Otherwise, the data values will plot off the strip-chart. If a data range does not encompass current data values, the RTQC display program may be restarted.
A menu bar across the top of the display is accessible with mouse and 'hot' keys and permits starting and stopping the data display, setting the data collection interval for the experiment-level charts, and quitting the program. The program can be shut down and restarted at any time during data acquisition but will only display data that has been acquired since program startup.
In order to display packet data, the packet must first be disassembled. This involves knowing, ahead of time, the type and format of the data stream each instrument transmits. Many of the instruments transmit ASCII character strings that need to be parsed and the data values converted to a suitable type for display. The instruments transmitting ASCII character strings include the magnetometer sensor, the gravity sensor data buffer, the GPS time code generator, both the GPS and GLONASS receivers, and the pressure transducer.
The laser altimeter generates a byte stream of unsigned integers. The output from the laser is not Intel-ordered (i.e., little-endian ordering), so each unsigned integer value needs to be byte-swapped during the decoding process (i.e., from a big-endian to a little-endian ordering, Figure 3.3).
typedef struct {
. . .
unsigned int rng; /* range (cm), data[2-4] */
. . .
} LASHZ1; /* data structure for the Laser(LAS) data stream */
void load_LAShz1(LASHZ1 *ptr, char *buf) {
unsigned char *byte;
/* assign byte variable to point to the packet laser data */
byte = (unsigned char *)buf;
/* To determine the laser range value, shift each
byte to its proper position and store range value in Laser
data structure. */
ptr->rng = byte[4] & 0x7F;
ptr->rng |= (byte[3] & 0x7F) << 7;
ptr->rng |= (byte[2] & 0x7F) << 14;
}
Figure
3.3.Code
segment demonstrating the conversion of big-endian to little-endian ordering.
The data acquisition interface for the inertial navigation system outputs a byte stream of signed integers, with each integer value needing to be scaled (multiplied) by a known resolution factor to determine its true value. These resolution factors are 'hard-coded' with #define statements within the 'globals.h' header file (Figure 3.4).
/* Resolution factors for AVNwp2 */
#define RES_G 0.0001220703125
typedef struct {
. . .
double vacl; /* vertical acceleration, data[82-83] */
. . .
} AVNWP2; /* data structure for the avionics(AVN) data stream */
void load_AVNwp2(AVNWP2 *ptr, char *buf) {
. . .
short bytes[34]; /* array for 34 of 2 bytes each */
memset(bytes, 0, SHORT_SIZE* 34); /* initialize array */
. . .
/* copy the packet data for vertical acceleration (from the AVN data
stream) into a temporary buffer */
memcpy(&bytes[++i], buf+82, 2);
/* decode vertical acceleration, multiply by resolution factor, and store in
avionics data structure */
ptr->vacl = (double)bytes[i] * RES_G;
. . .
}
Figure
3.4.Code
segment illustrating data decoding, scaling, and storage.
Each data stream is given a symbolic name that is used to identify the packet type and the packet data structure that stores all of the values embedded within a particular data stream. The data stream names are as follows:
The first three letters indicate the instrument supplying the data for this stream. The last three letters indicate a specific instrument model or manufacturer. A complete list of all stream names and packet data structures created can be found within the globals.h file listed in Appendix A. For each data stream a load_STReam(STREAM *, char *) function parses and decodes the raw data stream and stores the measured values within the stream's corresponding data structure (STREAM * specifies a pointer to the data structure and char * specifies a pointer to the raw packet data). This function is called each time a packet is acquired by the RTQC display program. Data values can then be accessed in the code by simply supplying a pointer to a particular data structure and using the pointer->data notation (Figures 3.3, 3.4, and 35)
Figure 3.5 shows a code example for displaying text output, but the same idea is used for supplying data to a graphical display, although the graphical display code is a bit more complex.
typedef struct {
double nT; /* nano Teslas, data[1-] */
} MAGGM2; /* data structure for the magnetometer (MAG) data stream */
typedef struct {
double lat; /* updated latitude, data[14-17] */
double lon; /* updated longitude, data[18-21] */
double wsp; /* wind speed, data[28-29] */
double oat; /* outside air temp, data[92-93] */
. . .
} AVNWP2; /* data structure for the avionics(AVN) data stream */
void main() {
AVNWP2 avnwp2;
MAGGM2 maggm2;
. . .
/* Identify stream, get a pointer to its data, access data values*/
switch ID {
case MAGgm2:
load_MAGgm2(&maggm2, ptr->data);
fprintf(stderr, "\t%6.3f nT\n", maggm2.nT);
break;
case AVNwp2:
load_AVNwp2(&avnwp2, ptr->data);
fprintf(stderr, "\tupdated latitude: %f?\n", avnwp2.lat);
fprintf(stderr, "\tupdated longitude: %f?\n", avnwp2.lon);
fprintf(stderr, "\twind speed: %f knots\n", avnwp2.wsp);
fprintf(stderr, "\toutside air temp: %.2f? C\n", avnwp2.oat);
. . .
break;
}
}
Figure
3.5.Code
segment showing data access from two different data streams.
Photon is the window manager for the QNX operating system and handles all of the graphical operations for the RTQC display. The Photon micro-GUI is structured as a "graphical micro-kernel process" [QNX Software Systems 1989] with GUI functionality distributed among cooperating processes communicating via QNX's message based IPC. The micro-kernel design is fault-tolerant such that a single failing process will not bring down the entire Photon event space and processes can be added and removed dynamically. Running as a small 55K process, Photon provides a resource-constrained graphical interface, ideal for real-time systems. The RTQC visual display was developed using Photon's development toolkit and is coded in C. The toolkit provides a graphical environment for designing a real-time visual display and provides pre-made objects for displaying data. An extensive set of attributes is associated with each graphical object and these attributes specify the object's appearance and operation. Each attribute has a default value that can be changed either in code or graphically during the design phase through a control panel. The control panel maintains an object's attributes and their current values. At any time during the design phase, Photon's development environment can generate and compile the code necessary to run the developing application.
Utilizing Photon's development environment required a significant initial learning phase, but once the RTQC display was complete it functioned flawlessly with the current programs and provided real-time visualization without crashing or degrading the performance of the data acquisition system. Despite harsh working conditions during SJB surveys (i.e. high elevation, cold, confined space) the RTQC program proved easy to activate, maintain, and monitor. During 3 months (November, 1998 through January, 1999) of field work in Antarctica, the complete system was installed and remained in use during 96 survey flights over the Trans-Antarctic Mountains, the South Pole region, and a coastal region called the Ford Ranges. A number of data acquisition problems were discovered in the field. By monitoring the RTQC display, these problems were diagnosed and fixed or the flight aborted before wasting the entire four to five hour flight period collecting incomplete or inaccurate data.
One interesting problem involved the atmospheric pressure data stream. A small tube is mounted on top of SJB and connected to the pressure transducer via a long rubber hose. Depending on weather conditions, the interior of this tube would sometimes become clogged with ice and could no longer supply the pressure transducer with an accurate outside barometric pressure. When this occurred the strip-charts displaying pressure data began plotting values with a subtle but distinct pattern and the values very slowly increased even during increases in the plane's altitude. Normally, an increase in altitude results in a decrease in atmospheric pressure. Accurate pressure readings are necessary for quality assessment of the gravity measurements.
The magnetometer exhibited measurement failure whenever the pilots performed HF radio transmissions. At these times the strip-charts recorded zero value readings. Normally, magnetometer readings vary between 50,000 and 60,000 nanoTeslas. Monitoring the RTQC display screen during radio use easily proved the connection between these two events. More subtle variations in magnetometer readings were noticed when the magnetometer sensor was in motion. Sometimes, air turbulence or icing on the sensor cable, would cause 'the bird' to sway violently from side to side. This situation is potentially dangerous should the bird become a projectile. Since the magnetometer measures ten times per second and since the sensor readings are extremely sensitive to height above the earth, the pendulous movement of the sensor generated a subtle cyclical pattern on the device-level strip-chart.
When the laser altimeter could not register returns from a laser pulse, during cloud cover or when SJB was flying greater than 2000 meters above the ice, height measurements defaulted to zero. This was obvious during in-flight monitoring. A more subtle variation in laser readings occurred when the plane porpoised up and down or rolled slightly from side to side. When the aircraft was off vertical the laser measured greater distances. This discrepancy displayed as a wavy pattern on the laser strip-chart, especially when surface topography was very flat. These observations highlight the plus side of the real-time quality control display but some attention needs to be focused on the problems. RTQC problem issues are discussed in the next section.
While the RTQC display proved a benefit to the current data monitoring system aboard SJB, a number of improvements and enhancements would make the complete display system a more effective real-time visualization tool. Since Photon proved its ability to handle real-time data display, having all display screens running within the Photon window manager as an integrated system would benefit the system by making it easier to operate and modify when needed. New recording instruments mean new data streams so a scheme for modifying or adding data stream structures and parsing functions would make the system more extendable/adaptable.
Displaying the counter-timer and time code generator values is important because those instruments did fail during the field season. A more effective visual graphic for keeping track of their failures would improve user awareness of when the devices were actually generating faulty data. The CTM05 board malfunctioned when it overheated and the time code generator malfunctioned due to a faulty power supply. The equipment operator often missed the problem when data failure was intermittent or did not recognize the exact time the device started producing bad data. Faulty pressure data was easier to recognize because a history of the previous data values is supplied by the PRS strip-charts. An internal data or data pattern interpreter could highlight when the pressure tube might be clogged based a consistent data pattern since a clogged pressure tube generated a recognizable, though subtle, data pattern on the strip-chart.
A method for zooming in and out of the experiment-level strip chart displays along with using a scrollable window, would increase the visibility of trend variations in the data. Constant elevation and constant plane attitude during a survey transect are absolutely essential for accurate geophysical measurements and the resulting geophysical interpretations. The surface topography, ice thickness, and cloud cover dictated a survey elevation for a particular transect. The presence of clouds or air turbulence often necessitates an increase in survey elevation. If the scale on the strip-charts is too small, a large change causes the data to be plotted off chart. If, on the other hand, the scale is too large and very little change in elevation, topography, or ice thickness is observed, small variations in the plotted data remain hidden. The best scale for a strip chart is hard to anticipate since data variability is unpredictable. Often the weather forces unexpected deviations from the designed flight plan. A visually adjustable scale would allow the strip chart graphic to capture the essential trend variations necessary for accurate quality control evaluation during a flight.
During data acquisition many packets are not visualized. They are dropped somewhere between spool acquiring them and the RTQC process displaying them. No mechanism exists within the currently used routing programs for monitoring data packet drops. Two possible reasons could explain the missing packets. router is designed to respond to 4 'PING' requests from each running display before asking grouper for another buffer of data packets. Data packets not yet delivered to the display processes are overwritten by the newly acquired packets from grouper and not able to be visualized. Another place data packets could be dropped is in the grouper process. If grouper's buffer fills before router sends a request for more packets, the buffer is completely cleared before being refilled with new data packets from spool.
Device-level strip-chart scrolling depends on the RTQC display receiving the different packet types at rates relative to their acquisition rates. When packets are dropped the strip-charts get behind in their scrolling and data comparison at similar collection times is no longer possible. An alternative may be to scroll the charts at a constant rate, while plotting a data stream's most recently acquired value with each scroll. Instruments acquiring at faster rates will have their current value updated more frequently than those instruments transmitting less frequently. Current values that change more slowly will plot fewer changes on the strip-charts than those values that change more often. Dropped packets will result in a plot missing an update but timing will be maintained.
A running statistical account during data acquisition and packet formation would inform the equipment operators if packet formation was keeping up with data acquisition. Generating real-time statistics such as mean data collection rate, mean seconds/sample, max/min data value, and RMS, requires a complete count of all packets as they are written to disk. Dropped packets will reduce the accuracy of acquisition statistics.
A reassessment and performance analysis of the current packet routing scheme is needed to route data packets more efficiently to the display sub-systems. The current scheme uses a synchronized, linearly-running, message-passing scenario which will always allow only a limited number of packets through to the display stations irrespective of data rates or packet sizes. More efficient methods could involve simply broadcasting the packets on the Ethernet for any process to read, or writing the data packets to shared memory or message queues where any display process could access the stored information when needed.