next up previous
Next: About this document ... Up: Response to Owens Previous: Response to Owens

Regarding Breck's notes on ARGO data telemetry

%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
% $Id: response-to-owens.tex,v 1.2 1999/04/29 14:47:58 swift Exp swift $
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
% Revision Log:
%
% $Log: response-to-owens.tex,v $
% Revision 1.2  1999/04/29 14:47:58  swift
% Minor modifications \& updates in preparation for April 29, 1999 meeting
% with Stan Wilson.
%
% Revision 1.1  1999/04/05 11:58:01  swift
% Initial version given to Steve prior to the April, 1999 ARGO planning 
% meeting
%
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following email was sent by Breck Owens to Dean Roemmich. My comments follow thereafter.

Date: Fri, 02 Apr 1999 17:50:10 -0500
From: Breck Owens <bowens@whoi.edu>
To: "Roemmich, Dean" <roem@beldar.ucsd.edu>
CC: "Riser, Steve" <riser@ocean.washington.edu>,
        "Valdes, Jim" <jvaldes@whoi.edu>
Subject: Argo Communications Paragraphs

Dean,
I have copied below the text for the paragraphs on Argo communications.
I've also attached a word file with them as well.

I've copied Steve Riser,  Bill Woodward, and Jim Valdes to insure that
what I've said is really true.

Breck

____________________________________________________

Transmission of the profiles of temperature and salinity to 2000 m
depth with high spatial resolution (2 dbar) in the upper ocean (to 500
dbar) and moderate resolution below (5 dbar) will require a significant
increase in satellite data communication bandwidth compared to that
available using the present ARGOS system.  It is also desirable to
increase the resolution of the transmitted data to a level greater than
the precision of the measurements so that the communications link does
not limit the quality of the data.  Using simple compression algorithms,
Argo profiles of temperature and salinity will be less than 2000 bytes.
An improved data communication system should also decrease its use of
electrical energy to minimize the batteries required for the floats and
minimize the time spent on the surface communicating.

There are three choices for improved data telemetry: an improved ARGOS,
ORBCOMM, or Iridium.  All three systems will require GPS receivers
either for positioning or accurate time keeping.

The ARGOS system is being upgraded. The first 2nd generation receiver
system is now in space on NOAA K.  Additional 2nd generation systems
will be launched in late 1999 and 2001.  The minimum time between
messages can be reduced to 20 seconds, effectively doubling the data
transfer rate. The receivers also have an increased sensitivity of 2 dB
which will allow a decrease in the float transmitter power output.  Use
of a GPS receiver with satellite ephemeris data in the float would allow
it to only transmit when a satellite is overhead.  However there would
be no way of updating this data on the float or responding to changes in
satellite usage until two way communications is available in the 2003
time frame.  Starting with the system on the ADEOS-II satellite, which
is to be launched in the 2000-2001 time frame, an acknowledgement will
be sent from the satellite upon receipt of the message.  A high data
rate (4500 bps) channel and full two way communications capability will
be available with the 3rd generation system to be launched in the 2003
time frame. In summary, the ARGOS system is evolving from the present
system with immediate savings of order of a factor of 2-3 with an
ultimate reduction by a two orders of magnitude with short surface times
possible by 2003.  Existing antennas will have to be augmented to
receive GPS. The present tariffs are approximately $10 per day for
positions and data transfer.

The ORBCOMM system is a low earth orbit, two-way, data transmission
system consisting of a constellation of approximately 26 satellite
(presently there are 23 operational satellites).  This system has two
modes, a store and forward system using 239 byte messages when only the
transmitter is in view of the satellite and a bent-pipe mode when the
down-link sites are also in view.  In either case, it is a polled system
where the satellite broadcasts its presence and controls the data
transfer.  At present there are 4 down-link sites in the US and one in
Europe with additional sites planned for Australia and Asia.   The
system is a polled system operating at 2400 baud in the 160 (?)
megahertz frequency band which means that the float antennae will have
to be approximately 50% longer.  Although positions can be obtained from
ORBCOMM, the float would be equipped with a GPS receiver necessitating a
dual-frequency antennae.  Worst-case delays waiting for satellite
coverage would be 30 minutes.  Once satellite coverage is available,
data transfer would be completed in less than 1 minute.  ORBCOMM is
presently transitioning to an operational system.  We have successfully
used the system in the laboratory.  Data from subsurface instruments on
a surface mooring near the Canary Islands is presently being sent back
to the University of Bremen using ORBCOMM.  Provisional tariffs are
$11.50 per Kbyte and transmitters presently cost the same as the ARGOS
radio transmitters used in the present profiling floats.  A meeting
between the US funding agencies and ORBCOMM is being set up for later
this year to investigate possible funding scenarios and viability of the
system.  A prototype ORBCOMM float should be deployed by summer 1999.

