- What is the charge for the service?
- Is it accessible to everybody?
- Can I connect over Internet?
- May I set-up a private line to the server?
- What types of point-to-point lines or circuits are recommended / supported? (MPLS, ADSL, SDSL, FR, leased lines...)
- Does the client require a connection with a fixed IP address?
- Will it work behind NAT on the client side?
- Does it work behind a proxy on the client side?
- What is the Client Software provided by you actually doing?
- What is the output of the Client Software provided with the data?
- SW requirements for running the Client Software
- Client bandwidth requirements
- I am a student, can I have access to the data?
- I am a private individual, can I have access to the data?
- Is the EDAS data valuable outside Europe?
- What is the impact of data transfer latency on the value of the data?
- How can I verify that the Client Software is working properly?
- May I have an offline sample of the data? (data stream capture)
- UDP packets
- How to restore CRC32
- EDAS Contacts
The data is provided for free during at least 2010. However, in order to use the software you need to develop your own programme behind the client software. If you decide to set-up a private point-to-point line, you are responsible for the costs.
In principle, yes. However, each application is treated individually, taking into account the indicated purpose and such circumstances as the available bandwidth. Please refer to the Conditions of use for more details.
Yes. However, this connection is provided on a best-effort basis (no latency and data integrity guarantee). This is good enough for data preview, testing and development, but not good enough for commercial exploitation (EDAS data is, in principle, a continuous real-time data stream). You should refrain from being connected 24/7 via the Internet as there is limited bandwidth. For better performance, you can set up a direct line (see below).
Yes. If you decide to set-up a private line you are responsible for the costs.
What types of point-to-point lines or circuits are recommended / supported? (MPLS, ADSL, SDSL, FR, leased lines...)
EDAS users should contact their preferred telecommunications provider to ask about available alternatives that can be analysed by the EDAS support team on a case-by-case basis.
In case a connection needs to cover several countries, it will most likely require the participation of several service providers. The important delay and bandwidth to be agreed upon by the customer and the line provider is from the customer's premises to the EDAS Servers.
The minimum requirements for a point-to-point connection to EDAS are:
- Bandwidth: Service Level 0 has a transmission rate of 0.6 Mbps. Service Level 1 has a transmission rate of 0.3 Mbps.
- Latency: As minimum as possible (tens of milliseconds)
- Data ordering: The EDAS Data is sent over UDP between the EDAS Data Servers and the provided Client Software, meaning technologies by contract that provide ordered packet transfers are advisable.
- Physical Connection: the EDAS Servers only support Ethernet, RJ45 cables to be connected from/to the point-to-point line.
An IP address is required to identify a determined Client Software (CS) attempting to get a connection to EDAS. If the IP address seen by EDAS from which the data packages originated by the CS is different to the configured one for that specific CS, the connection will not be established.
If the computer where the CS is running belongs to a network (N1) where the IP address is dynamically assigned (usually by DHCP), the IP address to be configured in order to identify the CS should be the external and fixed one of the device used by N1 to get access to the Internet. Furthermore, NAT capabilities should be properly configured inside N1 to enable the correct routing of data packages between the computer where the CS is running and the device granting access to the Internet.
Yes, providing that the NAT is properly configured for the corresponding IP addresses and ports.
An example of NAT rules as it would work for an IPTABLES – Linux-based firewall is similar to this:
# Source NAT for masqueranding internal Client IP Addresses
$IPTABLES –t nat –A POSTROUTING –o -s -j SNAT --to-source
# Destination NAT for masqueranding external Client Addressing to the internal environment
$IPTABLES –t nat –A PREROUTING –p udp –d --dport -j DNAT --to-destination
No, the EDAS client software does not support connections through proxy servers.
The Client Software enables the connection to the EDAS server and ensures a controlled flow of the EDAS data.
After the connection of the Client Software (CS) to the EDAS server, the data flow will be delivered from CS to Service Provider (SP) software, which is the program to be developed by the customer in order to use the data. The connection between CS and SP will be performed over a TCP connection.
The connection handling process can be summarised in the following steps:
- When the CS is initiated, it starts listening for TCP connections on a configurable port.
- The SP software connects to the CS open port using a standard TCP syn message.
- The CS replies with a TCP ack message.
- The CS starts delivering the messages over the opened TCP channel.
In some situations, depending on the OS context and the installed java virtual machine version, a TCP frame may encapsulate several EDAS frames.
The content of the EDAS frames will depend on the Service Level agreed and it is extensively explained in "Interface from Cl. Software to Srv. Provider" chapter of the Client Software User Manual.
In order to install and use the Client Software, the following configuration items must be available:
1. For Unix/Linux systems:
- Any operating system compatible with Sun Java Development Kit 1.5.
- Java SDK 1.5.0_08-b03 or better.
- GNU Tar and Gzip utilities.
2. For Windows systems:
- Windows (XP, 2000, 2003) as operating system
- Java SDK 1.5.0_08-b03 or better
- Winzip, 7zip or similar tool
Minimum throughput or Commited Information Rate (CIR) equals to 600 Kbits/sec for SL0 messages or 300 Kbits/sec for SL1 messages.
Yes, but your application is always subject to approval. You have to provide your school's data in the application form.
The value of the EDAS data will depend on the purpose for which it will be used. For example, applications running outside of Europe and performing analysis of GPS data around the world could find EDAS data valuable.
Data packets containing the information provided by EDAS leave the EDAS Platform server side with an average delay of 70ms. The delay of the time required to transfer the data between the EDAS Platform and the Client Software has to be added. However the exact impact of the total latency on the value of the data cannot be specified because it fully depends on how the data is used. Latencies of one second or even longer are acceptable for our current users.
When running the Client Software, its operation can be checked by analysing log information as it is described in "Client Software Execution" chapter of the Client Software User Manual.
This is available in the download area.
Please be aware that for the reception of the EDAS data you will need to configure your firewall or PC to receive UDP packets. This may be considered a security risk. It is good practice to separate such an experimental network or PC from your main production system.
In order to restore the CRC32 correctly, you should take the following into account:
. EDAS Header CRC field must be set to zero.
. The sixth byte (containing information about quota, corrupted messages received at Client SW level and EDAS gaps) must be also set to zero. Actually, only the first 4 bits must be set to zero (the other 4 of them are reserved for future use and currently are 0).
. The CRC32 must be computed over the complete message, including the EDAS Header modified as explained above.
In order to better explain how the CRC is computed, we include below a couple of examples.
Please see hereunder how the CRC32 should be restored for the Type 0 message generated for a data gap (65 22 DF 69 00 10 00 00).
00 00 00 00 00 00 00 00 --> 6522DF69 [right]
If we do not reset the 6th byte to 0 as explained above, then the result obtained is not correct:
00 00 00 00 00 10 00 00 --> 79047C19 [wrong]
For RTCM messages the CRC32 is computed in the same way. For instance, let us supposed the next beginning of a RTCM message (snippet):
8F 77 90 D4 03 00 00 00 D3 00 95 3E C0 16 46 0B
F2 2C 90 6C 10 C3 54 E9 .......
Therefore, if EDAS Header is set to zero, then CRC32 cannot be restored correctly.
00 00 00 00 00 00 00 00 D3 00 95 3E C0 16 46 0B
F2 2C 90 6C 10 C3 54 E9 ....... --> E130F049 [wrong]
Nevertheless, keeping unaltered the last four bytes of the EDAS Header, the restoring is achieved successfully.
00 00 00 00 03 00 00 00 D3 00 95 3E C0 16 46 0B
F2 2C 90 6C 10 C3 54 E9 ....... --> 8F7790D4 [right]
Technical support is provided after registration by the EGNOS-EDAS helpdesk, operated by ESSP:
By e-mail: firstname.lastname@example.org
By telephone: +34 911 236 555