A software-based GNSS receiver is now available on Tensilica ConnX DSP IP cores, according to an announcement by Cadence Design Systems and Galileo Satellite Navigation, Ltd. (GSN), a developer of multi-system GNSS products including software receiver technology. The core is being demonstrated at the Cadence booth at Mobile World Congress, being held this week in Barcelona, Spain.
The GSN GNSS receiver running on a Cadence ConnX BBE16 DSP consumes very little power — as low as 10mW of power on a 40nm process — and has the ability to work in lower rates, or snapshots for ultra-low-power mobile scenarios. The solution delivers high-sensitivity tracking, offering a seamless GNSS experience in challenging environments, the companies said.
“GSN’s software-based approach for satellite receivers perfectly complements Cadence DSPs, taking maximum advantage of the flexibility of our DSP architecture,” said Jack Guedj, corporate vice president of Research and Development at Cadence. “The availability of GSN’s software on our ConnX BBE16 further reinforces the strength of our low-power programmable modem strategy for advanced communications.”
“The Tensilica ConnX BBE16 DSP delivers outstanding performance for implementing our GNSS receivers and with a low-power footprint. This provides customers with the ability to easily upgrade their designs to include future satellite systems including Beidou, GLONASS, and Galileo via software,” said Eli Ariel, CEO at GSN. “With no additional silicon costs and at a low cost of deployment, this software-based solution results in a very compelling approach to implement satellite navigation functionality in many products where it otherwise might be impractical.”
The implementation changes and first live tests of BeiDou and Galileo on Teseo-3 GNSS chips developed in 2013 are covered, bringing it to a four-constellation machine. By 2020, we expect to have four global constellations all on the same band, giving us more than 100 satellites — under clear sky, as many as 30 or 40 simultaneously.
By Philip G. Mattos and Fabio Pisoni
Multi-constellation GNSS first became widely available in 2010/2011, but only as two constellations, GPS+GLONASS. Although receivers at that time may have supported Galileo, there were no usable satellites. BeiDou was a name only, as without a spec (an interface control document, or ICD), no receivers could be built. However, the hardware development time of receivers had been effectively shortened: the Galileo ICD had been available for years, BeiDou codes had been reverse-engineered by Grace Gao and colleagues at Stanford, and at the end of 2011 they were confirmed by the so-called test ICD, which allowed signal testing without yet releasing message characteristics or content.
The last weeks of 2012 saw two great leaps forward for GNSS. Galileo IOV3 and 4 started transmitting at the beginning of December, bringing the constellation to four and making positioning possible for about two hours a day. At the end of December, the Chinese issued the BeiDou ICD, allowing the final steps of message decode and ephemeris calculation to be added to systems that had been tracking BeiDou for many months, and thus supporting positioning. The Teseo-2 receiver from STMicroelectronics has been available for some years, so apart from software development, it was just waiting for Galileo satellites; however, for BeiDou it needed hardware support in the form of an additional RF front end. Additionally, while it could support all four constellations, it could not support BeiDou and GPS/Galileo at the same time, as without the BeiDou ICD the spreading codes had to be software-generated and used from a memory-based code generator, thus blocking the GPS/Galileo part of the machine.
The Teseo-3 receiver appeared late in 2013, returning to the optimum single-chip form factor: RF integrated with digital silicon and flash memory in the same package, enabling simultaneous use of BeiDou and GPS/Galileo signals. Multi-constellation in 2012 was GPS+GLONASS, which brought huge benefits in urban canyons with up to 20 visible satellites in an open sky. Now, for two hours a day in Europe while the Galileo IOVs are visible, we can run three constellations, and in the China region, GPS/BeiDou/Galileo is the preferred choice.
This article covers the first tracking of four Galileo satellites on December 4, 2012, first positioning with Galileo, and first positioning with BeiDou in January 2013. It will cover static and road tests of each constellation individually and together as a single positioning solution. Road tests in the United States/Europe will combine GPS/GLONASS/Galileo, while tests in the China region will combine GPS/Galileo/BeiDou. Results will be discussed from a technical point of view, while the market future of multi-constellation hardware will also be considered.
In the 2010–2020 timeframe, GLONASS and BeiDou (1602 MHz FDMA and 1561 MHz respectively) cost extra silicon in both RF and digital hardware, and cause marginal extra jamming vulnerability due to the 50 MHz bandwidth of the front end. The extra silicon also causes extra power consumption.
After 2020, GLONASS is expected to have the L1OC signal operational, CDMA on the GPS/Galileo frequency, and BeiDou is expected both to have expanded worldwide, and also to have the B3 signal fully operational, again on 1575 MHz. At that point we will have four global constellations all on the same band, giving us more than 100 satellites. With a clear sky, the user might expect to see more than 30, sometimes 40, satellites simultaneously.
Besides the performance benefits in terms of urban canyon availability and accuracy, this allows the receiver to be greatly simplified. While code generators will require great flexibility to generate any of the code families at will, the actual signal path will be greatly simplified: just one path in both RF (analog) and baseband (digital) processing, including all the notch filters, derotation, and so on. And this will greatly reduce the power consumption.
Will the market want to take the benefit in power consumption and silicon area, or will it prefer to reuse those resources by becoming dual-frequency, adding also the lower-L-band signals, initially L5/E5, but possibly also L2/L3/L6 ? The current view is that the consumer receiver will go no further than L5/E5, but that the hooks will be built-in to allow the same silicon to be used in professional receivers also, or in L2C implementations to take advantage of the earlier availability of a full constellation of GPS-L2C rather than GPS-L5.
This article presents both technical results of field trials of the quad-constellation receiver, and also the forward looking view of how receivers will grow through multi-frequency and shrink through the growing signal commonalities over this decade.
History
Galileo was put into the ST GPS/GNSS receiver hardware from 2006 to 2008, with a new RF and an FPGA-based baseband under the EU-funded GR-PosTer project. While a production baseband (Cartesio-plus) followed in high volume from 2009, in real life it was still plain GPS due to the absence of Galileo satellites.
The changed characteristics in Galileo that drove hardware upgrades are shown in Figure 1. The binary offset carrier BOC(1,1) modulation stretches the bandwidth, affecting the RF, while both the BOC and the memory codes affect the baseband silicon in the code-generator area.
Figure 1. Changes for Galileo.
Next was the return to strength of the GLONASS constellation, meaning receivers were actually needed before Galileo. However the different center frequency (1602 MHz), and the multi-channel nature of the FDMA meant more major changes to the hardware. As shown in Figure 2 in orange, a second mixer was added, with second IF path and A/D converter.
Figure 2. Teseo-2 RF hardware changes for GLONASS.Figure 3. Teseo-2 and Teseo-3 baseband changes for GLONASS.
The baseband changes added a second pre-processing chain and configured all the acquisition channels and tracking channels to flexibly select either input chain. Less visible, the code-generators were modified to support 511 chip codes and 511kchips/sec rates.
Teseo-2 appeared with GPS/GLONASS support in 2010, and demonstrated the benefit of GNSS in urban canyons, as shown by the dilution of precision (DOP) plot for central London in Figure 4. The GPS-only receiver (in red) has frequent DOP excursions beyond limits, resulting either in bad accuracy or even interrupted fix availability. In contrast, the GNSS version (in blue) has a DOP generally below 1, with a single maximum of 1.4, and thus 100 percent availability. Tracking 16 satellites, even if many are via non-line-of-sight (NLOS) reflected paths, allows sophisticated elimination of distorted measurements but still continuous, and hence accurate, positioning.
Figure 4. DOP/accuracy benefits of GNSS.
BeiDou
Like Galileo, BeiDou is a story of chapters. Chapter 1 was no ICD, and running on a demo dual-RF architecture as per the schematic shown in Figure 5. Chapter 2 was the same hardware with the test ICD, so all satellites, but still no positioning. Chapter 3 was the full ICD giving positioning in January 2013 (Figure 6), then running on the real Teseo-3 silicon in September 2013, shown in Figure 7.
Figure 5. Demo Teseo-2 dual RF implementation of BeiDou.Figure 6. Beidou positioning results.Figure 7. Teseo 3 development board.
The Teseo-3 has an on-chip RF section capable of GPS, Galileo, GLONASS and BeiDou, so no external RF is needed.
The clear green space around the Teseo-3 chip in the photo and the four mounting holes are for the bolt-down socket used to hold chips during testing, while the chip shown is soldered directly to the board. Figure 8A shows the development board tracking eight BeiDou satellites visible from Taiwan.
However, the silicon is not designed to be single-constellation; it is designed to use all the satellites in the sky. Figure 8b shows another test using GPS and BeiDou satellites simultaneously.
Figure 8A. Beidou.Figure 8b. GPS+Beidou.
A mobile demo on the Teseo-3 model is shown running GPS plus BeiDou in Figure 9, a road test in Taipei. Satellites (SV) up to 32 are GPS, those over 140 are BeiDou, in the status window shown: total 13 satellites in a high-rise city area, though many are non-LOS.
Figure 9. GPS + Beidou roadtrack in Taipei.
Extending the hardware to add BeiDou, which is on 1561 MHz and thus a third center frequency, meant adding another path through the IF stages of the on-chip radio. After the first mixer, GPS is at 4 MHz, and GLONASS at about 30 MHz, but BeiDou is at minus 10 MHz. While the IF strip in general is real, rather than complex (IQ), the output of the mixer and input to the first filter stage is complex, and thus can discriminate between positive frequencies (from the upper sideband) and negative ones (from the lower sideband), and this is normally used to give good image rejection. In the case of BeiDou, the filter input is modified to take the lower sideband, that is, negative frequencies, and a second mixer is not required; the IF filter is tuned to 10 MHz. The new blocks for BeiDou are shown in green in Figure 10. The baseband has no new blocks, but the code generator has been modified to generate the BeiDou codes (and, in fact, made flexible to generate many other code types and lengths). Two forms of Teseo-3 baseband are envisaged, the first being for low-cost, low-current continues to have two input paths, so must choose between GLONASS and BeiDou as required. A future high-end model may have an extra input processing path to allow use of BeiDou and GLONASS simultaneously.
Figure 10. Teseo-3 RF changes for Beidou shown in green.
Galileo Again
Maintaining the chronological sequence, Galileo gets a second chapter in three steps. In December 2012, it was possible for the first time to track four IOV satellites simultaneously, though not to position due to the absence of valid orbit data. In March 2012, it was possible for the first time to demonstrate live positioning, and this was done using Teseo-2 simultaneously by ESA at ESTEC and STMicro in Naples and Milan, our software development centres.
The demos were repeated in public for the press on July 24, 2013, at Fucino, Italy’s satellite earth station, with ESA/EC using the test user receiver (TUR) from Septentrio, and ST running simultaneous tests at its Italian labs. Figure 11 and Figure 12 show the position results for the data and pilot channels respectively, with independent LMS fixes. In real life, the fixes would be from a Kalman filter, and would be from a combined E1-B/E1-C channel, to take advantage of the better tracking on the pilot.
Good accuracy is not expected from Galileo at this stage. The four satellites, while orbited to give good common visibility, do not also give a good DOP; the full set of ground monitoring stations is not yet implemented and cannot be well calibrated with such a small constellation. Finally, the ionospheric correction data is not yet available. Despite these problems, the residuals on the solutions, against a known fixed position for the rooftop antenna, are very respectable, shown in Figure 13.
Figure 13. Galileo residuals, L1-B.
The common mode value is unimportant, representing only an offset in the receiver clock, and 10 meters is about 30 nanoseconds. The accuracy indicator is the spread between satellites, which is very respectable for a code-only receiver without full iono correction, especially around 640 on the TOW scale, where it is less than 2 meters. The rapid and major variation on the green data around t=400 is considered to be multipath, as the roof antenna is not ideally positioned with respect to other machinery and equipment also installed on the roof.
QZSS and GPS-III/L1C
Teseo-2 has supported the legacy (C/A code) signal on QZSS for some time, but Teseo-3 has been upgraded to handle the GPS-III/L1-C signal, waiting for modernized GPS. This signal is already available on the QZSS satellite, allowing tests with real signals. Significant changes were required in the baseband hardware, as the spreading code is a Weill code, whose generation complexity is such that it is generated once when the satellite is selected, then replayed real time from memory. Additionally it is long, in two domains. It is 10230 chips — that is, long to store but also long in time, with a 10-millisecond epoch. On Teseo-3, the legacy C/A code is used to determine code-phase and frequency before handing over to the Weill code for tracking.
Using a long-range crystal ball and looking far into the future, a model of the future Teseo-4 DSP hardware is available, with 64 correlation taps per satellite. Running this on the captured QZSS L1-C signal gives the correlation response shown in Figure 14. Having multiple taps removes all ambiguity from the BOC signal, simultaneously removing data transitions, which can alternatively be pre-stripped using the known pilot secondary code (which on GPS III is 5 dB stronger than the data signal). The resultant plot represents 2,000 epochs, each of 10 milliseconds, plotted in blue, with integrated result for the full 20 seconds shown in the black dashed line. Assuming vehicle dynamics is taken out using carrier Doppler, this allows extremely precise measurement of the code phase, or analysis of any multipath in order to remove it. This RF data was captured on a benign site with a static antenna, so it shows little distortion.
Figure 14. L1-C tracking on QZSS satellite.Figure 15. Dual RF implementation of dual-band front end.
The Future
Having already built in extreme flexibility to the code generators to support all known signals and generalized likely future ones, the main step for the future is to support multiple frequencies, starting with adding L5 and/or L2, but as before, ensuring that enough flexibility is built in to allow any rational user/customer choice. It is not viable for us to make silicon for low-volume combinations, nor to divide the overall market over different chips. Thus our mainstream chip must also support the lower volume options.
We cannot, however, impose silicon area or power consumption penalties on the high-volume customer, or he will not buy our product.
Thus, our solution to multi-frequency is to make an RF that can support either band switchably, with the high band integrated on the volume single-chip GNSS. Customers who also need the low band can then add a second RF of identical design externally, connected to the expansion port on the baseband, which has always existed for diagnostic purposes, and was how BeiDou was demonstrated on T2. By being an RF of identical design to the internal one, it incurs no extra design effort, and would probably be produced anyway as a test chip during the development of the integrated single-chip version. Without this approach, the low volume of sales of a dual-band radio, or a low-band radio, would never repay its development costs.
Conclusions
All four constellations have been demonstrated with live satellite signals on Teseo-2, a high-volume production chip for several years, and on Teseo-3 including use in combinations as a single multi-constellation positioning solution. With the advent of Teseo-3, with optimized BeiDou processing and hardware support for GPS-3/L1C, a long-term single-chip solution is offered.
For the future, dual-frequency solutions are in the pipeline, allowing full advantage of carrier phase, and research into moving precise point positioning and real-time kinematic into the automotive market for fields such as advanced driver-assistance systems.
Acknowledgments
Teseo III design and development is supported by the European Commission HIMALAYA FP-7 project.
This article is based on a technical paper first presented at ION-GNSS+ 2013 in Nashville, Tennessee.
ST GPS products, chipsets and software, baseband and RF are developed by a distributed team in: Bristol, UK (system R&D, software R&D; Milan, Italy (Silicon implementation, algorithm modelling and verification); Naples, Italy (software implementation and validation); Catania, Sicily, Italy (Galileo software, RF design and production); Noida, India (verification and FPGA). The contribution of all these teams is gratefully acknowledged.
Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. Since 1989 he has worked exclusively on GNSS implementations, RF, baseband and applications. He is consulting on the next-generation GNSS chips, including one-chip GPS (RF+digital), and high-sensitivity GPS and Galileo for indoor applications, and combined GPS/Galileo/GLONASS chipsets. In 2008-2009, he re-implemented LORAN on the GPS CPU, and in 2009-2010 led the GLONASS implementation team. He is leading the team on L1C and BeiDou implementation, and the creation of totally generic hardware that can handle even future unknown systems.
Fabio Pisoni has been with the GNSS System Team at STMicroelectronics since 2009. He received a master’s degree in electronics from Politecnico di Milano, Italy, in 1994. He was previously with the GNSS DSP and System Team in Nemerix SA and has earlier working experience in communications (multi-carrier receivers).
Rockwell Collins has received a 2 million contract from the Air Force Research Laboratory (AFRL) to develop and demonstrate a secure software-defined radio (SDR) GNSS receiver capability.
GNSS typically refers to equipment that can receive signals from multiple navigation satellite systems including GPS, GLONASS, Galileo, and the Chinese BeiDou system. By utilizing multiple available satellite signals, a GNSS receiver can provide improved navigation performance and signal availability.
Hosted in a software-defined radio, this AFRL program will develop the security architecture required for the receiver equipment certifications. The arrival of modernized GPS signals and other constellations is changing the way the U.S. military accomplishes GNSS-based positioning, navigation and timing.
“Rockwell Collins is actively researching GNSS capability as it applies to the U.S. and global customer base,” said John Borghese, vice president of the Rockwell Collins Advanced Technology Center. “We’re leveraging decades of GPS experience and leading edge security architectures to produce a navigation receiver that will meet global needs.”
TerraStar GNSS, a supplier of precision positioning services for land and near-shore applications, has established a base at Nottingham University’s GNSS Research and Applications Centre of Excellence (GRACE). GRACE operates operates under the auspices of its Institute of Engineering Surveying & Space Geodesy (IESSG).
TerraStar GNSS maintains and controls a worldwide network of more than 80 GPS and GLONASS DGNSS reference stations and associated control centers on behalf of a diverse range of users. Under the collaborative venture, TerraStar GNSS will contribute and have access to GRACE’s support facilities. These include customized incubation units, project offices, state-of-the-art test equipment, secure research and development laboratories, and dedicated training suites.
Expected projects include joint research and development of new GNSS-type solutions, in addition to provision of support for continued commercial exploitation of academic research endeavors. Also available will be mutual access to general geospatial expertise consistent with TerraStar GNSS’ present capability of providing year-round meter and decimeter-levels of precision for both land and aerial survey applications using software and a series of advanced purpose-designed integrated receivers.
Headed by General Manager Gary Wilcock, TerraStar GNSS’s new base facilities are at Office A03, The Nottingham Geospatial Building, University of Nottingham Innovation Park, Triumph Road, Nottingham NG7 2TU, UK.
Nexteq Navigation has launched accelGRx, a platform for accelerating professional-grade GNSS receiver development. The platform provides open and production-ready hardware and software building blocks for GNSS receivers. accelGRx is designed for organizations looking to research and develop new techniques and algorithms requiring deep in-receiver integreation or quickly produce a small, high-performance receiver.
accelGRx supports GPS L1 and Beidou B1, and the hardware is GLONASS and Galileo ready. It pairs a compact form factor and industry standard pin layout with a code and phase precision of 4 cm and 0.4 mm respectively for both GPS L1 and Beidou B1. It incorporates an array of software development tools, including the ability to record and play back digitized signals.
An accelGRx licensee wil have tools to develop and test new deep in-receiver integration techniques and algorithms:
• Access to all source code, logic and tools
• Deep in-receiver access to real-time GNSS information
• PC-based software model of receiver platform
• Store and playback of digitized signals for development and testing
• Testing with production-ready receiver and real-world conditions
An accelGRx licensee will have the necessary assets and tools to begin commercialization immediately after development is complete:
• Hardware design (schematic, PCB layout, and BOM)
• FPGA logic design
• Full tracking and PVT source code
• Receiver operating system
• Design documentation and manuals
Nexteq also released two other products:
matrixRTK is a combination of the PPP and network RTK approaches to benefit network-RTK vendors. matrixRTK has the benefits of network RTK (fast initialization) with the benefit of PPP (no baseline restrictions).
L1-RTK-systems is a solution that allows our handheld users to use 2/L1 high sensitive GNSS handhelds working as base and rover to achieve 2-20 cm level accuracy. This is a reliable and cost-effective solution for field workers, Nexteq said.
NVS Technologies has released updated firmware for its NV08C receiver series. Firmware v0206 is compatible with current and preceding hardware revisions of the NV08C receiver series. Firmware v0206 can be downloaded free of charge.
Firmware v0206 offers:
Stabilized raw data output for output rates up to 10 Hz
Extended $POUTC NMEA message, including current LEAP SECONDS value, flags for expected UTC correction, and PPS edge shift relative to UTC (sawtooth correction SW).
Stabilized sleep mode operation ($POPWR,1111*66) for all NV08C series HW versions
Increased position accuracy and stability in urban canyon conditions with poor SV visibility
Cold start initialized to LEAP SECOND 16 (LEAP SECOND 16 came into effect July 1, 2012)
Benefits include:
Obtain initial receiver coordinates more quickly, in cold starts, low satellite signal (foliage/canopy) and loss of satellite signal conditions (indoor, garages, tunnels…).
A New Approach to the Design and Development of Global Navigation Satellite Systems
By Daniele Gianni, Marco Lisi, Pierluigi De Simone, Andrea D’Ambrogio, and Michele Luglio
INNOVATION INSIGHTS by Richard Langley
MY FIRST DEGREE is in applied physics from the University of Waterloo. Founded in 1957, Waterloo was one of the first universities to introduce co-operative education. Co-operative education (or “co-op” as it is commonly known) is a program that uses both classroom study and temporary jobs to provide students with practical experience. Applied Physics was a co-op program and I worked in both industry and research environments including stints at Philips Electronics and the Atomic Energy of Canada Limited’s Chalk River Laboratories.
Both on campus and on the job, I met fellow co-op students from a variety of disciplines including mathematics (computer science) and various branches of engineering. One of those was systems design engineering or systems engineering for short. At that time, I really didn’t know much about systems engineering except that it was an all-encompassing branch of engineering and the most challenging of all of the engineering programs at Waterloo — at least according to the students in the program.
Systems engineering is an interdisciplinary field of engineering focusing on the design and management of complex engineering projects. According to the International Council on Systems Engineering, systems engineers establish processes “to ensure that the customer and stakeholder’s needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system’s entire life cycle. This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate [or, SIMILAR, for short].”
Central to the systems engineering process and the end-product design is the generation of models. Many types of system models are used, including physical analogs, analytical equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations, and even mental models. (If you want to learn a bit about mental and other kinds of models, including how to fix radios by thinking, you could do no better than to look at some of Richard Feynman’s writings including the eminently readable “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character.)
As aids to the modeling process, systems engineers have developed specialized modeling languages including the Unified Modeling Language (UML) and the Systems Modeling Language (SysML). These are graphical-based languages that can be used to express information or knowledge about systems in a structure that is defined by a consistent set of rules. Both UML and SysML are widely used in systems engineering. However, both are limited when it comes to representing the signal-in-space (SIS) interfaces for global navigation satellite systems.
In this month’s column, a team of authors affiliated with the Galileo project discusses the Interface Communication Modeling Language, an extension of UML that allows engineers to clearly represent SIS interfaces, critical for the design of GNSS receivers.
“Innovation” is a regular feature that discusses advances in GPS technology andits applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. To contact him, see the “Contributing Editors” section on page 4.
In this article, we present the results of ongoing research on the use of a modeling language, namely Interface Communication Modeling Language (ICML), for signal-in-space (SIS) interface specification of global navigation satellite systems (GNSS). Specifications based on modeling languages (also known as model-based specifications) have proven to offer a wide range of benefits to systems engineering activities, for supporting system interoperability, reducing design risk, automating software development, and so on. We argue that similar benefits can be obtained for satellite navigation systems and receivers, if a model-based approach is used for defining and expressing the SIS interface specification. In particular, we outline how a model-based SIS interface specification can support the identification of solutions to two key issues: GNSS interoperability and the design of GNSS receivers, particularly Galileo receivers. Both issues are becoming increasingly central to the Galileo program since it entered the In-Orbit-Validation (IOV) phase and is steadily approaching the 2014 milestone, when the first early services — the Open Service (OS) and the Search and Rescue Service — will be provided to users.
GNSS interoperability concerns the integration of different GNSS with the purpose of being used together, along with regional positioning systems, to provide a seamless navigation capability and improved services in terms of availability, continuity, accuracy, and integrity, for example. GNSS interoperability should be addressed in terms of intra-GNSS interoperability and GNSS-receiver interoperability. The intra-GNSS interoperability concerns the data exchanged among the GNSS, including coordination to guarantee data coherence and consistency over time. For example, GNSS may need to share terrestrial reference frames and constantly synchronize their global time references. On the other hand, GNSS-receiver interoperability concerns the capability of the receiver to use independent GNSS signals for the computation of positions globally. This capability implicitly requires that the receiver computations are decoupled from the SIS interface of any particular GNSS. A key condition to achieve this decoupling is that the SIS interface specification is available in a consistent, unambiguous, and possibly standard format, which can support engineers to more effectively design interoperable receivers. A model-based SIS interface specification would considerably facilitate this as it enables designers to use the processing capabilities of a computer system for the verification of the specification consistency and completeness, for example. Moreover, a model-based SIS interface specification would ease the visual and electronic inspection of the data messages, therefore facilitating the automatic identification of different data representations for the same orbital and temporal parameters.
The design of GNSS receivers, and particularly those for Galileo, is increasingly of interest, and a model-based SIS interface specification can similarly support the definition of future solutions. For Galileo, specifically, the receiver design is critical to support the marketing strategies that are promoting the use of Galileo services. Key issues underlying any marketing strategy concern the Galileo receiver market appealing from a cost-to-performance ratio point of view. As Galileo receivers may require new design and adaptation of existing software (SW) or hardware (HW), as well as new production chains, higher costs — in particular non-recurring ones — are likely to occur for the production of the Galileo receivers with respect to the well-established GPS receivers. As a consequence, limitations may be experienced in market penetration and in the growth velocity of Galileo receivers’ share of the receiver market. In turn, this may hinder the estimated economic return for the Galileo project.
Preventing and counteracting this possibility is therefore a critical issue if we aim to achieve the widest possible success of the Galileo project. Market barriers inherently originate from the following needs:
Designing new SW and HW solutions for Galileo receivers;
Reusing existing SW and HW for GPS receivers;
Converting existing production chains to the new Galileo-specific SW and HW solutions.
GNSS receivers often use established mathematical models that can determine the receiver position from a fundamental set of parameters, such as satellite orbit and system time. As a consequence, the intrinsic representation of the parameter set is a major factor in the adaptation of the existing design and implementation of SW and HW solutions.
To reduce the impact of the above needs, a model-based SIS interface specification may play a pivotal role in several ways, such as:
reducing ambiguities in the Galileo SIS interface specification;
enhancing the communication with the involved stakeholders;
linking the SIS interface specification to the design schemas of GNSS receivers — particularly Galileo ones — for tracing the interface elements onto the receiver functional and physical schema, thereby supporting the reuse and adaptation of existing HW and SW solutions;
supporting the model-based design of security solutions for blocking, jamming, and spoofing.
Galileo Project
In October 2012, the final two IOV satellites were launched into orbit, completing the designed configuration for the Galileo IOV phase — the initial stage of the Galileo constellation development. In this phase, preliminary validation tests will be performed and the initial navigation message will be broadcast to the Galileo ground segment for further validation. Shortly after the conclusion of this phase, a series of launches will take place to gradually deploy the remaining 26 satellites that will form the Galileo Full Operational Capability (FOC) configuration. Currently, the Galileo Early Open Service (EOS) is expected to be available by the end of 2014. The EOS will provide ranging capabilities and will enable receiver manufacturers to begin to design and test their technological solutions for Galileo receivers and Galileo overlay services, such as search and rescue.
In the meantime, the European GNSS Agency has been established and assigned the governance of the Galileo sub-systems, including activities such as:
initiating and monitoring the implementation of security procedures and performing system security audits;
system infrastructure management, maintenance, improvement, certification, and standardization, and service provision;
development and deployment of activities for the evolution and future generations of the systems, including procurement activities;
contributing to the exploitation of the systems, including the marketing and promotion of applications and services, including market analysis.
With the now-rapid development of the Galileo project, it becomes increasingly important to support the receiver manufacturers in the design and implementation of global navigation solutions based on the Galileo services. This is necessary to guarantee the widespread use of the Galileo services, particularly in an increasingly crowded GNSS panorama.
Model-Based Systems Engineering
Model-based systems engineering (MBSE) is predicated on the notion that a system is developed by use of a set of system models that evolve throughout the development lifecycle, from abstract models at the early stages down to the operational system. A visual presentation is provided by FIGURE 1, which shows the roles of MBSE approaches within the systems engineering V-shaped process. Specifically, the MBSE approaches enable the designer to effectively trace the requirements and design alternatives on the descending branch of the “V.” For the same characteristics, MBSE facilitates the verification through a model repository that interconnects not only the design products, but also the stakeholders involved in the entire process. In addition, MBSE approaches support the automatic generation of the documentation and of other artifacts, particularly software. All of these capabilities eventually enable the validation of the implementation activities on the ascending branch of the V-process. Also, in this case, MBSE and the model repository play a major role in connecting design to implementation, and users and designers to developers.
FIGURE 1. Systems engineering V-process supported by an model-based systems engineering with model repository (courtesy of the INCOSE Survey).
Main Concepts. MBSE approaches are gaining increasing popularity with the widespread adoption of standard modeling languages, such as Unified Modeling Language (UML) and Systems Modeling Language (SysML).
UML is a formally defined general-purpose graphical language and is mainly used in the context of software systems development. It has been developed and is being managed by the Object Management Group and is the core standard of the Model Driven Architecture (MDA) effort, which provides a set of standards to shift from code-centric to model-driven software development. By use of an MDA-based approach, a software system is built by specifying and executing a set of automated model transformations.
SysML is defined as an extension of UML and provides a general-purpose modeling language for systems engineering applications (See FIGURE 2). SysML supports MBSE approaches in the development of complex systems that include hardware, software, information, processes, personnel, and facilities.
FIGURE 2. UML-SysML relationships. (UML 2 is the second generation version of UML introduced in 2005.)
Advantages. With respect to the conventional document-based approaches, MBSE approaches present the following advantages:
Conformance to standard specifications and availability of development tools;
Increased level of automation due to the formal specification and execution of model transformations that take as input a model at a given level of abstraction and yield as output a refined model at a lower level of abstraction;
Better understanding of the system in its operational context;
Support for simulation activities at different levels of detail and at different development stages, from concept exploration to dynamic system optimization;
Support for the coherent extension of standard modeling languages to adapt them to a specific target or domain.
These capabilities have motivated and have been sustaining an increasing trend of moving from document-centric to model-centric systems engineering.
ICML Language
UML and SysML are widely used languages for MBSE. A plethora of tools and technologies are available to compose models, transform models into documents, derive software products from models, and share and reuse models by means of repositories. However, neither of these languages offers capabilities for the representation of SIS interfaces, which are the critical interfaces for the design of Galileo receivers. For this reason, we have introduced ICML: a modeling language that can enable a full MBSE approach for the design of Galileo receivers. Moreover, ICML extends UML, and therefore it can integrate with system specifications based on compliant technologies as well as be used within standard tools.
Layout of Interface Specification. The typical layout of ICML-based interface specification is shown in FIGURE 3. The specification covers the definition of both the message structure and conversion processes. The message structure consists of five abstraction levels, and describes how the data is structured within the message. The conversion processes describe how the data values are transformed between adjacent levels of the message specification.
FIGURE 3. Layout of ICML-based interface specifications.
The message structure is defined at five levels: Data Definition, (Logical) Binary Coding, Logical Binary Structure, Physical Binary Coding, and Physical Signal, each covering specific aspects of the SIS interface specification.
For example, the Data Definition level covers the specification of the logical data structure, which includes the data items composing the message information. A data item is either of application or control type. An application data item represents a domain-specific concept that conveys the information expected by the message recipient. On the other hand, a control data item represents a domain-independent concept that can support the correctness and integrity verification of the associated application data items. A data item can also be associated with semantic and pragmatic definitions. The former specifies the meaning of the data item and the latter specifies the contextual interpretation for the semantic definition.
Analogously, the Binary Coding level covers the specification of the binary coding for each of the data items defined at the above level. For a data item, the binary coding is represented as a binary sequence and it includes at least a sequence identifier, the semantic definition, and the pragmatic definitions. Similarly to the above level, the semantic and pragmatic definitions enrich the interface specification, conveying an accurate representation of the binary coding.
The conversion processes describe the activities to be performed for deriving message values between adjacent levels of the above structural specification. As shown in Figure 3, eight processes should be defined to specify all the conversions between adjacent levels. For example, the DataDefinition2BinaryCoding process defines the activities to be performed for the derivation of the logical binary sequences representing data values. Similarly, the LogicalBinary2PhysicalBinary process defines the activities for the implementation of convolution or encryption algorithms on the logical binary sequence. However, these processes do not always need to be explicitly defined. In particular, if the implementation of a process is trivial or standard, a textual note referring to an external document may suffice for the specification purposes.
The first prototypal version of ICML has been implemented and can be used within the open source TopCased tool. The prototypal version is available under the GNU General Public License (GPL) v3.0 from the ICML project website. We applied the profile and developed the example ICML-based specification given below.
Galileo-Like Specification. An ICML-based specification of a Galileo-like OS interface, concerning only the above-defined level 3, would display as shown in FIGURE 4. This figure specifically details a part of a reduced F/NAV (the freely accessible navigation message provided by the E5a signal for the Galileo OS) structure consisting of one data frame made up of two F/NAV subframes.
FIGURE 4. Example of ICML-based specification of an F/NAV-like message structure at the Logical Binary Coding level.
Benefits. ICML can bring the above-mentioned MBSE benefits to support GNSS interoperability and to GNSS and Galileo receiver design. For example, ICML can:
provide a reference guideline for structuring the specification data and thus facilitating the communication between the Galileo SIS designers and the receiver producers;
ease visual inspection of the specification for verification purposes and for the identification of data incompatibilities of two GNSS systems;
convey the data semantics as well as the measurement units, to guarantee that the binary data from different GNSS are correctly decoded and interpreted;
support syntactical model validation using existing tools;
provide support for future advance exploitation by means of a machine-readable data format.
In particular, the availability of a machine-readable format is also the basis for advanced use cases that can exploit the capabilities of modern computer technologies.
Advanced Future Use Cases. In line with the above-mentioned MBSE model exploitations, we foresee a number of possible exploitation cases:
Automatic generation of the interface specification documents;
Collaborative development of the interface specification;
Automatic completeness and consistency checking of the interface specification;
Integration of SIS specifications with model-driven simulation engineering approaches for the simulation of single- and multi-GNSS receivers;
Integration of SIS specifications with receiver design models in SysML, for requirements traceability and reuse of existing GNSS solutions.
The automatic generation of interface specification documents can be an important capability during the lifecycle of a specification. For example, the specification may be updated several times during the interface design, and the textual documentation may need to be produced several times. Using a model-based approach, it is possible to automate the error-prone activities related to the document writing as well as other important functions such as specification versioning.
Complex system specifications are often the product of collaborating teams, which may occasionally be geographically dispersed. Using a model-based approach, the interface specification can be stored within a version control system that can be concurrently accessed by team members.
Completeness and consistency checking is also a manual activity, which demands a high degree of mental attention, and it is consequently highly error prone. Once the specification is available in a machine-readable format, the checking can be easily automated by specifying the verification rules that the interface model must satisfy.
Existing technologies support the simulation of single- and multi-GNSS receivers. As the SIS specification has a major impact on the internal structure of the receiver, the interface specification is a key input for developing GNSS simulators as well as for determining the boundary properties of the input signal into the receiver, including the admitted analog signal and the format of the digital data.
Moreover, the model-based interface specification can be integrated with a receiver design schema in SysML. This would be important to provide traceability between the interface requirements and the receiver’s functional and physical components. In the following section, we provide an outline for a preliminary integration between the interface specification and the receiver design.
Designing Galileo Receivers
Model-based interface specifications can support the design of Galileo receivers in several ways. For example, a specification can provide a link between Galileo requirements down to the Galileo receiver specifications, as shown in FIGURE 5.
FIGURE 5. Links between ICML and SysML specifications.
This capability may be useful in several scenarios. In particular, we have identified three scenarios. Scenario 1 consists of the identification of the receiver requirements that are introduced or modified by the Galileo OS SIS, with respect to existing GPS receivers. Scenario 2 concerns the linking between the ICML specification and the receiver functional schema to identify how a Galileo receiver will differ from existing GPS solutions. Scenario 3 is a development of Scenario 1 and Scenario 2, in which the physical schema definition and the physical components identification (HW and SW) may further exploit the ICML-based approach for supporting the reuse of existing GPS components.
Below, we detail Scenario 2, introducing a simplified receiver functional schema in SysML and linking the above ICML example to the schema.
Example Functional Schema. In this section, we illustrate a preliminary SysML representation for a simplified GNSS receiver. However, the figures are meant for exemplification purposes only and are not to be considered fully realistic and detailed for real GNSS receivers. Nevertheless, the SysML hierarchical modeling capabilities can be used to further refine the model, up to a potentially infinitesimal level of detail.
A GNSS receiver functional schema has been derived from A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach (see Further Reading) and its equivalent SysML internal block diagram (IBD) is shown in FIGURE 6.
In particular, the IBD illustrates the functional blocks (instances and types) and connections among these blocks that define the GNSS receiver. In particular, each of these block types is also described in other diagrams, in which the designers can specify the operations performed by the block, the attributes of the block, the referred properties, and the defined values, for example.
In this short article, we have particularly focused on the navigation data decoder. The data decoder is defined by a Block Definition Diagram (BDD) and an IBD, which are shown in FIGURES 7 and 8, respectively.
FIGURE 7. Navigation data decoder block definition diagram.FIGURE 8. Navigation data decoder internal block diagram.
In particular, the BDD indicates that the navigation data decoder is composed of four types of blocks: shift buffer, parity checker, binary adder, and data item retriever. The shift buffer receives the incoming physical sequence of bits, which is subsequently verified by the parity checker. The verified sequence is then processed to retrieve the standard binary format from the SIS-specific logical coding for the data item. This function is guided by the data item retriever, which stores the defined properties of each incoming data item, in the form of a physical sequence of bits (level 1). As a consequence, the navigation data decoder is involved with data defined at several of the above-defined ICML levels. From this description, it is also possible to sketch the preliminary IBD diagram of Figure 8.
Using a model-based approach, it becomes easier to establish links between interface elements and the functional blocks in the receiver schema.
Moreover, these links can also be decorated with a number of properties that can be used to further describe the type of the relationship between the interface element and the functional block. The link identification is important to the receiver design in several ways. For example, linking the interface elements to the receiver functional blocks, it becomes easier to identify which functional blocks are affected by each element of the SIS interface. Moreover, the tracing can be transitively extended to the physical schema, enabling the receiver designers to more immediately identify which physical components can be reused and which ones must be replaced in existing GNSS solutions.
We exemplify the tracing of interface elements on the above data decoding functional schema in FIGURE 9. This figure shows the navigation data decoder’s BDD in conjunction with ICML level 3 elements (with a white background). As in Figure 7, the relationships are drawn in red, including a richer set of relationship qualifiers. For example, the <<use>> qualifier indicates that the originating block uses the data specified in the connected ICML element. Similarly, the <<consumes>> qualifier indicates that the originating block takes in input instances of the ICML element. ICML level 4 elements are also relevant to this BDD; however, they are not shown for the sake of conciseness.
FIGURE 9. Linking level 3 elements to the navigation data decoder block definition.
Conclusions
Galileo receivers may face market barriers that are inherently raised by the costs linked with the introduction of new technologies with respect to the existing GPS ones. In this article, we have advocated that a model-based SIS interface specification can help mitigate possible extra costs in several ways. For example, the model-based interface specification can ease the communication among stakeholders, promote the reuse and adaptation of existing GPS software and chipsets, and support the implementation of receiver-side multi-GNSS interoperability. With the objective of supporting model-based interface specifications, we have designed ICML, which has been provided with a UML profile implementation in an open-source modeling tool. We have also shown an excerpt of a possible model-based specification for a simplified Galileo OS interface. Moreover, we have outlined how the model-based specification can integrate with SysML models of GNSS receivers and support the reuse and adaptation of existing solutions. A preliminary identification of potential exploitations and further benefits is also included. Further research is ongoing to generalize the existing ICML language to more complex types of SIS interfaces.
Acknowledgments
The authors would like to thank the students Serena Annarilli and Carlo Di Bartolomei (University of Rome Tor Vergata) for implementing the first prototype version of the ICML profile. The authors would also like to thank Marco Porretta, European Space Agency (ESA) / European Space Research and Technology Centre (ESTEC), for the suggestions of the GNSS example. The ICML project has been partially sponsored by the ESA Summer of Code in Space Initiative, edition 2012. No endorsement is made for the use of ICML for the official Galileo SIS interface specification.
DANIELE GIANNI is currently a requirement engineering consultant at EUMETSAT in Germany. EUMETSAT is the European operational satellite agency for monitoring weather, climate and the environment. Gianni received a Ph.D. in computer and control engineering from University of Rome Tor Vergata (Italy), in the field of modeling and simulation, in 2007. He has previously held research appointments at ESA, Imperial College, and Oxford University.
MARCO LISI is currently GNSS services engineering manager at ESA’s Directorate of Galileo Programme and Navigation- Related Activities at ESTEC in Noordwijk, The Netherlands. He was previously responsible for system engineering, operations, and security activities in the Galileo project. He is also a special advisor to the European Commission on European space policies. Lisi has over thirty years of working experience in the aerospace and telecommunication sectors, holding management positions in R&D, and being directly involved in a number of major satellite programs, including Artemis, Meteosat Operational, Meteosat Second Generation, Globalstar, Cosmo-Skymed, and more recently Galileo.
PIERLUIGI DE SIMONE is currently working on system assembly, integration, and verification for the Galileo mission in ESA. He has worked on many software developments in the fields of graphics, safe mode software, and visual programming. He has worked on many space missions including Helios, Meteosat, Metop, Cosmo-Skymed, and Galileo. His main interests are in modeling paradigms and cryptography and he holds a master’s degree in physics from University of Rome Tor Vergata.
ANDREA D’AMBROGIO is associate professor of computer science at the University of Rome Tor Vergata. He has formerly been a research associate at the Concurrent Engineering Research Center of West Virginia University in Morgantown, West Virginia. His research interests are in the areas of engineering and validation of system performance and dependability, model-driven systems and software engineering, and distributed simulation.
MICHELE LUGLIO is associate professor of telecommunication at University of Rome Tor Vergata. He works on designing satellite systems for multimedia services both mobile and fixed. He received the Ph.D. degree in telecommunications in 1994.
FURTHER READING
• Interface Communication Modeling Language (ICML)
“A Modeling Language to Support the Interoperability of Global Navigation Satellite Systems” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in GPS Solutions, Vol. 17, No. 2, 2013, pp. 175–198, doi: 10.1007/s10291-012-0270-z.
• Use of ICML for GNSS Signal-in-Space Interface Specification
“A Model-based Signal-In-Space Interface Specification to Support the Design of Galileo Receivers” by D. Gianni, M. Lisi, P. De Simone, A. D’Ambrogio, and M. Luglio in Proceedings of the 6th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC), Noordwijk, The Netherlands, December 5–7, 2012, 8 pp., doi: 10.1109/NAVITEC.2012.6423066.
“A Model-Based Approach to Signal-in-Space Specifications for Designing GNSS Receivers” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in Inside GNSS, Vol. 6, No. 1, January/February 2011, pp. 32–39.
• Related Modeling Languages
The Unified Modeling Language Reference Manual, 2nd edition, by G. Booch, J. Rumbaugh, and I. Jacobson, published by Addison-Wesley Professional, an imprint of Pearson Education, Inc., Upper Saddle River, New Jersey, 2005.
A Practical Guide to SysML: The Systems Modeling Language, 2nd edition, by S. Friedenthal, A. Moore, and R. Steiner, published by Morgan Kaufman and the Object Management Group Press, an imprint of Elsevier Inc., Waltham, Massachusetts, 2012.
• Systems Engineering
Systems Engineering: Principles and Practice, 2nd edition, by A. Kossiakoff, W.N. Sweet, S.J. Seymour, and S.M. Biemer, published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2011.
A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser Boston, Cambridge, Massachusetts, 2007.
• Galileo Status and Plans
“Status of Galileo” (Galileo System Workshop) by H. Tork in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2474–2502.
“Galileo Integrated Approach to Services Provision” (Galileo System Workshop) by M. Lisi in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2572–2596.
The Universal Software Radio Peripheral as RF Front-End
By Ningyan Guo, Staffan Backén, and Dennis Akos
The authors designed a full-constellation GNSS receiver, using a cost-effective, readily available, flexible front-end, wide enough to capture the frequency from 1555 MHz to 1607 MHz, more than 50MHz. This spectrum width takes into account BeiDou E2, Galileo E1, GPS L1, and GLONASS G1. In the course of their development, the authors used an external OCXO oscillator as the reference clock and reconfigured the platform, developing their own custom wide-band firmware.
The development of the Galileo and BeiDou constellations will make many more GNSS satellite measurements be available in the near future. Multiple constellations offer wide-area signal coverage and enhanced signal redundancy. Therefore, a wide-band multi-constellation receiver can typically improve GNSS navigation performance in terms of accuracy, continuity, availability, and reliability. Establishing such a wide-band multi-constellation receiver was the motivation for this research.
A typical GNSS receiver consists of three parts: RF front-end, signal demodulation, and generation of navigation information. The RF front-end mainly focuses on amplifying the input RF signals, down-converting them to an intermediate frequency (IF), and filtering out-of-band signals. Traditional hardware-based receivers commonly use application-specific integrated circuit (ASIC) units to fulfill signal demodulation and transfer the range and carrier phase measurements to the navigation generating part, which is generally implemented in software. Conversely, software-based receivers typically implement these two functions through software. In comparison to a hardware-based receiver, a software receiver provides more flexibility and supplies more complex signal processing algorithms. Therefore, software receivers are increasingly popular for research and development.
The frequency coverage range, amplifier performance, filters, and mixer properties of the RF front-end will determine the whole realization of the GNSS receiver. A variety of RF front-end implementations have emerged during the past decade. Real down-conversion multi-stage IF front-end architecture typically amplifies filters and mixes RF signals through several stages in order to get the baseband signals. However, real down-conversion can bring image-folding and rejection. To avoid these drawbacks, complex down-conversion appears to resolve much of these problems. Therefore, a complex down-conversion multi-stage IF front-end has been developed. But it requires a high-cost, high-power supply, and is larger for a multi-stage IF front-end. This shortcoming is overcome by a direct down-conversion architecture. This front-end has lower cost; but there are several disadvantages with direct down-conversion, such as DC offset and I/Q mismatch. DC offset is caused by local oscillation (LO) leakage reflected from the front-end circuit, the antenna, and the receiver external environment.
A comparison of current traditional RF front-ends and different RF front-end implementation types led us to the conclusion that one model of a universal software radio peripheral, the USRP N210, would make an appropriate RF front end option. USRP N210 utilizes a low-IF complex direct down-conversion architecture that has several favorable properties, enabling developers to build a wide range of RF reception systems with relatively low cost and effort. It also offers high-speed signal processing. Most importantly, the source code of USRP firmware is open to all users, enabling researchers to rapidly design and implement powerful, flexible, reconfigurable software radio systems. Therefore, we chose the USRP N210 as our reception device to develop our wide-band multi-constellation GNSS receiver, shown in Figure 1.
Figure 1. Custom wide-band multi-constellation software receiver architecture based on universal software radio peripheral (USRP).
USRP Front-End Architecture
The USRP N210 front-end has wider band-width and radio frequency coverage in contrast with other traditional front-ends as shown by the comparison in Table 1. It has the potential to implement multiple frequencies and multiple-constellation GNSS signal reception. Moreover, it performs higher quantization, and the onboard Ethernet interface offers high-speed data transfer.
Table 1. GNSS front-ends comparison.
USRP N210 is based on the direct low-IF complex down-conversion receiver architecture that is a combination of the traditional analog complex down-conversion implemented on daughter boards and the digital signal conditioning conducted in the motherboard. Some studies have shown that the low-IF complex down-conversion receiver architecture overcomes some of the well-known issues associated with real down-conversion super heterodyne receiver architecture and direct IF down-conversion receiver architecture, such as high cost, image-folding, DC offset, and I/Q mismatch.
The low-IF receiver architecture effectively lessens the DC offset by having an LO frequency after analog complex down-conversion. The first step uses a direct complex down-conversion scheme to transform the input RF signal into a low-IF signal. The filters located after the mixer are centered at the low-IF to filter out the unwanted signals. The second step is to further down-covert the low-IF signal to baseband, or digital complex down-conversion.
Similar to the first stage, a digital half band filter has been developed to filter out-of-band interference. Therefore, direct down-conversion instead of multi-stage IF down-conversion overcomes the cost problem; in the meantime, the signal is down-converted to low-IF instead of base-band frequency as in the direct down-conversion receiver, so the problem of the DC offset is also avoided in the low-IF receiver. These advantages make the USRP N210 platform an attractive option as GNSS receiver front-end.
Figure 2 shows an example GNSS signal-streaming path schematic on a USRP N210 platform with a DBSRX2 daughter board. Figure 3 shows a photograph of internal structure of a USRP N210 platform.
Figure 2 GNSS signal streaming on USRP N210 + DBSRX2 circuit.Figure 3. USRP N210 internal structure.
The USRP N210 platform includes a main board and a daughterboard. In the main board, 14-bit high precision analog-digital converters (ADCs) and digital-analog converters (DACs) permit wide-band signals covering a high dynamic range. The core of the main board is a high-speed field-programmable gate array (FPGA) that allows high-speed signal processing. The FPGA configuration implements down-conversion of the baseband signals to a zero center frequency, decimates the sampled signals, filtering out-of-band components, and finally transmits them through a packet router to the Ethernet port. The onboard numerically controlled oscillator generates the digital sinusoid used by the digital down-conversion process. A cascaded integrator-comb (CIC) filter serves as decimator to down-sample the signal.
The signals are filtered by a half pass filter for rejecting the out-of-band signals. A Gigabit Ethernet interface effectively enables the delivery of signals out of the USRP N210, up to 25MHz of RF bandwidth. In the daughterboard, first the RF signals are amplified, then the signals are mixed by a local onboard oscillator according to a complex down-conversion scheme. Finally, a band-pass filter is used remove the out-of-band signals.
Several available daughter boards can perform signal conditioning and tuning implementation. It is important to choose an appropriate daughter board, given the requirements for the data collection.
A support driver called Universal Hardware Driver (UHD) for the USRP hardware, under Linux, Windows and Mac OS X, is an open-source driver that contains many convenient assembly tools. To boot and configure the whole system, the on-board microprocessor digital signal processor (DSP) needs firmware, and the FPGA requires images. Firmware and FPGA images are downloaded into the USRP platform based on utilizations provided by the UHD. Regarding the source of firmware and FPGA images, there are two methods to obtain them:
directly use the binary release firmware and images posted on the web site of the company;
build (and potentially modify) the provided source code.
USRP Testing and Implementation
Some essential testing based on the original configuration of the USRP N210 platform provided an understanding of its architecture, which was necessary to reconfigure its firmware and to set up the wide-band, multi-constellation GNSS receiver. We collected some real GPS L1 data with the USRP N210 as RF front-end. When we processed these GPS L1 data using a software-defined radio (SDR), we encountered a major issue related to tracking, described in the following section.
Onboard Oscillator Testing. A major problem with the USRP N210 is that its internal temperature-controlled crystal oscillator (TCXO) is not stable in terms of frequency. To evaluate this issue, we recorded some real GPS L1 data and processed the data with our software receiver. As shown in Figure 4, this issue results in the loss of GPS carrier tracking loop at 3.18 seconds, when the carrier loop bandwidth is 25Hz.
Figure 4. GPS carrier loop loss of lock.
Consequently, we adjusted the carrier loop bandwidth up to 100Hz; then GPS carrier tracking is locked at the same timing (3.18s), shown in Figure 5, but there is an almost 200 Hz jump in less than 5 milliseconds.
Figure 5. GPS carrier loop lock tracking.
As noted earlier, the daughter card of the USRP N210 platform utilizes direct IF complex down-conversion to tune GNSS RF signals. The oscillator of the daughter board generates a sinusoid signal that serves as mixer to down-convert input GNSS RF signals to a low IF signal. Figure 6 illustrates the daughter card implementation. The drawback of this architecture is that it may bring in an extra frequency shift by the unstable oscillator. The configuration of the daughter-card oscillator is implemented by an internal TCXO clock, which is on the motherboard. Unfortunately, the internal TCXO clock has coarse resolution in terms of frequency adjustments. This extra frequency offset multiplies the corresponding factor that eventually provides mixer functionality to the daughter card. This approach can directly lead to a large frequency offset to the mixer, which is brought into the IF signals.
Figure 6. Daughter-card tuning implementation.
Finally, when we conduct the tracking operation through the software receiver, this large frequency offset is beyond the lock range of a narrow, typically desirable, GNSS carrier tracking loop, as shown in Figure 4.
In general, a TCXO is preferred when size and power are critical to the application. An oven-controlled crystal oscillator (OCXO) is a more robust product in terms of frequency stability with varying temperature. Therefore, for the USRP N210 onboard oscillator issue, it is favorable to use a high-quality external OCXO as the basic reference clock when using USRP N210 for GNSS applications.
Front-End Daughter-Card Options. A variety of daughter-card options exist to amplify, mix, and filter RF signals. Table 2 lists comparison results of three daughter cards (BURX, DBSRX and DBSRX2) to supply some guidance to researchers when they are faced with choosing the correct daughter-board.
Table 2. Front-end daughter-card options.
The three daughter cards have diverse properties, such as the primary ASIC, frequency coverage range, filter bandwidth and adjustable gain. BURX gives wider radio frequency coverage than DBSRX and DBSRX2. DBSRX2 offers the widest filter bandwidth among the three options.
To better compare the performance of the three daughter cards, we conducted another three experiments. In the first, we directly connected the RF port with a terminator on the USRP N210 platform to evaluate the noise figure on the three daughter cards. From Figure 7, we can draw some conclusions:
BURX has a better sensitivity than DBSRX and DBSRX2 when the gain is set below 30dB.
DBSRX2 observes feedback oscillation when the gain set is higher than 70dB.
Figure 7. Noise performance comparisons of three daughter cards.
The second experimental setup configuration used a USRP N210 platform, an external OCXO oscillator to provide stable reference clock, and a GPS simulator to evaluate the C/N0 performance of the three daughter boards. The input RF signals are identical, as they come from the same configuration of the GPS simulator. Figure 8 illustrates the C/N0 performance comparison based on this experimental configuration. The figure shows that BURX performs best, with DBSRX2 just slightly behind, while DBSRX has a noise figure penalty of 4dB.
Figure 8. C/N0 performance comparisons of three daughter cards.
In the third experiment, we added an external amplifier to increase the signal-to-noise ratio (SNR). From Figure 9, we see that the BURX, DBSRX and DBSRX2 have the same C/N0 performance, effectively validating the above conclusion. Thus, an external amplifier is recommended when using the DBSRX or DBSRX2 daughter boards.
Figure 9. C/N0 performance comparisons of three daughter cards with an external amplifier.
The purpose of these experiments was to find a suitable daughter board for collecting wide-band multi-constellation GNSS RF signals. The important qualities of an appropriate wide-band multi-constellation GNSS receiver are:
high sensitivity;
wide filter bandwidth; and
wide frequency range.
After a comparison of the three daughter boards, we found that the BURX has a better noise figure than the DBSRX or DBSRX2. The overall performance of the BURX and DBSRX2 are similar however. Using an external amplifier effectively decreases the required gain on all three daughter cards, which correspondingly reduces the effect of the internal thermal noise and enhances the signal noise ratio. As a result, when collecting real wide-band multi-constellation GNSS RF signals, it is preferable to use an external amplifier.
To consider recording GNSS signals across a 50MHz band, DBSRX2 provides the wider filter bandwidth among the three daughter-card options, and thus we selected it as a suitable daughter card.
Custom Wide-band Firmware Development. When initially implementing the wideband multi-constellation GNSS reception devices based on the USRP N210 platform, we found a shortcoming in the default configuration of this architecture, whose maximum bandwidth is 25MHz. It is not wide enough to record 50MHz multi-constellation GNSS signals (BeiDou E2, GPS L1, Galileo E1, and GlonassG1). A 50MHz sampling rate (in some cases as much as 80 MHz) is needed to demodulate the GNSS satellites’ signals.
Meanwhile since the initiation of the research, the USRP manufacturer developed and released a 50MHz firmware. To highlight our efforts, we further modified the USRP N210 default configuration to increase the bandwidth up to 100MHz, which has the potential to synchronously record multi-constellation multi-frequency GNSS signals (Galileo E5a and E5b, GPS L5 and L2) for further investigation of other multi-constellation applications, such as ionospheric dispersion within wideband GNSS signals, or multi-constellation GNSS radio frequency compatibility and interoperability.
Apart from reprogramming the host driver, we focused on reconfiguring the FPGA firmware. With the aid of anatomizing signal flow in the FPGA, we obtained a particular realization method of augmenting its bandwidth. Figure 10 shows the signal flow in the FPGA of the USRP N210 architecture.
Figure 10. Signal flow in the FPGA of the USRP N210 platform.
The ADC produces 14-bit sampled data. After the digital down-conversion implementation in the FPGA, 16-bit complex I/Q sample data are available for the packet transmitting step. According to the induction document of the USRP N210 platform, VITA Radio Transport Protocol functions as an overall framework in the FPGA to provide data transmission and to implement an infrastructure that maintains sample-accurate alignment of signal data. After significant processing in the VITA chain, 36-bit data is finally given to the packet router. The main function of the packet router is to transfer sample data without any data transformation. Finally, through the Gigabit Ethernet port, the host PC receives the complex sample data.
In an effort to widen the bandwidth of the USRP N210 platform, the bit depth needs to be reduced, which cuts 16-bit complex I/Q sample data to a smaller length, such as 8-bit, 4-bit, or even 2-bit, to solve the problem. By analyzing Figure 10, to fulfill the project’s demanding requirements, modification to the data should be performed after ADC sampling, but before the digital down-conversion. We directly extract the 4-bit most significant bits (MSBs) from the ADC sampling data and combined eight 4-bit MSB into a new 16-bit complex I/Q sample, and gave this custom sample data to the packet router, increasing the bandwidth to 100 MHz.
Wide-Band Receiver Performance Analysis. The custom USRP N210-based wide-band multi-constellation GNSS data reception experiment is set up as shown in Figure 11.
Figure 11. Wide-band multi-constellation GNSS data recording system.
A wide-band antenna collected the raw GNSS data, including GPS, GLONASS, Galileo, and BeiDou. An external amplifier was included to decrease the overall noise figure. An OCXO clock was used as the reference clock of the USRP N210 system. After we found the times when Galileo and BeiDou satellites were visible from our location, we first tested the antenna and external amplifier using a commercial receiver, which provided a reference position. Then we used 1582MHz as the reception center frequency and issued the corresponding command on the host computer to start collecting the raw wide-band GNSS signals. By processing the raw wide-band GNSS data through our software receiver, we obtained the acquisition results from all constellations shown in Figure 12; and tracking results displayed in Figure 13.
Figure 12. Acquisition results for all constellations.Figure 13. Tracking results for all constellations.
We could not do the full-constellation position solution because Galileo was not broadcasting navigation data at the time of the collection and the ICD for BeiDou had not yet been released. Therefore, respectively using GPS and GLONASS tracking results, we provided the position solution and timing information that are illustrated in Figure 14 and in Figure 15.
Figure 14. GPS position solution and timing information.Figure 15. GLONASS position solution.
Conclusions
By processing raw wide-band multi-constellation GNSS signals through our software receiver, we successfully acquired and tracked satellites from the four constellations. In addition, since we achieved 100MHz bandwidth, we can also simultaneously capture modernized GPS and Galileo signals (L5 and L2; E5a and E5b, 1105–1205 MHz).
In future work, a longer raw wide-band GNSS data set will be recorded and used to determine the user position leveraging all constellations. Also an urban collection test will be done to assess/demonstrate that multiple constellations can effectively improve the reliability and continuity of GNSS navigation.
Acknowledgment
The first author’s visiting stay to conduct her research at University of Colorado is funded by China Scholarship Council, File No. 2010602084.
This article is based on a paper presented at the Institute of Navigation International Technical Conference 2013 in San Diego, California.
Manufacturers
The USRP N210 is manufactured by Ettus Research. The core of the main board is a high-speed Xilinx Spartan 3A DSP FPGA. Ettus Research provides a support driver called Universal Hardware Driver (UHD) for the USRP hardware. A wide-band Trimble antenna was used in the final experiment.
Ningyan Guo is a Ph.D. candidate at Beihang University, China. She is currently a visiting scholar at the University of Colorado at Boulder.
Staffan Backén is a postdoctoral researcher at University of Colorado at Boulder. He received a Ph.D. in in electrical engineering from Luleå University of Technology, Sweden.
Dennis Akos completed a Ph.D. in electrical engineering at Ohio University. He is an associate professor in the Aerospace Engineering Sciences Department at the University of Colorado at Boulder with visiting appointments at Luleå University of Technology and Stanford University
Economically, the System Differs Significantly from Its GNSS Cousins
John W. Lavrakas
In May 2007, I authored an article in GPS World looking ten years into the future and envisioning how the GNSS field would operate at that then-distant time. Reviewing my assessments, I see that I was both accurate and wide of the mark with my predictions.
The prediction that has proved accurate was that the GNSS world would be hybrid, with no one system as the sole provider of satellite-based positioning and timing services. This was hardly a risky prediction. Most in the GNSS community would have come to the same assessment.
But what I did not see coming were the advances China would take with its BeiDou program. My original assessment was based on three GNSSs only: GPS, GLONASS, and Galileo, and did not include BeiDou.
When I did my analysis in 2006, China was pretty quiet on BeiDou: no technical descriptions, no interface control document (ICD); no presentations at conferences of the Institute of Navigation. What little we knew about BeiDou was that it was a limited system, offering at best a regional solution. The original design was an active system using geosynchronous satellites, requiring each remote unit to request position from the satellite, which was calculated and sent back to the remote station.
How things have changed.
Since 2007, China has reshaped the BeiDou concept into a full-fledged modern GNSS, offering CDMA codes, navigation messages, and data rates comparable to GPS and Galileo — and lots of satellites. The ICD states in section 3.1, “When fully deployed, the space constellation of BDS consists of five geostationary Earth-orbit (GEO) satellites, twenty-seven medium Earth-orbit (MEO) satellites, and three inclined geosynchronous satellite orbit (IGSO) satellites.” No dates are provided, however, regarding attaining these numbers. So the BeiDou system promises to be on par with the other GNSSs.
Why does this matter?
While technically the BeiDou system resembles its cousins, economically it presents quite a different animal. Unlike other nations offering GNSS, China has a huge capacity for manufacturing at low cost. Considering this situation from a business perspective, a possible scenario could be that China offers GNSS chipsets that operate with BeiDou (either solely or as a hybrid with another GNSS)at extremely low prices. In doing so, China could corner the market for general purpose LBS applications (setting aside specialty receivers, such as for surveying and aviation applications). The price point would be so attractive that LBS services would employ Chinese devices in preference to the GPS ones, much like consumers purchase television sets: most come from China, and none are made in the United States any more.
China offers something, then, in this scenario that neither Russia, Europe, nor the United States can currently match. This may not be the scenario that eventually occurs, but it is possible. Other factors such as local terrestrial PNT solutions and dual-frequency improvements will come into play, but what I have described is one possible scenario. While the signal is free, the equipment is not, and when we are talking about a billion or more installations, cost is going to be a big driver.
Am I going out on a limb and saying that BeiDou will be the system of choice in another ten years or so? No, I would not go this far.
But I do say that serious competition for GNSS users (read “market share”) is now in play. Further, it is important for each GNSS operator to recognize this as they consider the services and features they choose to offer, and the impact these have in capturing their share of the market. GNSS providers now must factor the business aspect of their services as much as the technical, scientific, or safety of life. The U.S. government, for one, has gotten a bit complacent in upgrading GPS services to meet user needs, operating from a basis that it is the only GNSS on the block. It could wake up one day and find this no longer to be the case.
John Lavrakas is president of Advanced Research Corporation, where he provides consulting services on satellite navigation and fishery information systems. He has spent 32 years in GPS, supporting development of the GPS Control Segment, GPS user equipment, GPS performance analysis capabilities, and developing and marketing location-based systems. He is past president of the Institute of Navigation and an ION Fellow.
A Case History Using the New Galileo E6-B/C Signal
By Sergei Yudanov, JAVAD GNSS
A method of decoding an unknown pseudorandom noise code uses a conventional GNSS antenna and receiver with modified firmware. The method was verified using the signals from the Galileo In-Orbit Validation satellites.
Decoding an unknown GNSS pseudorandom noise (PRN) code can be rather easily done using a high-gain steerable dish antenna as was used, for example, in determine the BeiDou-M1 broadcast codes before they were publicly announced. The signal-to-noise ratio within one chip of the code is sufficient to determine its sign. This article describes a method of getting this information using a conventional GNSS antenna and receiver with modified firmware. The method was verified using the signals from the Galileo In-Orbit Validation (IOV) satellites. In spite of the fact that only pilot signal decoding seems to be possible at first glance, it is shown that in practice data signals can also be decoded.
Concept
The idea is to do coherent accumulation of each chip of an unknown signal during a rather long time interval. The interval may be as long as a full satellite pass; for medium Earth orbits, this could be up to six hours. One of the receiver’s channels is configured in the same way as for signal tracking. The I and Q signal components are accumulated during one chip length in the digital signal processor, and these values are added to an array cell, referenced by chip number, by the processor. Only a limited amount of information need be known about the signal: its RF frequency; the expected chip rate; the expected total code length; and the modulation method.
The decoding of binary-phase-shift-keying (BPSK) signals (as most often used) is the subject of this article. It appears that the decoding of more complicated signals is possible too, but this should be proved. A limitation of this method (in common with that of the dish method) is the maximum total code length that can be handled: for lengths greater than one second and bitrates higher than 10,000 kilobits per second, the receiver’s resources may not be sufficient to deal with the signal.
Reconstructing the Signal’s Phase
This method requires coherency. During the full accumulation period, the phase difference between the real signal phase and the phase of the signal generated by the receiver’s channel should be much less than one cycle of the carrier frequency. Depending on the GNSS’s available signals, different approaches may be used. The simplest case is reconstruction of a third signal while two other signals on different frequencies are of known structure and can be tracked.
The main (and possibly the only significant) disturbing factor is the ionosphere. The ionospheric delay (or, more correctly, the variation of ionospheric delay) is calculated using the two known tracked signals, then the phase of the third signal, as affected by the ionosphere, is predicted.
The final formula (the calculations are trivial and are widely available in the literature) is:
where:
φ1 , f1 are the phase and frequency of the first signal in cycles and Hz, respectively
φ2 , f2 are the phase and frequency of the second signal in cycles and Hz, respectively
φ3 , f3 are the phase and frequency of the third signal in cycles and Hz, respectively.
It was confirmed that for all pass periods (elevation angles less than 10 degrees were not tested), the difference between the calculated phase and real phase was always less than one-tenth of a cycle. GPS Block IIF satellites PRN 1 and PRN 25 were used to prove this: the L1 C/A-code and L5 signals were used as the first and second signals, with the L2C signal as the third unknown.
If two known signals are not available, and the ionospheric delay cannot be precisely calculated, it is theoretically possible to obtain an estimate of the delay from one or more neighboring satellites with two signals available. Calculations and estimations should be carried out to investigate the expected precision.
The Experiment
The Galileo E6-B/C signal as currently transmitted by the IOV satellites was selected for the experiment, as its structure has not been published. The E6 signal has three components: E6-A, E6-B and E6-C. The E6-A component is part of the Galileo Public Regulated Service, while the two other components will serve the Galileo Commercial Service. The E6-B component carries a data signal, while the E6-C component is a pilot signal.
From open sources, it is known that the carrier frequency of the E6 signal is 1278.75 MHz and that the E6-B and E6-C components use BPSK modulation at 5,115 chips per millisecond with a primary code length of one millisecond. E6-B’s data rate is 1,000 bits per second and the total length of the pilot code is 100 milliseconds (a secondary code of 100 bits over 100 milliseconds is also present in the E6-C signal, which aids in signal acquisition).
A slightly modified commercial high-precision multi-GNSS receiver, with the E6 band and without the GLONASS L2 band, was used for this experiment. The receiver was connected to a conventional GNSS antenna, placed on a roof and was configured as described above. The E1 signal was used as the first signal and E5a as the second signal. The E6 code tracking (using 5,115 chip values of zero) was 100 percent guided from the E1 code tracking (the changing of the code delay in the ionosphere was ignored). The E6 phase was guided from E1 and E5a using the above equation. Two arrays for 511,500 I and Q samples were organized in firmware. The integration period was set to one chip (200 nanoseconds).
Galileo IOV satellite PRN 11 (also variously known as E11, ProtoFlight Model and GSAT0101) was used initially, and the experiment started when the satellite’s elevation angle was about 60 degrees and lasted for only about 30 minutes. Then the I and Q vectors were downloaded to a PC and analyzed.
Decoding of Pilot Signal (E6-C)
Decoding of the pilot signal is made under the assumption that any possible influence of the data signal is small because the number of ones and zeros of E6-B in each of 511,500 chips of the 100-millisecond integration interval is about the same. First, the secondary code was obtained. Figure 1 shows the correlation of the first 5,115 chips with 5,115 chips shifted by 0 to 511,500 chips. Because the initial phase of the E6 signal is unknown, two hypotheses for computing the amplitude or signal level were checked: [A] = [I] + [Q] and [A] = [I] – [Q], and the combination with the higher correlation value was selected for all further analysis.
Figure 1. Un-normalized autocorrelation of E6-C signal chips.
In Figure 1, the secondary code is highly visible: we see a sequence of 100 positive and negative correlation peaks (11100000001111 …; interpreting the negative peaks as zeros).This code is the exact complement (all bits reversed) of the published E5a pilot secondary code for this satellite. More will be said about the derived codes and their complements later. It appears that, for all of the IOV satellites, the E6-C secondary codes are the same as the E5a secondary codes.
After obtaining the secondary code, it is possible to coherently add all 100 milliseconds of the integration interval with the secondary code sign to increase the energy in each chip by 100 times. Proceeding, we now have 5,115 chips of the pilot signal — the E6-C primary code.
To understand the correctness of the procedure and to check its results, we need to confirm that there is enough signal energy in each chip. To this end, a histogram of the pilot signal chip amplitudes can be plotted (see Figure 2). We see that there is nothing in the middle of the plot. This means that all 5,115 chips are correct, and there is no chance that even one bit is wrong.
Figure 2. Histogram of pilot signal chip amplitude in arbitrary units.
But there is one effect that seems strange at first glance: instead of two peaks we have four (two near each other). We will shortly see that this phenomenon results from the influence of the E6-B data signal and it may be decoded also.
Decoding the Data Signal
The presence of four peaks in the histogram of Figure 2 was not understood initially, so a plot of all 511,500 signal code chips was made (see Figure 3).
Interestingly, each millisecond of the signal has its own distribution, and milliseconds can be found where the distribution is close to that when two signals with the same chip rate are present. In this case, there should be three peaks in the energy (signal strength) spectrum: –2E, 0, and +2E, where E is the energy of one signal (assuming the B and C signals have the same strength).
Figure 3. Plot of 511,500 signal code chip amplitudes in arbitrary units.
One such time interval (starting at millisecond 92 and ending at millisecond 97) is shown in Figure 4. The middle of the plot (milliseconds 93 to 96) shows the described behavior. Figure 5 is a histogram of signal code chip amplitude for the signal from milliseconds 93 to 96.
Figure 4. Plot of signal code chip amplitude in arbitrary units from milliseconds 93 to 96.
Then we collect all such samples (milliseconds) with the same data sign together to increase the signal level. Finally, 5,115 values are obtained. Their distribution is shown in Figure 6.
The central peak is divided into two peaks (because of the presence of the pilot signal), but a gap between the central and side peaks (unlike the case of Figure 5) is achieved. This allows us to get the correct sign of all data signal chips. Subtracting the already known pilot signal chips, we get the 5,115 chips of the data signal — the E6-B primary code. This method works when there are at least some samples (milliseconds) where the number of chips with the same data bit in the data signal is significantly more than half.
Figure 5. Histogram of signal code chip amplitude.Figure 6. Histogram of the signed sum of milliseconds chip amplitude with a noticeable presence of the data signal.
Proving the Codes
The experimentally determined E6-B and E6-C primary codes and the E6-C secondary codes for all four IOVsatellites (PRNs 11, 12, 19, and 20) were put in the receiver firmware. The receiver was then able to autonomously track the E6-B and E6-C signals of the satellites.
Initial decoding of E6-B navigation data has been performed. It appears that the data has the same preamble (the 16-bit synchronization word) as that given for the E6-B signal in the GIOVE Interface Control Document (ICD). Convolutional encoding for forward error correction is applied as described in the Galileo Open Service ICD, and 24-bit cyclic redundancy check error detection (CRC-24) is used. At the time of the analysis, all four IOV satellites transmitted the same constant navigation data message.
Plots of PRN 11 E6 signal tracking are shown in Figure 7 and in Figure 8. The determined codes may be found at env-gpsworld-integration.kinsta.cloud/galileo-E6-codes. Some of these codes may be the exact complement of the official codes since the code-determination technique has a one-half cycle carrier-phase ambiguity resulting in an initial chip value ambiguity. But from the point of view of receiver tracking, this is immaterial.
Figure 7. Signal-to-noise-density ratio of E1 (red), E5a (magenta), E5b (blue), and E6 (green) code tracking of Galileo IOV satellite PRN 11 on December 21–22, 2012.Figure 8. Pseudorange minus carrier phase (in units of meters) of E1 (red), E5a (magenta), E5b (blue), and E6 (green) code tracking of Galileo IOV satellite PRN 11 on December 21–22, 2012.
Acknowledgments
Special thanks to JAVAD GNSS’s DSP system developers. The system is flexible so it allows us to do tricks like setting the integration period to one chip, and powerful enough to be able to do required jobs within a 200-nanosecond cycle. This article was prepared for publication by Richard Langley.
Manufacturers
A JAVAD GNSS TRE-G3T-E OEM receiver, a modification of the TRE-G3T receiver, was used in the experiment, connected to a conventional JAVAD GNSS antenna. Plots of E6 code tracking of all four IOV satellites may be found on the company’s website.
Sergei Yudanov is a senior firmware developer at JAVAD GNSS, Moscow.
Swiss-based u‑blox, a provider of GPS/GNSS and wireless semiconductors, has achieved successful satellite positioning using China’s BeiDou Navigation Satellite System. According to u-blox, the technical achievement establishes u-blox as the first GNSS component vendor to demonstrate compatibility with all globally deployed positioning systems: GPS, GLONASS, Galileo, QZSS and now BeiDou.
However, NovAtel has also announced support for the BeiDou Navigation Satellite System on its OEM6 family and select OEMStar GNSS receivers.
Customer demonstration of the u-blox technology will begin during Q1 2013.
“We are thrilled to have achieved this milestone only three weeks after the BeiDou specification was published,” said Thomas Seiler, u-blox CEO. “China will become the world’s most important single market for devices relying on embedded satellite navigation, and u-blox plans to be a major player in this market.”
BeiDou-2 currently has 15 satellites in orbit, offering navigation and positioning services to users in China and Southeast Asia. It will ultimately consist of 35 satellites providing worldwide positioning capability over its open service to within 10 meters accuracy.
u-blox will be demonstrating BeiDou compatibility with their latest GNSS platform at embeddedworld 2013 February 26-28 in Nuremberg, Germany, stand 4A-325.
NovAtel announces support for the BeiDou Navigation Satellite System on its OEM6 family and select OEMStar GNSS receivers.
The long-anticipated BeiDou Navigation Satellite System (BDS) Interface Control Document (ICD) release is a significant milestone that facilitates global acceptance of BeiDou into the growing range of satellite-based positioning applications, NovAtel said.
NovAtel has a long-standing partnership with several Chinese GNSS system manufacturers. This partnership has allowed NovAtel to verify B1 and B2 signal tracking on its latest generation receivers. The company has been supplying GNSS receivers that include the BeiDou constellation since Q4 2010.
“We are excited to see what performance improvements BeiDou will provide to our AdVance RTK, GL1DE and SPAN GNSS/INS positioning algorithms,” said Pat Fenton, NovAtel CTO.
BeiDou positioning has been available through NovAtel’s Chinese partners utilizing the receiver Application Programming Interface (API) feature. With the BeiDou ICD made available to the public, NovAtel is now able to offer BeiDou positioning on its receiver products directly.
Firmware updates for the OEM6 and OEMStar receivers will enable tracking of the BeiDou signal in conjunction with GPS, GLONASS, Galileo and QZSS signals that are currently supported. Over the coming months NovAtel will be working with early-adopter customers to optimize their receiver positioning engines to support the BeiDou signals.
Customers interested in trialing BeiDou functionality on their receivers should contact NovAtel Customer Support at [email protected].
