The challenge of transmitting useful Expendable Bathythermograph (XBT) data from ships at sea to shore in a timely manner is driven by economics and historical coding procedures. In the past we were constrained by how detailed the message being transmitted was, which limited the amount of useful information delivered from the ship. For instance how long could the ships radio officer using Morse code continue to key in a single message without making a mistake or the receiving station from making a decoding error? Hence, we started out using five (5) digit groups of numbers that were preceded and ended with internationally agreed upon letters like JJXX or JJVV for XBT data and BBXX for sea surface meteorological data.
In the case of XBT data these five (5) digit groups were used to identify date, time, position, ships call sign and converted the analog signal or physical trace of temperature vs. depth data into a digital format, called inflection points, for transmission and decoding ashore. Originally this coding of the XBT trace was done by manually or by hand by ships officers or sea going technicians who picked out the major inflection points of the XBT analog trace by determining those points of depth and temperature that best described the analog trace in its totality. By agreement no more than about 30 depth/temperature doublets were used for any single XBT trace even though the analog data collected was an order of magnitude more detailed.
As technology improved to convert analog signals to digital and software techniques were developed to remove the manual or hand selecting of these inflection points we began to develop more sophisticated procedures for transmitting this XBT data from the ship to the shore and saving the full resolution data on a computer. Oh, we still only transmitted the five (5) digit groups but we did it faster, better and cheaper by removing the need for a person to key in the information on the ship and another person to decode the same information on shore.
Depending on ones application, for instance where you are on the globe, on land or sea, or if you need a position, can make a difference. If you require a lot of information from the higher latitudes then you would want to use polar orbiter satellite technology. If you require a lot of information in the lower latitudes then you would want to use geosynchronous satellite technology. If you dont care because you are a fixed platform like a moored buoy or a fixed weather station and hence really dont require a position to be transmitted, then your considerations would focus more on the data throughput requirements.
In the oceanographic community we are faced with all of these questions and frequently make compromises based mostly on economics. Changing technologies can be expensive but just as we migrated from carrier pigeons to Morse Code, to HF voice, to satellite communications we must keep upgrading our systems to remain current and efficient. The paper Developments in Satellite Communications Systems, by David Meldrum and Oli Peppe of the CCMS, Dunstaffnage, Oban, Argyll, Scotland and presented at the Data Buoy Cooperation Panel Seventeenth Session held in Perth, Australia October 22-26, 2001, provides an excellent overview of the myriad of satellite systems presently utilized; and from which I have been given permission to flagrantly plagiarize.
There are three basic operational systems used for transmitting XBT data from ship to shore:
XBT Data Transmission Techniques for SOOP |
|||
| System | ARGOS |
GOES/Meteosat/GMS |
INMARSAT-C |
| Status | Operational | Operational | Operational |
| Satellite Type | Polar Orbiter | Geostationary | Geostationary |
| Orbit Type | LEO | GEO | GEO |
| Position of Observation | Pseudo/Doppler | Manual/GPS | Auto GPS |
| Message Type | Data: 32 Bytes | Data: 80 Bytes | No Maximum |
| Message Size/Transmission | 15 Data points | 40 to 120 Data points | Full Res.-Comp. Binary |
| Terminal Size | PC card | 5.5 kg | 1.0 kg |
| Required Hardware | Computer/Lap | Computer | Computer |
| Software Required | CSIRO/ORSTOM | SEAS | SEAS |
| Power Usage (watts) | 1 watt | 10-24 watts | 15 watts |
| Antenna | Omnidirectional | Omnidirectional | Omnidirectional |
| Data Delay | < 8 Hours | 1-24 Hours (preset) | < 0.25 Hour |
| Data Processing | Service Argos | National Governments | NOAA |
| GTS Insertion/Distribution | Service Argos | Nat. Telecomm. Gateways | Nat. Telecomm. Gateways |
| Cost per observation | < 5 USD | Free | < 0.5 USD |
General Comments:
Argos:
GOES:
INMARSAT-C:
The present definition of real time XBT data is to accept and insert onto the Global Telecommunications System (GTS) any XBT data collected within the previous 30 days. Therefore most XBT data can be inserted onto the GTS after the vessel is visited and serviced and not have to address the challenge of real-time transmission from ships at sea. One incentive for real-time transmission is the early identification of possible sampling problems that occur at sea thus providing the opportunity to address those problems quickly and/or make sampling adjustments. Another is that as the coordination of global monitoring and climate observing model development improves there will be an increased need for real-time data.
As technology continues to improve the cost per message transmitted should continue to decrease. Decisions based on mission requirements vs. cost should be considered by all national managers, however, guidelines need to be provided by international bodies to facilitate and improve the global dissemination of XBT data. Improvements to coding that allow for the transmission and efficient dissemination of more detailed metadata files and full resolution XBT data still need to be developed.