MBARI OASIS3 Mooring Guide

Data Logging On OASIS3

OASIS3 Data Logging

OASIS Data Record Format

OASIS is, in essence, a data logger and instrument controller. But because it is based on a small 16 bit microcontroller, it can't directly address enough memory to be useful. The designers have used a windowed memory scheme to circumvent this limitation. As a result, log memory on OASIS is divided into log blocks and log records. A log block is typically 16K of memory, although it can be any power of 2 up to 64K (the address limitation of the CPU). Within each block, we log as many data records as will fit. Data from every instrument in the system is logged sequentially as it comes in. To keep this straight, every data record is preceded by a record header, which contains the following information:

The instrument data varies in size, typically from a few bytes for analog instruments to several KBytes for instruments like the ADCP, Hobi Labs HydroRad, or ISUS nitrate sensor.

Binary File Format

The binary file format is normally used only the the Eqpac moorings, when the high frequency data is downloaded using the dump command while visiting the mooring. It consists of a stream of binary records as described above. Binary files can be decoded by decode and extract using the -b command-line flag.

Hex File Format

The hex file format is normally not used. Hex output from OASIS is intended to be more readable by humans, but is not an efficient format for downloading and storing data. Nevertheless, it is supported as a file format in decode and extract because sometimes data is (erroneously or intentionally) saved in this format. Use the -h flag. Note that the sync character is not sent. In this format, data is output one record (instrument) per line, unless the data field is too big to fit on a 64 character line, in which case the data portion is broken into multiple lines. The format is: tt rr nn tttt ddd...d, where tt is instrument type (see Instrument Types) rr is record number nn is record length tttt is time & date in Unix time_t format (seconds since 1/1/1970), and ddd...d is the instrument data.

UUencode File Format

The uuencode format is the normal format for downloading data, either via packet radio or a direct serial connection. Uuencode is a format invented by the Unix community to encode binary data as an ASCII stream, in order to allow the data to be passed on channels that can't pass 8 bit binary. The OASIS uuencode format follows the conventions of Unix uuencode, while passing information about block numbers in the field that Unix uses for file names. The format is as follows: begin 644 oasis.nn end begin 644 oasis.nn+1 end etc The nn (or nn+1) in the "begin" statement indicates the block number for the OASIS data (remember that record numbers are in the record headers). The next lines encode the binary data, as documented above, into ASCII characters; each 3 binary bytes is encoded into 4 ASCII characters. Every OASIS record begins on a new uuencode line. Finally, the "end" statement is required by uuencode. A minor difference between the binary and uuencode formats is that the uuencode format doesn't include the sync character. The uuencode format is the default for decode and extract.

OASIS3 Storage Capacity

OASIS3 stores the log data in files on the CF2's Compact Flash Memory (CFM) card, using standard file system calls. CFM card capacities from 8 MB (smallest available) to 1 GB are supported (see OASIS3 Limits). The data is stored in files named OASnnnnn.DAT, where nnn = 000 to 65535. Each file stores 16384 log records, though that can be changed through the defined constant RECS_PER_BLK in log.h. If the CFM capacity is exceeded, data files are deleted, oldest first.

The getoasis script uses the getdata command to automatically send the data acquired since the last download. If invoked with -r option, getoasis then reads the oasis.rcd file and requests the records specified in oasis.rcd using the getlog. getoasis does not check to see whether or not getlog was successful. The extract program also reads oasis.rcd; if a record marked as missing is found in a current data set, it is removed from oasis.rcd. extract also notes when records appear out of sequence and puts a new entry in oasis.rcd. There is currently a maximum of 40 records total in oasis.rcd(??? NLOGS=40...must build both extract and getoasis...). Note that if data is not recovered before the block drops out of the memory log (FIFO), it's entry in oasis.rcd may remain there indefinitely. If oasis.rcd fills up with records that have dropped out of the log memory, data gaps can occur.

ARGOS Messages

The equatorial Pacific (EQPAC) moorings use System ARGOS to send data to shore daily. Each EQPAC mooring is equipped with an ARGOS tranceiver. MBARI licenses 6 PTT numbers plus two failsafe PTT numbers (25981, 25982). Two PTT numbers are used to send data in each EQPAC can:

They are selected by setting PARM1 and PARM2 of the ARGOS driver in drvr.h. PARM1 is an index into the list of PTT numbers programmed into the ARGOS tranceiver; PARM2 is the number of PTTs to use. For example, to select PTTs 11909 and 11910, set PARM1=0 and PARM2=2. In the lab, only one PTT is used per can (i.e., PARM1=4 PARM2=1); the can under test transmits into a dummy load to a local receiver. The failsafe IDs, used for local moorings, are not configurable via OASIS; they must be programmed into the transponder before installing it in the OASIS can. Similarly, the PTT table must be set up on the transponder before it can be used. Some software and cables for this should exist in the lab.

Since there are not enough pairs of PTT numbers for four EQPAC cans (two on site and two under test), the units en route to the deployment station share PTT numbers with those on site and must always transmit into a dummy load to avoid mixing test data with data from the field.

In the EQPAC moorings, OASIS collects data to RAM and to hard disk, as with local moorings. It also maintains two sets of ARGOS message buffers for 'real time' (daily) data telemetry. One set of 10 is for transmission, the other is for data being collected. Once every 24 hours (at midnight usually), the new data buffer is marked for transmission, and the transmit buffers are marked for new data. Since ARGOS messages may only be 32 bytes in length, the data is an abbreviated version of the complete data set.

From the EQPAC stations, the satellites are in view during two four-hour windows each day. During these windows, the ARGOS driver runs, sending data from the transmit buffers every minute or so. It sends the 10 transmit buffers in turn, as many times as it can during each four hour window. The sequence that the buffers are sent in may be set by modifying sendOrder array in argos.c.

The organization of the message buffers is defined in argos.h. Modifying the data organization will require modifications in the argos data processing tools, argos and argextract.

ARGOS data is received daily via email from System ARGOS. Its arrival triggers a script (epmail) specified in the .forward file for user eqpac on Tsunami. The raw data contained in the email is filtered by PTT number; whenever the PTT number is changed in the field, it is necessary to modify the script \\Tsunami\oasis\eqpac\bin\process.