If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor
EGNOS Receivers
| EGNOS | |
|---|---|
| Title | EGNOS Receivers |
| Author(s) | GMV. |
| Level | Basic |
| Year of Publication | 2011 |
To receive EGNOS signals an EGNOS compatible receiver is required There are many receivers now already on the market from a variety of manufacturers.[1]
An EGNOS receiver is like a GPS receiver but with special software inside that allows the receiver to lock onto the code used by the EGNOS satellites and compute the EGNOS corrections to the GPS signals. Apart from this, an EGNOS receiver is just like a GPS receiver. This means that it can pick up GPS signals as well. An EGNOS receiver is the same size as a GPS receiver and uses the same type of antenna.
To test the EGNOS receiver, special prototypes have been developed with extensive capabilities to log and analyze data.
Receiver types
EGNOS-enabled receiver depend on the targeted application, the EGNOS functions that will be used and the integration constraints. In choosing a receiver, users should establish whether it correctly supports EGNOS, then select the interface type. Check if the protocols supported by the receiver allow retrieval of the data required for the targeted application.[2]
EGNOS-enabled receivers can be designed using a chipset, hybrid component or auxiliary card.
- Chipset: consists of one or two components that must be installed on a circuit board. The routing of the RF part is sensitive. This compact solution is also the least expensive.
- Hybrid component: consists of a single component integrating the RF and signal processing parts to be installed on a circuit board. Routing is easier compared to chipsets. The price is higher than for the chipset solution.
- Auxiliary card (piggyback): all the receiver and peripheral components are integrated on a ready-to-use card connected to the final product’s main circuit board. It is an ideal solution for prototyping embedded applications. This is the most expensive solution.
Communications protocols
Manufacturers generally use proprietary protocols which give access to almost all the data (pseudoranges, satellite navigation messages, SBAS messages, etc.) associated with a standardised protocol, NMEA 0183. Some receivers also generate data in RINEX (Receiver INdependent EXchange) format.
RINEX is an exchange format that is independent of the receiver. It was developed by the Astronomical Institute of the University of Bern in order to provide data in a single format that has been collected in proprietary formats by different brands of receiver. This format is generally supported by professional receivers. It is also used by IGS servers for supplying GNSS data. In this format, the GNSS data are provided as text files. A description of this format described by the University of Bern is available free of charge on http://igscb.jpl.nasa.gov/igscb/data/format/rinex210.txt.
Manufacturer’s specifications
Although some manufacturers clearly specify that EGNOS is supported, others indicate that their receivers are “WAAS Capable” or “WAAS Enabled”, with WAAS referring to both the North American satellite-based augmentation system (SBAS) and the SBAS standard. In practice, “WAAS Capable” means that the receiver can use SBAS services but the user must activate this function once only, or each time it starts up. “WAAS Enabled” usually means that the receiver activates SBAS reception by default.
It is important to bear in mind that there is no guarantee a “WAAS Capable” or “WAAS Enabled” receiver will support EGNOS (this is due in particular to the MT0/2 message which is sometimes interpreted as MT0).
Besides, navigation services are developing swiftly, so it is vital to keep in pace with international standards.[3]
Receiver list
Helios produced a list of receivers compatible with EGNOS as part of a market study completed in 2008 on behalf of the GNSS Supervisory Authority.[4] It is a non-exhaustive list but it provides, for each receiver, the degree to which its SBAS capability is recorded, as well as the GNSS chipset used (where this information is available). This information is available in (http://egnos-portal.gsa.europa.eu/files/dmfile/OPO-09-004_Receiver_list_091021.pdf).
Many devices are suitable, and marketed, for more than one of the market segments identified here. Outdoor recreation devices, for example, cross over into the maritime and general aviation segments.
Many products are sold as being SBAS compatible, but it is often impossible to tell whether the device is making full use of the SBAS corrections (category 1) or is simply capable of receiving the signal from the SBAS satellites (category 2). In these cases, the product is shown as being in both categories 1 and 2.
For category 3 the chipset in the receiver is known to be SBAS compatible, but the receiver does not make use of this ability and does not process the augmentation data. Products in this category would require a more extensive receiver firmware upgrade to make use of SBAS.
Category 4 lists receivers for which the SBAS capability of the device/chipset is unknown.
N/A denotes those platforms that do not have an HMI and therefore do not offer full user functionality. They instead provide an output data feed.
Besides, it should be noted that this classification is not aligned with the equipment operational classes defined in the MOPS RTCA DO 229 D.