Q: Ever wonder why it is SO difficult to launch your spaceborne GNSS receiver?
A: I often wonder if most people, both inside and outside the aerospace community, really understand all the challenges that must be overcome prior to launching a spaceborne GNSS receiver.
Q: Ever wonder why it is SO difficult to launch your spaceborne GNSS receiver?
A: I often wonder if most people, both inside and outside the aerospace community, really understand all the challenges that must be overcome prior to launching a spaceborne GNSS receiver.
My perception is frequently confirmed by the astonished looks received from financial managers and project managers when the true development costs and schedule begin to reflect reality. Incorrect assumptions about receiver costs are reinforced by the explosive growth in the commercial GPS receiver market, which has given access to GPS solutions to much of our population (without their knowledge).
Between the $150 handheld receiver, the factory-installed automotive GPS navigation system, and the E911 navigation services operating transparently in modern cell phones, it is no wonder that spaceborne receivers are considered overpriced.
Baseline cost and schedule estimates for testing any spaceborne GNSS receiver must be realistic. The number of scenarios that need to be demonstrated with hardware in the loop to cover the entire mission scenario is often underestimated.
Is the GNSS receiver expected to perform even if the spacecraft is slowly spinning or slewing to a new target attitude? Is the GNSS receiver expected to have a complete unobstructed view of the GNSS constellation at all times? Is multipath adding noise to your GNSS signal? Such questions must be considered in order to complete functional testing, often the most important aspect of receiver development.
For spacecraft applications, the adage is: “We test, we test again, and then we test some more.” This leads to the corresponding axiom for costs: “We incur cost, more costs, and then add even more costs.”
Often significant costs involved in the test program are not appreciated at the start of the development. Testing a spaceborne receiver can be accomplished in several methods, but the most effective has been the use of a GPS signal generator.
Most terrestrial receivers are not designed to accommodate the effects experienced by an on-orbit receiver’s acquisition and tracking loops in a space environment: increased range of Doppler shifts (±60 kHz at low earth orbit missions versus ±5 to 10 kHz for terrestrial receivers), quickly changing satellite visibility due to high speeds of the spacecraft being positioned, and increased dynamic range in signal power (due to the varying proximity to the GNSS satellites).
In addition to these cost drivers, today’s space missions are pushing the boundaries of multi-spacecraft formations that not only track GNSS signals but also communicate ranging information amongst other spacecraft. (For example, see the two-part Working Papers column, “GNSS in Space,” in November/December 2008 and January/February 2009 issues of this magazine.) This gives rise to an even wider range of tests that can quickly get out of control, both in complexity and cost.
As more and more of the spacecraft functions are distributed to individual satellite sensors or subsystems (e.g., GNSS receiver or reaction wheel), the need for thorough component-level testing has greatly increased. Microprocessors and field programmable gate arrays (FPGAs) enable a receiver designer to use either unfiltered or filtered navigation solutions.
This allows a GNSS receiver to provide a continuous stream of navigation data under a wide range of dynamic environments; nulling spacecraft attitude rates, slow attitude spin rates, and even in highly elliptical orbits above the constellation.
The embedded software design approach — which develops software intended to be modified only under extreme circumstances — provides many advantages for spacecraft designers. One is the opportunity to find problems earlier in the design cycle. However, this approach introduces the risks associated with not testing key requirements or operational scenarios prior to spacecraft integration.
At times, an operational scenario can be very difficult to replicate fully on the ground, making pre-launch analysis of the on-orbit scenario extremely important. One good example of such challenges is modeling the multipath environment on a spacecraft for all operational situations that may be encountered.
Another example: the thermal performance of a patch antenna mounted away from large amounts of thermal mass can play havoc with the ability to receive GNSS signals.
Assessing the radiation susceptibility of critical GNSS receiver parts is also very important and yet expensive to conduct on the ground. Testing of each operational scenario has to be clearly defined early in the receiver development process, and approaches to improve mission performance — such as using redundant receivers, for example — need to be devised and tested.
Hardware selection is both a blessing and a curse when crafting a GNSS receiver for spaceflight. The usual spaceflight issues arise: parts qualification for radiation, performance over temperature, material compatibility, and parts reliability. However, the availability and cost of these parts can prove to be a significant challenge.
Operational requirements of the mission is also a cost driver for receiver components and associated computational requirements. For example, many space missions strongly desire the navigation time-to-first-fix to be very short (on the order of seconds or minutes).
Additionally, once a navigation solution has been computed, the overall navigation solution errors need to remain at acceptable levels — even in the absence of GNSS signals.
Unavailability of GNSS signals can occur when a GPS receiver is orbiting above the GPS constellation. In the case of the Magnetospheric Multiscale Mission (MMS), for example, the orbit of this group of spacecraft takes their GPS receivers well above the GPS constellation. The solution may involve the use of an onboard Kalman filter, which can be computationally expensive, or the supplemental use of other positioning/orientation sensors and technologies.
In addition to the computational demands of the receiver’s “software” components (for example, a Kalman filter), receiver designers have several choices for implementing the signal processing components: ASIC (application specific integrated circuit), FPGA, or microprocessor. Each choice has advantages and disadvantages with the criticality of the navigation data being a driving requirement for the choice of logic devices.
Availability of spacecraft qualified parts (i.e., radiation tested) for the GNSS receiver is always challenged by the need for proper documentation of each component. Proof of an electronic part’s reliability and compatibility for the mission environment and performance requirements often create a vast amount of paperwork.
The seemingly pointless drudgery involved in this step has nonetheless proven invaluable. On numerous occasions, troubleshooting the unexpected behavior of an electronic part could only start when the engineer knows exactly which part was installed on the electronic board.
A recent example of this situation involved a star tracker–reset anomaly encountered during cold-temperature testing. The resets never occurred at room temperature and only appeared after many hours of operation when they would begin to occur intermittently.
The resets were finally traced down to a single faulty part. Using the paper trail associated with that part was critical to understanding the most likely causes of the computer resets. This unforeseen problem occurred only a few weeks prior to final delivery of the tracker for integration with the spacecraft.
The benefit of systems engineering performed early in the process will be evident when the whole spacecraft starts to operate as one complete system. This usually occurs during one of the most expensive periods of spacecraft development; integration and test, or I&T. At that point, a receiver software fix is usually the preferred solution for a performance problem, followed by the less desirable option of modifying the hardware.
Problems can range from signal blockage to the GNSS antennas and signal multipath by large solar arrays, to thermal issues with the GNSS antennas (which are usually not positioned on a good heat sink in order to maximize signal tracking coverage). Other problems include electromagnetic interference between spacecraft communications transponders and the GNSS antennas.
As any experienced I&T engineer will tell you, just the routing of all the cables from antennas to the receivers can be a challenge. Trying to get a handle on how the entire spacecraft will operate for each phase of the mission can be a daunting task when so many receiver requirements cannot be fully defined.
Another lesson learned from GNSS spaceborne usage has been to guarantee that the proper amount of telemetry is collected for on-orbit receiver anomaly resolution. Onboard data recorders are sized to maximize science data collection between ground contacts using telemetry for transmission of science data back to Earth. Housekeeping telemetry data, which includes GNSS receiver performance metrics, is often limited by the number of different variables and the frequency with which each variable can be transferred to the data recorder.
A good analogy is trying to debug 1,000 lines of computer code, while you are only allowed to see a total of 10 variables once per second! The challenge is further increased by how you use fault detection and correction. Will you want to have the fault set a flag and then reset, or latch in the failed position until manually reset? Will the time and details about the fault be stored in the data recorder?
Ultimately, the most important effort will be the challenge of replicating a problem on the ground. Without the ability to replicate the problem, one may never fully understand and thus resolve the anomaly.
Another source of frustration throughout the aerospace industry is the lack of a commercial incentive to create new spaceborne receivers, despite the availability of sufficient funds to finance their development. The quantities of purchased parts for space applications are very small compared to terrestrial customers (cell phones, computers, gaming stations, and so on).
The requirements imposed by the aerospace industry on the sensor manufacturers are often unique and therefore expensive compared to a terrestrial receiver counterpart. Consequently, the pool of spaceborne-receiver developers is small simply because the number of flight opportunities is very limited.
Lack of interest in long-term support of the spaceborne receiver is also an issue, and the user of a receiver frequently becomes the long-term maintainer of its software. This arrangement creates a lengthy set of legal negotiations because no one likes to release intellectual property without proper compensation and safeguards.
The use of GNSS receivers on satellites has allowed numerous improvements in autonomous operations and science data collection. These improvements will continue to be highly sought after because their cost savings are very real. The reality is that for spaceborne receivers, the challenges of this technology improvement need to be better understood.