Iridium consists of 77 satellites providing global coverage for both
voice and data communications and is expected to be comparable to the
present cellular phone system.  Voice communications is now available
and improving rapidly.  Data communications is expected to be available
later in 1999 and will operate at 2400 baud.  Tariffs for data
communications are presently unavailable, however voice usage is priced
at $5-10 per minute.  Iridium uses a frequency band close to that used
by GPS.  Motorola Iridium handsets presently cost $3000.  Alternate
sources for data only units will be available in the near future at a
price approximately half that of the handsets and will allow access to
GPS time and position data which is used by Iridium to locate the
handset.  The higher frequency used for Iridium means that an antennae
shorter than that presently used for the floats could be used for both
Iridium data communications and GPS positioning.  Plans are to deploy an
Iridium float as soon as possible.

My comments will be directed at each point in turn.

1.
 
Transmission of the profiles of temperature and salinity to 2000 m depth with high spatial resolution (2 dbar) in the upper ocean (to 500 dbar) and moderate resolution below (5 dbar) will require a significant increase in satellite data communication bandwidth compared to that available using the present ARGOS system.
This sampling scheme involves $\sim 550$ STP observations. If these 550 observations are to be encoded using 2 kbytes then the data encoding scheme must achieve an encoding ratio of $\frac{2000\
bytes}{550\ obs} \approx 28$ bits/observation. Keep this number in mind for later use.

2.
 
It is also desirable to increase the resolution of the transmitted data to a level greater than the precision of the measurements so that the communications link does not limit the quality of the data. Using simple compression algorithms, Argo profiles of temperature and salinity will be less than 2000 bytes.
If I took this statement literally and at face-value, then there is a potential contradiction with item 1 above since the precision of the pressure sensor will almost certainly be better than 5 decibars (ie., the resolution of the sampling scheme in deeper waters). For example, the Sea-Bird SBE-41 STP module has an absolute accuracy of $\sim 2.4$ dbars (see URL: www.seabird.com/alace.htm) and the precision is at least an order of magnitude smaller than this. To avoid a contradiction between items 1 & 2 then I would have to conclude that the water column were being subsampled every 2 or 5 decibars rather than being binned and averaged every 2 or 5 decibars. However, I would think the latter strategy to be superior in that it would produce more stable and representative profiles. Ok, suppose we keep the sampling scheme described in item 1 and stipulate the use of a bin-average sampling strategy with 2 dbar bins when shallower than 500 decibars and 5 dbar bins when deeper than 500 decibars. Next, suppose we ask that the T & S data be encoded in such a way that the resolution inherent in the encoding scheme represents a smaller error than the statistical variability within any given sampling bin. I believe this more-or-less encapsulates the notion that was intended in item 2. One immediate consequence of the bin-average sampling strategy is that the pressure in any given bin needn't be transmitted back at all. The mean and variance of the measured pressures can probably be taken to be known a priori with reasonable reliability given the ascent rate of the float and the sampling rate of the pressure sensor. This goes a long way in terms of data reduction and its down-sides are probably easy to live with. Hence, we are left with 28 bits/observation to encode both temperature and salinity. To take the subtropical Atlantic as a specific example, the minimum variance within each 5 dbar bin in the deep water is on the order of (0.001 psu, $0.002 ^{\circ}$C) and the dynamic range over the slug of water that represents the subtropical Atlantic is (3 psu, $35\ ^{\circ}$C) (based directly on results of our Atlantic array). If no decimation or compression schemes are used at all, we would need $\log_2({3\ psu/0.001\ psu})\approx 12$ bits for salinity and $\log_2({35\ ^{\circ}C/0.002\ ^{\circ}C})\approx 15$ bits for temperature. Thus, using no decimation or compression schemes at all for T & S then 27 bits/observation are required which is less that than the 28 bits/observation allowed by Breck. Given what I have learned from previous work, it is reasonable to expect a compression ratio of $\sim 1.25:1$ using only decimation. This gets us down to say 22 bits/observation or about 1.5 kbytes per profile. Excluding modern compression algorithms, it might be possible to squeeze a few more percent using various ad hoc methods but any that I know of involve increasing complication and risk. I doubt the potential pay-off makes it worthwhile. Of course, there exist modern compression algorithms such as those used by GNU's gzip. They regularly achieve compression ratios of 1.5:1 - 2:1 for ascii data (much less for random data). However, the use of such methods in conjunction with data telemetry involves a large risk with respect to missing or corrupted segments of data. If some segment of data in the middle of the data set is missing or corrupted for whatever reason, the remainder of the data stream could not be reconstructed if these compression algorithms are used. I would recommend against the use of these methods because of this risk. I should note that there are error correcting codes that could be used in conjunction with compression that can reduce the probability of such problems (but the probability will not vanish). However, modern error correcting codes that are practical exploit the mathematics of degenerate matrices in order to incorporate redundancy in very precise ways. This redundancy will necessarily degrade the gains made by the compression scheme itself. I believe any potential data reduction scheme must possess the property that missing or corrupted segments have only localized effects on the recovered data. That is, it should not have the potential to inhibit the recovery of the data from the remainder of the data stream. Decimation schemes exist that have this property but you can expect compression ratios of only $\sim 1.25:1$ or so.

