Skip to content
Home » Validation of the GNSS-System

Validation of the GNSS-System

Our boardcomputer, called FMS (Flight Management System), not only houses a Cortex M3, memory, inertial sensors, and pressure sensors but also a GNSS module from uBlox. More specifically, the uBlox CAM-M8Q.

For most of our previous rocket launches the specifications of this module were more than enough and it was mostly able to send back accurate location data from launch to landing. For our current project The Hound however the CoCom-Limits are reached.

 In GPS technology, the term “COCOM Limits” also refers to a limit placed on GPS tracking devices that disables tracking when the device calculates that it is moving faster than 1,000 knots (1,900 km/h; 1,200 mph) at an altitude higher than 18,000 m (59,000 ft). This was intended to prevent the use of GPS in intercontinental ballistic missile-like applications.

source Wikipedia. According to the manufacturer the GNSS module is specified to a maximum altitude of 50 km and a maximum speed of 500 m/s (1800 km/h, Ma 1.45). Exact information about what would happen if the limits are overshot are not provided by the manufacturer. A burning question for our record attempt arises: Does the module, when it falls below the upper limits upon reentry, begin to send location data again or does the module require reinitialisation?

We wanted to answer this question with the help of GNSS simulators which RUAG Space Austria was kind enough to let us use. This simulator is attached to the module instead of the GNSS antenna and simulates received satellite signals. This way variable trajectories of the vehicle, satellite constellations, atmospheric models etc were able to be simulated. For our tests we used Simulationsprogram OpenRocket in order to create different trajectories: One test case was for a flight underneath the limit and one where the limit was exceeded.

Less than 50 seconds after the cold start the module sent its (simulated) position, which coincided with the experience gained during field tests with the active GNSS antenna.

The test for a launch to 600 meter AGL ran as expected and the module sent its simulated positions during the whole flight:

For the simulated launch of The Hound with apogee > 100 km the following data was collected:

As expected, the module stopped sending its location after exceeding the maximum speed – during and after the burning period of both motors – and after exceeding the maximum altitude. After falling below the limits the module started to resend its location again. The time period of around 50 seconds between falling below the limit and its first fix is unknown, one reason could be that the filter for location calculation requires a certain time period before successful calculation compared to a coldstart of the module.

In conclusion: The used GNSS module fulfils our requirements and can resend its position data after falling below the limit again. Thus, successfully locating the rocket will not be a problem.

What the module is not able to/allowed to do however is indicate the maximum height at apogee. This was not required anyway since maximum altitude would be evaluated during post-processing using the data from the inertial sensor and last location data from the GNSS module as well as the maximum height calculated from the pressure sensors.
The flight path can thus be successfully reconstructed with a very small error margin.