September 8, 2020
Ricardo Verdeguer Moreno
“Shift left” has become a common phrase in the software industry, but not so much – yet – in GNSS receiver development. It refers to the stage of the development cycle at which testing is carried out. In the past, software applications were typically tested only after they’d been written, meaning that whole systems had to be sent back for rework if any flaws were found.
Today, software testing is typically done alongside (rather than after) development, ensuring quality is baked in from the start. In the parlance, it has shifted left’ in the development process.
As GNSS receivers become more complex, a shift-left approach is starting to look more attractive to GNSS chipset designers and developers, too. Vast amounts of work go into the early stages of chipset design, with the modelling of complex algorithms for purposes including multipath handling, anti-jamming, anti-spoofing and sensor fusion.
But typically, the efficacy of those algorithms has only been extensively tested once the design has been implemented in the ASIC hardware. That’s the point at which real or simulated radio frequency (RF) signals can be played to the receiver, and its behavior in various real-world scenarios can be evaluated.
Any issues discovered at this point mean the designers must go back to the drawing board and adjust the underlying algorithms. But by the time the design has reached the hardware stage, a lot of time and budget has already been spent.
For GNSS chipset manufacturers, and for industries developing highly-specialized GNSS instrumentation, retracing their steps at this stage increases development costs and delays product introductions.
At the same time, we’re seeing the rapid growth of GNSS software receivers in industries like automotive and drone development. They use software-defined radio (SDR) to perform signal processing functions that were historically performed in the hardware.
With more attention being paid to the functionality of the software, early testing is becoming essential to avoid expensive errors and delays. Testing parameters like positioning and timing accuracy, acquisition, and tracking sensitivity and resilience with software in the loop can also help to identify the most appropriate hardware frontend for the receiver. (For more on this, read our eBook on How to Choose a GNSS Receiver.)
It remains true that receiver hardware would have to be rigorously tested, as parameters provided by manufacturers are often incomplete or unable to be compared due to different boundary conditions in establishing the performance.
These are issues that Spirent is addressing with the launch of our SimIQ Capture and SimIQ Replay software solutions. Together, they enable GNSS chipset and receiver developers to extend testing with realistic scenarios all the way back to the earliest stages of development.
With SimIQ Capture, Spirent’s RF signal simulators can be used to generate I/Q data files that contain all of the GNSS signal data required to test the algorithms, conformance, and performance of software receivers before they are implemented into hardware.
I/Q files are RF signal waveforms in a digital format suitable for testing models and software functionality. Rather than being upconverted to RF in the simulator, SimIQ Capture allows them to be used in their existing form without the variables associated with the hardware.
This means that the same Spirent simulator can now be used throughout the whole product cycle – from the earliest algorithm models all the way to the finished vehicle or device. This not only reduces the amount of test equipment needed, but also supports a consistent test regimen from R&D to new product introduction.
The same I/Q files can also be played through Spirent’s GSS6450 Record & Playback System (RPS), allowing the RPS to function as a low-cost RF signal generator for less complex testing.
SimIQ Replay, meanwhile, allows Spirent GNSS simulators to generate RF signals from I/Q files generated by any compatible source, without losing any of the signal fidelity and quality you expect from Spirent.
This is especially useful for defense agencies and contractors, as it allows them to work with classified codes and signals without involving a third party.
It also means that non-GNSS signals, such as RF interference waveforms, can be generated as I/Q files and played through the Spirent simulator alongside the simulated GNSS signals – removing the need to invest in a separate interference generator.
As more powerful functionality is built into GNSS receiver algorithms and software, test teams need new ways to evaluate real-world performance. With SimIQ, Spirent is supporting receiver designers and developers in critical industries to shift testing left and assure quality from the earliest stages of development.
To learn more about SimIQ, visit www.spirentfederal.com/gps/products/simiq/overview/ or contact us directly.