3.
 
An improved data communication system should also decrease its use of electrical energy to minimize the batteries required for the floats and minimize the time spent on the surface communicating.
Agreed. Data telemetry via Argos currently constitutes about 35-40% of the energy budget for the floats in our Atlantic array. The present ARGOS system consumes about 2.2 Joules/byte of data. The present Panasonic and Stellar Orbcomm transceivers transmit at 5 watts (see Fig. 1 and URLs: www.stellar-sat.com/html/i_products.html and home.earthlink.net/ koryt/). If the communications overhead plus the transmission of 2 kbytes of data requires 5 minutes of transmission time then the energy cost is 0.75 Joules/byte. Iridium is expected to have 4.3mW of transmission energy. I don't know what the consumption rate is but it will almost certainly less than 5 watts. Hence, Iridium should have an advantage here.


  
Figure 1: Panasonic Orbcomm transceiver specification sheet.
\includegraphics[width=6in,bb=30 325 500 725,clip,draft=false]{panasonic.ps}

4.
 
There are three choices for improved data telemetry: an improved ARGOS, ORBCOMM, or Iridium. All three systems will require GPS receivers either for positioning or accurate time keeping.
Hmm...this statement is a little vague but I think I disagree:

Hence, regardless of whether ARGOS, Orbcomm, or Iridium is used, I don't see the need to provide a separate GPS receiver in the floats. Perhaps the statement did not mean to imply that the GPS receiver was necessarily separate.

5.
 
The ARGOS system is being upgraded. The first 2nd generation receiver system is now in space on NOAA K. Additional 2nd generation systems will be launched in late 1999 and 2001. The minimum time between messages can be reduced to 20 seconds, effectively doubling the data transfer rate. The receivers also have an increased sensitivity of 2 dB which will allow a decrease in the float transmitter power output. Use of a GPS receiver with satellite ephemeris data in the float would allow it to only transmit when a satellite is overhead. However there would be no way of updating this data on the float or responding to changes in satellite usage until two way communications is available in the 2003 time frame. Starting with the system on the ADEOS-II satellite, which is to be launched in the 2000-2001 time frame, an acknowledgement will be sent from the satellite upon receipt of the message. A high data rate (4500 bps) channel and full two way communications capability will be available with the 3rd generation system to be launched in the 2003 time frame. In summary, the ARGOS system is evolving from the present system with immediate savings of order of a factor of 2-3 with an ultimate reduction by a two orders of magnitude with short surface times possible by 2003. Existing antennas will have to be augmented to receive GPS. The present tariffs are approximately $10 per day for positions and data transfer.
While ephemeris data could be used to determine when a float should start its ascent, it seems to me that the time spent on the surface is of secondary importance to ARGO's mission. Thus if energy considerations are the more important issue, then there is another way (other than requiring knowledge of the satellite ephemeris) to manage the problem of determining when the satellite is overhead. It is my understanding that current (and future) ARGOS satellites transmit continuously on a known frequency. Thus the satellites announce their presence overhead. Currently, PTT's have no provision for sensing this down-link signal and so the announcement by the satellite is not exploited. In order to avoid transmissions by the float when no satellite is overhead (and thus to avoid unnecessary energy expenditure), it is not necessary to be able to ``read'' the down-link signal; it is only necessary to sense the signal's existence. If manufacturers (maybe Seimac?) can be coerced (by a large order?) into providing a PTT that can sense the existence of a satellite's down-link signal, then considerable energy can be saved with perhaps only a small marginal cost.

