Abstract
Abstract. In 2013 a project was started by the geophysical centre in Dourbes to install a fully automated magnetic observatory in Antarctica. This isolated place comes with specific requirements: unmanned station during 6 months, low temperatures with extreme values down to −50 °C, minimum power consumption and satellite bandwidth limited to 56 Kbit s−1. The ultimate aim is to transfer real-time magnetic data every second: vector data from a LEMI-25 vector magnetometer, absolute F measurements from a GEM Systems scalar proton magnetometer and absolute magnetic inclination–declination (DI) measurements (five times a day) with an automated DI-fluxgate magnetometer. Traditional file transfer protocols (for instance File Transfer Protocol (FTP), email, rsync) show severe limitations when it comes to real-time capability. After evaluation of pro and cons of the available real-time Internet of things (IoT) protocols and seismic software solutions, we chose to use Message Queuing Telemetry Transport (MQTT) and receive the 1 s data with a negligible latency cost and no loss of data. Each individual instrument sends the magnetic data immediately after capturing, and the data arrive approximately 300 ms after being sent, which corresponds with the normal satellite latency.
Highlights
Princess Elisabeth Antarctica (PEA, Fig. 1b), located on Utsteinen Nunatak in Queen Maud Land (71◦57 S 23◦20 E), is a Belgian scientific polar research station, which went into service on 15 February 2009
We focus on the nearreal-time aspect, other aspects are important for this project:
When it comes to limited-bandwidth connections on satellite links, sending packages that are only filled with 10 % of useful data becomes a waste of resources
Summary
Princess Elisabeth Antarctica (PEA, Fig. 1b), located on Utsteinen Nunatak in Queen Maud Land (71◦57 S 23◦20 E), is a Belgian scientific polar research station, which went into service on 15 February 2009. The LEMI-25 introduces a known delay of 0.3 s (Lviv, October 2014) before the data are available and can be sent over the Internet Because of these time delays, the correct term to use is near-real time (NRT). Rsync typically uses Secure Shell (SSH) connections to encrypt and secure data transfer It will only update the necessary differences between two files. First of all the files need to be created, and secondly the protocols are focussed on sending a file correctly but not really on fast transfer with limited overhead Using these protocols to attain near-real-time data transfer is against their intended purpose, and all of them are still bandwidth-intensive. While these protocols can always serve as fallback mechanisms, it is time to investigate other protocols that minimize the time it takes to read the data from the instrument and send them to the data centre
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
