Return to RSS data set page.
PDS_VERSION_ID                  = PDS3
RECORD_TYPE                     = STREAM

DATA_SET_ID                     = "VG1/VG2-SR/UR-RSS-4-OCC-V1.0"

OBJECT                          = TEXT
  PUBLICATION_DATE              = 2003-12-31
  NOTE                          = "Voyager RSS Ring Occultation
Data Set Tutorial"
END_OBJECT                      = TEXT

           Voyager RSS Ring Occultation Data Set Tutorial

This document provides a tutorial on how to make optimal use of this
data set. It is organized as follows:
    1. Data Set Overview
    2. Directory Structure
    3. File Names
    4. File Formats
    5. PDS Labels
    6. Processing Guidelines
    7. References

1. Data Set Overview

This data set contains processed ring occultation data obtained by the
Voyager Radio Science Subsystem (RSS). It includes ring occultation
profiles from Saturn (Voyager 1 egress) and Uranus (Voyager 2 ingress
and egress). Ring occultations at Jupiter and Neptune returned
negative results. This data set includes only highly process ring
profiles. See volumes VG_2301 to VG_2369 for the Saturn data in raw
form; the raw Uranus data is not yet archived with the PDS.

A great deal of processing goes into the transformation from raw radio
occultation data to a calibrated, geometrically corrected ring
profile. See Marouf et al. (1982, 1986) for further details. Note
that, when processing the data, one must choose the radial scale at
the outset.

For the Saturn occultation, the Stanford RSS team provided us with
four different ring profiles:

ID    Tape Date    Rev  Resolution  Sampling     Limits
                           (km)       (km)        (km)
RS1   1984-09-20   1.1     0.4        0.2      70,000-145,000
RS2   1989-02-01   1.3     0.4        0.2      70,000-115,000
RS3   Unknown       ?      1.0        0.5      73,000-145,000
RS4   Unknown       ?      5.0        2.5      70,000-144,000

The team warns that the 400-m files may have anomalies and are to be
used with caution. In practice, we have found that the two versions of
the Saturn data processed at 0.4-km resolution are indistinguishable.

Resolution here indicates the smallest spatial wavelength (km/cycle)
present the data; note that all these files have been sampled at the
Nyquist rate, i.e. two samples per wavelength.

For the Uranus occultations, the Stanford RSS team provided us with
ASCII files containing opacity and phase shift as a function of
radius. Note that the rings have individual inclinations, and this
inclination must be considered in the processing. Hence, these files
are provided on a ring-by ring basis.

ID  Resolution  Sampling   Band   Rings
       (km)       (km)
RU1    0.05       0.025     X     All

RU2    0.20       0.025     X     Delta only
                            S     All

RU3    0.20       0.050     X     Delta only

RU4    0.50       0.250     X+S   All

RU5    1.00       0.050     X     Eta only

Note that the RU3 and RU5 profiles are over-sampled relative to the
Nyquist rate.

2. Directory Structure

This volume contains a large variety of files, supporting the RSS
occultation data set. Included are ancillary files related to the
geometry and calibration of the observations.

At the top level, directories S_RINGS/ and U_RINGS/ contain all the
files related to each data set. Within each of these are the
following subdirectories:

Category                      Directories
Derived ring profiles         EASYDATA
Primary data files            EDITDATA
Ring footprint geometry       GEOMETRY
Calibration files             CALIB
Original source files         SORCDATA
PDS-compliant source files    RAWDATA

A few top-level directories contain additional information:
Category                      Directories
Supplementary geometry        SPICE
Documentation                 DOCUMENT, CATALOG, INDEX
Software tools                SOFTWARE

2.1 Derived Ring Profiles

The EASYDATA directories contain easy-to-use derived ASCII profiles
tabulating ring opacity and phase shift, and its uncertainty, vs.
radial location in a ring system. Files are included at a variety of
radial samplings. For Saturn, the profiles are sampled at 0.2, 0.5, 1,
2, 2.5, 5, 10, 20, and 50 km. For Uranus, the profiles are sampled at
0.025, 0.05, 0.1, 0.2, 0.25, 0.5, 1, 2, 5, 10, 20 and 50 km per
sample. Separate profiles are provided for each Uranian ring. Note
that the directories are named based on the sampling interval, not the
resolution; this was chosen for consistency with the analogous
directories of the other Voyager ring occultation volumes, VG_2801
(PPS) and VG_2802 (UVS). All files are Nyquist-sampled so the shortest
spatial wavelength in each profile is twice the sampling value.