6.
 
The ORBCOMM system is a low earth orbit, two-way, data transmission system consisting of a constellation of approximately 26 satellite (presently there are 23 operational satellites). This system has two modes, a store and forward system using 239 byte messages when only the transmitter is in view of the satellite and a bent-pipe mode when the down-link sites are also in view. In either case, it is a polled system where the satellite broadcasts its presence and controls the data transfer. At present there are 4 down-link sites in the US and one in Europe with additional sites planned for Australia and Asia. The system is a polled system operating at 2400 baud in the 160 (?) megahertz frequency band which means that the float antennae will have to be approximately 50% longer. Although positions can be obtained from ORBCOMM, the float would be equipped with a GPS receiver necessitating a dual-frequency antennae. Worst-case delays waiting for satellite coverage would be 30 minutes. Once satellite coverage is available, data transfer would be completed in less than 1 minute. ORBCOMM is presently transitioning to an operational system. We have successfully used the system in the laboratory. Data from subsurface instruments on a surface mooring near the Canary Islands is presently being sent back to the University of Bremen using ORBCOMM. Provisional tariffs are $11.50 per Kbyte and transmitters presently cost the same as the ARGOS radio transmitters used in the present profiling floats. A meeting between the US funding agencies and ORBCOMM is being set up for later this year to investigate possible funding scenarios and viability of the system. A prototype ORBCOMM float should be deployed by summer 1999.
A potential problem that I see here is the limited amount of data that can be transmitted in store-n-forward mode. My understanding is that the satellites have very little memory (I have heard 1 Mbyte but have not been able to confirm that) and consequently there is a limit of 16 messages each of length 229 bytes. I have managed to confirm these specific numbers by talking with someone in Orbcomm's engineering services department. However, during the same conversation I was informed that it is unlikely that more than 3 or 4 of the 229-byte messages would be transmitted to the satellite in the time the satellite was overhead. It doesn't sound at all right to me that at 2400 baud the satellite would pass into and out of view after only 700-900 bytes have been transferred. Such a thing would imply that the satellite is only in view something like 3 or 4 seconds which is far too short a period to be reasonable. In any case, the number of bytes must be kept to less than a few kilobytes per profile per float. With hundreds of floats operating in a given basin, might it be possible to fill the available memory before the satellite can download to the ground station? I think what is needed here is a good empirical test of the Orbcomm system designed specifically with our intended use in mind. This would involve deploying a surface drifter outside the bent-pipe footprint of the any Ground Earth Station (GES) and sending back known messages in store-n-forward mode. The statistics of the accumulated data set could then be used to evaluate Orbcomm's suitability. Acording to Craig Chick (Senior Technical Trainer, Engineering and Operations), Orbcomm is scheduled to have their full constellation (36 satellites) in place by the end of 1999. According to Orbcomm's web page (URL: www.orbcomm.com/about/elementsets/elementsets.html) as of March 31, 1999 there are 28 operational satellites with 24 available to end-users.

March 31, 1999.
These element sets are updated weekly.

