By Julian Thomas
Managing Director, Racelogic
Driving simulators are commonly used by vehicle manufacturers to expedite the test and development process of their many electronic systems. This not only saves the considerable time and expense of using a real car on a test track, but it is, of course, significantly more environmentally friendly.
LabSat simulators are used by many leading technology companies and car manufacturers to develop and verify the performance of their new products containing GNSS receivers. These tests are performed using either a pre-recorded or an artificially generated RF signal. This RF signal contains the combination of multiple satellite signals, which are decoded by the GNSS engine, tracking the artificial satellites as though they were real. Static or moving scenarios can be generated, and the user can select parameters to suit their own application, such as time, date and available constellations.
Managing Director
Racelogic
Recently, an automotive LabSat customer had a specific requirement to synchronize a GNSS receiver with the real-time trajectory data generated by one of their driving simulators. This was for a hardware-in-the-loop test rig where a human driver would navigate a route around a virtual test track, while the normal electronic systems reacted as if the vehicle were being driven around a real environment.
The challenge in this customer’s application was that the time delay between the trajectory coming from the simulator and the generation of the corresponding GNSS signals had to be less than 100 ms. This low latency was necessary to achieve realistic synchronization between the driver’s inputs and the resulting output from the GNSS-based device under test.
Traditionally, low-latency real-time simulators use bulky expensive hardware that relies on power-hungry field programmable gate arrays (FPGAs) to create the necessary satellite signals. However, due to the inevitable tick of Moore’s Law, and with some clever optimizations, your entry-level desktop PC now packs more than enough punch to simulate multiple constellations and signals with very low latency.
Using a standard PC to do the heavy lifting means that the hardware required to output the simulated signal is much easier to obtain, can be a lot simpler, and is considerably more cost effective. For example, an 8-core, 3-Ghz Intel i7 processor can generate the signals from 20 satellites in real-time, which normally is sufficient to simulate all but the most complex scenarios.
Our LabSat SatGen software has been continuously developed and optimized during the past 15 years, so it did not take us long to enable the reception of an NMEA trajectory stream with a latency of less than 100 ms. We then streamed this simulated data via USB to our LabSat Real-Time, which generated a corresponding RF signal that can be connected directly to the RF input of any modern GNSS engine.
Using a PC to generate the signals does not mean a loss of fidelity, with the resulting output achieving a repeatable position of less than 10 cm, while the trajectory data can be received at up to 100 Hz.
The resulting solution can take trajectory data from any kind of simulator that has an API to obtain real-time data, such as many popular off-the-shelf driving and flight software simulators, and use this to provide a real-time signal that can be utilized by the GNSS device under test.
Our future development roadmap includes synthesizing external signals, such as CAN-based sensors or inertial measurement units, and then synchronizing these signals with the incoming trajectory. With the amazing power of a modern PC, we are finding that this kind of complex simulation is now much more cost effective and easier to achieve.