For users who wish to make plots of ring opacity without worrying
about the many subtle issues relating to calibration, geometry, and
sensitivity of the RSS data, this directory is the place to look. The
data are suitable for most theoretical analyses and for comparison
with other data sets.

Note that most of the files in these directories have been created by
a resampling of the profiles at finer resolution. Furthermore, we have
updated small errors in the radial scale, which were present in when
the Stanford team originally generated the profiles. This violates our
original assertion that it is best to derive a ring profile directly
from the raw data, by selecting the radial scale and resolution in
advance. We believe that errors introduced by this non-ideal approach
to resampling the data are likely to be quite small.

2.2 Edited Data Files

The EDITDATA subdirectories contains files of the RSS ring profiles
formatted as a radial series of complex emissivities, at the original
sampling of the Stanford team. The ring opacity is directly related
amplitude of the emissivity, and the phase shift is related to the
complex phase. See Marouf et al. (1986) and Gresh et al. (1989) for
the mathematical details.

In this directory, the X-band and S-band data appear in separate files
(with identical structure). Also the files are provided in various
binary formats to support most hardware.

For users wishing to coherently resample the data to a different
radial scale (and understanding the caveats discussed to paragraphs
above), these are the recommended data files to use. You simply need
to resample each component (real and imaginary) separately before the
conversion back to opacity and phase.
2.2 Footprint Geometry Files

The GEOMETRY subdirectories contain files that tabulate the ring
intercept geometry (ring intercept time, radius, and longitude). These
files are simple ASCII tables, uniformly sampled in a parameter called
NOMINAL_RING_RADIUS, i.e., the corresponding radius in the ring plane
during the original processing by the Stanford team. The same sampling
parameter is used in the EDITDATA files, although the GEOMETRY files
are sampled less frequently.

For the Saturn data, the radial scale used by the Stanford team
(Simpson et al., 1983) is slightly outdated now. With the revised
geometry of Nicholson et al. (1990), features shift by 2-10 km. Both
geometry models are included in the GEOMETRY subdirectory. The new
geometry model is sampled according to the same NOMINAL_RING_RADIUS as
the original, making it possible to find the same corresponding sample
in the EDITDATA files. However, the new file lists the corrected
geometry parameters, so the nominal ring radius and the actual ring
radius differ in this file.

For the Uranus data, the orbital elements of the rings that Gresh et
al. (1990) used changed only very little in a later update by French
et al. (1991). The radial scale shifts by ~1 meter during the ingress
occultation and ~40 meters at egress. Nevertheless, both geometry
models are provided.

2.3 Calibration Models

The CALIB subdirectories contain files that tabulate the complex
free-space signal and the noise power in the data. Like the GEOMETRY
files, these are tabulated according to NOMINAL_RING_RADIUS.

Because the EDITDATA files are already fully calibrated, the relevant
free-space signal is always unity in these files. However, including
files of this type makes it possible for a future, minor correction to
the calibration, such as a phase shift correction, to be released via
a simple, small ASCII file, leaving the much larger EDITDATA files

Furthermore, these files contain an additional column, the noise
power. This is a critical piece of information for understanding the
uncertainty in the data.

2.4 Original Source Files

The SORCDATA subdirectories contain the data files in the exact form
in which they were delivered to the Ring-Moon Systems Node. We do not recommend
that they be used, but they are available if needed or for historical
record. They contain no information that cannot be found, probably in
simpler form, elsewhere in this data set.

For the Saturn data files, these are direct copies (using the Vax/VMS
COPY command) of the files on the original 9-track tapes. They are in
Vax variable-length format, in which each record is preceded by a
two-byte value indicating the length of the record.

For the Uranus data files, these are the ASCII tables with some header
information, as originally generated by Donna Gresh.

2.5 Raw Data Files

The RAWDATA subdirectories contain "raw" data, here meaning data
identical to that in the SORCDATA but in more PDS-compliant, easier to
use formats. Binary files are included in multiple formats for the
broadest possible compatibility with current hardware.

