Search
Current schedule
Monday 3/6: Maintenance day, power and access from 0730 to 1630.
Tuesday 3/7: Maintenance day, power and access from 0730 to 1630. RF06 planning meeting at 1100 (to decide whether we want to fly on Thursday or on Friday, and whether there are any objectives left at that point other than those already discussed).
Wednesday 3/8: EMI / flight day. The GV will be moved to the ramp by 0800. The EMI will start at 0830; only MTHP and GPIT are participating in the EMI, other investigators don't need to be onboard. If you wish to operate your instrument at 0830 please check with Kurt if he allows that. RF05 was cancelled due to an instrument malfunction, re-scheduled for Thursday.
Thursday 3/9: RF05. Power and access at 0800 on the ramp, take off at 1000, estimated flight duration 2.3 hours. The flight plan is the same as today except we will add a short mid altitude portion at the beginning to reach ~26,000 feet for 10 minutes, then turn back and descend towards Greeley, do the L-s and pass at 1,000 ft over the reservoirs.
Friday 3/10: RF06 is planned for Friday. Power and access on the ramp at 0800, planned take off at 1000, estimated duration 2.3 hours. The GV will be moved on the ramp at 0745, provided the winds don't prevent it. If the winds are too strong we will enter the standby pattern that we are so used to by now, and move the aircraft once we determine that take-off is possible. Flight plan is as discussed earlier: leave Jeffco, reach 26,000 for 20 minutes, descend to 1,000 ft, do 4 passes over Lake Mcconaughy, do a speed run at 1,000 ft, climb to 10,000, fly there for 20 min and return to Jeffco.
Monday 3/13: Payload post-project calibrations and un-installation begin. Power and access will be as usual from 0730 to 1630. We ask that investigators carry out the necessary calibrations and then let RAF technicians or myself know that they are ready for their rack to come out. If you have shipments to go out, please stage them near the ground power unit behind the GV in the hangar, label them clearly and provide Nate and I with pickup instructions. If you brought chemicals, please take them back with you, unless you made other arrangements with me. Arrange for pickup of any compressed gases as well..
Instrument Description
Aircraft Data System (ADS) Description
Distributed data acquisition boxes acquire data and a record once per second via ethernet to a central computer which records the data to Exabyte. Each box is kept in time synch to the nearest 100 microseconds via an IRIG-B network. Quickly adaptable to new instruments/interfaces.
Each box can sample:
- 64 Analog channels up to 10K samples per second (sps)
- 64 bits of Digital and/or counter
- 8 Serial ports, RS-232 and RS-422
- 3 PMS-1D probes
- 2 PMS-2D probes
- ARINC 429
- Synchro

Two DSMs are shown; the top is open; the bottom shows front LCD display.

NRL P3 ADS rack with data server computer.

