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.”
Ukraine’s allies in Europe are sending the country new UAVs and counter-UAV equipment, reported The Defense Post.
German weapons provider Rheinmetall is preparing to send its LUNA NG (next generation) unmanned reconnaissance UAV to Kyiv, the company announced August 14. The system should be delivered by the end of the year, according to Rheinmetall.
The LUNA NG is part of a sizable military aid package for Ukraine initiated by the German government in July. Per Rheinmetall, the package includes a ground control station and several UAVs, as well as a launch catapult, an optional net equipment for catching landing UAVs and equipment for rapid repair. The system is mounted on a Rheinmetall HX truck with a swap body system.
The UAV is designed for a range of mission-specific payloads — including LTE network and electronic warfare support measures such as detection, classification and analysis of electromagnetic radiation for threat detection.
UAV can remain aloft for more than 12 hours and maintain a datalink range of up to 100 kilometers normally, and up to 300 kilometers when fitted with optional satellite communication equipment, according to Rheinmetall.
The Bundeswehr (the German military) has operated LUNA UAV systems since the early 2000s. Those were originally developed by German manufacturer EMT Penzberg, which was acquired by Rheinmetall in 2021.
Berlin has already delivered several reconnaissance UAVs to Ukraine, including 88 Vector UAVs from Quantum Systems, 20 RQ-35 Heidrun systems Sky-Watch, and 32 unspecified reconnaissance UAVs, as of August 9.
Ukraine will also soon receive a series of Cortex Typhon counter-UAV systems made by Norway’s Kongsberg, after the company signed an agreement via the International Fund for Ukraine.
The delivery consists of several Cortex Typhon systems — developed to counter a wide spectrum of UAVs with solutions to either physically harm or disable an aerial threat, Kongsberg said.
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.
The Open Geospatial Consortium (OGC) has released the first iteration the Integrated Geospatial Information Framework (IGIF)-M (Marine) Spatial Data Infrastructure (SDI) Maturity Roadmap for both marine and terrestrial domains.
“The IGIF-MSDI maturity roadmap is an important step that supports a holistic understanding of data-exchange and processing environments,” said OGC Chief Technology Innovation Officer, Ingo Simonis.
According to the OGC, the core of the IGIF-(M)SDI Maturity Roadmap is formed by the World Bank SDI Diagnostic Toolkit where, with contributions from IHO and OGC, its terrestrial heritage was augmented to maximize its benefits to the marine domain.
u-blox has partnered with ORBCOMM, a pioneer in Internet of Things (IoT) technology, to develop solutions for the convergence of terrestrial and satellite IoT communications markets.
According to the Ericsson Mobility Report, the number of cellular IoT connections is projected to reach around 5.5 billion by 2028. The satellite IoT communications market is also expected to triple by 2025. Combining these two technologies will provide gap-free global connectivity for IoT communications, even in previously uncovered areas, making it more accessible for IoT deployers.
With this partnership, u-blox will integrate ORBCOMM’s satellite communication protocols into its UBX-R52/S52 LPWA (low-power wide-area) modem SoC (system-on-a-chip) resulting in a smaller, less complex chipset that offers dual connectivity. This chipset will be used in future u-blox module products, enabling connected solutions across the globe.
The collaboration between ORBCOMM and u-blox will meet the increasing demand for IoT solutions capable of connecting devices in remote locations, areas with poor cellular coverage and isolated environments. Various industrial IoT applications can benefit from these solutions, such as asset tracking, equipment tracking in agriculture and construction industries, and industrial sensors.
“Pairing ORBCOMM’s satellite technology with u-blox’s innovative UBX-R52/S52 chipset will allow customers deploying IoT solutions in the supply chain, heavy equipment, and agriculture industries to benefit from ubiquitous coverage, device simplicity, along with optimal reliability and longevity,” said David Roscoe, ORBCOMM’s executive vice president of satellite communications and products.
“It has been no secret — there are vulnerabilities within the timing and synchronization platforms used by the energy sector,” according to David Wells. Citing well recognized vulnerabilities associated with using signals from GPS, Wells said “…a secure, verifiable, and reliable solution is paramount.”
CAST’s mission is to research, establish and demonstrate best practices for timing within electrical grids.
As part of its efforts, DOE and the Oak Ridge team recently published “Implementing a Terrestrial Timing Solution: Best Practices.” The document is an important complement to the model network CAST has established to demonstrate practices and do further research.
Best practices in the document include discussion of:
equipment needed
various timing sources and transfer methods
the need for environmental stability
IEEE 1588 Precision Time Protocol
hardware recommendations.
Implementing these best practices and establishing timing networks will be up to grid operators as encouraged by DOE’s Power Marketing Administrations.
Others are already taking notice, though.
Concerned about their ability to maintain land mobile radio networks and other applications when GPS is denied or manipulated, the National Guard, in coordination with Homeland Security advisors and emergency managers, has implemented its own terrestrial timing network across the states and territories. The project, Nationwide Integration of Timing Resiliency for Operations (NITRO), has already been implemented in seven states. Major General William Crane, adjutant general for West Virginia, said that NITRO and CAST are well aligned, and the NITRO team will be working with DOE to ensure that continues to be the case going forward.
Pat Diamond, a member of the President’s Space-based Positioning, Navigation, and Timing Advisory Board and a former consultant to CAST, contributed to the development of the best practices. He is also an on-going participant in timing forums such as the ATIS Sync Committee.
When asked for his view he replied “The CAST best practices lay out the how wide area time synchronization networks should be deployed. There needs to be a concerted effort for DOE jointly with the power generating industry to actually implement an end-to-end time synchronization network demonstrating that these best practices are cost effective, manageable and implementable to solve the technical limitations of GPS dependence within a power generating marketplace.”
Inertial Labs has added a new scanning and mapping solution to its Resepi line, the Resepi Teledyne Optech CL-360-HD. The device has a powerful four-return laser and increased range of up to 750 m, making it ideal for mobile mapping, forestry and crack detection in critical infrastructure areas such as airport runways.
Resepi is a sensor-fusion platform designed for accuracy-focused remote sensing applications. Resepi utilizes a high-performance Inertial Labs INS and a high-accuracy dual antenna GNSS receiver, integrated with a Linux-based processing core and data-logging software. The platform also provides a WiFi interface, optional imaging module, and external cellular modem for RTCM corrections. Resepi can be operated by a single hardware button or from a wirelessly connected device via a simple web interface.
Resepi, equipped with Teledyne‘s CL-360HD lidar, offers various laser scan speeds and frequencies, allowing users to tweak the settings to match their individual needs.
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.
Military officials from across all branches, federal security personnel, and industry leaders are set to convene for the second installment of AUVSI Defense 2023 on September 14 at the United States Army General Gordon R Sullivan Conference and Event Center in Arlington, Virginia.
The forum encourages industry leaders and attendees to connect with decision-makers and program managers across various agencies — as well as accelerating the development, funding, and acquisition of critical uncrewed technologies.
AUVSI Defense is where military and industry can set the course for innovation to support critical missions. This specialized program equips the armed services and their partners with the information and relationships they need to meet constantly shifting threats around the globe.
This year, the event will focus on the role that autonomy and AI play in U.S. Defense uncrewed/unmanned systems scalability and technology development, and why this is essential to strategic competition.
Program highlights include:
Keynote by Brent Ingraham, Deputy Assistant, Secretary of Defense Platform and Weapons Portfolio Management, OUSD
Keynote by Dr. Matt Turek, Deputy Director I2O, DARPA
Panel Discussion – Autonomy and AI Intelligent Systems Development and Integration for Strategic Advancement of Military Uncrewed Systems.
Moderated by: Dr. Jaret Riddick – Senior Fellow, Center for Security and Emerging Technology, Georgetown University
Panelists including: CAPT Daniel Malatesta, Program Manager PMS 408, U.S. Navy; Dr. Randy Yamada, Vice President Digital Battlespace Autonomy, Booze Allen Hamilton; and Dr. Jordan Fletcher, Chief Engineer, Army Platforms, MITRE.
For more information and registration, visit the AUVSI Defense website.
Image: Safran Federal Systems (formerly Orolia Defense & Security)
As the number of constellations, satellites, and signals has grown in recent years — especially in the past few years, with the completion of the BeiDou and Galileo constellations — simulator manufacturers have been challenged to keep up. Threats of jamming and spoofing also increased. Then, a few companies began to develop new positioning, navigation and timing (PNT) constellations in low-Earth orbit (LEO).
Due to the limited space available in print, I was able to use only used a small portion of the interviews I conducted for our August cover story. For full transcripts of them see below:
Full interview with Tim Erbes, Technical Director, Safran Federal Systems (formerly Orolia Defense & Security).
Full interview with JulianThomas, Managing Director, Racelogic.
Full interview with Jürgen Pielmeier, Managing Director, IFEN.
Full interview with Mark Holbrow, VP of Product Development, Spirent Communications and Roger Hart, Sr. Director of Engineering, Spirent Federal Systems.
REIGL and StriekAir engineering GmbH have successfully completed the integration of an airborne scanning system, the RIEGL VUX-12023, on the StriekAir VTOL CarryAir UAV from Germany. During its inaugural flight, the integrated technology successfully captured accurate data of the ground structure.
The RIEGL VUX-12023 laser scanner is recognized for its precision and accuracy in aerial surveys. When integrated with the VTOL CarryAir, the UAV can reach a cruising speed of 85 km/h and offers users a combination of point cloud density and efficient data acquisition.
With the integration, users can acquire data about eight times faster than with conventional multicopters, according to REIGL. This time-saving feature aims to provide users with enhanced efficiency and data accuracy.
Matthias Hutecek (RIEGL) and Thomas Strieker (StriekAir engineering GmbH). (Image: REIGL)
The UAV can be utilized in a variety of applications — including surveying construction sites and infrastructure projects, mapping corridors, collecting topographic data for urban planning and environmental studies and more.
The RIEGL VUX-12023 offers smooth integration on UAS/UAV/RPAS, small manned airplanes and helicopters. It is offered as a stand-alone UAV lidar sensor and also in various fully integrated UAV-based laser scanning system with appropriate INS/GNSS system and optional cameras based on users’ needs.
Many have heard about efforts by Amazon to use UAVs for home delivery of orders within hours. Unfortunately, Amazon’s UAV trials have yet to be transitioned to “production” across the United States. Its website states that UAV deliveries are only available in College Station, Texas, and Lockeford, California.
Walmart is also in a trial phase of getting its rapid UAV delivery system working; however, its same-day UAV delivery is only servicing customers in the Tampa, Orlando, Phoenix, and Dallas areas. Nevertheless, there are many other automated deliveries underway around the world for meals and product deliveries, especially in Asia.
One segment where UAV deliveries appear to have been successful for medical samples and medications, which are now being shipped regularly on time-sensitive routes by UAVs (and, of course, several trial deliveries of these items are still underway).
The EMED transport/courier service used extensively by the UK National Health Service took part in one of the most recent medical shipment trials — which recently wrapped up in UK — with more than 400 pathology samples being rapidly shipped by fixed-wing UAVs between two hospital sites.
Loading a UAV in a UK medical trial. (Image: ESA)
The UAV used in the EMED trial was a tried and tested Swoop Aero Kookaburra III fixed-wing aircraft with a 3kg payload that flies at 330 ft in segregated airspace.
In the United States, OhioHealth aims to use a proven medical delivery system supplied by Zipline. Its plans for delivery UAVs include rapid shipments between Ohio medical facilities and prescription delivery to patients. By 2025, OhioHealth predicts that more than two million people in the Columbus area could be served by the Zipline delivery system.
OhioHealth plans to use Zipline’s Platform 2 delivery UAV — a fixed-wing carrier UAV with vertical take-off and landing (VTOL) capabilities able to autonomously hover and accurately lower a package-carrying “droid” into a tight delivery spot. The previous Zipline Platform 1 system drops packages by parachute, which requires a substantial area to receive deliveries. The “droid” has three directional fans that allow it to maneuver at the end of the tether to within six feet of the planned delivery point.
Over the last six years, Zipline has built up a whole fleet of Platform 1 aircraft and the complete infrastructure for its medical delivery operation in Rwanda.
In Rwanda, there was a need for different delivery methods to get medical supplies to hospitals, as communities are spread over large distances. Before bringing such a service to the United States, Zipline aimed to get a delivery service running, get experience, and de-bug and prove the system’s capabilities. Six years and half a million deliveries later, Zipline is now ready. For civil certification, the Federal Aviation Administration previously liked to see lots of evidence of established operational activity. Therefore, Zipline was fortunate to have six years of proven delivery activity in Rwanda when they looked to start up in the United States.
Platform 2 ‘droid’ containing a package is lowered on a tether from a hovering carrier drone. (Image: Zipline)
Zipline has also done everything needed to ensure the delivery process in Rwanda is as efficient as possible — from the order processing system, through packaging and loading into the UAV, a catapult launch system that accelerates the aircraft to climb-out speed, battery charging and exchange for each flight, autonomous navigation to the delivery point, parachute delivery at destination, autonomous return to base, and an automated capture system on arrival. As a result, it’s not unusual if a delivery can be dispatched within 90 seconds from receipt of an order.
The distances are large in Rwanda between where people are sick and where they can get help, and the necessary supplies may well be located elsewhere — at times, as much as 150 miles away. However, since Zipline deliveries became common, in-hospital maternal mortality rates have been reduced by 88% — quite an achievement. Each delivery that is dispatched really has the potential to save a life.
Now, Zipline has the potential to improve turn-round times for the health system in the United States. The company is ready to prove that the Platform 2 system makes very little noise because of specially designed propellers, that precise deliveries are possible, and it is even ready to take on regular parcel deliveries without being limited to only medical shipments.
Hopefully, some of the big retail organizations will be willing to watch, listen, trial and eventually bring the proven Zipline delivery system into their operations. There is much work to do to bring about regular UAV deliveries, but with a proven track record in Rwanda, the odds favor a successful outcome in the United States.