2.6 Supplemental Geometry Files

SPICE - This root-level directory contains the ephemerides of the
planet and its major satellites, plus the Earth, Moon and Sun, during
the Voyager encounters. Users familiar with the SPICE toolkit can use
these files to generate just about any other piece of geometric
information relevant to the occultation experiments. See
for more information about the SPICE software toolkit.

2.7 Documentation

Several additional root-level directories contain documentation
associated with this data set. These are directories are required by
PDS standards.

DOCUMENT - This directory contains a variety of documents associated
with the RSS experiments. This directory also contains subdirectories
named GEOMETRY and PROGRAMS, which contain programs and intermediate
data files developed at the Ring-Moon Systems Node for the production of the files
found in the data subdirectories. Any software in these directories is
provided for documentation purposes only and is not otherwise

Note that this directory also contains ATLAS.PDF, at digital
reconstruction of a set of strip charts of the entire Saturn ring
system, published by the Stanford team in the early 1980s. The
explanatory notes can be found in ATLNOTES.PDF.

CATALOG - This directory contains the PDS "Catalog Objects" providing
general information about the data set. The files are:

File name      Topic
DATASET.CAT    This data set.
DSCOLL.CAT     The data set collection---Voyager ring occultations.
MISSION.CAT    The overall Voyager mission.
PERSON.CAT     Personnel involved in the production of this data set
               (Ring-Moon Systems Node staff & RSS team members).
REF.CAT        Bibliographic references.
SOFTWARE.CAT   Supported software tools.
VG1HOST.CAT    The Voyager 1 spacecraft.
VG1SINST.CAT   The RSS instrument and receiving system for Voyager 1
               at Saturn.
VG2HOST.CAT    The Voyager 2 spacecraft.
VG2UINST.CAT   The RSS instrument and receiving system for Voyager 2
               at Uranus.

INDEX - This directory contains a tabulation of all the data files in
this data set.

2.7 Software Tools

SOFTWARE - This directory contains the source code for several
toolkits supporting the processing of this (and other) ring
occultation profiles. More information about these toolkits is found
below (Section 6.4).

This directory also contains two FORTRAN programs, SRSSRESA.FOR and
URSSRESA.FOR, which generate calibrated profiles given an edited data
file, geometry model and calibration model. The former is for Saturn
and the latter for Uranus, but they are essentially identical except
for the format of the output files. These are the programs used to
populate the EASYDATA subdirectories.

3. File Names

ISO-9660 Level 1 standards for CD-ROMs require that file names be a
maximum of eight characters, followed by an extension or type of up to
three characters. All file names are upper case but they sometimes
appear as lower case when the disk is loaded on some systems.

3.1 File Extensions

The major file types used on this volume are:

Binary files:
    Binary data files                       *.DAT
    SPICE ephemeris files                   *.BSP
    Adobe Acrobat documentation files       *.PDF
    Adobe Postscript documentation files    *.PS

ASCII text files:
    PDS labels                              *.LBL
    ASCII tables and indices                *.TAB
    PDS catalog files                       *.CAT
    Text documentation files                *.TXT, *.ASC
    Source code files                       *.C, *.H, *.FOR, *.INC,
                                            *.PRO, *.F1, *.C1, *.H1
    Software build scripts                  *.COM, *.MAK, *.DEF
    SPICE kernels                           *.TLS, *.TPC
    SPICE transfer ephemeris files          *.XSP
    Other files (for documentation only)    *.FIT, *.LOG, *.OUT

3.2 File Naming Conventions

Most of the supported data files provided on this volume are named
according to the following nomenclature:

Characters 1-3: Experiment indicator
    1st character: R for RSS.
    2nd character: S for Saturn; U for Uranus.
    3rd character: 1-5 indicating the processing version of the file.

    The IDs listed in the tables of Section 1 above have been
    constructed according to these rules. If the third character is 0,
    the file is assumed to apply to all the processing versions.

Character 4: File type
    C = calibration models.
    D = edited data consisting of complex emissivities.
    G = footprint geometry files.
    P = resampled ring profiles.
    R = raw data.

Characters 5: Version number
    A one-digit number indicating the version number of the given
    file. In general, the meaning of this number depends on the
    experiment and file type.

Character 6: Band
    S = S-band; X = X-band; B = both.

