More industries are using CubeSats for communications and data services, with many containing GPS/GNSS receivers for orbit determination and timekeeping. As commercial CubeSat use matures, onboard GNSS receiver performance must be thoroughly tested using simulation.
have come a long way in a short time. Since the first 10cm3 nanosatellite was launched in 2003, these miniaturised spacecraft have evolved beyond research and hobby projects, and are starting to provide critical data for civilian and commercial services.
CubeSats have many potential applications, from earth and space observation to asset tracking and telecommunications. Observation data from reflectometry CubeSats, for instance, are likely to be used in applications like weather forecasting, agriculture, drought monitoring and flood prediction.
Commercial CubeSats must perform as expected
As CubeSats start to provide mission-critical services, operators need to be confident their satellites will perform as expected – especially if they’re providing data and services to third parties. Operational faults or inaccurate data may impact the operator’s commercial viability, as well as that of the third party, so assuring performance is vital.
With a CubeSat project potentially costing hundreds of thousands of dollars, the more quality assurance that can be done pre-launch, the lower the risk. Nobody wants to spend years launching a CubeSat into orbit, only to discover that it’s sending back faulty data, or mysteriously losing power. Discovering and ironing out potential issues early on is key to a successful mission.
Thorough testing of position, navigation and timing capabilities is critical
One of the critical functions within the CubeSat is altitude and orbit determination and control. CubeSats in operation today typically use a commercial GPS L1 receiver to determine the satellite’s orbit. CubeSats that fly in formation may also use data from a GPS/GNSS receiver to co-ordinate their position with others in the same constellation, and to synchronise operations between them. In addition, GNSS is one of the most prevalent sources for the synchronisation of different onboard operations, and for the timestamping of earth observation data.
With CubeSat operations becoming increasingly reliant on GNSS for such functions, satellite operators will need to be sure it works as expected – both during normal operations and in more unusual scenarios.
Simulation is the only way to rigorously test PNT performance prior to launch
Testing with live sky GNSS signals is a very unreliable way to assess performance, however. Conditions in low earth orbit (LEO) are very different from those on Earth – the device would need to be moving at several km/s, experience Doppler shift in a way that mirrored relatively close proximity to the GNSS satellites, and be fully repeatable to enable representative and meaningful testing. This is not possible using live sky signals, and is therefore not a viable test and development methodology.
For many of the same reasons, simulation with a GNSS signal generator has long been the test method of choice for more established commercial, military and space applications. Using a GNSS simulator with appropriate control software, CubeSat developers can also accurately evaluate representative performance - specifically in-orbit individual satellites and satellite constellations.
CubeSat capabilities to test with GNSS simulation
Key performance criteria to test with the simulator include:
Doppler shift handling: A CubeSat operating in LEO flies as fast as 7km/s. The GNSS receiver must be able to handle the Doppler shift between the motion of the CubeSat and the motion of the GPS satellites. This is a good example of a capability that’s impossible to test pre-launch with live-sky GNSS signals, as the required velocity can’t be achieved on the ground.
Precise orbit determination (POD): POD allows the CubeSat to determine its precise position in orbit - in relation to the Earth, the Sun and any other satellites in its constellation. The accuracy of orbit determination using a GNSS receiver can range from a few meters to a few centimetres, depending on which outputs of the receiver are being used. POD is also typically achieved by taking frequent GPS or multi-GNSS measurements, which can be limited by the power and data capacity onboard the CubeSat. Simulation will allow engineers to determine the optimum data type and sampling frequency to be used for their positioning algorithm to achieve the required precision.
Antenna performance: The placement and control of the GNSS antenna (or antennas) is critical to the CubeSat’s proper functioning. Developers will need to know that the antenna is well positioned to receive GNSS signals effectively (e.g., the antenna has a sufficient ground plane), and that it won’t be affected by multipath from the satellite structure (e.g. solar panels). While this is easy to test with a simulator, thorough testing of the antenna will require the simulated signals to be broadcast over the air in a sealed chamber environment with the antenna set up in its operating configuration within the satellite.
Time synchronisation: CubeSats are made up of multiple subsystems that must operate in sync. CubeSats flying in formation must also synchronise operations across the constellation. The precise time signal from GNSS satellites, received by the LEO GNSS receiver, is typically used for time and sync, but timing may start to drift if not regularly refreshed or held over in an onboard clock.
Simulation will allow engineers to determine the optimum refresh rate in order to, for instance, accurately time manoeuvres in formation flying – as well as test the receiver’s handling of special timing events like leap second insertions (see below).
Special events: CubeSats designed to be in orbit for longer missions are likely to encounter unusual or one-off events that aren’t part of daily GNSS services. One such event is the, to bring Universal Co-ordinated Time (UTC) back into alignment with the earth’s rotation. Developers will need to know that the CubeSat’s receiver can properly handle leap second insertions: something that’s trivial to simulate, but is impossible to test with the live signal environment (other than waiting for to occur).
Onboard interference handling: The small form factor of the CubeSat means the GNSS receiver must be housed very close to other components of the satellite’s circuitry. RF noise from these other components, such as transmissions from communication systems, can leak into the GNSS frequency bands, affecting the receiver’s ability to distinguish and process the GNSS signals. In addition, the GNSS receiver may also be affected by electromagnetic interference from surrounding electronics. Testing the receiver’s ability to cope with the level of noise within the CubeSat will be critical to ensuring a successful mission.
Impact of environmental testing: CubeSats, as with all satellites, must pass vibration and thermal-vacuum testing prior to launch to ensure the satellite can withstand the launch and its operating environment. These tests subject the satellites to very harsh conditions, and it is important to ensure that the GNSS unit continues to perform its function in these representative environments. Using a simulator means the receiver performance can be tested in identical conditions each time, so any degradation can be quickly highlighted.
Find out more about CubeSat PNT testing with Spirent
Spirent has over 25 years’ experience of working with the space industry to characterise the performance of space-borne GNSS receivers in all earth orbits. If you’d like to discuss how Spirent’s simulation equipment and professional services can position your CubeSat mission for success, please do.