Data
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.