Characters 7-8: Supplemental
    These characters are only used when needed to further identify a
    file. They are used to distinguish rings, ingress vs. egress,
    binary data formats, etc. These characters are explained in the
    *INFO.TXT file in each relevant subdirectory.

Non-data files do not follow these conventions.

4. File Formats

4.1 ASCII Text Files

Different popular operating systems use different standards for how
ASCII text files are formatted. On Unix systems, lines are terminated
by a >LF< (linefeed character, control-J, ASCII 10). On Macintosh
computers, lines are terminated by a >CR< (carriage return character,
control-M, ASCII 13). On PCs, lines are terminated by a >CR<>LF< pair.
PDS standards require all text files to use >CR<>LF< line termination.
STREAM, then this line termination is in use.

On occasion, users on Unix and Macintosh computers may need to change
the line termination on some text files before they can use them. This
can be handled via text editors or a variety of utilities. For
example, the Unix tr (translate) command can be used to change
carriage returns to blanks:
    tr "\015" " " >oldfile.txt <newfile.txt

Note that some software tools provided with this data set could fail
if the extraneous >CR< characters are simply removed from ASCII-format
data files rather than being replaced by blanks; the reason is that
removing the >CR< changes the record lengths within the file, which
could make the file incompatible with its PDS label.

4.2 Binary Data Files

Binary data file formats differ among hardware platforms. Most binary
files are provided in these formats:

IEEE: For Sun, SGI and Macintosh platforms. Integers appear with most
significant byte first; floating-point numbers appear in IEEE format.

PC: For PC platforms. Integers appear with least significant byte
first; floating-point numbers appear in byte-reversed IEEE format.

Vax: For DEC (now HP) VMS platforms. Integers appear with least
significant byte first; floating-point numbers appear in Vax G format.
Although not widely used today, this is the platform on which most
Voyager data were originally used. Note that, for files containing
nothing but integers, the PC versions of files can be used.

Note that the software tools included in the SOFTWARE/PROFILE
subdirectory take care of all data conversions automatically.

5. PDS Labels

5.1 Types of Labels

On this volume, every file has a PDS label. Most are in the form of
detached labels, where the label corresponding to a given file has the
same name but an extension ".LBL". For example, the file RS1D1XCI.DAT
is described by the label file RS1D1XCI.LBL.

There are a few exceptions to this rule. Some text files (like this
one) have attached labels, meaning that the label information can be
found at the top of the actual file. These can be recognized by the
fact that the file ends with .TXT and there is no corresponding file
ending in .LBL. Information files *INFO.TXT that appear in most
directories and describe that directory's contents use this approach.

Finally, a few directories employ "combined-detached" labels, in which
a single label file describes most if not all the files in the
directory. In this case, the label file is given the same name as the
enclosing directory, with the .LBL extension. For example, the
directory DOCUMENT/EDITDATA/PROGRAMS contains a single
combined-detached label file PROGRAMS.LBL.

5.2 PDS Label Structure

PDS labels contain nothing but ASCII text and can be viewed using any
editor or word processor software. However labels have a very specific
format that can be read by humans and also (relatively) easily parsed
by computers. The PDS has developed toolkits called the Label Library
(L3) and the Object Access Library (OAL), which make it easy to read,
manipulate and write PDS labels and the data files that they describe,
using programs written in C or FORTRAN. The directory SOFTWARE/OAL on
this volume contains the source code for both of these libraries.

A PDS label consists of a sequence of expressions of the form "keyword
= value". These keywords are sometimes nested inside data objects,
indicated by "OBJECT = xxx" and terminated by "END_OBJECT = xxx".
These data objects describe specific components of the corresponding
data files. PDS objects can be nested; for example a PDS TABLE object
generally contains multiple COLUMN objects. Keywords inside the TABLE
object describe the overall properties of the table, and afterward the
keywords inside each COLUMN object describe one particular column.

Here is an annotated example, excerpted from file
U_RINGS/EASYDATA/KM00_1/RU1P2XEE.LBL, which describes the derived
X-band profile of the Uranian Epsilon Ring during the egress
occultation. The file begins with information about the structure of
the data file:

  PDS_VERSION_ID                  = PDS3
  RECORD_TYPE                     = FIXED_LENGTH
  RECORD_BYTES                    = 50
  FILE_RECORDS                    = 831
  ^SERIES                         = "RU1P2XEE.TAB"

