Data

How WII6 keeps data: one write-once store of every record, message and run, plain directories copied with rsync, every binary format named and versioned so it still decodes in a decade.

A wave buoy produces wave results and motion records that may be needed years after a deployment. You choose which captures send just the power spectrum, which send a 2 Hz record, and which send the full-rate data at 8 or 64 Hz. The full record is kept on the card.

The sizes below are examples for fifteen-minute captures:

Kind How it is retrieved Example size
Wave results compact satellite messages or the card from 326 bytes
2 Hz record over Iridium or from the card about 56 kB
64 Hz full-rate record from the card; satellite transfer uses more airtime about 3 MB

Position and buoy health can accompany the wave results. The 2 Hz record is the practical choice for most satellite reprocessing requests; sending full-rate data costs more airtime. See what the buoy sends.

One store, no database

Everything a project produces lives in one directory tree: the project, its buoys, and under each buoy the records exactly as the card wrote them, the messages exactly as the satellite delivered them, and every processing run associated with its source record. Files are kept as written, and each capture has its own record identifier. The store can be copied with rsync and checked with a checksum manifest. When combining archives, the record identifiers and checksums let you identify duplicates and any differences between copies.

A simplified view of the contents:

Project
  Buoy
    Captures from the card
      Metadata and calibration
      Full-rate motion record
      2 Hz record
      Wave results
    Received satellite messages
      Original message bytes
      Decoded results
    Shore processing runs
      Source record, processing version and results

You get the store, or the part of it that is yours, as files. Nothing is locked in a service.

The buoy writes the captures to its card. On shore, the store also keeps the received satellite messages and any later processing runs.

Formats that outlive the firmware

Every binary file starts with a header that names its format and version. Every satellite message starts with a format id that is never reused. Every format has a definition kept in one place, compiled into the firmware and published as JSON for everyone else, with a real sample message kept as a test that runs on every build.

The registry keeps every revision of every format used since 2016: a message from any deployment since then still decodes, and the tests prove it on every build. The earlier generations kept their own formats; their data is listed below.

Formats and tools

Contact us for the format registry, JSON definitions, command-line decoders and sample records. The documentation covers the directory layout and how to read the files, so you can work with the same formats and decoders used by the cloud site.

Older data

The public datasets from the earlier generations, the SIPEX II, PIPERS and JARE-61 archives on Mendeley, and the publications built on them, are listed on the WII5 site:

The deployment histories from 2012 to 2024 are on the heritage page.