COTS-based LEO-PNT hardware simulator

Continuing our efforts in exploring the LEO-PNT (Low Earth Orbit Positioning, Navigation, and Timing) technology, this post proposes an end-to-end LEO-PNT hardware simulation setup based on cost-effective and commercially available off-the-shelf (COTS) components and open-source software libraries. Given a static position and a time span, the setup is able to simulate and track the RF navigation signal and generate pseudoranges, carrier-phases, Doppler and C/N0 observables.

The full setup of the simulator is shown in the following video, with all components plugged and in operation, which can be summarized in the following main building blocks:

1. Scenario and I&Q samples
2. Generation of the RF signal
3. Signal tracking and observables

As you may be correctly guessing by now, we are attempting to cheat COTS hardware by reusing the GPS PRN codes to build a navigation system based on CDMA (Code Division Multiple Access) but using LEO orbits instead. In doing this, we will be able to use commercial receivers that already track these PRN satellites.

Scenario and I&Q samples

In order to generate the I&Q samples, the open-source package gps-sdr-sim has been used. Given a location, a time span and a broadcast file with the navigation ephemeris (in RINEX v2.0 format), this SDR simulator generates the I&Q samples for the visible satellites (with GPS PRN codes as well as the data bits of the navigation message). At this point, several noteworthy points need to be taken into account:

1. Only GPS constellation is supported by the gps-sdr-sim software, which effectively limits the number of satellites to simulate to 32. This makes simulating mega-constellation not possible with this tool (as is). This is a problem for LEO satellites, since their orbital period is very short (ca. 90 minutes) and therefore the visbility span at a given location in Earth is about 20 minutes only. This implies that a careful orbital design needs to be carried out to ensure satellite visibility over a certain location during certain time span. In previous posts we discussed how TLE of existing constellations could be used to compute ephemeris, but in this particular case, we opted to use existing open-source tools such as poliastro to design a LEO constellation at a height of 1.300 km. In doing this, we can make sure that several satellites are visible over the target location at a given epoch.
2. The LEO orbits need to be transferred into RINEX 2 format. In previous posts we discussed a custom RINEX 4 format to support navigation message for LEO satellites. We first created the orbits and wrote their corresponding ephemeris in RINEX 4 format and then converted them to RINEX 2 format for GPS, the only format accepted by the gps-sdr-sim package.

The following plot illustrates the overpasses of the LEO satellite orbits simulated for this scenario.

Generation of the RF signal

The open-source software library generates a binary file containing the I&Q samples. These samples can be then injected to an SDR using tools such as GNU radio, or using a custom software, as we did specifically for this setup.

For the SDR front-end, we used the Analog Devices Adalm Pluto, which can be purchased for little more than 200€. While this SDR has limitations – it can only simulate one band with a relatively small bandwidth (up to 20 MHz) – it's sufficient for our purposes, specifically simulating the GPS L1 C/A signal (Galileo E5 simulation wouldn't be feasible due to the large bandwidth of the signal).

After signal generation, the SDR's RF output connects to an attenuator. This helps mitigate any oscillator leakage, which could be misinterpreted as continuous wave interference by the GNSS receiver.

Signal tracking and observable generation

To achieve LEO signal acquisition and tracking, we opted to leverage the existing tracking loops from a commercial GNSS receiver (the u-blox ZED-F9P embedded in our MEDEA GNSS computer) rather than modifying open-source tools like GNSS-SDR to track LEO-PNT satellites. This is the main reason why we had to reuse GPS PRN codes for the LEO satellites. However, this approach has a key limitation – the commercial receiver operates as a black box, offering minimal to no control over the internal tracking process.

One of the anticipated challenges with this approach was the significantly larger Doppler values associated with LEO PNT signals (as illustrated in the figure below, which depicts the simulated pseudorange and Doppler of a Starlink LEO satellite, as if it were a LEO-PNT satellite).

These larger Doppler values have implications in the tracking process as shown below. Despite these limitation, the magnitude of these Doppler shifts is not significant enough to completely disrupt the tracking loops employed by the commercial receiver. Consequently, the GNSS MEDEA computer is capable to actually issue UBX-RXM-RAWX messages with ranges from fake "GPS" satellites, as shown in the following video of the u-center running during the simulation session.

Once the u-blox binary packets are obtained, they can be parsed for further analysis. The following plots show the pseudorange and Doppler measurements for the simulation session performed during the experiment

The following points are noticed:

• ATTENTION: The measured range values weare unexpectedly closer to 20,000 km (typical of Medium Earth Orbit, MEO) than the simulated LEO constellation's actual orbital height of 1,300 km. While this might seem surprising initially, performing a simple Single Point Positioning (SPP) session revealed a clock estimate near 20,000 km. Consequently, subtracting this clock estimate from the receiver's reported ranges yielded more realistic values (approximately 1,300 km for high-elevation satellites). This suggests that the commercial receiver might be making internal clock adjustments to compensate for the anticipated range discrepancies associated with LEO signals.
• The observed Doppler values were indeed larger than those encountered in traditional MEO constellations. Setting satellites reached peak values of -6,000 m/s, while rising satellites exhibited lower starting values (around 3,000 m/s). This difference suggests potential limitations in the receiver's Frequency Locked Loops (FLLs) during signal acquisition, particularly when faced with the higher dynamic Doppler shifts associated with LEO satellites. However, it's noteworthy that the receiver successfully tracked the signal even with Doppler shifts as large as 6,000 m/s for setting satellites.

Conclusions and future work

This work successfully demonstrates the development of a LEO-PNT hardware simulator using readily available COTS components and open-source software. This cost-effective and accessible approach offers a valuable solution for simulating LEO-PNT functionalities and evaluating GNSS receiver performance with LEO constellations.

Key advantages of this hardware-based simulator include:

• Realistic Noise Patterns: The setup can simulate realistic noise patterns within the measurements, providing a more comprehensive testing environment, than a simpler purely software-based simulation.
• Raw Measurement Generation: The simulator generates raw measurements suitable for future exploration of positioning algorithms. These algorithms can focus solely on LEO-PNT measurements or combine them with traditional MEO constellations, opening doors for further research.

While limitations exist, such as the reliance on GPS PRN codes and potential receiver behavior with high Doppler shifts or COTS GNSS receiver absorving in the clock estimate the difference in range from MEO to LEO, the overall results provide valuable insights for further development of LEO-PNT simulation environments. Future work will explore these limitations and investigate the integration of the simulated raw measurements into LEO-based positioning algorithms.

The hardware development and integration has been performed by Aleix Tejada, while the scenario definition and data analysis has been contributed by Miquel Garcia.