The authors are members of the European Geostationary Navigation Overlay Service (EGNOS) Project Office at the European Space Agency (ESA). They can be contacted at [email protected].
Satellite navigation (SN) addresses the seemingly simple — but in reality very complex — question of "Where am I?" This question is answered with the help of GPS satellites that broadcast pseudorandom digital signals to users. Each satellite synchronizes signals with the system time, thanks to an extremely precise atomic clock.
On the receiving end, users have receivers that capture the signals coming from the satellites. The receiver's software can reproduce the signals generated at each satellite, since they are predictable. Hence, the software knows the time it takes signals to travel from a given satellite to the receiver. This is done by measuring the delay between the signal generated by the receiver and that received from a given satellite. The result of multiplying that delay by the speed of the signals (that is, the speed of light) is the satellite-to-receiver distance, referred to as "pseudorange."
By calculating the distance to three satellites, the receiver software calculates the user's 3D position with respect to a given coordinate system, normally called "navigation solution." This is reasonable, since there are three unknown variables. However, there's something else that must be considered: The receiver's clock normally is not a precise atomic clock and not synchronized with the system time base. Consequently, the receiver clock is delayed by an offset, with respect to the satellite's clock. This requires adding a fourth variable — the time offset — to the problem. Hence, the solution consists of measuring the pseudorange to a fourth satellite. In other words, the receiver calculates the 3D position and the time offset by measuring the pseudorange to four satellites.
As you might expect, these measurements are always subject to errors from different sources. Superposition of these errors produces a total error in pseudorange measurements and, hence, a total error in the navigation solution. Therefore, the accuracy of the navigation solution depends on how the receiver compensates for the different error sources. The main sources of errors include:
- The quality of the receiver's hardware.
- User location. Some locations present noisier signals than others. Topography can also introduce multipath errors: The signals are reflected in near objects, so that users receive several versions of the original signal with different delays.
- Propagation effects. In traveling from satellites to users, signals travel through the ionosphere and troposphere, which make the signal speed different from the speed of light. This causes a delay, which contributes to pseudorange errors.
- Time synchronization accuracy. Satellite clocks may not be in perfect synchrony with system time.
- Orbit determination. Users must determine satellite positions to calculate navigation solutions. There are several error sources that make the orbits different from those estimated through Kepler laws.
Some error components can be reduced by satellite-based augmentation systems that can calculate and send precise differential corrections (in the form of digital messages) to users located within a wide area. EGNOS and WAAS are the European and U.S. versions, respectively, of one GPS satellite-based augmentation system (SBAS).
With SBASs, a network of reference stations — distributed over a nominal region — gathers pseudorange measurements and sends it to a processing facility, which generates the differential corrections. This message is broadcast to users through one or more Geostationary (GEO) satellites. In particular, EGNOS and WAAS monitor the GPS ephemeris, onboard clocks, and reference time, as well as broadcast accurate ionospheric models that improve user accuracy. From an accuracy point of view, these SBAS corrections improve GPS-only systems from a typical 15-20 meters horizontal accuracy (95 percent of time) to 1-3 meters.
Although EGNOS (http://www.esa.int/navigation/egnos/) is still under development (the system should be fully operational in 2004), a preoperational system known as the EGNOS System Test Bed (ESTB; http://www.esa.int/navigation/estb/) provides both GPS-improved accuracy and GPS-integrity services. Figure 1 illustrates the ESTB architecture, including reference stations, processing facilities, and the GEOs. The NLES components are satellite Earth stations, which uplink the information to the GEOs.
The SISNET Project
Satellite broadcasting through GEO satellites is an efficient strategy for aviation and maritime users, but others, such as land mobile, may experience a reduction of SBAS availability. This is particularly true with mobile users in urban areas, where the buildings prevent correct reception of the GEO signals. However, since EGNOS messages are still useful for these applications, an alternative transmission link can better leverage EGNOS's potential. For this reason, the European Space Agency (ESA) has recently launched projects to demonstrate architectures where a ESTB signal is broadcast through nonGEO means — FM or GSM broadcasting, for instance. Dubbed the "Signal in Space Through the Internet" (SISNET), the project aims at providing access to ESTB messages through the Internet.
Interestingly, in situations where user visibility of GPS satellites is limited, say, to 4-5 satellites, the availability of the SBAS corrections plays a major role. Indeed, SBAS-available accuracy is quite insensitive to the number of GPS satellites in visibility, while GPS-only accuracy degrades significantly. SISNET benefits from this, making SBAS messages available regardless of user visibility conditions.
SISNET Overview
Figure 2 illustrates the architecture of the SISNET platform. The principal components are:
- The Base Station (BS), a PC equipped with an EGNOS receiver. Software components enable acquiring and sending EGNOS messages to a remote computer, the Data Server, in real time — one message per second. The TCP/IP-based protocol SIS2DS is used for this.
- The Data Server (DS), a high-performance computer, optimized for running server software with large numbers of connected users. The DS software receives the EGNOS messages from the BS and transfers them to remote users in real time via the Internet, using another TCP/IP-based protocol called DS2DC. In addition, the DS implements other extra services provided by SISNET (broadcasting text messages to users, for instance). The DS periodically sends the most recent EGNOS messages to remote web servers, making possible the development of web/WAP applications.
- The User Application Software (UAS), a flexible application that defines each specific application of SISNET. This software can be freely developed, using the desired hardware platform (PCs or PDAs, for instance), operating system, and programming language. However, there is one constraint: The DS2DC client must accomplish some interface control specifications provided by ESA under the SISNET User Interface Document. This is the only way you can be sure an application correctly communicates with SISNET.
A SISNET prototype setup by the European Space Agency in August 2001 successfully demonstrated the feasibility of the SISNET concept. In this first prototype, the UAS runs on a PC, and the Internet connection is via a LAN. To demonstrate the SISNET potential, the European Space Agency has developed the first UAS implementation, including four parallel processing blocks (thus enabling four different applications):
- SISNET-augmented GPS positioning. The EGNOS corrections are applied to the measurements coming from a GPS receiver. The result is an improvement of the position accuracy with respect to the GPS-only solution.
- Real-time analysis of the ESTB messages. A multithreaded real-time processing block presents the information contained in the ESTB messages, through GUIs.
- Real-time performance monitoring. The UAS shows real-time graphical results about the ESTB performance.
- ESTB monitoring through the Internet. Users will soon be able to know the status of the ESTB signal in real time, by going to http://www.esa.int/navigation/estb/. SISNET automatically updates the web site with information about the ESTB status and its performance.
Currently, some European companies are working on the development of SISNET-based applications. The expected achievements include developing a SISNET-powered GPS receiver (by integrating a GPS receiver and a GSM connection to the Internet), perform demonstrations embedding SISNET receivers into cars and buses, and improving the network performance.
Presently, SISNET is only accessible to the European Space Agency development team, but we intend to allow access to SISNET free of charge very soon. You will also be able to download the ESA implementation of the UAS through http://www.esa.int/navigation/estb/.
Building SISNET Applications
Because SISNET is not available at this writing, we present here a DS emulator (available electronically; see "Resource Center," page 5) that provides the main SISNET capability — broadcasting EGNOS messages across the Internet. With this emulator, you can test SISNET applications until SISNET is available.
And even though SISNET works with EGNOS, you may want to use it with the U.S. WAAS or Japanese MSAS systems. Luckily, SISNET can be set up to work with WAAS and MSAS, since the messages broadcast by both systems adhere to the Minimum Operational Performance Standards (MOPS; http://www.rtca.org/downloads/doclist.html). The MOPS Standards clearly define the format and contents of the messages to be broadcast — reading them is a must if you plan to develop SISNET applications.
The SISNET application we build here is a UAS program that monitors received EGNOS messages in real time (in this case, originating from the DS emulator) and analyzes their type identifier. It will be straightforward for you to use this UAS as a springboard for developing new applications. In particular, the type identifier helps you to quickly know how to analyze the message and exploit the information inside. The complete Borland C++ Builder (BCB) project for this UAS (along with executables) also is available electronically.
Building this UAS follows the typical steps of a SISNET development:
- Develop a SISNET-compliant DS2DC client software. This component obtains the EGNOS messages in real time. The best solution is to create a reusable software component (VCL or ActiveX component). Here, we simplify the problem by directly coding the algorithms into the source of a TForm component (the main form of the application). Our client only uses one of the available DS2DC services — receiving the EGNOS messages.
- Develop one or more processing blocks. We have included a simple — but useful — processing algorithm that calculates the received message type. This information is useful, since it defines the purpose and contents of each EGNOS message.
- Create an output interface, which is usually implemented through a GUI.
Once a BCB main form is opened, the first thing you need is a component that creates a TCP client socket and connects it to a TCP server socket. The BCB 5.0 TClientSocket component enables this. Place that component on the main form, and complete the GUI.
Listing One is the contents of the implementation file corresponding to that form (Main.cpp). The implementation of the three main blocks of the UAS (Figure 2) is distributed through that code as follows:
- GUI management code (output interface) is distributed across several methods and event handlers. The objective is to obtain a context-sensitive GUI, basically enabling the command buttons that can be used in a given moment and disabling the rest. In addition, this code must update the TStaticText controls of the GUI (showing the received EGNOS message, corresponding GPS time and week, and type identifier).
- DS2DC Client implementation. This involves several event handlers, linked to the TClientSocket component, which manage the status of the communications and detect potential errors. In addition, the OnClick event handlers linked to the command buttons make use of the TClientSocket methods for starting/ending communications.
- Processing block. Only one processing block is included, analyzing the type identifier of each message.
When users press the Connect button, the BtnConnectClick event handler is invoked. The TClientSocket component is programmed by setting the IP address and port to use for contacting the DS (Address and Port properties). If those data are correct, the Open method is invoked, connecting the client socket (CS) to the server socket (SS, located at the DS).
The following event handlers are involved in the communications process:
- ClientError indicates that an error has occurred during the communications. The code informs users and disconnects the CS from the SS (using the Close method of TClientSocket).
- ClientDisconnect is triggered when the connection is effectively closed. The code informs users and resets the GUI to its initial state.
- ClientLookup is triggered just before trying to find the SS. The code informs users through the status bar.
- ClientConnecting is thrown when the CS finds the SS. The code informs users.
- ClientConnect indicates that the CS is connected to the SS. The code informs users and enables the Timer component.
Once the connection is made, program flow is controlled by the Timer component. The timer invokes the TimerTimer event handler every second. The code sends a text string to the DS, containing the "MSG" command of the DS2DC protocol. This is done through the Client->Socket->SendText method. The DS immediately answers by sending a "*MSG" command to the CS; see Figure 3(a). When the answer arrives, the ClientRead event handler is called. The code uses the Client->Socket->ReceiveText method to obtain the answer form the DS as a text string.
The next step consists of analyzing the contents of the "*MSG" command. The ExtractDS2DCField method plays an important role in that context. The DS2DC commands contain fields separated by commas (the first field always corresponds to the command name). The ExtractDS2DCField method returns the content of the field indicated by an integer index. Hence, it is easy to extract the information from the message and present it on the form. The code analyzes the first field, ignoring commands other than "*MSG".
The fourth field of the "*MSG" command — see Figure 3(b) — contains a compressed version of the EGNOS message. Instead of explaining the decompression algorithm, we present the component, called SINCA, that lets you decompress it. SINCA works as follows:
- First, you put the compressed message in the Data property.
- Next, you call the Decompress method.
- Finally, the decompressed EGNOS message is available in the Data property.
The EGNOS message contains 250 bits and is expressed as a hexadecimal string of 63 digits; see Figure 3(b). That means the last two bits must be ignored (since 63x4=252 bits). The string is ended with an asterisk, followed by an 8-bit checksum.
The processing block analyzes the message type and all necessary code is integrated in the GetMT method. Since the message type identifier is included from bits 9-14 of each EGNOS message, only the third and fourth hexadecimal digits are used. A "0x" string is put at the beginning of those digits, and the ToInt method of the AnsiString class is called. The result is a translation of the hexadecimal number to an integer number. In this case, we use a char to store the result (since it is 8 bits wide and we only need to use 6 bits). After the conversion, a mask is applied by using a bitwise AND operator. The result contains the 6 bits of interest starting at the more significant position. Therefore, shifting the result two times to the right (that is, dividing by 4), you obtain the message type identifier.
All of the processing just described is repeated every second. We work at a proper frequency, since processing takes an insignificant time with respect to a second. Communications end when users press the Disconnect button. The BtnDisconnectClick event handler ends the communications (through a call to TClientSocket's Close method) and returns the application to its initial state.
Testing
To build and test an executable version of the UAS program, start by opening the UAS_example.bpr file with BCB, and select Build (under the Project menu). If you don't want to perform the compilation process, simply run the compiled version (UAS_Example.exe) we provide here.
Before using the UAS program, however, remember to run and configure the DS emulator (SISNET_DSE.exe). First, you must introduce the port number at which the DS listens to users. In addition, the existence of the BS must be simulated. This is done using an ASCII file, previously recorded using an EGNOS receiver. That file contains the information that the BS sends to the DS in real time — the EGNOS messages, GPS week and time, and other data. We provide an example of such a file (ReceiverFile.asc). You will find its structure easy to understand, and be able to create your own files or even develop software for their generation.
Visually select the receiver file using the Browse button, then press Start Server and the emulation runs. You will see an EGNOS message appearing on the screen once a second. This is the same you would see if the DS emulator was connected to the real SISNET BS.
You can then run UAS_example.exe. To configure the program, enter:
- The IP address of the data server. This information is shown in the Current IP address field of the DS emulator.
- The port at which the DS listens to the users. This is the port number you previously introduced into the DS emulator, using the Port field.
When you press Connect you will start receiving the EGNOS messages and the complementary information from the DS. You will experiment the usage of SISNET, anticipating to the future.
Now you can perform several experiments. If you work on a LAN environment, you can try to access the DS emulator from another computer. Moreover, you can test the concurrent access of several users, by opening several instances of the UAS, and connecting them to the DS emulator (using one or more computers).
DDJ
Listing One
///////////////////////////////////////////////////////////////////// // SISNET USer Application Software (UAS) Example // // (c) ESA 2001 by Felix Toran-Marti, Javier Ventura-Traveset and // // Juan Carlos de Mateo. // // For any question or suggestion, please contact the authors at: // // Felix Toran-Marti ([email protected] ; [email protected]) // // Javier Ventura-Traveset ([email protected]) // // J.C. de Mateo ([email protected]) // // This application demonstrates how to build a basic SISNET UAS. // // The source code can be used as a baseline for integrating // // SISNET applications on it. In fact, this application basically // // monitors the EGNOS messages received from the SISNET DS. // // Only one processing block has been applied, which mission is to // // analyse the received message types. // //////////////////////////////////////////////////////////////////// //------------------------------------------------------------------- #include <vcl.h> #pragma hdrstop #include "Main.h" //------------------------------------------------------------------- #pragma package(smart_init) #pragma link "SINCA" #pragma resource "*.dfm" TMainForm *MainForm; //------------------------------------------------------------------- __fastcall TMainForm::TMainForm(TComponent* Owner) : TForm(Owner) { } //------------------------------------------------------------------- void __fastcall TMainForm::BtnCloseClick(TObject *Sender) { //Close the application Close(); } //------------------------------------------------------------------- void __fastcall TMainForm::BtnConnectClick(TObject *Sender) { //Configure the client component Client->Address=DataServerIP->Text; try { Client->Port=Port->Text.ToInt(); } catch(...) { ShowMessage("The port must be an integer number!!!"); return; } //Connect to the SISNET Data Server try { Client->Open(); BtnConnect->Enabled=false; BtnClose->Enabled=false; BtnDisconnect->Enabled=true; } catch(...) { ShowMessage("Connection failed. Please, check the settings."); } } //------------------------------------------------------------------- void __fastcall TMainForm::ClientError(TObject *Sender, TCustomWinSocket *Socket, TErrorEvent ErrorEvent, int &ErrorCode) { //Communications Error ShowMessage("Communications error. Please, check IP address and port."); //Close the connection Client->Close(); ResetBtns(); ErrorCode=0; } //------------------------------------------------------------------- void __fastcall TMainForm::ClientConnect(TObject *Sender, TCustomWinSocket *Socket) { //The client is now connected to the SISNET Data Server. Status->SimpleText="Connected to the SISNET Data Server!!!"; //A timer is enabled, in order to send an EGNOS message request each second. Timer->Enabled=true; } //------------------------------------------------------------------- void __fastcall TMainForm::ClientConnecting(TObject *Sender, TCustomWinSocket *Socket) { //The Data Server has been found. The connection starts now. Status->SimpleText="SISNET Data Server found, connecting..."; } //------------------------------------------------------------------- void __fastcall TMainForm::ClientLookup(TObject *Sender, TCustomWinSocket *Socket) { //The client socket will search the server socket just now. Status->SimpleText="Looking up SISNET Data Server..."; } //------------------------------------------------------------------- void __fastcall TMainForm::ClientDisconnect(TObject *Sender, TCustomWinSocket *Socket) { //The client socket is now disconnected from the server socket. Status->SimpleText="Disconnected from the SISNET Data Server."; ResetBtns(); } //------------------------------------------------------------------- //The client socket has received an answer from the Data Server. void __fastcall TMainForm::ClientRead(TObject *Sender, TCustomWinSocket *Socket) { //Receive the command sent by the data server AnsiString Cmd=Client->Socket->ReceiveText(); Status->SimpleText="Command received from the Data Server ("+ TimeToStr(Now())+")"; //The only allowed message is "*MSG" if( ExtractDS2DCField(Cmd,1)!="*MSG" ) return; //Extract and show GPS week and time Week->Caption=ExtractDS2DCField(Cmd,2); Time->Caption=ExtractDS2DCField(Cmd,3); //Extract and decompress the message SINCA->Data=ExtractDS2DCField(Cmd,4); SINCA->Decompress(); //Show the decompressed EGNOS message EGNOSMsg->Caption=SINCA->Data; //Finally, calculate and show the message type MsgType->Caption=GetMT(EGNOSMsg->Caption); } //------------------------------------------------------------------- void __fastcall TMainForm::TimerTimer(TObject *Sender) { //Ask the server for an EGNOS message Client->Socket->SendText("MSG"); } //------------------------------------------------------------------- void __fastcall TMainForm::BtnDisconnectClick(TObject *Sender) { //Disconnect from the Data Server Status->SimpleText="Disconnecting from the Data Server..."; Client->Close(); } //------------------------------------------------------------------- //This method returns a field from a DS2DC '*MSG' command. The arguments //indicate the full command to analyse and the order number of the field to //extract. Please, note no error handling code is included. It is assumed //that a correctly-formatted command is received. AnsiString __fastcall TMainForm::ExtractDS2DCField(AnsiString Cmd,int FieldNum) { //Ease the search algorithm by placing a comma at the end of the command Cmd=Cmd+","; int pos=0; //Delete previous fields for(int n=0;n<FieldNum-1;n++) { pos=Cmd.Pos(","); Cmd.Delete(1,pos); } //Extract the requested field pos=Cmd.Pos(","); return Cmd.SubString(1,pos-1); } //------------------------------------------------------------------- //Resets the command buttons to the original state void __fastcall TMainForm::ResetBtns() { BtnConnect->Enabled=true; BtnClose->Enabled=true; BtnDisconnect->Enabled=false; } //------------------------------------------------------------------- //Returns the message type of an EGNOS message int __fastcall TMainForm::GetMT(AnsiString Msg) { //If we number the message's bits starting from 1, //the 6-bit message type identifier starts at bit 9. //Just the third and fourth hexadecimal digits are significative. Msg=Msg.SubString(3,2); //Convert to a decimal value (8-bit is enough) Msg="0x"+Msg; char dec=Msg.ToInt(); //Apply a mask to extract only the first 6 bits dec&=0xFC; //Shift the bits two times to the right dec/=4; return dec; }
