The “Signal Simulation and Testing: Fundamentals and New Frontiers” webinar, held March 10, generated in-depth Q&A, printed in part here. Inertial positioning can be tested with GNSS. Download full webinar free.
Question: What is the toughest multi-constellation performance parameter to meet?
John Fischer, Spectracom. In the multi-constellation environment, having to test for synchronization between the different constellation presents a challenge. The timing references GPS, GLONASS, Galileo and BeiDou use are all slightly different. Each has a different time base, and they do different things to control them. It’s a challenge for receiver designers to make sure that they are synchronizing correctly.
There are a couple of classes of multi-constellation receivers. Some are multi-constellation but they’re only doing one constellation at a time. Others create a larger navigation solution using satellites from different constellations all into one solution. That’s a more challenging set-up. There’s more of an accuracy dilution problem in the second case, because depending on a couple of factors you might be making it less accurate by having more constellations because you’re having more availability. You can, if you’re really clever in doing these very large matrix solutions, combine satellites from different constellations, but that’s a very big challenge.
The third challenge is multi-frequency. As you do these added things, your receivers are getting L1, L2, and L5, even further away. Wideband receivers have issues of flatness and frequency response, group delay and so on: big challenges for receiver designers
John Pottle, Spirent/Spirent Federal. In a simulator you have to set up the scenario, the test conditions. If you’re doing a GPS test, you have to set up the GPS constellation parameters. Then you have propagation of the signals, atmospheric and other effects including blockages around the simulated antenna. The antenna position position could be open sky or surrounded by buildings, foliage and so on.
At the most basic level, adding another constellation to a test is really not difficult. You would simply add a GLONASS constellation, for example. The GLONASS signals would then be generated however you’ve set them up, either default or with other effects. At the receiver end, the antenna would not be changed, because you’ve just added a constellation; you’d keep the environment around the antenna exactly the same. You’ve just added another constellation or one, or two, or three, or other signals, which we simulator manufacturers aim to make straightforward.
Julian Thomas, RaceLogic. One of the challenges of multi-constellation testing is when a constellation isn’t yet full; it is in its early phase of development. How do you simulate the satellites that are coming up in the future? That is especially true for BeiDou and Galileo. We have generated artificial almanacs that contain the future satellites that do allow you to test what will happen when there’s a larger number in the sky.
Question: There is increasing interest in incorporating data from other sensors in a positioning solution. How can a multi-PNT solution be tested?
John Fischer: A lot of simulators can accommodate that data. For inertial, whatever the accelerometers or gyroscopes may output, a lot of simulators including ours can output that data as well, to match whatever scenario you’re doing. We are looking at the idea of doing crowd-sourced navigation. Say I’m a device that’s on a network, a node on a network, which most things are nowadays. Even though I don’t know exactly where I am — or I want to supplement my GNSS signal — over the network I can talk to other nodes that may know where they are, and then measure my distance to them. That can help my solution. That’s an interesting advanced area we’re working in. Network delays measuring that and synchronizing that, is a new area being tested.
John Pottle: It’s really important to write down what the test objective is, if you are testing these other sensors. An example: If you take a device that’s got GPS and inertial, in the real world it will be receiving GPS signals and the inertial sensor will be putting out data consistent with the movement of the platform. How do you simulate that? One way is to know what the output data of the inertial sensors is under different conditions, and simulate those. In that case, in the test you don’t actually simulate the inertial sensors themselves, but you provide the output of those sensors to your sensor fusion engine.
That works well for high-grade IMUs, but for noisy MEMS-type sensors, it tends to be not a very satisfactory approach. Another approach is you can actually physically move the device in the lab, consistent with the motion that you’re simulating. That’s easier for some sensors than for others. You can put a magnetometer or a digital compass on a turntable fairly readily. But for accelerometers, it’s extremely difficult to simulate ongoing accelerations in a lab environment, consistent with a long real-world journey.
Finally, GNSS are broadcast systems. Inertial sensor outputs are broadcast as well. There’s no handshaking. When you get into WiFi signals or data provided over a vehicle CAN bus, it’s no good just recording the data and playing it back later. The test system must take account of the handshaking and the system message protocols.
Julian Thomas. Our main expertise in this area is recording the real-world signal and then playing it back on the bench. Our LabSat can record lots of other data from the vehicle, and then when it’s replayed on the bench, you get all of those signals synchronized. Luckily, the other side of our business is very heavily automotive data-logging based. We have vast experience interfacing with cars, with the CAN bus of cars, and reading out information and transmitting on the CAN bus. You get that sort of experience free, really. Other signals you can get are wheel-speed data, lots of times that’s incorporated in the Kalman filter routines to vastly improve accuracy in tunnels, for example.