This indicates that file RU1P2XEE.TAB is a FIXED_LENGTH file in which
each record contains 50 characters, INCLUDING the >CR<>LF< pair. The
file has 831 records. Next come some general information that appears
in essentially every PDS-formatted data file:

  DATA_SET_ID                     = "VG1/VG2-SR/UR-RSS-4-OCC-V1.0"
  RING_OBSERVATION_ID             = "U/OCC/VG2/RSS/X/1986-01-24"
  PRODUCT_ID                      = "KM00_1/RU1P2XEE.TAB"
  PRODUCT_TYPE                    = RING_PROFILE
  PRODUCT_CREATION_TIME           = 2002-12-29T16:00:00
  SOURCE_PRODUCT_ID               = {"RU1D1XEE.TAB",

  SPACECRAFT_NAME                 = "VOYAGER 2"
  SPACECRAFT_ID                   = VG2
  INSTRUMENT_ID                   = "RSS-VG2U"
  TARGET_NAME                     = "U RINGS"
  START_TIME                      = 1986-01-24T22:52:44.386
  STOP_TIME                       = 1986-01-24T22:52:54.357
  EARTH_RECEIVED_START_TIME       = 1986-01-25T01:37:34.887
  EARTH_RECEIVED_STOP_TIME        = 1986-01-25T01:37:44.858
  SPACECRAFT_CLOCK_START_COUNT    = "26853:57:742"
  SPACECRAFT_CLOCK_STOP_COUNT     = "26853:58:108"

Here RING_OBSERVATION_ID is a creation of the Ring-Moon Systems Node, used as a
parameter by which our on-line catalogs are organized. The PRODUCT_ID
is a unique identifier for each file in the data set. The
SOURCE_PRODUCT_ID parameter provides a link back to the files used in
the generation of this file. Since this is a calibrated profile, it
uses three different files---an edited data file, a geometry footprint
file and a calibration model.

Note that, for radio occultations, START_TIME and STOP_TIME refer to
the moments when the photons left Voyager. EARTH_RECEIVED_START_TIME
and EARTH_RECEIVED_STOP_TIME refer to the moments when the photons
arrived at the Earth-based receiving station.

Following is a set of parameters that are common to all of the Rings
Node's occultation data files:

  OCCULTATION_TYPE                = RADIO
  WAVELENGTH                      = 3.5602985e4  /* microns, X-band */

  RADIAL_RESOLUTION               = 0.2
  MINIMUM_RING_RADIUS             = 51301.
  MAXIMUM_RING_RADIUS             = 51384.
  INCIDENCE_ANGLE                 = 8.47111

The wavelength unit of microns is a bit peculiar for radio science,
but has been chosen for compatibility with other data sets.

Note that we list two parameters, RADIAL_RSESOLUTION and
RADIAL_SAMPLING_INTERVAL. These are Nyquist-sampled files so the two
differ by a factor of two.

Next come some geometry parameters describing the ring model used
during the processing of the data:

  SOFTWARE_NAME                   = "STANFORD RSS 1988"
  SOFTWARE_VERSION_ID             = "1.0"
  NAIF_DATA_SET_ID                = 'N/A'
  TELESCOPE_LATITUDE              = -35.22092298  /* geocentric */
  TELESCOPE_LONGITUDE             = -148.98127910
  TELESCOPE_SITE_RADIUS           = 6371.688735
  COORDINATE_SYSTEM_ID            = (J2000,B1950)
  POLE_RIGHT_ASCENSION            = (77.3115314,76.597462)
  POLE_DECLINATION                = (15.1746250,15.111782)

  FEATURE_NAME                    = "EPSILON RING"
  REFERENCE_TIME                  = 1977-03-10T20:00:00.000
  RING_SEMIMAJOR_AXIS             = 51149.32
  RING_ECCENTRICITY               = 7.936E-03
  RING_INCLINATION                = 0.0002
  RING_PERICENTER_LONGITUDE       = (214.69,214.97)
  NODAL_REGRESSION_RATE           = -1.36148
  RING_RADIAL_MODE                = 'N/A'
  REFERENCE_KEY_ID                = FRENCHETAL1988

The hope is that, if some new model for the Epsilon ring is released,
we could generate new profiles in which this piece of the label
describes the updated orbital model. Some parameters are given in
pairs, where the first value is in J2000 coordinates (the PDS default)
and the second is B1950 (the coordinate frame in which these files
were originally processed).

Next, this label describes a data file containing derived ring opacity
and phase shift vs. radius. It is formatted as a table with columns.
This is now described by a SERIES object:

  OBJECT                          = SERIES
    NAME                          = OCCULTATION_PROFILE
    ROWS                          = 831
    COLUMNS                       = 6
    ROW_BYTES                     = 50
    DESCRIPTION                   = "This is a radial profile...

Most of the data products on this volume are structured as either a
table or a series. Both of these have the same logical structure---a
set of rows structured identically, each containing a sequence of
column values. The difference is that a series has rows that are
uniformly spaced in a particular "sampling parameter", as indicated by
the SAMPLING_PARAMETER keywords shown above. They indicate that this
file is sampled uniformly in ring intercept radius, with one record
every 0.1 km, starting at 51,301 km and ending at 51,384 km.

Next come a set of six COLUMN objects, each describing one column in
the table. For example, the fourth column is described this way:

    OBJECT                        = COLUMN
      NAME                        = NORMAL_OPACITY_UPPER_LIMIT
      DATA_TYPE                   = ASCII_REAL
      START_BYTE                  = 27
      BYTES                       = 7
      FORMAT                      = "F7.4"
      MAXIMUM                     = 99.
      UNIT                        = 'N/A'
      DESCRIPTION                 = "Estimated upper limit on the 50%
    confidence interval for the ring opacity. For opaque rings, this
    value is set to 99."
    END_OBJECT                    = COLUMN

It indicates that characters 27-33 in each row contain the upper limit
on ring's opacity, defined by the 50% confidence interval. The column
is formatted as F7.4 using FORTRAN notation. A maximum value of 99 is
indicated; in this case, it means that a value of 99. means the actual
upper limit is larger, possibly undefined because the received signal
is statistically indistinguishable from zero.

After the last column object, the file ends as follows:

  END_OBJECT                      = SERIES

The first line here marks the end of the SERIES object description,
and the second marks the end of the label itself.

Here are the first three lines of the data file:
  51301.000,-0.0460,-0.0977, 0.0072,   3.99,  1.52
  51301.100,-0.0055,-0.0583, 0.0487,   3.05,  1.55
  51301.200, 0.0469,-0.0073, 0.1026,   6.30,  1.59
The six columns are, in order, named RING_INTERCEPT_RADIUS,
The column described by the NORMAL_OPACITY_LOWER_LIMIT column is

The detailed definition of every PDS keyword appearing in the label of
a data file can be found in the file DOCUMENT/PDSDD.TXT. These
definitions have been extracted from the PDS Data Dictionary.

See the PDS Standards Reference (JPL D-7669) for a complete
description of PDS label formats. This document can also be found on
line at

6. Processing Guidelines

As noted above, many users will find that files in the EASYDATA
directories meet their needs for RSS data. These contain tabulations
of ring opacity, phase shift and their uncertainties, resampled to be
uniformly spaced in ring radius.

In this section we discuss some of the technical details behind the
generation of these calibrated profiles.

First a reminder---the optimal way to generate processed profiles is
to go back to the raw data (not provided) and follow the procedures
described by Marouf et al. (1982, 1986). These files have been
generated instead by resampling the already-processed files. We
believe this to be a close enough substitute to provide results that
are generally valid, but requiring much less computational effort.

6.1 Edited Data

The primary input file for one of these profiles is an edited data
file, as are found in the EDITDATA directory. The key property of
these files is that they are uniformly spaced in "nominal ring
radius". The word "nominal" is chosen to indicate that, subsequent to
the original processing by the Stanford team, the ring models have
changed. "Nominal ring radius" is used to indicate a particular sample
in the edited data files; it is not necessarily identical to the
actual ring radius once a new geometry model has been applied.

6.2 Geometry Files

The edited data files are labeled as SERIES objects, in which the
files are indexed using exactly the same sampling parameter, so that
it is relatively straightforward to find the values of geometry
parameters associated with a data sample. Geometry parameters are
sampled much more coarsely than the data, but can be interpolated if
necessary because they vary smoothly.

In addition to the NOMINAL_RING_RADIUS, columns in these files include
RING_INTERCEPT_TIME (corrected for light travel time),
the ring plane's ascending node on the Earth's equator of J2000),
B1950_RING_INTERCEPT_LONGITUDE (same as previous but measured using
the Earth's equator of B1950), SPACECRAFT_EVENT_TIME (the time the
photon left Voyager in seconds), EARTH_RECEIVED_TIME (the time the
photon arrived at the ground station, in seconds) and INCIDENCE_ANGLE
(in degrees). The *_TIME columns are measured in seconds relative to a
REFERENCE_TIME specified in the corresponding COLUMN object, typically
midnight UTC at the beginning of the current day. INCIDENCE_ANGLE is
included as a geometry parameter because, unlike in stellar
occultations, it changes slightly during a radio occultation