The following satellites have been commissioned for service:
A1, A2, A4, A5, A6, A8,
B1, B2, B3, B4, B5, B6, B7, B8,
C2, C3, C4, C5, C6, C7, C8,
G1, G2, F2
Some International NCCs do not have access to all commissioned satellites.
The element sets for satellites F1, A3, A7, and C1 are for informational purposes only - these satellites are not currently available for use by customers attempting to send messages.
Here is an excerpt from Orbcomm's web page (URL: www.orbcomm.com/about/sysdesc.html) regarding the frequency bands involved.

Frequency Allocation
The ORBCOMM System uses 137-138 MHz and 400 MHz frequencies for transmissions down to mobile or fixed data communications devices; and 148-150 MHz frequencies for transmissions up to the satellites.
I agree that a dual-frequency antennae is required. Not to quibble too much but 1 minute might be a bit optimistic when overhead, wave-action, and interference is factored in. Sea trials should enable us to pin this down.

7.
 
Iridium consists of 77 satellites providing global coverage for both voice and data communications and is expected to be comparable to the present cellular phone system. Voice communications is now available and improving rapidly. Data communications is expected to be available later in 1999 and will operate at 2400 baud. Tariffs for data communications are presently unavailable, however voice usage is priced at $5-10 per minute. Iridium uses a frequency band close to that used by GPS. Motorola Iridium handsets presently cost $3000. Alternate sources for data only units will be available in the near future at a price approximately half that of the handsets and will allow access to GPS time and position data which is used by Iridium to locate the handset. The higher frequency used for Iridium means that an antennae shorter than that presently used for the floats could be used for both Iridium data communications and GPS positioning. Plans are to deploy an Iridium float as soon as possible.
Here is an excerpt from Iridium's web site (see URL: www.motorola.com/GSS/SSTG/projects/iridium/facts.html) regarding the satellites in the Iridium system. According to this, only 66 satellites are used.

Space Segment  
Number Of Satellites 66 Interconnected
Number Of Orbital Planes 6
Orbit Height 780 kilometers
Inclination Of Orbital Planes 86.4 degrees
Orbital Period 100 minutes, 28 seconds
Coverage 5.9 million square (statute) miles/satellite
Satellite Weight 689 kilograms
Spot Beams/Satellite 48
Link Margin 16 decibels (average)
Lifetime 5-8 years
I have a copy of the current price structure for voice communications via the Iridium System. It is fairly complicated but for US/ARGO purposes, the most relevant price is that for calls made from international waters to North America. The price for this voice service is presently a bit less that $6.50 per minute. My sources have said that Iridium is projecting $7.20 per minute for data service between international waters and the US. However, I'm also told that much cheaper data service (sold on a per byte basis rather than by time) will be available near the end of 1999.

The frequency bands relevant to the Iridium System are given in the following excerpt taken the same URL as above.

Frequency Bands  
L-Band Service Links 1616-1626.5 MHz, L-Band
Intersatellite Links 23.18-23.38 GHz, Ka-Band
Gateway/TT & C Links  
Downlinks 19.4-19.6 GHz, Ka-Band
Uplinks 29.1-29.3 GHz, Ka-Band
The frequency bands relevant to the GPS system are given in the following excerpt from the URL: www.utexas.edu/depts/grg/gcraft/notes/gps/gps.html#`<SVSignals

GPS Satellite Signals
The SVs transmit two microwave carrier signals. The L1 frequency (1575.42 MHz) carries the navigation message and the SPS code signals. The L2 frequency (1227.60 MHz) is used to measure the ionospheric delay by PPS equipped receivers.
Thus the GPS & Iridium signals are much better matched than GPS & Orbcomm signals. This should help make antennae construction somewhat easier for GPS/Iridium than GPS/Orbcomm.

On technical grounds only, I think that weaning away from the present ARGOS data telemetry mechanism should be methodical and deliberate. It should give time for higher bandwidth data telemetry mechanisms to evolve with the benefit of experiential feedback from (initially) at most a few trial instruments. Simultaneously and in the mean time, I think more work should be done to wring more effective bandwidth from ARGOS and to decrease its share of the energy budget. I do not believe that all ARGO floats should be stipulated to use a single data telemetry system only.


next up previous
Next: About this document ... Up: Response to Owens Previous: Response to Owens
Dana Swift, swift@ocean.washinton.edu