Evaluation Kit NV08C-EVK-CSM by NVS Technologies is a set of instruments for a developer of systems based on NVS Technologies’ NV08C-CSM module. Use of EVK-CSM is a convenient way to learn functionality of NV08C-CSM and begin system design.
The EVK-CSM may be used in navigation systems to obtain the current position (latitude, longitude and elevation), velocity vector, and time GNSS signals including GPS, GLONASS, Galileo, Compass, and SBAS in any location on Earth and at any time. The EVK-CSM is a flexible tool that allows users to evaluate various modes of operation of the NV08C-CSM and to override a default configuration and connection diagram with jumpers.
Connectors and jumpers on EVK-CSM PCB provide simple monitoring of intermediate signals and parameters (digital IOs state, power supply voltages, and currents on individual supply inputs).
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.
by James T. Curran, Mark Petovello, and Gérard Lachapelle
Within a day of their initial activation over central Europe on March 12, Galileo satellites were visible over North America. The PLAN Group of the University of Calgary was successful in capturing and processing the signals from these satellites as they emerged. Galileo PRN 11, 12, and 19 were found and tracked on E1B/C. The PLAN software GSNRx was also able to track simultaneously GPS L1 and GLONASS L1 and produce combined position solutions.
Examining the Galileo navigation message transmitted on the E1B signal, it was found that the satellite health status is flagged as E1BHS=3 meaning Signal Component currently in Test, and the data validity status is flagged as E1BDVS=1 meaning Working without Guarantee. Current Galileo-ready commercial receivers may automatically discard measurements from a satellites broadcasting such messages. Parsing the received words in the I/NAV message, it was noted that more 50 percent of them were of type 0, although all words (types 0 to 10) were decoded at some point during the test.
Data was collected using a roof-mounted NovAtel 702GG antenna and an in-house two-channel digitizing front-end clocked by a high quality OCXO and also a three-channel National Instruments front-end for post-processing. The two-channel intermediate frequency data was streamed live to a laptop computer for real-time processing with GSNRx. Two RF channels were processed, the first centered at 1574.0 MHz with an IF bandwidth of 10.0 MHz, for the GPS L1 C/A and Galileo E1B/C signals and the second centered at 1602.0 MHz again with a bandwidth of 10.0 MHz, for the GLONASS L1 OF signals. The GPS and GLONASS signals were tracked using a Kalman-filter-based tracking strategy while the Galileo signals were tracked using a specialized data-pilot algorithm.
Figure 1. Scatter plot of the north and east position
Pseudorange and Doppler observations were extracted from the tracking strategies at a rate of 2 Hz. A 2D horizontal plot of the combined GPS & GLONASS and the combined Galileo, GLONASS & GPS single-frequency single-point solutions is presented in Figure 1.
Figure 2: Skyplot of the Galileo satellites.
The pseudorange residuals are plotted against time for each PRN tracked from each of the three systems in Figure 3. It is apparent that the addition of the three Galileo observations contributes to a reduction in bias and standard deviation in the horizontal directions, showing an excellent functioning of the Galileo satellites and PLAN Group equipment and software.
Figure 3. Pseudorange residuals are plotted against time for each PRN tracked from each of the three systems.Figure 4. A screenshot of the receiver processing the data.
Septentrio became the first receiver manufacturer to report an autonomous real-time position calculation using Galileo IOV satellites, with its own standard commercial receiver. The company based in Leuven, Belgium announced on March 12 that it performed a first autonomous real-time Galileo position, velocity, and timing (PVT) calculation, based on live Interface Control Document (ICD)-compliant Galileo messages from the four Galileo in-orbit validation (IOV) satellites.
The standalone position was calculated from in-orbit navigation messages using a standard PolaRx4 GNSS receiver equipped with commercially released firmware.
This achievement followed another recent Septentrio milestone; the announcement of a first GPS+Glonass+BeiDou PVT less than two weeks after the BeiDou2 ICD publication in December — and it was itself followed by a Septentrio release stating performance of what it believes to be the first 4-constellation PVT performed by a standard commercial receiver.
“On Tuesday 12-Mar-2013 at approximately 10:35 UTC we included three Galileo IOV satellites (E12, E19 & E20) in a multi-constellation PVT. The 3D-position fix happened shortly after it was brought to Septentrio’s attention that the Galileo IOV satellites were transmitting, for the first time ever, a fully usable navigation message as part of an ESA experiment.
“This ability to rapidly incorporate new constellations demonstrates the flexibility of the architecture of Septentrio receivers,” the company statement continued.
“We are delighted that Septentrio receivers are amongst the first to witness the readiness of the Galileo navigation message to perform a position fix from in orbit signals,” commented Peter Grognard, Septentrio’s founder and CEO. “Septentrio has been involved since 2003 in all major milestones that pave the way for the European constellation genesis.”
IFEN GmbH, based outside of Munich, Germany, has established IFEN Inc. in the United States. The new U.S. company will address the needs of the American market for GNSS test equipment, IFEN said.
“IFEN Inc., located in Corona, California, will greatly facilitate order placement, delivery and support for U.S. customers,” said Günter Heinrichs, head of Customer Applications and Business Development, of IFEN GmbH. “We look forward to addressing the needs of this market.”
IFEN has appointed of Mark Wilson vice president of sales at IFEN Inc. Wilson has more than 20 years of experience in the GNSS market. “I am very excited to join the IFEN team. They have extensive experience in all aspects of GNSS and I am looking forward to offering this expertise and the excellent IFEN products to the American Market,” Wilson said. “Our exceptional products offer unrivaled flexibility and capability, at realistic prices providing huge advantages to our customers.”
IFEN has more than 15 years of experience in GNSS and offers a range of GNSS test equipment, including simulators capable of simulating all GNSS constellations and frequencies and a multi-GNSS software receiver.
Spectracom announces its ability to simulate up to 64 RF channels in four frequency bands for testing the integration of most advanced GNSS receivers.
The GSG series of GNSS simulators are designed to offer as much capability as needed by developers, integrators, and manufacturers of applications for global satellite navigation. “We understand the needs for simulating GPS and GNSS signals varies as much as the applications themselves,” said Spectracom CTO John Fischer. “Now the diversity of GNSS signals enables a new generation of receivers requiring a new set of test tools. We designed our simulators to grow along with the GNSS eco-system while maintaining the affordability and ease-of-use that has been our hallmark.”
Spectracom offers two fully configurable and upgradeable platforms. For common single frequency applications, the GSG-5 series simulates up to 16 GPS satellites in the L1 band. Users can start with a single-channel RF generator and upgrade their unit in the field when their needs change. For more advanced applications, the GSG-6 series offers up to 64 channels in four different frequency bands simultaneously. Current firmware generates GPS and GLONASS satellites in L1, L2, L2C, and L5. Customers will receive firmware updates when they need to simulate Galileo and Beidou satellites in the E1/B1, E5/B2, E6/B3 bands.
In addition to generating satellite signals, these GPS and GNSS simulators include other advanced capability in every unit such as simulating satellite-based augmentation systems (SBAS), dynamic motion characteristics (trajectories), multipath, white noise, and interference. Tests can be performed anywhere, anytime, from the convenience of the test bench, Spectracom said.
“Comprehensive testing and validation of high-reliability positioning, navigation and timing applications has been a natural extension of our rich heritage in delivering precision time and frequency products and systems,” said Spectracom CEO Lisa Withers. “As we continue to expand our GNSS signal management offerings, we are excited to introduce synchronization, simulation and test solutions that are geared to be readily adaptable to our customers’ unique applications.”
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
New Organization Advocates for GPS Industry; Galileo Lives to Fly Another Day, Budget Passed; Safer Skies for EGNOS; and GLONASS in Brazil
New Organization Advocates for GPS Industry
A new group, the GPS Innovation Alliance, has formed and announced itself as the voice of the U.S. GPS industry and community of users, to “support the ever-increasing importance of GPS” in the U.S. capital, Washington, D.C. The organization subsumes and replaces both the U.S. GPS Industry Council, an entity of longstanding, and the Coalition to Save Our GPS, which arose in March 2011 in response to a Federal Communications Commission (FCC) conditional waiver granted to LightSquared.
The alliance appears to reflect a desire on the part of some industry members to take a more aggressive approach inside the Washington Beltway, a sign, it would seem, of the political times. Some of those involved spoke informally of a desire to take advantage of contacts made on Capitol Hill and in the media during the highly visible LightSquared combat, fought in the glare of media attention heretofore unknown in industry circles.
GPSv Innovation Alliance logo
Members of the Alliance are drawn from a variety of fields and businesses reliant on GPS, as well as leading manufacturers of GPS equipment. The former group includes, aviation, agriculture, construction, transportation, first responders, and surveying and mapping, and consumer organizations representing users of GPS for boating and other outdoor activities, and in automobiles, smartphones, and tablets.
Joining John Deere, Garmin, and Trimble — three lead drivers of the Coalition effort at the FCC — are NovAtel Inc. and Topcon Positioning Systems. All five were previously long-time members of the USGIC, and they appear as founding members of the alliance at www.gpsalliance.org.
Affiliate members listed on the website include the Association of Equipment Manufacturers, General Aviation Manufacturers Association, National Association of Manufacturers, Association for Unmanned Aerial Vehicles International, and Boat Owners Association of the United States.
The alliance plans to build on “the proud heritage and extensive expertise of the United States GPS Industry Council (USGIC), which was formed in 1991 to promote broader commercial applications of GPS and to expand global markets while assisting in safeguarding the technology’s military advantages. The council has a long history of highly effective advocacy on behalf of the GPS industry, as well as serving as a trusted source of objective information for policy makers, the media and the public both in the U.S. and around the world.” The alliance website gives a longer statement about the history and record of the USGIC, highlighting its role in international negotiations.
Michael Swiek, executive director of the USGIC, has transitioned to become the executive director, executive branch and international, of the Innovation Alliance. In addition to working closely with leading offices of executive branch departments of the U.S. government, he will continue well-established dialogs with governmental, private sector and academic entities in areas critical to GPS and satellite navigation among key players in Europe, Japan, Russia, Korea, China, and elsewhere.
Heather Hennessey, a principal of Innovative Federal Strategies LLC, a “comprehensive government relations firm,” has taken the position of executive director, legislative, at the alliance. Hennessey has seven years of service in the House of Representatives, including two years as chief of staff for Congressman Jack Kingston of Georgia.
An active voice in alliance representations on Capitol Hill will presumably be that of Jim Kirkland, vice president and general counsel for Trimble. Kirkland was the most prominent spokesperson for the coalition during the LightSquared battle, which appears to be either over or nearly so. “The alliance is committed to ensuring constructive, robust dialog between GPS users, manufacturers and policy makers on critical policy issues affecting GPS,” Kirkland said, “a commitment Trimble is pleased to be a part of as the industry continues to innovate and modernize.”
The alliance mission statement cites the importance of GPS to global economy and infrastructure; vows to aid further GPS innovation, creativity and entrepreneurship; and to protect, promote and enhance the use of GPS.
The GPS Innovation Alliance officially launched on February 13 with a reception on Capitol Hill, a traditional lobbying tactic that previous efforts had perhaps not envisioned. The organization has also hired a public relations firm, Prism Public Affairs, and commissioned a logo.
Galileo Lives to Fly Another Day, Budget Passed
European Union leaders approved a scaled-down budget in early February, with none of the cuts to the Galileo program that had been widely feared. The project, conducted by the European Space Agency (ESA) under close supervision of the European Commission (EC), will draw on funding of 6.3 billion euros (about $8.5 billion) from 2014 to 2020. The satellite navigation program held onto its requested revised budget of 6.3 billion euros, even as telecommunications research and broadband deployment projects, including another ESA pet project, the somewhat related Copernicus Global Monitoring for Environment and Security (GMES), underwent severe cuts. Galileo has already spent more than 3 billion euros ($4 billion), three times its original budget, to launch four of an envisioned 30-satellite constellation.
The EU deliberative system requires unanimous approval of budget decisions, so what smaller countries seek for their farmers or fishermen carries practically equal weight to the desire of industrial/aerospace giants like Germany, closely followed by France and the United Kingdom. Negotiation is a delicate matter indeed, and reached an impasse in November 2012; resolution came only after a 24-hour marathon session of talks. The total budget represents the first decrease in the European Union’s history; austerity is the watchword in a region beset with an ongoing bevy of international debt crises and serious recession in many of the smaller EU countries.
Galileo supporters within the European Commission, the EU’s policy-making arm, continued to maintain that Galileo will “open a whole new world” for business to develop applications, as Antonio Tajani, EC vice president stated recently. The program drew strong support, for once, from powerful backers in the EU administrative capital, Brussels, and among industrial and political interests in key member states: France, Germany, and for an exception Britain, often a proponent of deep cuts.
Negotiators helped Galileo’s chances by placing it in a research group labeled “Competitiveness for Growth and Jobs.” This category actually rose in budget allocation by nearly 40 percent over the last seven-year allotment.
The allocation should cover operational costs for EGNOS and Galileo, the completion of the initial Galileo constellation of 14, and early procurement stages of a full, or second-generation orbiting set of 30.
The program still faces an extremely unlikely date for the establishment of early services by the end of 2014. “Then, the market, as well as the governments of the Member States, will start increasing their interest and promoting further investments,” the ever-optimistic Tajani maintained.
The budget must still secure approval by the European Parliament. Its president, Martin Schulz of Germany has stated, “The further we step away from the Commission’s proposed figures, the more likely the proposal will be rejected. More and more tasks, and less and less money — the inevitable result is budget deficits. The Parliament will not go along with this.”
Parliament’s decision is forecast for the summer months. Parliament’s budget power consists of a direct yes-or-no vote to accept or reject the budget. The body cannot make modifications, and if rejecting would simply send it back to the EU ministers to begin all over again. The picture is further complicated somewhat by the 20-nation make-up of ESA, whereas the European Union and its executive commission have 27 national members.
Safer Skies for EGNOS
Results of a September 2012 flight test in the Galileo Test and Development Environment (GATE) near Berchtesgaden, Germany, the one place on Earth where Galileo services are already routinely available, show that adding Galileo signals to the European Geostationary Navigation Overlay Service (EGNOS) should boost accuracy significantly. EGNOS augments the accuracy and reliability of GPS signals over Europe, rendering satnav usable for safety-critical applications such as aircraft guidance, as well as more general precision uses.
Operational horizontal and vertical distance “protection levels” for safety were cut by half by combining use of GPS and Galileo within EGNOS. In addition, new integrity algorithms installed within the user receiver turned out to reliably detect and exclude reflected or otherwise faulty signals.
Next-generation EGNOS, planned for 2020, is envisaged to augment both constellations and dual frequencies at the same time, making the system much more robust.
GLONASS in Brazil
The first overseas GLONASS ground monitoring station for differential correction and monitoring outside Russian territory opened in Brasilia, Brazil, in mid-February. The station represents an early step in an initiative to modernize and significantly improve the accuracy of GLONASS signals.
Plans call for similar monitoring stations “in more than 30 countries of the world. Most of the countries that received the offers for the installation of the stations responded positively.However, the process is slow because of the need to conclude appropriate intergovernmental agreements. The documents with Brazil were signed in 2012. Agreements with Spain, Indonesia and Australia will be finalized soon,” according to a Pravda story.
Monitoring the Ionosphere with Integer-Leveled GPS Measurements
By Simon Banville, Wei Zhang, and Richard B. Langley
INNOVATION INSIGHTS by Richard Langley
IT’S NOT JUST FOR POSITIONING, NAVIGATION, AND TIMING. Many people do not realize that GPS is being used in a variety of ways in addition to those of its primary mandate, which is to provide accurate position, velocity, and time information.
The radio signals from the GPS satellites must traverse the Earth’s atmosphere on their way to receivers on or near the Earth’s surface. The signals interact with the atoms, molecules, and charged particles that make up the atmosphere, and the process slightly modifies the signals. It is these modified or perturbed signals that a receiver actually processes. And should a signal be reflected or diffracted by some object in the vicinity of the receiver’s antenna, the signal is further perturbed — a phenomenon we call multipath.
Now, these perturbations are a bit of a nuisance for conventional users of GPS. The atmospheric effects, if uncorrected, reduce the accuracy of the positions, velocities, and time information derived from the signals. However, GPS receivers have correction algorithms in their microprocessor firmware that attempt to correct for the effects. Multipath, on the other hand, is difficult to model although the use of sophisticated antennas and advanced receiver technologies can minimize its effect.
But there are some GPS users who welcome the multipath or atmospheric effects in the signals. By analyzing the fluctuations in signal-to-noise-ratio due to multipath, the characteristics of the reflector can be deduced. If the reflector is the ground, then the amount of moisture in the soil can be measured. And, in wintery climes, changes in snow depth can be tracked from the multipath in GPS signals.
The atmospheric effects perturbing GPS signals can be separated into those that are generated in the lower part of the atmosphere, mostly in the troposphere, and those generated in the upper, ionized part of the atmosphere — the ionosphere. Meteorologists are able to extract information on water vapor content in the troposphere and stratosphere from the measurements made by GPS receivers and regularly use the data from networks of ground-based continuously operating receivers and those operating on some Earth-orbiting satellites to improve weather forecasts.
And, thanks to its dispersive nature, the ionosphere can be studied by suitably combining the measurements made on the two legacy frequencies transmitted by all GPS satellites. Ground-based receiver networks can be used to map the electron content of the ionosphere, while Earth-orbiting receivers can profile electron density. Even small variations in the distribution of ionospheric electrons caused by earthquakes; tsunamis; and volcanic, meteorite, and nuclear explosions can be detected using GPS.
In this month’s column, I am joined by two of my graduate students, who report on an advance in the signal processing procedure for better monitoring of the ionosphere, potentially allowing scientists to get an even better handle on what’s going on above our heads.
Representation and forecast of the electron content within the ionosphere is now routinely accomplished using GPS measurements. The global distribution of permanent ground-based GPS tracking stations can effectively monitor the evolution of electron structures within the ionosphere, serving a multitude of purposes including satellite-based communication and navigation.
It has been recognized early on that GPS measurements could provide an accurate estimate of the total electron content (TEC) along a satellite-receiver path. However, because of their inherent nature, phase observations are biased by an unknown integer number of cycles and do not provide an absolute value of TEC. Code measurements (pseudoranges), although they are not ambiguous, also contain frequency-dependent biases, which again prevent a direct determination of TEC. The main advantage of code over phase is that the biases are satellite- and receiver-dependent, rather than arc-dependent. For this reason, the GPS community initially adopted, as a common practice, fitting the accurate TEC variation provided by phase measurements to the noisy code measurements, therefore removing the arc-dependent biases. Several variations of this process were developed over the years, such as phase leveling, code smoothing, and weighted carrier-phase leveling (see Further Reading for background literature).
The main challenge at this point is to separate the code inter-frequency biases (IFBs) from the line-of-sight TEC. Since both terms are linearly dependent, a mathematical representation of the TEC is usually required to obtain an estimate of each quantity. Misspecifications in the model and mapping functions were found to contribute significantly to errors in the IFB estimation, suggesting that this process would be better performed during nighttime when few ionospheric gradients are present. IFB estimation has been an ongoing research topic for the past two decades are still remains an issue for accurate TEC determination.
A particular concern with IFBs is the common assumption regarding their stability. It is often assumed that receiver IFBs are constant during the course of a day and that satellite IFBs are constant for a duration of a month or more. Studies have clearly demonstrated that intra-day variations of receiver instrumental biases exist, which could possibly be related to temperature effects. This assumption was shown to possibly introduce errors exceeding 5 TEC units (TECU) in the leveling process, where 1 TECU corresponds to 0.162 meters of code delay or carrier advance at the GPS L1 frequency (1575.42 MHz).
To overcome this limitation, one could look into using solely phase measurements in the TEC estimation process, and explicitly deal with the arc-dependent ambiguities. The main advantage of such a strategy is to avoid code-induced errors, but a larger number of parameters needs to be estimated, thereby weakening the strength of the adjustment. A comparison of the phase-only (arc-dependent) and phase-leveled (satellite-dependent) models showed that no model performs consistently better. It was found that the satellite-dependent model performs better at low-latitudes since the additional ambiguity parameters in the arc-dependent model can absorb some ionospheric features (such as gradients). On the other hand, when the mathematical representation of the ionosphere is realistic, the leveling errors may more significantly impact the accuracy of the approach.
The advent of precise point positioning (PPP) opened the door to new possibilities for slant TEC (STEC) determination. Indeed, PPP can be used to estimate undifferenced carrier-phase ambiguity parameters on L1 and L2, which can then be used to remove the ambiguous characteristics of the carrier-phase observations. To obtain undifferenced ambiguities free from ionospheric effects, researchers have either used the widelane/ionosphere-free (IF) combinations, or the Group and Phase Ionospheric Calibration (GRAPHIC) combinations. One critical problem with such approaches is that code biases propagate into the estimated ambiguity parameters. Therefore, the resulting TEC estimates are still biased by unknown quantities, and might suffer from the unstable datum provided by the IFBs.
The recent emergence of ambiguity resolution in PPP presented sophisticated means of handling instrumental biases to estimate integer ambiguity parameters. One such technique is the decoupled-clock method, which considers different clock parameters for the carrier-phase and code measurements. In this article, we present an “integer-leveling” method, based on the decoupled-clock model, which uses integer carrier-phase ambiguities obtained through PPP to level the carrier-phase observations.
Standard Leveling Procedure
This section briefly reviews the basic GPS functional model, as well as the observables usually used in ionospheric studies. A common leveling procedure is also presented, since it will serve as a basis for assessing the performance of our new method.
Ionospheric Observables. The standard GPS functional model of dual-frequency carrier-phase and code observations can be expressed as:
(1)
(2)
(3)
(4)
where Φijis the carrier-phase measurement to satellite j on the Li link and, similarly, Pijis the code measurement on Li. The term is the biased ionosphere-free range between the satellite and receiver, which can be decomposed as:
(5)
The instantaneous geometric range between the satellite and receiver antenna phase centers is ρ j. The receiver and satellite clock errors, respectively expressed as dT and dtj, are expressed here in units of meters. The term Tj stands for the tropospheric delay, while the ionospheric delay on L1 is represented by I j and is scaled by the frequency-dependent constant μ for L2, where . The biased carrier-phase ambiguities are symbolized by and are scaled by their respective wavelengths (λi). The ambiguities can be explicitly written as:
(6)
where Ni jis the integer ambiguity, bi is a receiver-dependent bias, and bi j is a satellite-dependent bias. Similarly, Bi and Bi j are instrumental biases associated with code measurements. Finally, ε contains unmodeled quantities such as noise and multipath, specific to the observable. The overbar symbol indicates biased quantities.
In ionospheric studies, the geometry-free (GF) signal combinations are formed to virtually eliminate non-dispersive terms and thus provide a better handle on the quantity of interest:
(7)
(8)
where IFBr and IFB j represent the code inter-frequency biases for the receiver and satellite, respectively. They are also commonly referred to as differential code biases (DCBs). Note that the noise terms (ε) are neglected in these equations for the sake of simplicity.
Weighted-Leveling Procedure. As pointed out in the introduction, the ionospheric observables of Equations (7) and (8) do not provide an absolute level of ionospheric delay due to instrumental biases contained in the measurements. Assuming that these biases do not vary significantly in time, the difference between the phase and code observations for a particular satellite pass should be a constant value (provided that no cycle slip occurred in the phase measurements). The leveling process consists of removing this constant from each geometry-free phase observation in a satellite-receiver arc:
(9)
where the summation is performed for all observations forming the arc. An elevation-angle-dependent weight (w) can also be applied to minimize the noise and multipath contribution for measurements made at low elevation angles. The double-bar symbol indicates leveled observations.
Integer-Leveling Procedure
The procedure of fitting a carrier-phase arc to code observations might introduce errors caused by code noise, multipath, or intra-day code-bias variations. Hence, developing a leveling approach that relies solely on carrier-phase observations is highly desirable. Such an approach is now possible with the recent developments in PPP, allowing for ambiguity resolution on undifferenced observations. This procedure has gained significant momentum in the past few years, with several organizations generating “integer clocks” or fractional offset corrections for recovering the integer nature of the undifferenced ambiguities. Among those organizations are, in alphabetical order, the Centre National d’Études Spatiale; GeoForschungsZentrum; GPS Solutions, Inc.; Jet Propulsion Laboratory; Natural Resources Canada (NRCan); and Trimble Navigation. With ongoing research to improve convergence time, it would be no surprise if PPP with ambiguity resolution would become the de facto methodology for processing data on a station-by-station basis. The results presented in this article are based on the products generated at NRCan, referred to as “decoupled clocks.”
The idea behind integer leveling is to introduce integer ambiguity parameters on L1 and L2, obtained through PPP processing, into the geometry-free linear combination of Equation (7). The resulting integer-leveled observations, in units of meters, can then be expressed as: (10)
where and are the ambiguities obtained from the PPP solution, which should be, preferably, integer values. Since those ambiguities are obtained with respect to a somewhat arbitrary ambiguity datum, they do not allow instant recovery of an unbiased slant ionospheric delay. This fact was highlighted in Equation (10), which indicates that, even though the arc-dependency was removed from the geometry-free combination, there are still receiver- and satellite-dependent biases (br and b j, respectively) remaining in the integer-leveled observations. The latter are thus very similar in nature to the standard-leveled observations, in the sense that the biases br and b jreplace the well-known IFBs. As a consequence, integer-leveled observations can be used with any existing software used for the generation of TEC maps. The motivation behind using integer-leveled observations is the mitigation of leveling errors, as explained in the next sections.
Slant TEC Evaluation
As a first step towards assessing the performance of integer-leveled observations, STEC values are derived on a station-by-station basis. The slant ionospheric delays are then compared for a pair of co-located receivers, as well as with global ionospheric maps (GIMs) produced by the International GNSS Service (IGS).
Leveling Error Analysis. Relative leveling errors between two co-located stations can be obtained by computing between-station differences of leveled observations:
(11)
where subscripts A and B identify the stations involved, and εl is the leveling error. Since the distance between stations is short (within 100 meters, say), the ionospheric delays will cancel, and so will the satellite biases (b j) which are observed at both stations. The remaining quantities will be the (presumably constant) receiver biases and any leveling errors. Since there are no satellite-dependent quantities in Equation (11), the differenced observations obtained should be identical for all satellites observed, provided that there are no leveling errors. The same principles apply to observations leveled using other techniques discussed in the introduction. Hence, Equation (11) allows comparison of the performance of various leveling approaches.
This methodology has been applied to a baseline of approximately a couple of meters in length between stations WTZJ and WTZZ, in Wettzell, Germany. The observations of both stations from March 2, 2008, were leveled using a standard leveling approach, as well as the method described in this article. Relative leveling errors computed using Equation (11) are displayed in Figure 1, where each color represents a different satellite. It is clear that code noise and multipath do not necessarily average out over the course of an arc, leading to leveling errors sometimes exceeding a couple of TECU for the standard leveling approach (see panel (a)). On the other hand, integer-leveled observations agree fairly well between stations, where leveling errors were mostly eliminated. In one instance, at the beginning of the session, ambiguity resolution failed at both stations for satellite PRN 18, leading to a relative error of 1.5 TECU, more or less. Still, the advantages associated with integer leveling should be obvious since the relative error of the standard approach is in the vicinity of -6 TECU for this satellite.
FIGURE 1. Relative leveling errors between stations WTZJ and WTZZ on March 2, 2008: (a) standard-leveled observations and (b) integer-leveled observations.
The magnitude of the leveling errors obtained for the standard approach agrees fairly well with previous studies (see Further Reading). In the event that intra-day variations of the receiver IFBs are observed, even more significant biases were found to contaminate standard-leveled observations. Since the decoupled-clock model used for ambiguity resolution explicitly accounts for possible variations of any equipment delays, the estimated ambiguities are not affected by such effects, leading to improved leveled observations.
STEC Comparisons. Once leveled observations are available, the next step consists of separating STEC from instrumental delays. This task can be accomplished on a station-by-station basis using, for example, the single-layer ionospheric model. Replacing the slant ionospheric delays (I j) in Equation (10) by a bilinear polynomial expansion of VTEC leads to:
(12)
where M(e) is the single-layer mapping function (or obliquity factor) depending on the elevation angle (e) of the satellite. The time-dependent coefficients a0, a1, and a2 determine the mathematical representation of the VTEC above the station. Gradients are modeled using Δλ, the difference between the longitude of the ionospheric pierce point and the longitude of the mean sun, and Δϕ, the difference between the geomagnetic latitude of the ionospheric pierce point and the geomagnetic latitude of the station. The estimation procedure described by Attila Komjathy (see Further Reading) is followed in all subsequent tests. An elevation angle cutoff of 10 degrees was applied and the shell height used was 450 kilometers. Since it is not possible to obtain absolute values for the satellite and receiver biases, the sum of all satellite biases was constrained to a value of zero. As a consequence, all estimated biases will contain a common (unknown) offset. STEC values, in TECU, can then be computed as:
(13)
where the hat symbol denotes estimated quantities, and is equal to zero (that is, it is not estimated) when biases are obtained on a station-by-station basis. The frequency, f1, is expressed in Hz. The numerical constant 40.3, determined from values of fundamental physical constants, is sufficiently precise for our purposes, but is a rounding of the more precise value of 40.308.
While integer-leveled observations from co-located stations show good agreement, an external TEC source is required to make sure that both stations are not affected by common errors. For this purpose, Figure 2 compares STEC values computed from GIMs produced by the IGS and STEC values derived from station WTZJ using both standard- and integer-leveled observations. The IGS claims root-mean-square errors on the order of 2-8 TECU for vertical TEC, although the ionosphere was quiet on the day selected, meaning that errors at the low-end of that range are expected. Errors associated with the mapping function will further contribute to differences in STEC values. As apparent from Figure 2, no significant bias can be identified in integer-leveled observations. On the other hand, negative STEC values (not displayed in Figure 2) were obtained during nighttimes when using standard-leveled observations, a clear indication that leveling errors contaminated the observations.
FIGURE 2. Comparison between STEC values obtained from a global ionospheric map and those from station WTZJ using standard- and integer-leveled observations.
STEC Evaluation in the Positioning Domain. Validation of slant ionospheric delays can also be performed in the positioning domain. For this purpose, a station’s coordinates from processing the observations in static mode (that is, one set of coordinates estimated per session) are estimated using (unsmoothed) single-frequency code observations with precise orbit and clock corrections from the IGS and various ionosphere-correction sources. Figure 3 illustrates the convergence of the 3D position error for station WTZZ, using STEC corrections from the three sources introduced previously, namely: 1) GIMs from the IGS, 2) STEC values from station WTZJ derived from standard leveling, and 3) STEC values from station WTZJ derived from integer leveling. The reference coordinates were obtained from static processing based on dual-frequency carrier-phase and code observations. The benefits of the integer-leveled corrections are obvious, with the solution converging to better than 10 centimeters. Even though the distance between the stations is short, using standard-leveled observations from WTZJ leads to a biased solution as a result of arc-dependent leveling errors. Using a TEC map from the IGS provides a decent solution considering that it is a global model, although the solution is again biased.
FIGURE 3. Single-frequency code-based positioning results for station WTZZ (in static mode) using different ionosphere-correction sources: GIM and STEC values from station WTZJ using standard- and integer-leveled observations.
This station-level analysis allowed us to confirm that integer-leveled observations can seemingly eliminate leveling errors, provided that carrier-phase ambiguities are fixed to proper integer values. Furthermore, it is possible to retrieve unbiased STEC values from those observations by using common techniques for isolating instrumental delays. The next step consisted of examining the impacts of reducing leveling errors on VTEC.
VTEC Evaluation
When using the single-layer ionospheric model, vertical TEC values can be derived from the STEC values of Equation (13) using:
(14)
Dividing STEC by the mapping function will also reduce any bias caused by the leveling procedure. Hence, measures of VTEC made from a satellite at a low elevation angle will be less impacted by leveling errors. When the satellite reaches the zenith, then any bias in the observation will fully propagate into the computed VTEC values. On the other hand, the uncertainty of the mapping function is larger at low-elevation angles, which should be kept in mind when analyzing the results.
Using data from a small regional network allows us to assess the compatibility of the VTEC quantities between stations. For this purpose, GPS data collected as a part of the Western Canada Deformation Array (WCDA) network, still from March 2, 2008, was used. The stations of this network, located on and near Vancouver Island in Canada, are indicated in Figure 4. Following the model of Equation (12), all stations were integrated into a single adjustment to estimate receiver and satellite biases as well as a triplet of time-varying coefficients for each station. STEC values were then computed using Equation (13), and VTEC values were finally derived from Equation (14). This procedure was again implemented for both standard- and integer-leveled observations.
FIGURE 4. Network of stations used in the VTEC evaluation procedures.
To facilitate the comparison of VTEC values spanning a whole day and to account for ionospheric gradients, differences with respect to the IGS GIM were computed. The results, plotted by elevation angle, are displayed in Figure 5 for all seven stations processed (all satellite arcs from the same station are plotted using the same color). The overall agreement between the global model and the station-derived VTECs is fairly good, with a bias of about 1 TECU. Still, the top panel demonstrates that, at high elevation angles, discrepancies between VTEC values derived from standard-leveled observations and the ones obtained from the model have a spread of nearly 6 TECU. With integer-leveled observations (see bottom panel), this spread is reduced to approximately 2 TECU. It is important to realize that the dispersion can be explained by several factors, such as remaining leveling errors, the inexact receiver and satellite bias estimates, and inaccuracies of the global model. It is nonetheless expected that leveling errors account for the most significant part of this error for standard-leveled observations.
For satellites observed at a lower elevation angle, the spread between arcs is similar for both methods (except for station UCLU in panel (a) for which the estimated station IFB parameter looks significantly biased). As stated previously, the reason is that leveling errors are reduced when divided by the mapping function. The latter also introduces further errors in the comparisons, which explains why a wider spread should typically be associated with low-elevation-angle satellites. Nevertheless, it should be clear from Figure 5 that integer-leveled observations offer a better consistency than standard-leveled observations.
FIGURE 5. VTEC differences, with respect to the IGS GIM, for all satellite arcs as a function of the elevation angle of the satellite, using (a) standard-leveled observations and (b) integer-leveled observations.
Conclusion
The technique of integer leveling consists of introducing (preferably) integer ambiguity parameters obtained from PPP into the geometry-free combination of observations. This process removes the arc dependency of the signals, and allows integer-leveled observations to be used with any existing TEC estimation software. While leveling errors of a few TECU exist with current procedures, this type of error can be eliminated through use of our procedure, provided that carrier-phase ambiguities are fixed to the proper integer values. As a consequence, STEC values derived from nearby stations are typically more consistent with each other. Unfortunately, subsequent steps involved in generating VTEC maps, such as transforming STEC to VTEC and interpolating VTEC values between stations, attenuate the benefits of using integer-leveled observations.
There are still ongoing challenges associated with the GIM-generation process, particularly in terms of latency and three-dimensional modeling. Since ambiguity resolution in PPP can be achieved in real time, we believe that integer-leveled observations could benefit near-real-time ionosphere monitoring. Since ambiguity parameters are constant for a satellite pass (provided that there are no cycle slips), integer ambiguity values (that is, the leveling information) can be carried over from one map generation process to the next. Therefore, this methodology could reduce leveling errors associated with short arcs, for instance.
Another prospective benefit of integer-leveled observations is the reduction of leveling errors contaminating data from low-Earth-orbit (LEO) satellites, which is of particular importance for three-dimensional TEC modeling. Due to their low orbits, LEO satellites typically track a GPS satellite for a short period of time. As a consequence, those short arcs do not allow code noise and multipath to average out, potentially leading to important leveling errors. On the other hand, undifferenced ambiguity fixing for LEO satellites already has been demonstrated, and could be a viable solution to this problem.
Evidently, more research needs to be conducted to fully assess the benefits of integer-leveled observations. Still, we think that the results shown herein are encouraging and offer potential solutions to current challenges associated with ionosphere monitoring.
Acknowledgments
We would like to acknowledge the help of Paul Collins from NRCan in producing Figure 4 and the financial contribution of the Natural Sciences and Engineering Research Council of Canada in supporting the second and third authors. This article is based on two conference papers: “Defining the Basis of an ‘Integer-Levelling’ Procedure for Estimating Slant Total Electron Content” presented at ION GNSS 2011 and “Ionospheric Monitoring Using ‘Integer-Levelled’ Observations” presented at ION GNSS 2012. ION GNSS 2011 and 2012 were the 24th and 25th International Technical Meetings of the Satellite Division of The Institute of Navigation, respectively. ION GNSS 2011 was held in Portland, Oregon, September 19–23, 2011, while ION GNSS 2012 was held in Nashville, Tennessee, September 17–21, 2012.
SIMON BANVILLE is a Ph.D. candidate in the Department of Geodesy and Geomatics Engineering at the University of New Brunswick (UNB) under the supervision of Dr. Richard B. Langley. His research topic is the detection and correction of cycle slips in GNSS observations. He also works for Natural Resources Canada on real-time precise point positioning and ambiguity resolution.
WEI ZHANG received his M.Sc. degree (2009) in space science from the School of Earth and Space Science of Peking University, China. He is currently an M.Sc.E. student in the Department of Geodesy and Geomatics Engineering at UNB under the supervision of Dr. Langley. His research topic is the assessment of three-dimensional regional ionosphere tomographic models using GNSS measurements.
FURTHER READING
• Authors’ Conference Papers
“Defining the Basis of an ‘Integer-Levelling’ Procedure for Estimating Slant Total Electron Content” by S. Banville and R.B. Langley in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 2542–2551.
“Ionospheric Monitoring Using ‘Integer-Levelled’ Observations” by S. Banville, W. Zhang, R. Ghoddousi-Fard, and R.B. Langley in 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. 3753–3761.
• Errors in GPS-Derived Slant Total Electron Content
“GPS Slant Total Electron Content Accuracy Using the Single Layer Model Under Different Geomagnetic Regions and Ionospheric Conditions” by C. Brunini, and F.J. Azpilicueta in Journal of Geodesy, Vol. 84, No. 5, pp. 293–304, 2010, doi: 10.1007/s00190-010-0367-5.
“Calibration Errors on Experimental Slant Total Electron Content (TEC) Determined with GPS” by L. Ciraolo, F. Azpilicueta, C. Brunini, A. Meza, and S.M. Radicella in Journal of Geodesy, Vol. 81, No. 2, pp. 111–120, 2007, doi: 10.1007/s00190-006-0093-1.
• Global Ionospheric Maps
“The IGS VTEC Maps: A Reliable Source of Ionospheric Information Since 1998” by M. Hernández-Pajares, J.M. Juan, J. Sanz, R. Orus, A. Garcia-Rigo, J. Feltens, A. Komjathy, S.C. Schaer, and A. Krankowski in Journal of Geodesy, Vol. 83, No. 3–4, 2009, pp. 263–275, doi: 10.1007/s00190-008-0266-1.
“Undifferenced GPS Ambiguity Resolution Using the Decoupled Clock Model and Ambiguity Datum Fixing” by P. Collins, S. Bisnath, F. Lahaye, and P. Héroux in Navigation: Journal of The Institute of Navigation, Vol. 57, No. 2, Summer 2010, pp. 123–135.
Spectracom has announced its upgrade capability to China’s global navigation satellite system, Beidou. The Spectracom GSG Series 5 and Series 6 GNSS signal simulators, released in 2012, are designed to be field upgradeable to simulate current and future GNSS constellations. GSG simulators are capable of outputting the frequencies, modulations and data formats of anticipated GNSS systems. The January release of the Beidou ICD specification has confirmed that Spectracom GPS/GNSS simulators will be able to emulate these satellite signals with a simple field-upgradeable firmware update.
“In anticipation of the deployment of these new, major GNSS systems, Spectracom ensures that every GSG simulator that leaves the factory is tested for compliance with all the signal frequency and modulation specifications as defined in their ICDs. Customers who have purchased our Series 5 or 6 simulators since June 2012 have this upgrade capability,” Spectracom CTO John Fischer said.
Spectracom GSG-6 series simulator. Photo: Spectrum
The Series 5 single frequency simulator is fully capable of the all the signals in the L1 (GPS and GLONASS) / E1 (Galileo) / B1 (Beidou) band, including all the GLONASS FDMA satellites.
The Series 6 multi-frequency simulator is fully capable of all four bands of all the systems: L1 / E1 / B1; L2 / L2C; L5 /E5 /B2; and E6 / B3.
Fischer added, “As the need for new signals arise, firmware upgrades will be available. This ensures our customer’s investment is protected. Galileo signals will be available this year and Beidou will be available next year.”
Next month Spirent is hosting a meeting with hands-on training sessions on GNSS simulation equipment led by Spirent engineers. The 2013 Spirent Federal 2013 GNSS Technical Interchange Meeting will be held March 19-21 at the DoubleTree Hotel Anaheim-Orange County, in Orange, California.
March 19 and 20 are for general participation. The third day, March 21, features FOUO (For Official Use Only) sessions for U.S. citizens only.
Symmetricom, Inc. today announced two new capabilities for its SSU 2000 Synchronization Supply Unit: a GLONASS timing reference that uses signals from the satellite navigation system operated by the Russian Aerospace Defense Forces, and Synchronous Ethernet (SyncE), an ITU-T synchronization standard that delivers frequency synchronization over the Ethernet physical layer.
This enhanced version of the SSU 2000 will be the first in a series of forthcoming Symmetricom products that include GLONASS capabilities.
Available as an integrated card for the Symmetricom SSU 2000, the GLONASS referencing feature will allow customers to support both GPS and GLONASS simultaneously, providing added protection should signals from one navigation system become unavailable. GPS has long served as the primary reference signal for timing and synchronization in telecommunications and other networks. Operators in some regions prefer to use the GLONASS system, either as the primary time reference or in conjunction with GPS signals. Symmetricom has enhanced the SSU 2000 satellite receiver functionality to meet this demand.
“GLONASS signals have become an important primary reference for timing and synchronization systems,” said Laura Finkelstein, vice president of product management for Symmetricom. “The SSU 2000 is well-established as the synchronization platform for communication service providers globally. The integrated capability to simultaneously support both GPS and GLONASS provides our customers another way to improve the reliability of their network.”
Timing and synchronization are a focal point technology in Ethernet and mobile carrier networks today. Synchronous Ethernet allows frequency signals to transfer at the physical layer over Ethernet, helping improve network reliability by offering synchronization services to Carrier Ethernet networks. Using SyncE to complement IEEE 1588 Precision Time Protocol (PTP) can enhance PTP services being delivered to mobile base stations deployed in radio access networks. The new SSU 2000 capability puts SyncE and PTP on the same output port, thus providing an ideal synchronization solution for the evolution of mobile networks as they extend coverage and increase capacity.
Designed in a NEBS-compliant package, the SSU 2000 integrates intelligent functional modules into a flexible, fully redundant system. This enables telecom network operators to seamlessly satisfy current and future requirements for generating and distributing superior synchronization signals for advanced network services.
The SSU 2000 has been deployed in more than 125 countries as a timing and synchronization distribution system for communications service providers.
