The Australian and New Zealand governments, with support from FrontierSI, are conducting a survey with original equipment manufacturers (OEMs) to identify the opportunities and barriers for integrating Southern Positioning Augmentation Network (SouthPAN) signal support in GNSS chips, devices and equipment.
SouthPAN is a Satellite-Based Augmentation System (SBAS) in the Southern Hemisphere and provides improved positioning and navigation services in Australia, New Zealand and maritime regions.
Precise positioning from the network offers improved accuracy down to 10 cm. SouthPAN provides augmented and corrected satellite navigation signals directly from the satellite rather than through a mobile phone, providing accuracy that overcomes gaps in mobile internet and radio communications.
SouthPAN early Open Services has been live since September 2022, and aviation safety-of-life certified SouthPAN services are set to go live in 2028. Safety-of-life certified services are designed to support end users engaging in life risking operations, such as landing an aircraft at an airport.
OEMs of positioning and/or navigation service equipment are asked to share insights on the support of SouthPAN’s three services into chips, devices and equipment. In particular, the company is looking for OEM’s’ views on barriers and opportunities for support of the L1, dual frequency multi-constellation (DFMC) and precise point positioning (PPP) via SouthPAN services.
The information provided will assist Geoscience Australia (GA) and Toitū Te Whenua Land Information New Zealand (LINZ) to maximize SouthPAN ‘s full potential and benefits.
Click here to access the survey. Responses will be accepted until Sept. 30, 2023.
The U.S. Department of Transportation (DOT) has unveiled its Complementary Positioning Navigation and Timing (CPNT) Action Plan, which contains steps the department is taking to drive CPNT adoption across the United States transportation system and within other critical infrastructure areas. This plan was mentioned by Robert Hampshire — Deputy Assistant Secretary for Research and Technology and Chief Science Officer, U.S. DOT — during his keynote address at the annual Civil GPS Service Interface Committee (CGSIC) meeting on September 12, at ION GNSS+, which GPS World’s Editor-in-Chief, Matteo Luccio, is attending.
In 2020, the U.S. DOT Volpe National Transportation Systems Center conducted field demonstrations of various PNT technologies that could offer complementary service if GPS is disrupted. The department was able to gather information on PNT technologies at a high technology readiness level that can work in the absence of GPS.
The U.S. DOT have selected 11 candidate technologies to demonstrate positioning or timing functions:
Two vendors demonstrated low-Earth orbit satellite PNT technologies — one L-band and one S-band;
two vendors demonstrated fiber-optic timing systems, both based on the White Rabbit Precision Time Protocol;
one vendor demonstrated localized database map matching database, inertial measurement unit, and ultra-wideband technologies; and,
six vendors demonstrated terrestrial radio frequency PNT technologies across low frequency, medium frequency, ultra-high frequency, and Wi-Fi/802.11 spectrum bands.
Five of the selected technologies were demonstrated at Joint Base Cape Cod in Massachusetts, and six were demonstrated at NASA Langley Research Center in Virginia. The demonstrations were scenario-based implementations modeled on critical infrastructure use cases under different operating conditions.
Two central recommendations from the demonstration were made: the U.S. DOT should develop system requirements for PNT functions that support safety-critical services; and the U.S. DOT should develop standards, test procedures, and monitoring capabilities to ensure that PNT services, and the equipage that utilize them, meet the necessary levels of safety and resilience identified in recommendation one.
The U.S. DOT has also released a request for information (RFI) as one of the steps in driving adoption of complementary PNT services to augment GPS. The department is planning a resiliency test, evaluation, and performance monitoring strategy for PNT-dependent transportation systems.
If any readers are interested in participating, click here for more information.
Spirent has concluded a review of Xona Space Systems’ PULSAR production signals, and has deemed them feasibile for integration into the SimXona product line. Spirent will integrate the Xona production signals as an evolution of the SimXona platform.
Support will become available to existing and new users throughout 2024.
Xona is developing PULSAR, a high-performance positioning, navigation, and timing (PNT) service built on low-Earth orbit (LEO) small satellites. Xona’s high-powered smallsat signals aim to improve PNT resilience and accuracy by augmenting GNSS while operating with an independent navigation and timing system architecture.
M3 Systems has launched a disruptive project, co-financed by the Occitanie Region, aiming to provide new GNSS services.
Image: M3 Systems
The IOD-full software-defined radio (SDR) GNSS project will enable new services through a reconfigurable SDR payload, enabling on-demand analysis of GNSS signals from space. Through space-based signal analysis, this project paves the way for reconfiguring GNSS signal processing and developing expertise in adaptable and scalable GNSS receivers to accommodate signals from future constellations.
M3 Systems, Loft Orbital, and Space Co-Design play a key role by providing rapid access to space for the facilitated and accelerated deployment of the receiver in orbit. Co-financed by the Occitanie Region, the IOD-full-SDR-GNSS project was selected as part of the “Nanosatellites Plan – Acceleration of In-Orbit Validations (IoD/IoV)” call for projects, co-developed with the French government based on the needs expressed by regional companies under the ADER 4 Recovery Plan.
In 1973, on March 1, Xerox launched the Alto, the first computer designed from its inception to support an operating system based on a graphical user interface; on April 3, Martin Cooper of Motorola made the first cellphone call, from 6th Avenue in New York City; and TCP, Ethernet, and fiber optics were created.
That same year, over Labor Day weekend, a dozen people in a small conference room on the top floor of a nearly deserted Pentagon, at a meeting called and chaired by Brad Parkinson that became known as “Lonely Halls,” made the key design choices for the Global Positioning System. None of those fundamentals have changed in the intervening half century, during which GPS was developed, launched, and modernized and became a worldwide utility underpinning many critical economic sectors — including precision agriculture, financial services, location-based services, mining, surveying and telecommunications.
At the time, Parkinson — a United States Air Force colonel with a Ph.D. in astronautical engineering from Stanford University, three years of experience in inertial guidance, and 26 combat missions in AC-130 gunships — was the first director of the GPS Joint Program Office in Los Angeles. As he and his co-authors recalled in a detailed two-part history of GPS (see the May and June 2010 issues of GPS World), the aspects of GPS that were defined at Lonely Halls included:
Simultaneous passive ranging to four satellites in inclined orbits, ensuring user equipment would not require a synchronized atomic clock.
A signal structure using CDMA modulation, including both a precision military code and a clear acquisition one that would be freely available to civil users worldwide.
Two GPS broadcast frequencies in the L band.
A family of user equipment prototypes, including a low-cost set that would demonstrate civilian use.
I recently asked Parkinson how GPS today differs from the design that came out of the Lonely Halls meeting. “The fundamental answer is that it’s identical,” he said, “in terms of design, the atomic clock, the CDMA signal, and four satellites to eliminate the need for a user clock. What has been evolving, of course, is that we’ve added another frequency and several new signals, including those for the military and L1C.”
From the very beginning, Parkinson encouraged civilians to use the system, correctly predicting that “they would apply their research and design talents to drive the size, weight and power requirements of the receivers down and the family of applications up,” he said. “That’s exactly what happened, in my opinion.”
Which applications surprised him the most? “Our revolution has been enabled by the advent of integrated circuits in terms of size and cost,” he said. For example, RTK has now given dynamic users access to centimeter accuracies.
“We were driven by visions of the many beneficial applications of GPS; visions that were not yet shared by the Air Force. GPS is a testimony to my team’s engineering competency, their tenacity, and their resourcefulness. I, and the whole world, owe them a large debt for the benevolent revolution they created.”
Two recent announcements showed China’s progress establishing its national “High-Precision Ground-based Timing System.” Some verbiage in the most recent announcement could indicate that the system is nearing completion.
The timing system is designed to support a vast array of scientific and technological applications as well as provide services when space-based signals are not available.
According to some Western observers, it is another example of China’s increasing lead over the United States in positioning, navigation, and timing (PNT) technology.
Completion of the terrestrial system could have even more troubling implications for the United States.
Recent Announcements
On May 21 this year, a government affairs article in Shaanxi’s “The Paper” announced accelerated construction in Xi’an of a science center. Its centerpiece will be the country’s High-precision Ground-based Timing System. It is not entirely clear from the article whether this site will be the engineering and administrative headquarters for the system, or one of several “timing stations.”
The article also says the national system will be the largest in the world — with more than 20,000 kilometers of optical fiber and 295 time and frequency transmission sites — and will integrate space- and ground-based signals.
The network, according to the article, will supplement and improve the new eLoran (sometimes mistranslated by software as “Roland”) system in the western portion of the country. It will also support legacy eLoran “long-wave” signals in the east ensuring that the entire nation is well served.
Graphic from 2014 Chinese Academy of Sciences paper on Laron showing projected coverage in the western part of the country. Subsequent papers and announcements have indicated that western part of the network is complete or soon will be. (Image: Chinese Academy of Sciences)
Accuracy for the system’s fiber-optic transmissions is claimed to be less than 100 pico-seconds, with differential eLoran at less than 100 nanoseconds.
Construction recently announced in Xi’an and Nagqu as part of China’s High-precision Ground-based Timing System.
A much shorter press release was issued on June 8, announcing groundbreaking for a “timing station” in Nagqu on the Tibetan plateau in China’s west. The announcement said that, once the station was complete, China will “…realize national soil coverage of long-wave [eLoran] timing signals…”
Expansion of its eLoran and fiber infrastructure to serve the entire nation gives China what some have called the “PNT resilience triad” — signals from space, from terrestrial broadcast, and over fiber. The three sources of delivery are sufficiently different that an accidental or malicious disruption of one is highly unlikely to impact the other ones. Users accessing all three should experience minimal to no impact.
Both the May and June announcements said that finishing the timing project will benefit China’s national economy and national security.
Timing is essential tech infrastructure. More precise and robust timing enables improvements to current applications and the creation of new ones. For example, better timing can enable greater spectrum efficiency with more throughput on existing frequency bands. Highly precise fiber-based timing could also support using 5G telecommunications networks for hyper-precise positioning in autonomy corridors serving self-driving vehicles, UAVs, and other systems.
China’s ground-based timing system is part of a larger plan by its National Timing Service Center for a system of systems approach to PNT. Described as a “comprehensive approach” at the Standford PNT Symposium in 2019, the architecture has satellite-based navigation at its heart and includes a wide variety of other capabilities.
Graphic showing China’s plan for multiple, mutually supporting, diverse methods of positioning, navigation, and timing service and data. (Presentation by China’s National Time Service Center at 2019 Standford PNT Symposium)
Some observers trace China’s national PNT efforts to an incident in 1996 during the Third Taiwan Strait Crisis. Chinese forces fired three missiles toward a point in the sea offshore of Tiawan’s Kee Lung naval base. Two of the missiles were lost. According to the People’s Liberation Army this was because the United States denied or altered GPS signals that the missiles were using for guidance.
Known by China’s military as “The Unforgettable Humiliation” the incident sparked decades of effort to ensure China would never again be dependent upon another nation or space for PNT. The BeiDou global navigation satellite system and the High-precision Gound-based Timing System are the two most noteworthy accomplishments in this regard.
Implications for the United States
China’s ever-increasing lead in essential PNT technology and infrastructure is of great concern to many in the United States.
China’s global navigation satellite system, Bei Dou, is newer and, according to a presidential advisory board, substantially superior to GPS in many ways. Using it as an instrument of “soft power,” China is offering other nations BeiDou signals, along with discounted user and support equipment, as part of its Belt and Road, and Digital Silk Road initiatives. Where successful, these efforts erode both GPS usage and U.S. influence.
Of greater concern to many are the “hard power” implications of China’s PNT dominance.
While China has and continues to develop multiple and resilient sources of PNT, in the United States “GPS is still a single point of failure,” according to a member of the National Security Council.
As a result, if China were to interfere with GPS in some way, a U.S. response in-kind against BeiDou would have much less impact. This strategic asymmetry has been described by former CIA senior analyst George Beebe as “an open invitation” for mischief or attack. One that could easily lead to an escalating series of responses ending in an armed conflict no one wants.
At a more tactical level, China’s eLoran system extends 1,000 miles offshore covering Taiwan, the Strait, and all approaches. In a conflict to capture the island and make it subject to the Communist regime, China could block all signals from space while preserving its forces’ ability to maneuver and communicate. Already at a disadvantage having to deploy far from their support bases, this would further hamper U.S., Japanese, and other forces hoping to help Taiwan maintain its independence.
The U.S. Department of Defense boasts it can operate well in GPS-denied environments and says it is also working on alternative means of navigation for deployed forces.
This begs the strategic question, though, of whether the United States would be willing to come to the aid of Taiwan or another ally if the homeland were threatened with a prolonged and crippling disruption of GPS services.
Prior to Russia’s invasion of Ukraine, the Kremlin destroyed a defunct satellite and boasted it would shoot down all 32 GPS satellites and “blind NATO” if the alliance intervened. Many observers have wondered whether that has played into subsequent U.S. and NATO policy toward the conflict.
Unfortunately, little has been done to eliminate the possibility of a belligerent adversary holding the U.S. homeland hostage through GPS.
For two decades narrow government and industry interests in GPS production have successfully opposed any effort they see as possibly “competing” for space in limited budgets. Appeals that such projects would increase system security by “taking the bullseye off” GPS satellites and signals have been to no avail.
However, this may be changing. Several years ago the National Guard began development of a national timing architecture and network, called NITRO. The project supports the Guard’s own requirements to be able to operate without GPS and to aid state first responders. It is already in use in 7 states.
The future of NITRO is unclear, though, as the Department of Defense sees it as a civil defense rather than a national defense project and is no longer supporting it in the budget. Yet, the National Guard’s funding flows through defense appropriations.
As of this writing, the National Guard and NITRO remain stuck in a bureaucratic and budgetary no-man’s land with no clear path forward.
GNSS researchers presented hundreds of papers at the 2022 Institute of Navigation (ION) GNSS+ conference, which took place Sept. 19-23, 2022, in Denver, Colorado, and virtually. The following four papers focused on the use of GNSS in urban environments. The papers are available here.
GPS World will be attending this year’s ION conference in Denver, Colorado, on Sept. 11-15.
FGO-based GNSS/INS integration improves performance in urban canyons in Hong Kong
The integration of GNSS and inertial navigation systems (INS) has the potential to improve performance due to their complementariness. In this paper, the authors investigated positioning based on the integration of GNSS and INS using factor graph optimization (FGO). This ultimately showed improved performance in urban canyons in Hong Kong. The effectiveness of the proposed method was verified using challenging datasets collected using two automobile-level GNSS receivers in the urban canyons of Hong Kong.
For the experiment conducted in this paper, only the GNSS pseudorange measurement was utilized in the existing FGO-based GNSS/INS integration. The overall potential of the Doppler frequency and carrier-phase measurements has yet to be explored by the authors. To fill this gap, the authors proposed a tightly coupled GNSS/INS integration, using FGO, by exploiting the potential of diverse raw GNSS measurements. The GNSS pseudorange, Doppler frequency, and time-differenced carrier-phase measurements were integrated with the INS, using FGO.
The authors believe the improved performance using FGO-based GNSS/INS integration positioning was due to the global optimization property and the increased measurement redundancy of FGO, compared with the method based on extended Kalman filtering.
Weisong, Hsu; “Factor Graph Optimization for Tightly-Coupled GNSS Pseudorange/Doppler/Carrier Phase/INS Integration: Performance in Urban Canyons of Hong Kong.”
3D mapping in urban environments aided by surround mask GNSS/lidar SLAM
Automatic driving with coupled GNSS/INS and lidar sensors has been implemented in many urban environments successfully over the years. However, this technology is still prone to errors. These potential errors are especially evident in challenging environments, such as urban canyons with several moving objects and building layouts that provide unexpected and abnormal features for lidar sensors and multi-path for GNSS signals.
To address these error challenges in urban environments, the authors of this paper proposed a surround mask that explores error sources from surrounding environments, which could subsequently improve the performance of an integrated mapping system. The surround mask in this experiment extracted a two-layer factor, including non-line-of-sight detection and static objects detection, to collectively compensate for the specific drawbacks of the lidar-based SLAM and the navigation system.
The authors explain that the surround mask eliminated the need to apply complex post-processing to eliminate the accumulated error for each observing unit.
The experimental results demonstrated that the proposed surround mask detected the represented error sources in the local coordinate and provided environment-awareness information for the integrated mapping system.
Ai, Luo, El-Sheimy; “Surround Mask Aiding GNSS/LiDAR SLAM for 3D Mapping in the Dense Urban Environment.”
Novel process noise model helps GNSS Kalman filter degradation in busy cities
Improving the accuracy of GNSS positioning in urban environments is difficult, especially when using low-cost GNSS receivers. In this paper, the authors showed that if the process noise covariance is turned up in a “naïve” manner for poor satellite geometry, the estimation-error covariance could become unintentionally large in a certain direction.
The unintentional inflation of estimation-error covariance could cause the degradation of accuracy. The authors also proposed a fictitious process noise covariance based on an extension of a novel process noise model, which was proposed in their previous work.
The authors stated that in Kalman filter for GNSS positioning, the process noise covariance is often bumped up to avoid the filter divergence in the presence of unknown model errors, by assuming there is a fictitious process noise in addition to the nominal process noise. In this study, the fictitious noise covariance is determined based on the observation matrix, step-by-step, and it reduced the estimation errors without causing the unintentional inflation of estimation-error covariance.
The effectiveness of the derived process noise model is demonstrated for the data sets that simulate GNSS signals from the antenna that moves from open sky areas to urban areas. The estimation errors with the derived process noise model were significantly reduced, compared to the ones with other two process noise models.
Takayama, Yoji, Urakubo, Takateru, Tamaki, Hisashi; “Avoiding GNSS Kalman Filter Degradation in Urban Canyons with a Novel Process Noise Model.”
3D lidar-aided GNSS RTK positioning for increased accuracy mapping in urban canyons
The GNSS real-time kinematic (RTK) positioning technique has shown centimeter-level absolute results in open-sky areas; however, it can suffer from polluted GNSS measurements and poor satellite geometry in urban environments. This is due to the non-line-of-sight (NLOS) and multipath reception caused by signal blockage and reflection.
In this paper, the authors stated that lidar sensors integrated with odometry systems that include an inertial measurement unit (IMU) provided a precise environment description and short-term accurate relative positioning capabilities that could be utilized for aiding GNSS-RTK to obtain better performance.
While 3D lidar-aided GNSS RTK positioning methods detect the GNSS NLOS receptions via an incrementally built map and improve the satellite geometry using the low-lying virtual satellite from lidar features, the high-elevation angle NLOS receptions cannot be fully detected, and the multipath signals cannot be effectively mitigated.
In response to this, the authors proposed a 3D lidar-aided GNSS RTK positioning method with iterated coarse to fine batch optimization by a global 3D NLOS exclusion aided by a point cloud map, which enables the detection of high-elevation angle NLOS receptions. Additionally, the authors proposed iterated batch optimization based on a devised, tightly coupled, factor graph that fully exploited the global consistency among the constraints of lidar, IMU and GNSS RTK to exclude potential multipath signals.
The proposed method aimed to achieve lifelong accurate positioning performance in deeply urbanized areas. The effectiveness of the proposed method has been proved by the evaluation conducted on the author’s open-source challenging dataset, UrbanNav, which contains various sequences collected by automobile-level low-cost GNSS receivers in urban canyons of Hong Kong.
Liu, Wen, Hsu; “3D LiDAR Aided GNSS Real-time Kinematic Positioning via Coarse-to-fine Batch Optimization for High Accuracy Mapping in Dense Urban Canyons.”
The Galileo Open Service has been upgraded with three features added to its I/NAV message, one of the four message types broadcast by Galileo satellites. These features are now available to all Galileo Open Service users.
The process of upgrading the Galileo Full Operational Capability constellation satellites has been finalized and the I/NAV improvements are openly accessible through the I/NAV message carried by the E1-B signal. If users have experienced delays when turning on a GNSS device, the recent I/NAV improvements may reduce them significantly, reported the European Union Agency for the Space Programme (EUSPA).
The I/NAV message is now faster and offers more robust positioning. The Reed Solomon Outer Forward Error Correction (RS FEC2) increases demodulation robustness, which enhances the sensitivity. It also improves the overall time to retrieve clock and ephemeris data (time to CED) with the broadcasting of additional, redundant CED information while allowing for the device to restore potentially corrupted data autonomously.
The Reduced CED (RedCED) enables fast initial positioning, with lower than nominal accuracy, by decoding a single I/NAV word, while waiting to receive the four I/NAV words carrying the full-precision CED.
The combination of RS FEC2 and RedCED enables I/NAV to obtain a first course position solution faster and to reduce the time required to obtain a first full accuracy solution (RS FEC2). This translates into a reduced time to first fix (TTFF) for the Open Service users, particularly when operating in harsh environments.
Additionally, the improvements benefit applications working in assisted GNSS (A-GNSS) mode, through the Secondary Synchronisation Pattern (SSP). In A-GNSS mode, when navigation data is received from non-GNSS channels and the receiver’s knowledge of the Galileo System Time is affected by a relatively large error, typically in the order of a few seconds, the clock uncertainty must be resolved quickly and stably.
With the I/NAV improvements, receivers will be able to do this via the new SSP feature, thus reducing the TTFF, also in A-GNSS mode.
While the I/NAV improvements are fully operational, EUSPA will launch a testing campaign open to receiver manufacturers, that will consist of several testing windows. The tests will allow the participants to have a confirmation of the correct implementation of the OS SIS ICD 2.0 — i.e., the right processing of the three I/NAV improvements in their products.
The tests will be conducted at the laboratories of the European Commission’s Joint Research Centre in Ispra, Italy, and of the European Space Agency ESA/ESTEC in Noordwijk, The Netherlands.
EUSPA will assign each applicant to one of the two laboratories depending on the specific conditions and availability.
The Russian Federal Space Agency has launched one of its Glonass global positioning satellites, Glonass-K2 No. 13 (Kosmos 2569), into medium-Earth orbit (MEO) on August 7, at 13:20 UTC, reported Everyday Astronaut and Russian Space Web. The satellite was launched on the Soyuz 2.1b launch vehicle from Plesetsk Cosmodrome, in Russia.
Glonass-K2 No. 13 was launched to improve the accuracy of the Russian dual-use global positioning system. The K2 satellites are the fourth iteration in satellite design for GLONASS.
The new generation of satellites provide navigation accuracy of less than 30 cm and feature an unpressurized satellite bus (Ekspress-1000) manufactured by ISS Reshetnev. The satellites also use a novel navigation signal, code-protected selection, to transmit three signal types, including two in the L1 and L2 ranges for military users, and one channel in the L1 range accessible to the civilian users.
Each K2 satellite weighs 1,645 kg and has an operational lifetime of 10 years.
Ground antenna at Schriever Air Force Base, home of the 50th Space Wing. (Photo: Raytheon)
GPS ground stations that are contracted by Raytheon Technologies to replace the current ground stations are more than seven years behind schedule and lawmakers are not happy, reported Defense One. This delay has caused the U.S. Department of Defense (DOD) to go over its yearly budget and has sparked discussions as to future budget allocations for the U.S. Space Force (USSF) to continue to control and enhance the GPS constellation.
The USSF has been working to replace the current GPS ground stations with the GPS Next Generation Operational Control Segment (OCX) program since 2016. The operation was first delayed when the COVID-19 pandemic swept the world.
The additional delay was caused by efforts to replace IBM as the OCX hardware supplier after IBM sold its server product line to the Chinese company, Lenovo. The Pentagon believed the OCX program would be at a high risk for Chinese hacking after the sale to Lenovo, and in response, the contract with Raytheon was modified to replace the hardware with HP in 2020.
All of the delays have come at a cost, as the replacement of ground control stations has increased from $4 billion to $7 billion — a 73% increase over the original estimate — which was reported by a Government Accountability Office report in June.
Lawmakers wrote in the 2024 DOD appropriations bill, “[t]he fiscal year 2024 President’s budget request for the Space Force is $30,197,634,000, an increase of $3,907,806,000 or 15[%] over last year’s enacted level, continuing a trend of double digit growth over the past several years… [h]owever, despite these significant increases, the budget request continues to include serious shortfalls and disconnects.”
The USSF operates 32 GPS satellites, including six of the expected 10 next-generation GPS III satellites. However, some of the new satellites’ capabilities, including increased jamming resistance, can only be used once OCX comes online.
The lawmakers shared their displeasure with the OCX program delay, “[t]his is unacceptable and demands senior leader attention to ensure the program has the appropriate resources to complete OCX development and deliver the capability as soon as possible. The Committee remains concerned by other poor performing programs including Space Command and Control, Family of Advanced Beyond-line-of-site Terminals, Military GPS User Equipment Increment 1, and Enterprise Ground Services.”
An exclusive interview with Julian Thomas, managing director, Racelogic. For more exclusive interviews from this cover story, click here.
In which markets and/or applications do you specialize?
We originally designed our LabSat simulator for ourselves, because we supply GPS equipment to the automotive market. Then, we decided to sell it into that market, which is our primary market, for other people to use. That’s where we started, but it has moved on since then. We supply many of the automotive companies who use it for testing their in-car GPS-based navigation systems.
However, we’ve moved on to our second biggest market, which is the companies that make deployment systems for internet satellites, which use it for end-of-life testing. Several of our customers use it. That’s because we do space simulations, so we can simulate the orbits of satellites. That’s very useful when they’re developing their satellites.
We supply many of the major GPS board manufacturers — such as NovAtel, Garmin, and Trimble — when they’re developing their boards and testing their devices. We supply many of the phone companies — such as Apple and Samsung — and many of the GPS chip manufacturers — such as Qualcomm, Broadcom, and Unicom. More or less any company that’s into GNSS.
How has the need for simulation changed in the past five years, with the completion of the BeiDou and Galileo GNSS constellations, the rise in jamming and spoofing threats, the sharp increase in corrections services, and the advent of new LEO-based PNT services?
It all started off very simple, with just GPS, which was one signal and one frequency. We got that up and working very well and it helped us a lot. Then we got into this market. In the last few years, we’ve had to suddenly invent 15 new signals. We do two systems, really: one is a record-and-replay system. You put a box in a car, on a bike, in a backpack, or on a rocket, and you record the raw GPS signals; then you can replay those on the bench. That requires greater bandwidth, greater bit depth, smaller size, battery power, all of that.
The other is pure signal simulation. We simulate the signals coming from the satellites from pure principles. So, we’ve had to dive into how those signals are structured, reproduce them mathematically, and then incorporate that in into our software. That’s been 15 times the original work we thought it would be, but as we add each signal it tends to get a bit simpler until they add new ways to encode signals, and then it gets complex again. We’ve had to increase our bandwidth, increase our bit depth for the recording to cover all of these new signals.
Because our systems record and replay, they’re used a lot to record real-world jamming. In many scenarios, our customers will take one of our boxes into the field and record either deliberate jamming or jamming that’s been carried out by a third party. Then they can replay that in the comfort of their lab.
With regards to spoofing, we’ve just improved our signal simulation. So, we can completely synchronize it with real time. We can do seamless takeover of a GNSS signal in real time. We can reproduce the current ephemeris and almanac. If we transmit a sufficiently powerful signal, we can completely take over that device. Then we can insert a new trajectory into it. That’s a very recent update we’ve done.
If the complexity and amount of your work has gone up so much in the last few years but you cannot increase your prices at the same rate, what does that do to your business model?
It’s the same people that produce the signals in the first place, so they still have a job. However, as we add more signals and capabilities, we tend to get more customers as well.
Oh, so, you’re expanding your market!
Right, right.
Regarding some of the new PNT services being developed, how do you simulate them realistically without the benefit of recordings of live sky signals?
It is all pure signals simulation. You go through the ICD line-by-line and work out the new schemes. Here’s an interesting anecdote. Our developer who does a lot of the signal development is Polish and is also fluent in Russian. When we were developing the GLONASS signals, he was working from the English version of the GLONASS ICD. He said that it didn’t make any sense. So, he looked at the Russian version and discovered that the English one had a typo. When he used the Russian version, everything worked perfectly. He told this to his contacts at GLONASS and they thanked him and updated the English translation of their document. So, you are very, very much reliant on every single word in that ICD.
Are there typically differences between the published ICD and the actual signal?
No, no. Apart from the Russian one, which had a typo, they’re very good. For example, we’ve recently implemented the latest GPS L1C signal. My developer spent six months recreating it and getting all the maths right and the only way you could test it was to connect it to a receiver and hit “go.” It just worked the first time. He almost fell off his chair. The ICD in that case was very, very accurate.
Hope that Xona’s ICD is just as good.
Yeah.
Are accuracy requirements for simulation increasing, to enable emerging applications?
Yes, absolutely. No one can have too much accuracy. Everyone’s chasing the goal of getting smaller, faster, and more accurate systems. They want greater precision and better accuracy from their simulators, as well as a faster response. We do real-time simulators and they want a smaller and smaller delay from when you input the trajectory to when you get the output. Luckily for us, Moore’s law is still in effect, so, as the complexity of the signals and the accuracy requirements increase, computers can churn through more data. Luckily, we’re able to keep up on the hardware side as well, because much of our processing is done using software. Some companies do it in hardware and some companies do it in software. We concentrate on the software side of things.
Here’s another interesting anecdote from my Polish guy. He noticed that the latest Intel chips contain an instruction that multiplies and divides at the same time but that it wasn’t available in Windows. So, he put in a request with Microsoft for that operational code and they incorporated it into the very latest version of dotnet, which has improved our simulation time by 7%. I see little improvements like that all the time.
Are all your simulators for use in the lab or are some for use in the field? If the latter, for what applications and how do they differ from the ones in the lab? (Well, for starters, I assume that they are smaller, lighter, and less power-hungry…)
All our systems are designed to be used inside and outside the lab. They can all be carried in a backpack, on a push bike, in a car. We do that deliberately, because we come from the automotive side of things, so we have to keep everything very small and compact.
Besides automotive, what are some field uses?
Some of our customers have put them in rockets, recording the signal as it goes up, or in boats. We have people walking around with an antenna on their wrist connected to one of our systems, so that they can simulate smartwatches. There are many portable applications. We have a very small battery-powered version, which makes it very independent.
Are there any recent success stories that you are at liberty to discuss?
Our most exciting one is a seamless transition for simulation that we developed to replace or augment GPS in tunnels. We’ve been talking to many cities around the world that are building new tunnels. Because modern cars automatically call emergency services when they crash or deploy their airbags, they need to know where they are, of course. Cities need to take this into account when they are building new tunnels, which can pass over each other or match the routes of surface streets. Therefore, accurate 3D positioning in the tunnels has become essential. It requires installing repeaters every 30 meters along each tunnel and software that runs on a server and seamlessly updates your position every 30 meters. As you enter a tunnel, your phone or car navigation system instantly switches to this system. It’s been received very well because it’s mainly software and the hardware is pretty simple. We’ve brought the cost down to a fifth of the cost of standard GPS simulators for tunnels. So, we’re talking to several cities about some very long tunnels, which is very exciting.
An exclusive interview with Tim Erbes, Technical Director, Safran Federal Systems (formerly Orolia Defense & Security). For more exclusive interviews from this cover story, click here.
What are currently the key challenges for simulation?
One of our big challenges is determining what performance requirements are necessary for our users. Often, they can’t determine what the specs need to be. All they know is that they need it to work. “I need this receiver from one company, this IMU from another company, and the simulator I got from you guys to work together and I need the performance to match reality.” It can be very challenging to say, “What are the requirements for the simulator? How accurate does it need to be? What types of things matter in this integration?”
Often, we’re left trying to figure that out. So, that’s an interesting, maybe unexpected challenge. It’s easy to look at the datasheet and see what some specs are, but it’s a much harder thing to say, “Well, what do you need the specs to be?” So, we’ve been working with our customers to try to nail down some of those specs, particularly with Wavefront. We have some specs on such things as phase alignment and phase stability. But how do you translate that into something like “Well, I just want the CRPA to work the same in the lab as it does in the real world?” There’s not a direct, easy way to do that. We’re in the middle of trying to figure that out. That’s definitely one of our challenges.
What about the increase in jamming and spoofing threats?
In the last five years, we’ve seen a lot more open talk about jamming and spoofing in the world. The receiver manufacturers must think about this a lot more. What’s interesting from a simulator point of view is that this is not actually new for us. We have the advantage that we’ve been designing to program requirements for years and they have included jamming and spoofing for years. So, in a way, simulation is ahead of this state of the world. Jamming and spoofing are not new or hard ideas for us. In fact, spoofing is similar to simulation. So, we already know how to do that.
Image: Safran Federal Systems (formerly Orolia Defense & Security)
However, jamming and spoofing are new to programs and integration labs. So, there might be platforms where they’re now testing against jamming or spoofing requirements where in the past, maybe they didn’t do that. They certainly can use our simulators to help them do that. However, we’re not seeing a lot of new requirements coming to us saying we need new jamming or spoofing capabilities, because we already have them. Luckily, we are future oriented regarding the jamming and spoofing requirements, so those really haven’t been a challenge for us yet.
That can always change, right? If new requirements come up, such as higher data rates or wider bandwidth waveforms or different types of waveforms, then we would have to adapt and add support for that kind of stuff. As of right now, however, we aren’t really seeing that. So, luckily, we’re prepared for that. As for the industry as a whole, there has definitely been a big movement in the last few years to understand the effects of jamming and spoofing. Simulation is a big part of that.
What about the completion of the BeiDou and Galileo constellations?
For a long time, we simulated four constellations. Then that began to get fuzzy. Do you consider SBAS a constellation or is that just an augmentation? Do you count EGNOS and other supplemental constellations for the other constellations? What about NavIC and QZSS? Before you know it, you start to lose track of exactly how many you have. We just released our 8th constellation, Xona.We’re going to be demonstrating it at JNC.
Tell me more about that.
We are trying to have all the constellations and that can be a fuzzy definition. Does that mean all that are up there right now or all that will be up there in the future? We’re trying to be forward looking and add everything that is going to be up there or might be up there so that lab users can develop and test. Multi-constellation simulation is a particularly challenging problem for groups that don’t have simulators. If you’re just doing research on, say, GPS, and want a new code, you might be able to do that in a lab on your own. But as soon as you say, “I want to do research on whether this LEO constellation helps navigation on a receiver that also uses Galileo and GPS,” suddenly, your research requires a full multi-constellation simulation.
There are two choices. One is to have a simulator do the constellations that already exist, and then you have some research to add constellations. That can be very challenging, especially with time alignment and things like that. The other is to have a simulator that can do all the constellations. That would be the easy choice, right? That presents a problem with such things as LEO navigation being on the rise and these constellations that are just emerging, that are still not even fully defined.
So, we’re trying to build those into our simulation products, to help researchers and decision makers determine whether these will be useful features to add to their receivers or their systems. We have the advantage of having a software-defined architecture. We designed the software so that it is easy to add new constellations to it. Basically, once we’re given a proper ICD, we’re only a couple of months away from a first draft implementation of that new signal. Then we iterate. There used to always be a government-driven, multi-year program to develop an ICD. Now, we have this new concept of the signal manufacturers. We’re seeing private companies release signal specs. That’s a very different way of creating a signal in a constellation. So, sometimes you don’t get much time between when the ICD is available and when simulator users want to use that constellation. Having a software-defined architecture really helps us move quickly. We can add such things as Xona very fast.
Xona told me a couple of days ago that they will soon put out an ICD. What’s the difference between actual signals that you can record and play versus something that’s only on paper?
That’s a great point. Probably many people don’t realize, when they first look at this, that what’s in the ICD and what’s on live sky are sometimes very different. Is the simulator supposed to match live sky? Or is it supposed to match the intended final state of the constellation, according to the ICD? This is a huge topic for M-Code, which is ever changing, and has a very large ICD that’s been released. Space Systems Command/Military Communications & Position, Navigation, & Timing (MCPNT) controls the features and releases them incrementally. We’re constantly having to make changes to the simulator to match those releases. The same is true for the other ICDs. At the Institute of Navigation Joint Navigation Conference (JNC), we will demonstrate an expanded PRN. I think this showed up in the ICD a couple of years ago, but it’s not used by any users yet. Some of the receiver manufacturers are starting to look at using PRNs beyond 32. So, we’re adding that to the simulator. This has already happened for BeiDou as well. I think their ICD goes up to more than 60 satellites. It’s an ever-changing race. The ICDs are constantly being updated and we’re trying to update the simulator.
Image: Safran Federal Systems (formerly Orolia Defense & Security)
Meanwhile, live sky is many years behind the paper, right? This creates an interesting challenge: when you design a system, are you designing it for today or for the future? We have users in both groups. We have users that only care about what is happening today, because they need a model. Maybe you want to model a specific mission and you want to make sure that everything’s going to go properly. Or maybe you’re designing a system that you want to release in three or four years, and you want to make sure that it’s going to work with the state of the system then.
A big challenge is to make sure that we’re keeping pace with all these ICDs. There are more constellations than ever and the technology makes it easier to change signal architectures. We’re seeing signals change faster than we’ve ever seen them change before. We go to conferences and hear about such things as on-orbit reprogramming and signals that might even change specs while they’re being transmitted. Maybe they don’t even have to have a fixed bandwidth or fixed bit rate. We’re going to start talking about signals that can reprogram on the fly. That’s going to make simulation more and more challenging. The technology exists to do this.
Software-defined waveforms is a very logical step. In the software world, we have this concept of version nightmare. When you have 20 different pieces of software that are interdependent, it can get very challenging. We’re going to start to see that in simulators. We’re going to see, “Hey, what version of navigation authentication are you using? We updated it six months ago. Are you using the new one or the old one? Which one should we use?” Well, it depends on what your receiver is using. It’s going to be interesting and challenging to keep all this straight in the next few years as things evolve. Certainly, however, our goal is to be there for all of it and to be as fast and as forward thinking as we can for our customers. That means that we also need to know what our customers need. So, we’re always looking for feedback and requests, what challenges our customers face and we’re responding to those requests.
Tell me more about the difference between simulators used by receiver manufacturers in their labs as they’re tweaking receivers or developing new ones vs. simulators used for mission planning.
The simulators are the same, but they’re used in very different ways. In most lab simulation, what the constellation looks like that day doesn’t matter very much. They can just run with a default constellation for a given day. They’ll run that scenario hundreds or thousands of times and never need to change it because they’re testing parts of the receiver that don’t care a whole lot about the specifics of what’s happening.
Whereas missions are time- and location-specific.
Yeah, exactly. They want to know which satellites will be overhead at an exact time and place. It’s not so much a problem anymore, but there used to be certain days and times when you would not get enough satellites in view, or you might have very bad dilution of precision, and your mission might actually fail. We’re past those days. There are now enough satellites up there. Most receivers will navigate within their specs most of the time in most places. However, for critical missions, such as military operations or rocket launches, you might not want to just assume that any day is a good day. So, if you’re about to launch a rocket, you might want to check. “What does the constellation look like right now?” The challenges that brings is that simulators have a default constellation, but the constellations are constantly changing.
When you’re doing real day mission planning, the big problem isn’t so much how to generate a signal, it’s how to find out what’s happening today. That’s really the nature of the problem because what’s out there today is different from what was happening yesterday or what will happen tomorrow. You might have unhealthy satellites. You need to know that if you want to model them. It becomes a big challenge to get all the right data into the simulator. Once all that data is in there, then it’s the same as any other simulation.
Are there good sources for current data on GLONASS, BeiDou and Galileo?
Image: Safran Federal Systems (formerly Orolia Defense & Security)
There are a couple of websites that provide information about where the satellites currently are. However, we’ve found that each one of those sites has its own challenges. Some are maybe 30 minutes out of date, which is pretty good, but puts the satellites in slightly different spots. Some of those sites only support some of the constellations. We’re talking about multiple countries and they don’t all agree on how this should be done. So, there’s not a single point that you can visit to get all the satellite data. There are a couple of companies that try to fix this. U-blox has AssistNow; Qualcomm has an assist for its cellular receivers; Trimble, NovAtel, and a couple of other companies have their error correction services to which you can subscribe to get some of that data.
If you want real-time up-to-date ephemeris for all the constellations, that is challenging. There are one or two options we have found that seem to work, but they each have their disadvantages. Maybe they don’t have all the satellites. Again, we’re talking about versioning issues. So, if you’ve designed your system with a certain version of an ICD and they’ve added more satellites since, those new SVs maybe aren’t so important for your users, so you don’t publish them. Other users want those satellites. So, we see versioning issues in these data streams. For example, we use the CORS network to get a lot of GPS data but that whole network, as far as I know, is only running the legacy data. As far as I know, no network is distributing the L1C modernized data that we will need at some point. So, as we launch new signals and constellations, we need the networks to provide this new data.
What are some other challenges?
For us, being a software-defined simulator on a platform dependent on software-defined radio (SDR), we’re constantly looking at what’s changing in the SDR technology community. There’s always some interesting stuff happening there that we try to incorporate. We don’t have any big announcements this year, as far as new architectures or anything like that. However, the SDR community is evolving. It’s still a rather new industry. A few years ago, we were an early adopter of SDR technology for mass deployment. Now, we’re seeing some more mature SDRs starting to push such things as channel count and coherency. We will probably take advantage of that in the future.
The other interesting thing technology-wise is that we’re also a GPU-dependent technology. So, as the GPU industry continues to evolve and makes bigger and faster GPUs, we get a relatively low-cost way to upgrade. We don’t have to do a lot of R&D to upgrade to a new GPU. For our users that means that the number of signals they can generate on their simulators is always increasing even using the same hardware from one generation to the next. Our first simulator did 75 signals; the next version did 150. We could build a system that did more than 1,000 signals, but our users don’t need it.
I assume that the growth curve for GPUs is steeper than that for signals.
I think that you’re right about that. I’m sure glad they do, because then something like Xona shows up and we don’t have to rearchitect our system to generate 300 signals, right? At JNC we will show expanded PRN, 300 Xona satellites in the constellation, and a 10 fold improvement on Wavefront performance specs.. We will continue to build simulators that meet our customers’ requirements. Besides GPUs, a lot of the technology involves software R&D and signals. The stuff that we do digitally inside of our system that allows us to do things like extremely precise phase alignment on Wavefront, for example. We spent a lot of time developing that stuff.