Values in these files are generally provided at much greater precision
than can be considered reliable. The additional precision makes it
easier to interpolate the models smoothly.

For the rings of Saturn, two geometry solutions are provided, RS0G1B
and RS0G1B. They both apply to all processings of the file and to both
wavelengths. The former only contains the model as used during the
original processing of the data. The latter contains the update based
on the work of Nicholson et al. (1990).

Because many rings of Uranus are inclined, the ring intercept geometry
depends on the specific inclination and orientation of a given ring.
As a result, it was necessary to provide a unique geometry file for
each ring. The naming convention is as follows:
    RU0GnBrd.TAB & .LBL
    n = ring model number: 1 = as used by the Stanford team;
                           2 = updated by French et al. (1988).
    r = ring identifier: 6 = Ring 6;
                         5 = Ring 5;
                         4 = Ring 4;
                         A = Ring alpha;
                         B = Ring beta;
                         N = Ring eta;
                         G = Ring gamma;
                         D = Ring delta;
                         L = Ring lambda;
                         E = Ring epsilon.
    d = occultation direction: I = ingress; E = egress.

6.3 Calibration Files

Like the geometry files, calibration files are labeled as SERIES
objects and use the same SAMPLING_PARAMETER as the corresponding
edited data files and geometry files. The four columns in these files
FREE_SPACE_SIGNAL_IM and NOISE_POWER. Normally one would divide the
EDITDATA complex values by the complex "free space signal" found in
these files. However, because the EDITDATA files have already been
normalized and no revise calibrations have been produced, this step is
actually unnecessary. The noise power, however, is critical to
understanding the uncertainty in the data files.

