Remotely Monitoring a Satellite Instrument
G & A Technical Software (GATS) is a small aerospace company located in Newport News, Virginia. Our primary area of business is the analytical support of satellite-based atmospheric remote-sensing projects. We started using Linux in 1995 for software development and data processing workstations.
NASA is funding a two-year satellite mission called TIMED (Thermosphere Ionosphere Mesosphere Energetics and Dynamics) to study the atmosphere. One of the experiments on the spacecraft is called SABER, which stands for Sounding of the Atmosphere using Broadband Emission Radiometry. SABER's mission is to make measurements of temperature, ozone, carbon dioxide, water vapor and other trace gases to learn more about the complex relation of energy transfer between the upper and lower atmosphere. GATS has been contracted by NASA to develop and operate the systems and software that process the data from the spacecraft.
A big part of the SABER experiment is calibrating and testing the instrument while it is on the ground. This task involves making measurements of known sources and analyzing the results so that data taken from orbit can be understood. Calibration of SABER is a difficult task, because measurements need to be made at conditions found in space. To accommodate this, SABER is calibrated in a large chamber that is capable of cold temperatures and near vacuum pressures. SABER and its calibration facility were built by the Space Dynamics Laboratory (SDL) in Logan, Utah. Figure 1 is a photograph of the actual calibration test happening in the testing facility at SDL.
In this article, I will describe a Linux-based system that allows remote monitoring of the SABER calibration tests. I will discuss the porting of software from a Windows NT workstation to a Linux workstation due to reliability requirements, as well as the use of several open-source products such as the GNU C++ compiler, CVS for configuration management, Xmgr for diagnostic plots, PostgreSQL database, VNC for remote terminal access and Perl. Many of the systems proven by this project can be used by other small businesses for powerful cross-country data processing while keeping total costs and development time low. The system is robust and provides real-time monitoring and analysis of the SABER instrument (located in Logan, Utah) from Newport News, Virginia. The same system will be used for post-launch data processing.
Big projects go through several iterations of requirements/design/review, and SABER was no exception. When the time came to put together a final design, the requirements for the system were well-documented. Basically, the system needed to talk via a socket to a computer (a Sun workstation dubbed GSE for ground system equipment). The GSE computer provided raw data from the SABER instrument as well as all the test equipment connected to it. We needed to unpack the data into large staging files which could be read by analysis programs. On top of this, the system needed to access a PostgreSQL database on the GSE that was being populated by the SDL test operators with information on the various tests being run, such as times and readings from the various sensors. We had to provide software flexible enough to quickly analyze data with unknown quirks. This means easy debugging and code-level diagnostic plotting capability. The system had to work 24 hours per day and provide remote access from Virginia to Utah so that our engineers could have timely access to the data for supporting the actual tests. Finally, the system we developed had to be easily reconfigurable for post-launch data processing.
We began the design by using software that GATS developed for another project. These C routines provide an interface to raw spacecraft data in the standard spacecraft format developed by the Consultative Committee for Space Data Systems (CCSDS). SDL simplified the job for us by making the raw CCSDS data available over a TCP socket, which our system already supported. We call this stage of the processing Level 0. It takes the raw binary data in packet form and unpacks it into ASCII files, sorted by data type. We chose ASCII for the initial design because disk space was not an issue (9GB total), and troubleshooting is much simpler if files are human-readable. ASCII is also a friendly format for passing between different systems. We wanted this stage of processing to write across the network as well, so NFS was a must. Note that utilizing socket calls and NFS at this stage means the physical location of the Level 0 computer is irrelevant, as long as the Internet is available.
The next stage of the processing is called Level 1, and its first job is to query the PostgreSQL database for test information. With this, the relevant data is extracted from the Level 0 files and broken out into a single file for each test. For this part of the design, Linux was a must. The Level 1 processing had to talk to an NT box and a Sun workstation. We chose Linux because Samba is easy to set up for NT file sharing, and data sharing with the Sun is automatic via NFS. The software design called for object-oriented programming (OOP) using C++, so that classes writing the Level 1 files could be reused downstream to read the data. Linux comes with GNU C++, which is extremely reliable and easy to debug. Another reason for choosing Linux was that the analysis tools for this project were developed in C++ on a Linux workstation using the powerful (and freely available) display package called Xmgr.
This design is easily modified for post-launch processing, since the data coming from the calibration setup is in precisely the same format as that coming from the spacecraft.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Reply to comment | Linux Journal
15 min 41 sec ago
- Reply to comment | Linux Journal
1 hour 5 min ago
- Not free anymore
5 hours 7 min ago
8 hours 54 min ago
- Reply to comment | Linux Journal
9 hours 2 min ago
- Understanding the Linux Kernel
11 hours 17 min ago
13 hours 47 min ago
- Kernel Problem
23 hours 50 min ago
- BASH script to log IPs on public web server
1 day 4 hours ago
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?