Testing has always been a major challenge in the development of space applications. Field testing is not a realistic, cost-effective, or safe option, and that means that testing in the lab is paramount — however, the challenge here is that testing needs to be representative of the real- world operating environment — and this is not easy to accomplish in a terrestrial laboratory.
Understanding Test Requirements
In order to create a comprehensive test environment in the lab, the first step has to be to gain an understanding of the conditions the equipment under test will experience throughout its operational lifetime. This could include launch, deployment, orbiting, and eventual deorbiting.
For the purposes of PNT equipment used on satellites in LEO orbits, this article will focus mainly on the orbiting phase. The survivability of equipment through the vibrations and forces of launch would need to be established, but, generally speaking, the PNT function is not operational at that stage so does not require performance testing.
On-orbit considerations should include, but are not be limited to...
• Air pressure
• Temperature variation
• Gravitational forces
• Doppler shift
• Atmospheric interference/delay
• Receiving antenna field of view (e.g., horizon)
To create a realistic test environment, understanding these variables with specific reference to your application is critical and there is no generalized solution. LEO orbits can be anything up to 2,000 km above the surface of Earth, and being specific about your intended orbital altitude within that range can be important in testing.
Atmospheric Delay As An Example
In a vacuum, for instance, the distance between the orbiting altitude of the LEO satellites and the GNSS satellite they derive PNT data from would make little-to-no difference. The GNSS receiver would perform its ranging calculations in the same way, regardless of delta, calculating pseudorange to output a PVT solution.
However, single-frequency terrestrial receivers have to incorporate atmospheric corrections to account for delays caused by ionospheric interference and similar effects. Commonly
used models, such as Klobuchar, perform this calculation based on the angle (or slant) of a received signal as it passes through a point measured at around 300 km altitude. Satellites orbiting above this fixed point would still experience atmospheric delay, but this could not be calculated accurately using this model.
Whether users would benefit from using a Galileo receiver that employs NeQuick-G, or uses 3D computational models, would be something that is established through testing. In order to test this you would need to...
• Define your orbiting altitude
• Understand and model the atmospheric delay that would be experienced at that altitude
• Analyze the impact on performance using your chosen mitigation strategy (or without any mitigation) against your specified requirements
• Be able to adjust these parameters according to changes between, for instance, day and night, or for changing space weather conditions
Be able to adjust these parameters according to changes between instance, day and night, or for changing space weather conditions
Modeling Orbits
Modeling an orbit for a given mission requires a deep understanding of the relative magnitude of all forces acting on the target space vehicle. For instance, atmospheric drag plays a substantial role at low altitudes, whereas for most practical purposes, it vanishes above 2000 km. Similarly, the gravitational impact caused by the uneven mass distribution of the Earth (non-sphericity, ocean and solid tides) tend to become less prominent when the distance from the Earth increases.
Traditional Keplerian orbit modeling has been, despite its relative simplicity, an enormously useful tool for a long time. However, for a realistic test environment, the range of perturbations experienced in LEO must be taken into account — gravitational pull from various celestial bodies, atmospheric drag, and the physical shape of the Earth, to name a few.
As with any complex model, this introduces the need to find the best compromise between accuracy and complexity. The potential to accumulate tens or even hundreds of kilometers of error over a relatively short orbital period means the adoption of an existing, closed-form model is not sufficient; but how do you incorporate enough representative accuracy into your testing?
As with atmospheric delay, there are data-led models that exist, and being able to incorporate these into testing helps to create a dramatically more representative development cycle.
Considering Test Equipment
For GNSS testing, there are three primary methodologies: field testing using live sky signals, simulation, and record and playback.
As mentioned previously, and unlike testing for terrestrial applications, live sky testing is not a workable solution. For similar reasons — including challenges in capturing and verifying recordings — record and playback is much less viable than simulation for LEO testing, and far more limited in application. This means that, in reality, simulation is the only available option.
The most important factor to bear in mind is that all GNSS simulation systems are not created equal. There are a number of factors to take into account when selecting test equipment for your project. To name a few...
The update rate of the simulator plays a crucial role in applications with the dynamics of LEO satellites. With speeds in excess of 7.5 km/s, this simulation update rate plays a crucial role in mapping the trajectory of the vehicle. Low update rates will directly and inherently lead to greater error in the modeling.
Available orbital models are crucial for the reasons identified above. Using established MEO models and using pseudorange ramps to alter the orbiting altitude will not create a realistic test environment.
The ability to alter atmospheric parameters enables you to define the environment according to the specifics of your orbit. Depending on the receiver and the GNSS used, the availability of existing models may also be important.
Testing A LEO Constellation With Spirent Simulation Systems
Spirent has led the GNSS testing industry since the firm’s inception in the 1980s. In recent times, the company has supported the creation of major LEO comms constellations, as well as the earliest adopters in the LEO PNT space.
Working with SpacePNT, an innovator in low-cost, high-accuracy PNT solutions for space applications, Spirent has implemented the first, LEO-specific, orbital model in a GNSS simulation environment. If you’d like to find out more about building a high-quality LEO test environment, or about how Spirent can help you to get a high performance constellation into operation, please contact us.
www.spirent.com
Author Mia Swain is the Product Line Manager at Spirent Communications