6.4 Profile Generation Procedure

Files in these subdirectories identified as version 1, i.e. files
named RxxP1*.TAB, have been generated using the original geometry of
the Stanford team.

The remaining files in these subdirectories have been generated by the
Ring-Moon Systems Node using programs SOFTWARE/SRSSRESA.FOR and
SOFTWARE/URSSRESA.FOR. It should be possible for computer-savvy users
to build these programs and run them locally if they wish. They are
built upon the PROFILE and OAL libraries, which are also included. The
label of each derived EASYDATA profile includes a summary of the input
parameters used by the programs.

The programs request three input files: edited data, geometry, and
(optionally) calibration. These must refer to the same ring
occultation and must overlap, as indicated by a common range of

The programs convert the edited data to a uniformly-spaced series of
samples using the new geometry model, in which each new radial sample
is calculated via a weighted average of the relevant raw samples. The
weighting function is derived from the known weighting of the raw data
(a sinc function, sin(x)/x) and a target point-spread function (PSF).
The target PSF is usually another sinc function, but the user is free
to chose alternative PSFs.

The program then converts the resampled data to opacity and phase, via
the procedures described by Marouf et al. (1986) and Gresh et al.
(1989). First, the mu factor can be derived from the emission angle,
found in the geometry file:
        mu = cos(emission_angle)
Note that the angle must be converted from degrees to radians!

The opacity tau is then defined as
        tau = -2 * mu * log(abs(emissivity))

The phase shift is simply the complex phase of the emissivity, i.e.
        cos(phase) = Re(emissivity) / abs(emissivity)
        sin(phase) = Im(emissivity) / abs(emissivity)

