Galileo OSNMA and Galileo HAS are changing how an embedded system can use satellite navigation. The job is no longer limited to calculating coordinates: a compatible receiver can verify the authenticity of Galileo navigation messages, use high-accuracy corrections, and contribute to a more resilient PNT architecture for drones, robots, vehicles, industrial systems and distributed infrastructure.
When people casually say “GPS”, they often mean a multi-constellation GNSS receiver. GPS is the United States system, while Galileo is the European Union's Global Navigation Satellite System. Modern receivers normally combine these and other global or regional constellations to improve availability and solution quality.
Galileo gives Europe its own infrastructure for Positioning, Navigation and Timing (PNT). Its value is not just the existence of a European constellation: services such as OSNMA and HAS add authentication and high-accuracy functions that can be designed into real embedded products.
For an introduction to constellations, NMEA messages, electronic modules and positioning techniques, see our guide to GPS and GNSS in embedded systems. This article focuses on Galileo OSNMA, Galileo HAS, development boards, Linux, SDR and the design of resilient PNT systems.
Key points
- Galileo is the European Union's GNSS and provides positioning, navigation and timing services.
- OSNMA lets a compatible receiver verify the authenticity of Galileo navigation messages.
- OSNMA does not prevent jamming and does not automatically authenticate the entire position solution.
- Galileo HAS distributes free global PPP corrections by satellite and over the Internet, targeting decimetre-level performance.
- Development boards, Linux platforms, IMUs and SDRs make it possible to validate a PNT system before designing the final board.
From GPS to European PNT
Satellite navigation is often reduced to a dot on a map. GNSS systems actually provide three different resources: position, navigation and time. Position tells us where the receiver is; navigation also covers speed, heading and trajectory changes; a time reference synchronises equipment in different places. Together, these capabilities are known as PNT: Positioning, Navigation and Timing.
PNT is used by smartphones and vehicle navigation, but also by telecommunications, power networks, financial systems, agricultural machinery, drones, mobile robots, maritime transport, logistics and distributed industrial acquisition.
That dependency makes a European infrastructure strategically important. When a network, vehicle or automated system relies on position and time, GNSS is no longer an accessory: it is part of the operating architecture.
European autonomy does not mean configuring every receiver to use Galileo alone. A multi-GNSS device can combine Galileo, GPS and other constellations, increasing the number of visible satellites and improving solution geometry. Galileo's value is the availability of a complete European infrastructure on which specific European services can be built, without depending entirely on systems controlled by other states.
The problem is not only knowing where we are
A conventional GNSS receiver acquires satellite signals, decodes navigation messages and uses them to calculate position, velocity and time. In many applications the module simply returns coordinates and firmware passes them to an application, server or control system.
That design assumes the received data are trustworthy. GNSS signals can be degraded by obstructions, buildings, vegetation, reflections, electronic noise and interference from other radio sources. Jamming introduces interference that reduces or prevents reception; spoofing uses false or manipulated signals to make the receiver calculate the wrong position or time reference.
The consequences depend on the application. A mapping error may only be inconvenient; the same error on a drone, robot, synchronisation system or autonomous vehicle can change the behaviour of the whole system. The engineering question becomes: the device knows its position, but how can it assess whether the information it is using is trustworthy?
Galileo OSNMA: authenticating the navigation message
Galileo Open Service Navigation Message Authentication (OSNMA) is a free feature of the Galileo Open Service.
The initial OSNMA service was declared operational on 24 July 2025. In July 2026, one year after activation, EUSPA documented its progressive integration into professional receivers for timing, transport, maritime applications and connected devices.
OSNMA enables a compatible receiver to verify that a received navigation message genuinely comes from the Galileo system and has not been modified. Authentication information is carried in dedicated fields of the Galileo I/NAV message on the E1-B component. The receiver must extract that data, run the prescribed cryptographic functions and verify the authentication chain.
The protocol is based on TESLA (Timed Efficient Stream Loss-Tolerant Authentication). It uses authentication codes and delayed disclosure of the keys needed to verify them. The receiver stores messages and their cryptographic tags; when the relevant key becomes available, it can authenticate the previously received data. This deliberate delay explains why a position solution and authenticated navigation data are not necessarily available at the same instant.
What Galileo OSNMA changes in firmware
Adding OSNMA is not simply a matter of reading an extra flag from a GNSS module. A compatible receiver must extract OSNMA information from the Galileo message, perform the relevant cryptographic operations, start with sufficiently reliable Galileo System Time knowledge and preserve the integrity of the verification material.
Initial material includes items such as the Merkle-tree root and certified public keys. The product lifecycle must also allow that material to be updated or renewed through the service mechanisms. The requirement crosses several parts of the product:
GNSS receiver → key management → time reference → firmware → diagnostics → application logic
Firmware should distinguish several operating states. A position can be available while authentication is still in progress. In other cases the receiver can report failed authentication, incomplete information or inadequate radio quality.
Possible states in an embedded system using Galileo OSNMA
| State | Meaning | Possible behaviour |
|---|---|---|
| No PVT solution | The receiver does not yet have enough information to calculate position, velocity and time. | Wait, use other sensors or enter a degraded mode. |
| PVT available, authentication in progress | A position is available, but Galileo data have not reached the required authentication state. | Use it for non-critical functions or wait for verification. |
| Authenticated navigation data | The receiver has verified the Galileo data covered by the service. | Use according to the product's normal operating policy. |
| Authentication failed | Verification did not complete or an inconsistent condition was detected. | Log the event, raise an alarm, exclude the affected data or switch to a safe mode. |
| Degraded or interfered GNSS | Radio quality, continuity or solution consistency is insufficient. | Use sensor fusion or dead reckoning, reduce functionality or perform a controlled stop. |
The right response is driven by application risk. A logistics tracker may continue recording position with a reduced-confidence indicator. An industrial robot, autonomous vehicle or drone may need to limit certain functions or temporarily rely on other sensors.
A professional product should therefore log more than latitude and longitude: OSNMA state, estimated accuracy, constellations in use, signal quality, interference indicators and the reason for any transition to a degraded mode are all valuable diagnostic data.
OSNMA authenticates data, not automatically the position
Precise terminology matters. OSNMA provides data authentication: it authenticates specific information in the Galileo navigation message. It does not directly authenticate every satellite-range measurement, and it does not automatically certify the complete PVT solution computed by the receiver.
It is therefore accurate to say “a solution calculated using authenticated navigation data”, not “a certainly authentic, spoofing-proof position”.
OSNMA improves the system's ability to recognise unauthenticated data and makes a credible attack more difficult, but it does not prevent jamming or eliminate every form of spoofing. EUSPA also envisages further developments, including the Galileo Signal Authentication Service, intended to add authentication at the ranging-signal level and complement OSNMA's protection.
OSNMA should therefore be treated as an important component of a resilient PNT strategy, not as an isolated solution to every GNSS anomaly.
From an authenticated receiver to resilient PNT
A resilient embedded system can combine several information layers to assess navigation consistency. A multi-constellation receiver increases the satellites that can be used; multi-band reception can reduce some errors and improve behaviour in multipath conditions; OSNMA adds authentication of Galileo messages; receiver indicators can report noise, interference or anomalous changes.
Independent sensors can be added to that picture:
GNSS → IMU → magnetometer → barometer → odometry → vision → fusion and integrity logic
Consider a drone whose GNSS position is incompatible with its acceleration, attitude and barometric altitude. No individual sensor automatically proves spoofing, but the divergence among independent sources can create an anomaly indicator. A ground robot can compare GNSS trajectory with encoders and odometry; a vehicle can use wheel data, heading, maps and inertial sensors; a static system can monitor impossible shifts in position or time.
Sensor fusion does more than improve accuracy. It can let the system keep operating during a brief GNSS outage. This temporary operation is often called dead reckoning, and its effectiveness depends on sensor quality and calibration, the duration of the GNSS loss and vehicle dynamics.
Galileo HAS: European high-accuracy positioning
Galileo adds more than authentication services. The Galileo High Accuracy Service (HAS) is free and globally available for applications requiring better performance than the normal Open Service.
HAS uses PPP (Precise Point Positioning). It distributes precise orbit, satellite-clock and bias information needed to improve the receiver's solution. Corrections can be received directly through the Galileo E6-B signal or over the Internet through Galileo Service Centre services.
EUSPA describes HAS as capable of decimetre-level performance. Generic Galileo support on a module is not enough: the receiver, firmware and complete RF chain must be compatible with the delivery method in use.
Galileo HAS and RTK are not the same technology
HAS is sometimes presented as a direct replacement for RTK, but the two approaches have different characteristics. RTK uses corrections from a local base or a reference-station network, usually via RTCM. It can achieve centimetre-level accuracy and very short convergence times, but it requires corrections to be available and a channel to distribute them.
PPP instead uses precise corrections that apply over much wider areas. It does not necessarily require a local base, but it may need more time to converge before reaching the expected accuracy.
Comparison of standalone GNSS, RTK and Galileo HAS
| Technology | Corrections | Main characteristic |
|---|---|---|
| Standalone GNSS | No external high-accuracy corrections | Simple architecture; accuracy depends on receiver, signals and environment. |
| RTK | Local base or reference network, normally via RTCM | Centimetre accuracy and fast convergence when infrastructure and connectivity are available. |
| PPP | Precise global corrections | Does not necessarily need a local base, but has different convergence dynamics. |
| Galileo HAS | Free PPP corrections via E6-B or Internet | Global coverage and decimetre-level performance without a local RTK-base dependency. |
The choice follows the application. A robot that must immediately follow a centimetre-accurate path may need RTK. A device in a remote area with no local correction network may benefit from global PPP. Hybrid architectures are also possible.
2026 tests show the potential of Galileo HAS
In 2026, EUSPA published results from a Galileo HAS precision-agriculture trial. In the specific conditions of that campaign, the test recorded a 95% horizontal error of about 5.9 cm and a 95% vertical error of about 12.4 cm, below the service targets of 20 cm horizontally and 40 cm vertically.
Those values must not be read as guaranteed accuracy in every environment. Buildings, vegetation, multipath, satellite geometry, antenna design, receiver quality, vehicle dynamics and convergence time can materially change performance. The key point is that a free European high-accuracy correction service is becoming usable on commercial receivers and in real applications.
Industrial timing: reading NMEA time is not enough
A GNSS receiver is not only for finding a position. Satellites distribute extremely precise time references, and a receiver can use them to discipline its local clock. Telecommunications, power networks, financial systems, data loggers, industrial gateways and distributed acquisition platforms can depend on a shared time reference.
In a professional application, reading date and time from an NMEA sentence is not enough. Important factors include the time-pulse or 1PPS output, offset from the reference time scale, jitter, local-oscillator stability and holdover behaviour during a temporary GNSS outage.
Holdover is the ability to continue supplying a local time reference when satellite reception is lost. Its uncertainty grows over time according to the oscillator and environmental conditions. Software should therefore distinguish at least:
time acquired → valid synchronisation → authenticated source → degraded GNSS → holdover
Dedicated products such as the u-blox ZED-F9T and EVK-F9T make it possible to explore multi-band GNSS, OSNMA and 1PPS through a timing-oriented kit. Timing is consequently a system problem involving receiver, antenna, oscillator, power supply, firmware, signal distribution and diagnostics.
Experimenting with Galileo on commercial development boards
It is not necessary to design a custom RF board before starting work with Galileo. Development boards allow the receiver to be evaluated, data to be logged, antennas to be compared and firmware behaviour to be developed before committing to the final PCB.
The choice must start from the test objective. An inexpensive dual-band GNSS board may be enough to study acquisition, NMEA, PPS, power consumption and microcontroller integration. That does not mean it supports OSNMA, HAS, RTK or advanced interference indicators. Likewise, seeing “Galileo” in a datasheet does not automatically imply support for all Galileo services.
Examples of platforms for a Galileo and GNSS lab
| Platform | Primary use | Engineering note |
|---|---|---|
| ST X-NUCLEO-LIV4A1 | Introduction to dual-band GNSS, NMEA, PPS and STM32 Nucleo integration. | Useful for basic GNSS development; do not assume it is an OSNMA or HAS platform. |
| u-blox EVK-X20P | All-band GNSS, RTK, raw measurements, OSNMA, logging and high-accuracy evaluation. | Available features depend on the module variant and installed firmware. |
| u-blox ZED-X20P-01B | Galileo HAS, global PPP, RTK and high-accuracy positioning. | The 01B variant, announced in 2026, explicitly adds Galileo HAS support. |
| Septentrio mosaic-go X5 | Professional RTK, OSNMA, interference analysis and integration with robotics or autonomous systems. | Includes AIM+ tools and a web interface for monitoring reception and RF spectrum. |
| u-blox EVK-F9T | GNSS timing, 1PPS, synchronisation and OSNMA. | Suitable when time, rather than dynamic positioning, is the principal requirement. |
| SDR with GNSS-SDR | Study of acquisition, tracking, Galileo messages and OSNMA in software. | A research and lab tool, not necessarily the final product receiver. |
Verify support on the exact variant
One of the most important checks is the exact hardware variant and firmware version in use. A commercial family can contain modules with different capabilities. Even where package and main product name look similar, OSNMA support, received bands, HAS, RTK, timing and security features can change.
For example, OSNMA is available on the u-blox ZED-X20P platform, while Galileo HAS support must be verified on the specific variant. The ZED-X20P-01B was introduced in 2026 specifically with HAS and global PPP.
The product name alone is not sufficient. Before purchase or integration, verify:
part number → hardware revision → firmware version → bands → Galileo services → interfaces → antenna requirement
This avoids building a proof of concept around a board that cannot expose the functions required by the application.
A practical proof-of-concept architecture
A Galileo lab can be built progressively, without starting from a custom board. A first architecture can be:
multi-band antenna → GNSS development board → Linux platform → IMU → logging and dashboard
The receiver provides position, time, solution quality, OSNMA state and other available data. The IMU makes it possible to compare acceleration and rotation with GNSS-derived motion. The Linux platform collects data, records sessions and visualises system state in real time.
A later phase can add a cellular modem, LoRa link, local storage, battery power or application-specific sensors.
Progressive phases of a Galileo proof of concept
| Phase | Objective |
|---|---|
| Commercial receiver | Verify constellations, bands, position, accuracy, OSNMA and supported services. |
| Linux logging | Record GNSS and diagnostic data during static and dynamic tests. |
| Sensor fusion | Compare GNSS with IMU, odometry or other independent sensors. |
| High-accuracy tests | Compare standalone, RTK, PPP and Galileo HAS. |
| SDR analysis | Observe Galileo signals and messages with deeper access to the processing chain. |
| Dedicated PCB | Integrate module, antenna, power and firmware into the final hardware. |
Linux as a GNSS analysis platform
An embedded Linux computer can turn a GNSS development board into a portable lab. It can acquire position, satellite state, C/N0, estimated accuracy, OSNMA state, correction information, and data from an IMU or other sensors. During a road test, drone test or industrial-vehicle test, data can be stored locally for later analysis.
A dashboard can show:
constellations → satellites → bands → signal quality → position → OSNMA state → corrections → sensors
Linux also connects several interfaces at once: USB, UART, Ethernet, CAN, cellular modems, SDRs and measurement devices. Before final hardware design, this makes it easy to change configurations, compare receivers and create diagnostic tools that can be reused during product development.
Going deeper with software-defined radio
A commercial development board performs much of the GNSS processing chain internally and mainly returns messages, observables and processed results. With a software-defined radio (SDR), signal samples can be acquired and part of the processing moved onto a computer.
The open-source GNSS-SDR project implements a software-defined GNSS receiver and supports Galileo OSNMA. It lets a team study acquisition, tracking, navigation-message decoding, observables and authentication with access normally unavailable on a commercial module.
GNSS-SDR can use OSNMA in warning mode or configure a solution that accepts only authenticated data, depending on the source and configuration. That does not mean an SDR should replace the final receiver. A productive two-layer approach is:
commercial receiver for the product → SDR for analysis, research and validation
Record signals to make tests repeatable
Recording RF samples or the raw data produced by a receiver makes it possible to reproduce the same situation repeatedly. A field session can be analysed with different software versions or used to compare algorithms and configurations without immediately repeating the route.
Repeatability matters because satellite and radio conditions continually change. A data set can include:
IQ samples → observables → Galileo messages → PVT → OSNMA state → IMU → external reference
Tests that generate or retransmit GNSS signals over radio must be performed only in controlled, shielded environments. For normal development, prefer IQ files, cable-connected simulators or systems that cannot radiate signals capable of interfering with external receivers.
A good development board cannot fix poor RF design
Strong results from an evaluation board do not guarantee the final product will perform the same way. GNSS signals at ground level are extremely weak, so the antenna and RF path are decisive.
Evaluate antenna type, supported bands, ground plane, PCB position, enclosure, metal surfaces, cabling, filters, amplification and active-antenna power. The situation becomes more complex when LTE, 5G, Wi-Fi, Bluetooth, LoRa or other transmitters share the same device.
To use Galileo HAS by satellite, for example, the RF path must also support E6-B. A compatible receiver cannot use that band correctly if the antenna, filters or amplifiers do not pass it. Noise from switching converters, displays, processors and high-speed interfaces can also degrade reception.
Moving from a development board to the PCB therefore requires fresh validation with the real electronics, enclosure and intended mounting location.
A GNSS proof of concept is measured, not judged from a dot on a map
An apparently correct position is not enough to validate a receiver or PNT architecture. A professional trial must produce comparable data under the conditions in which the product will really operate. Tests can be static and dynamic and, when relevant, should include open areas, partially obstructed areas, buildings, vegetation, metal structures, motion, vibration and the radios present on the device.
Useful metrics when validating a Galileo and GNSS system
| Metric | What it evaluates |
|---|---|
| Time To First Fix | Time to obtain the first solution after cold start, warm start and restart. |
| Time To First Authenticated Fix | Time to obtain authenticated data required by the application policy. |
| PVT availability | Percentage of the test during which position, velocity and time remain available. |
| 50% and 95% error | Actual error distribution relative to a reference position or trajectory. |
| OSNMA state | Availability, continuity and any authentication failures. |
| C/N0 and satellites used | Reception quality and differences between environment, antenna and configuration. |
| DOP and satellite geometry | How satellite distribution affects solution uncertainty. |
| RTK fix ratio | Time spent in fixed, float or standalone solution states. |
| Correction age | Effect of the network and channel used to distribute RTCM, PPP or other data. |
| HAS or PPP convergence | Time to reach and maintain the required accuracy. |
| Interference indicators | RF noise, jamming, antenna degradation or anomalous conditions. |
| 1PPS offset and jitter | Synchronisation quality in timing applications. |
| Power consumption | Whether the GNSS configuration fits the product's power and battery budget. |
The outcome should be more than a visual demonstration. A useful proof of concept produces a report that compares receivers, antennas, configurations, firmware and operating conditions, making margins and limits visible before the final board is designed.
Which applications are realistic?
Galileo OSNMA, HAS and resilient-PNT techniques can be used in many sectors, but each application needs its own architecture.
In a drone, OSNMA can contribute to the assessment of Galileo-data trustworthiness, while IMU, barometer, magnetometer and vision systems compare real motion with GNSS-derived motion. In an outdoor mobile robot, RTK or HAS can be combined with odometry, encoders and visual localisation, while application logic handles transitions between open areas and satellite-obstructed areas.
In precision agriculture, RTK and Galileo HAS can be evaluated for assisted guidance, georeferencing, task automation and reduced overlap. In an industrial tracker, position and authentication state can be associated with timestamps, events, sensors and connectivity data, with only necessary information sent through LTE, LoRaWAN or other networks.
For timing, the device can be completely static: the receiver disciplines the local clock and synchronises distributed systems. In maritime applications, multi-band GNSS, OSNMA and interference indicators can contribute to a more observable navigation chain alongside the sensors and systems already on board.
What a development-board test does not prove
A successful development-board test does not automatically prove that the final product is spoofing-proof, works through every interference event or keeps centimetre accuracy in every environment. Bench results can change when the module is placed on a PCB beside other radios, put in an enclosure, mounted near metal structures or powered by a noisy converter.
OSNMA does not replace RF design, sensor fusion, integrity monitoring or an application policy for degraded conditions. Likewise, a HAS test in open field does not guarantee the same results near buildings, trees or obstacles. A proof of concept verifies feasibility and identifies limits; final-product validation must be repeated on the real hardware and installation.
Europe's future: Galileo and the Celeste LEO-PNT constellation
European PNT development will not stop with the operational Galileo constellation. On 28 March 2026, the European Space Agency launched the first two satellites of the Celeste LEO-PNT demonstration mission. In April 2026, Celeste broadcast the first European navigation signal from low Earth orbit.
The demonstrator is planned to include eleven satellites and will study new signals, bands and services designed to work with Galileo, EGNOS and other GNSS. Galileo satellites operate in medium Earth orbit; Celeste explores a complementary layer in low Earth orbit, closer to the surface.
The objective is not to replace Galileo, but to assess whether a new constellation can improve robustness, availability and performance through a multi-layer architecture. For embedded-system designers, the lesson is clear: the PNT subsystem should be modular and should not depend rigidly on a single source.
Galileo, EGNOS, future LEO signals, IMUs, odometry, vision and terrestrial radio technologies can all contribute to systems that assess position and time using different, complementary information.
How to evaluate a Galileo proof of concept
A GNSS project should not start by choosing the module with the largest number of constellations or the best datasheet accuracy. Start by defining the real requirements:
accuracy → availability → update rate → authentication → timing → dynamics → environment → power consumption → degraded behaviour
Then select a development board compatible with the functions to validate. Test in representative conditions: antenna placement, buildings or vegetation, motion, speed, other radios, power supply and possible noise sources. For safety-oriented systems, define the response when PNT quality drops: the product may continue with other sensors, restrict some operations, raise an alarm or stop functions for which a trusted position is essential.
Only after this phase does it make sense to define the final architecture, select the module, design the RF path and integrate the receiver on the PCB.
How Silicon Logix can help
Silicon Logix develops and prototypes systems that combine embedded firmware, microcontrollers, embedded Linux, sensors, communications and hardware interfaces.
A Galileo or GNSS project can begin with commercial development boards to quickly validate feasibility before investing in final hardware design. The proof of concept can include a multi-band receiver and antenna, Galileo OSNMA, RTK or HAS, a Linux platform, IMU, data acquisition and visualisation tools.
Tests can compare different configurations and measure accuracy, continuity, acquisition time, authentication state, reception quality and system behaviour in degraded conditions. For research and characterisation, an SDR platform can complement the commercial receiver and provide deeper access to Galileo signals and messages.
The output is not only a demonstration: it can be a technical report with a recommended architecture, measured metrics, identified limits, components to integrate and a path to the final PCB. If testing confirms feasibility, the prototype can evolve into a custom board with GNSS module, antenna, power supply, firmware, diagnostics, connectivity and sensor-fusion logic.
Frequently asked questions about Galileo OSNMA and HAS
Can Galileo work without GPS?
Yes. Galileo is an autonomous global GNSS. Commercial receivers often use it together with GPS and other constellations to improve availability, satellite count and geometry.
Does OSNMA completely prevent spoofing?
No. OSNMA authenticates specific Galileo navigation-message data and helps identify unauthenticated information. It does not prevent jamming and does not directly authenticate every range measurement used to calculate position.
Does every Galileo receiver support OSNMA?
No. The receiver must implement the required OSNMA functions. Support must be checked on the exact hardware variant and firmware version being used.
Does Galileo HAS replace RTK?
No. HAS uses PPP and distributes global corrections through E6-B and the Internet. RTK uses a base station or reference network, with different infrastructure, convergence and accuracy characteristics.
Can OSNMA be tested with a development board?
Yes, provided the board includes a receiver and firmware explicitly compatible with OSNMA. Receiving the Galileo constellation alone does not guarantee service support.
Is an Internet connection required for Galileo HAS?
Not necessarily. HAS corrections can arrive over the Internet or directly from the Galileo E6-B signal. Satellite reception requires a receiver and RF path compatible with the E6 band.
Can a GNSS receiver be used only for time synchronisation?
Yes. Timing-oriented receivers can provide 1PPS outputs and time information to synchronise networks, gateways, data-acquisition systems and distributed infrastructure.
Conclusion
Galileo is much more than a European alternative to GPS. A European GNSS infrastructure makes independent position, navigation and time services possible. OSNMA adds Galileo navigation-message authentication; HAS distributes free global PPP corrections with decimetre-level performance; timing services make Galileo valuable even for systems that do not move.
Development boards, commercial receivers, Linux platforms and SDRs make those technologies accessible to companies, developers and laboratories that want to validate them before designing custom hardware. But the value does not come from simply adding a GNSS module.
A professional system integrates receiver, antenna, firmware, diagnostics, sensor fusion and a clear policy for degraded conditions. The question is no longer only “Which GPS module can we add to the product?” It is “How can we build a system that knows where it is, how accurate that position is, and how far it can trust the information it uses?”
That is the level at which Galileo OSNMA, HAS, Linux, SDR and embedded firmware become components of a new generation of European PNT systems.
Technical references
[1] European GNSS Service Centre, Galileo Open Service Navigation Message Authentication – OSNMA: official service description, architecture and receiver requirements.
[2] European Union Agency for the Space Programme, Celebrating one year of Galileo OSNMA: a milestone for trusted positioning, 27 July 2026.
[3] European Union Agency for the Space Programme, Galileo to be the first GNSS to offer authentication service worldwide with launch of OSNMA, July 2025.
[4] European GNSS Service Centre, Galileo Services: operational and developing services.
[5] European Union Agency for the Space Programme, Galileo High Accuracy Service: description of the global PPP service.
[6] European GNSS Service Centre, Galileo High Accuracy Service – HAS: corrections, E6-B distribution and Internet access.
[7] European Union Agency for the Space Programme, Galileo HAS ready to increase efficiency of farming tasks: results of the 2026 test campaign.
[8] u-blox, ZED-X20P all-band high-precision GNSS module.
[9] u-blox, EVK-X20P evaluation kit.
[10] u-blox, ZED-X20P-01B with Galileo HAS and global PPP, 28 April 2026.
[11] u-blox, ZED-F9T high-accuracy timing module.
[12] Septentrio, mosaic-go X5 evaluation kit.
[13] STMicroelectronics, X-NUCLEO-LIV4A1: dual-band GNSS development board for STM32 Nucleo.
[14] GNSS-SDR, Introducing GNSS Navigation Message Authentication: Galileo OSNMA in a software-defined receiver.
[15] European Space Agency, Celeste LEO-PNT: European demonstrator for a complementary low-Earth-orbit navigation layer.
[16] European Space Agency, Celeste broadcasts first navigation signal from low Earth orbit, April 2026.
Would you like to integrate Galileo, OSNMA or GNSS features into your firmware?
Silicon Logix can support proofs of concept and embedded applications based on GNSS receivers and commercial development boards, focusing on the integration of module, firmware and software.
The project can include GNSS-data acquisition and management, receiver-message integration, OSNMA-state monitoring, logging, diagnostics, handling of fix-loss conditions, and Linux tools to visualise and analyse collected information.
An initial phase can use commercial hardware to validate the software architecture and define product requirements more confidently before any dedicated hardware development.
Let's discuss your GNSS project
Canonical source: Galileo OSNMA and HAS: Europe's GNSS for embedded systems.
Top comments (0)