Aircraft data acquisition architecture, with future satellite ground communications
Data Formats
ADS Data Format
ADS Header Format
The first "record" of every ADS image (tape or disk) starts with the text string "ADS DATA TAPE" which is 20 bytes long (regardless of what you just counted). The second and third record are identical and contain the header, which describes what was recorded on this image. The header is a binary sequence of C structures. All C structures reside in a file called header.h. The first structure is always Fl:
struct Fl {
str8 thdr; /* I.D. "THDR" */
long item_len; /* Length of this struct in bytes */
str8 version; /* header version number */
str8 prnum; /* project number */
str8 fltnum; /* flight number */
str8 tpnum; /* tape number, obsolete */
str12 date; /* "mm/dd/yyyy */
str12 time; /* "hh:mm:ss" */
str4 tzone; /* i.e. "MST" */
str8 acraft; /* i.e. "N308D" */
long n_items; /* # of items excluding this one */
long lrlen; /* logical record length */
long lrppr; /* logical records per physical rec */
long thdrlen; /* length of this tape header */
str8 ads_type; /* data system type */
};
typedef struct Fl Fl;
struct Fl is then followed by a number of struct Sh's, which describe each analog and digital channel to be sampled:
struct Sh {
str8 item_type; /* desc type, 'SDI' 'HSKP' 'DIGOUT' */
long item_len; /* Length of this struct in bytes */
long start; /* byte address in the data record */
long length; /* data item length in bytes */
long rate; /* sample rate */
long adsaddr; /* ADS channel address */
str8 name; /* name of variable */
str4 type; /* "A", "D", or "C" */
long offset; /* offset between samples */
float convert; /* conversion factor, bits to units */
long order; /* number of cal coefficients */
float cof[MX_COF]; /* cal coefficients array */
long ch_gain; /* channel gain setting, 1, 5, 10, 20 */
long ch_offset; /* channel offset, 0 or 10 volts */
str8 dsm_locn; /* sampling module location */
long convert_offset; /* conversion offset counts at 0 volts*/};
typedef struct Sh Sh;
Notice that all structures start with the same two fields, item_type and item_len. And all structures except Fl also contain start and length, which give the position of the data in each record.
The Sh's are followed in some order by various other probe header structs (Blk, Pms1d, etc. See header.h for a full list):
struct Blk {
str8 item_type; /* 'HDR','GPS','LRNC','JPLTDL','CLIMET' */
long item_len; /* Length of this struct in bytes */
long start; /* byte address in the data record */
long length; /* block length in bytes */
str8 locn; /* sensor location */
str8 dsm_locn; /* sampling module location */
long rate; /* sample rate */
};
typedef struct Blk Blk ;
A minumum header would consist of an Fl and a Blk for the HDR type. HDR contains the data and time stamp for each record.
An example header:
Structure type: __________________________________________________________________________________ | Fl | Sh | Sh | Sh | Sh | Sh | Blk | Blk | Irs | Pms1v3 | ---------------------------------------------------------------------------------- Corresponding variable or block: __________________________________________________________________________________ | | ADIFR | BDFIR | OZONE | CNTS | TTRL | HDR | GPS | INS | FSSP-100| ----------------------------------------------------------------------------------
Some example code to print out all the names in the header:
FILE *fp;
char header[32000], *p;
int i;
fp = fopen("ADS.image", "r");
fread(&fl, sizeof(Fl), 1, fp);
fread(header, fl.thdrlen - sizeof(Fl), 1, fp);
p = header;
for (i = 0; i < fl.n_items; ++i)
{
if (strncmp(p, "SDI", 3) == 0)
printf("%s\n", ((Sh *)p)->name);
else
if (strncmp(p, "HDR", 3) == 0 ||
strncmp(p, "GPS", 3) == 0 ||
strncmp(p, "IRS", 3) == 0)
printf("%s\n", ((Blk *)p)->item_type);
else
if (strncmp(p, "PMS1V3", 6) == 0)
printf("%s\n", ((Pms1v3 *)p)->name);
p += ((Blk *)p)->item_len;
}
At RAF it is unnecessary to actually read the header like this as we have C (libhdr_api.a) and C++ (libraf++.a::hdrAPI) API's for reading the header.
ADS Record Format
Analog and digital are 16-bit values interleaved and grouped by data rate. Many instruments/interface cards/ISRs will produce a block of binary data, which follows the analog/digital section. A header reorded at the front of each file will tell exactly what is/was recorded in that file, and where in each record the data can be found. Header is produced by program xbuild.
ADS Processed Data Format
netCDF. Format supports multi-rate and vector data.
Data Catalog
ADS Data Catalog (for each project)
Files from each project are archived to the SCD Mass Store System (MSS) in an unique directory (See description below.)
- Raw ADS data archived to the MSS
- Tape Images
- One large file per tape
- Occasional multiple-tape flights
- After project completion, tapes are sent to ML machine room
- MIGS jobs with "msimp" verb used to transfer tape image to COS-blocked bitfiles
- Operators mount tapes when jobs are run
- Occasional mismounted tape, probably less than 1%, causes rearchival
- Files larger than about 1.2GB are split into segments
- Disc File Images
- Usualy one large file per flight
- Occasional multiple-file flights
- After project completion, disc files are archived via NCAR network into transparent bitfiles
- Stripped categorized data (SDI, PMS-2D, MCR, MASP)
- Data are stripped at RAF and put into separate files <= 1GB
- Use MIGS or DCS to transfer files (transparent format) to MSS (can set a write password)
- Tape Images
- Production data sets produced using disc images, tape images or stripped ADS data
- Bitfiles for processing are transferred from the MSS to Jeffco using C-shell scripts (msget...)
- NIMBUS produces the netCDF files
- After QC, netCDF files are archived to the MSS
- MSS path prior to 2000: /RAF/YYYY/PPP/xRT/fltno.nc
where:
YYYY = fiscal year
PPP = project number
fltno = flight number - MSS path since 2000: /ATD/DATA/yyyy/Project/Platform/type/fltno.yyyymmdd.ShSmSs_EhEmEs.PNI.nc
where:
yyyy = calendar year
Project = project name or acronym
Platform = example: C-130
type = high- or low-rate data
fltno = flight number
yyyymmdd = flight date
ShSmSs = flight start time (hhmmss)
EhEmEs = flight end time (hhmmss)
PNI.nc = extent (production NIMBUS netCDF)
- MSS path prior to 2000: /RAF/YYYY/PPP/xRT/fltno.nc
- Metadata (description) files also archived to the MSS
- Support files (e.g., NIMBUS processor) archived to the MSS (large tar files)
- Data catalog added to RAF web page
- URL: http://data.eol.ucar.edu
- MSS bitfile log (per project), which includes
- Project name, fiscal year and number
- Aircraft ID
- Principal Investigator(s)
- RAF Project staff
- Processor type (NIMBUS or GENPRO)
- Processed data rate (LRT = 1 sps, HRT = 25 sps)
- Output file format (netCDF or GENPRO and COS-blocked or transparent)
- MSS path and bitfile names
- Flight number
- Flight date
- Start and end times
- netCDF bitfile size
- Bitfile log example (/node/9680)
- Example header (per project), which includes
- Data identifier (RAF contact information) (netCDF only)
- Date data were processed
- Project name
- Aircraft tail number
- Flight number
- Flight start date
- Flight duration (start and end times)
- Descriptions of measurements made on the project
- Short name
- Output data rate (samples per second = sps)
- Calibration coefficients (netCDF only)
- Dependencies for derived measurements, e.g., winds (netCDF only)
- Housekeeping information, like SampledRate, VectorLength (netCDF only)
- Header example (netCDF or GENPRO)
- Future enhancement possibilities
- Scientific objectives
- Data quality report
- Condensed flight data summaries
- Scientist notes
- Map showing where project's measurement were made
- Publications resulting from this project
- "Automatic" data ordering (EMDAC)
Last update: Fri Oct 3 14:03:43 MDT 2003
Display/Analysis Software
ADS Display/Analysis Software
- Support Information
- Supported Operating Systems
-
- Unix
- Solaris 2.4 (WINDS)
- Programming Languages used
-
- C & C++
- Support Libraries and required tools
-
- netCDF 3.4 or later.
- X11R5 with Motif 1.2 or later.
- xview (WINDS)
- Components
Data Distribution
RAF Data Distribution
- Data are public, available to all, unless Principal Investigator (PI) requests restricted access
- If approved, one year restriction, then public access
- Raw ADS data typically not distributed
- Specialized raw data subsets available by special request
- PMS Gray-Scale
- MCR
- MASP
- Specialized raw data subsets available by special request
- Production netCDF data are distributed to PI(s) and scientists
- Project documentation binder to PI(s) (prior to 1996)
- Project documentation web site (since 1996)
- Original video tapes to primary PI
Who gets access to the data; what does it cost?
- MSS data files are readable by anyone having access to the MSS
- By request, data duplicated and sent to scientists via:
- Direct Download from ATD web site
- Anonymous ftp
- SCD Mass Store System (MSS)
- Occasionally on other media
- CD-ROM
- Zip disk
- Magnetic tape
- No charge to PIs
- At present, we do not charge scientists for archived data unless the volume is excessive.
Available data formats
- netCDF
- GENPRO-I and GENPRO-II (obsolete)
- ASCII (small data sets by special request)
Direct download location
FTP location
- ftp.eol.ucar.edu
Supported tape formats
- Binary
- Tar
Contact:
Who do I contact to obtain these data?
- RAF Data Manager (Ron Ruth)
- rafdmg at ucar.edu
- (303)497-1084
Last update: Fri Oct 3 14:11:59 MDT 2003