The program also converts the noise power, as found in the calibration
file to a confidence interval on tau and phase. See Marouf et al. and
Gresh et al. for these details.

6.5 Notes about Effective Resolution

As you search the EASYDATA directories, you will find that files of
the same ring and output resolution have been generated from different
source resolutions. For example, in the S_RINGS/EASYDATA/KM001/
directory are files resampled from the RS1 (0.4-km resolution) and RS3
(1.0-km resolution) edited data files. Shouldn't they be the same?

We expected this to be the case but it is not. In fact, data from Tape
#1 (0.4 km), when resampled to 1 km, shows distinctly sharper edge
features than does the data from Tape #3 (already at 1 km). The reason
for this is unclear. Mark Showalter, of the PDS Ring-Moon Systems Node, believes
that the Stanford group subjected their data to a modest low-pass
filtering. In support of this conjecture:

(a) Fourier transforms of the source data show that the amount of
power in spatial wavelengths less than 2-3 times the Nyquist
wavelength are systematically low.

(b) Whenever data files are subsampled by more than a factor of ~3,
the results are indistinguishable regardless of the source. For
example, the 0.4 km and 1 km source files (Tapes #1 and #3), when
resampled to 5 km, are indistinguishable from one another but much
sharper than profiles from the 5-km source files (Tape #4). This again
suggests that the 5-km source files are systematically lacking in
spatial frequencies that are present in the finer-resolution files.

(c) In the source data, the deviations between adjacent estimates of
tau are substantially smaller than the estimated uncertainties. If
adjacent samples where statistically independent, then this would not
be the case. In the resampled profiles, the deviations are much more
consistent with noise estimates.

(d) Only edges known to be sharp (via other occultation data) show
extra sharpness in the resampled profiles. Thus, it is not an
artificial sharpening of the data that has been applied.

So which files should you use in the EASYDATA subdirectories?  Here
are few rules of thumb.

(1) If you want the original geometry used by the Stanford team, use
the version-1 files, RxxP1*.TAB. These only exist in the directories
with the same sampling as the source files, as listed in the tables of
Section 1.

(2) If you believe that the Stanford files are slightly smoothed, and
prefer the sharpest possible data, use the version-2 files the lowest
ID. In other words, use the files RxnP2*.TAB where n is smallest.
These are the files that have been resampled furthest relative to the
original source.

Note that, in some directories, the lowest n is not 1. This is
because, once the data have been resampled by more than a factor of
~3, files of the same resolution are essentially indistinguishable,
regardless of the resolution of the original files.

(3) If you prefer the files as close as possible to the Stanford
versions, but with the corrected geometry, use the version-2 files
with the highest ID. In other words, use the files RxnP2*.TAB, where n
is largest.

Nevertheless, it is also clear that resampling the data, even in a
coherent manner as programs SRSSRESA.FOR and URSSRESA.FOR do, is not
quite the same as processing the original, raw RSS data to the desired
resolution. Thus, this issue remains unresolved. For the time being,
we provide the data in both forms and let the user decide which
version of a profile to use.

7. References

French, R.G., P.D. Nicholson, C.C. Porco and E.A. Marouf 1991.
Dynamics and structure of the Uranian rings. In Uranus (J.T.
Bergstralh, E.D. Miner and M.S. Matthews, Eds.), University of Arizona
Press, Tucson, pp. 327-409.

Gresh, D.L., E.A. Marouf, G.L. Tyler, P.A. Rosen, and R.A. Simpson
1989. Voyager radio occultation by Uranus' rings: I. Observational
results. Icarus 78, 131-168.

Marouf, E.A., G.L. Tyler, and V.R. Eshleman 1982. Theory of radio
occultation by Saturn's rings. Icarus 49, 161-193.

Marouf, E.A., G.L. Tyler, and P.A. Rosen 1986. Profiling Saturn's
rings by radio occultation. Icarus 68, 120-166.

Nicholson, P.D., M.L.Cooke, and E. Pelton 1990. An absolute radius
scale for Saturn's rings. Astron. J. 100, 1339-1362.

Simpson, R.A., G.L. Tyler, and J.B. Holberg. Saturn's pole: Geometric
correction based on Voyager UVS and radio occultations. Astron. J. 88,
1531-1536, 1983.

Return to RSS data set page.