Sample position analysis output produced by the offline tooling.
Everything that doesn’t run on the buoy itself: the satellite-side server,
offline analysis tooling, web-based viewers, and the on-board maths code
that runs on the Linux maths-CPU host.
Server — receives data from Iridium / satellite, decodes, stores.
Analysis — offline tools to review and assess archived data.
Viewers — web-based dashboards showing real-time and historical data.
Onboard Data Processing — on-buoy maths that turns raw acceleration + GPS into a small wave-statistics payload before transmission.
Other — inventory of the wider WII-family repositories (earlier buoys, dashboards, test rigs, data archives). None individually assessed yet — ask if any sound useful and we’ll see what’s possible.
1 - Server
Server that receives Iridium / satellite data from buoys, decodes, stores, and exposes it to viewers.
The internet-side server collects data from Iridium / satellite delivery,
decodes the short-burst-data payloads, stores them, and feeds the
viewers and downstream consumers.
Status: placeholder. Server source to be released.
2 - Analysis
Offline tools to review and assess archived buoy data.
Offline tools used to analyse archived data: review, validate, convert
between formats, and feed scientific workflows that don’t run live against
the server.
Status: placeholder. Analysis tooling to be released.
3 - Viewers
Web-based dashboards showing real-time and historical buoy data.
Web-based viewers for buoy data: real-time status, historical trends, GPS
tracks, and per-deployment summaries. The viewers consume what the
server decodes.
Status: placeholder. Viewer source to be released.
4 - Onboard Data Processing
On-board maths and signal processing — turns raw acceleration and GPS into a small wave-energy / period / direction payload that fits inside an Iridium short-burst message.
The on-board processing pipeline takes raw accelerometer and GPS samples
captured by the buoy and reduces them — on the buoy itself — into a
compact summary that fits inside an Iridium short-burst-data message:
significant wave height, peak period, directional spectrum, energy bands.
Doing the maths on the buoy (rather than transmitting raw samples) is
what makes long-duration polar deployments practical — satellite bandwidth
is expensive, power-hungry, and unreliable.
The maths code is written in C and compiles for any Linux. On the buoy
it runs on the Maths Control host (a low-power Linux board woken
briefly to do the calculation), described below.
Maths control — Linux services, Raspberry Pi
image, debug web UI, and the automation around the maths-CPU that
schedules wakes, runs the C code, and packages the output for the
Iridium uplink.
Wave-motion mathematics
The wave-motion mathematics — significant wave height, peak period,
spectral and directional analysis — was developed by Dr Alison Kohout
(NIWA) and collaborators, and is the scientific core of the WII
project. Her work is documented and partly open at:
The peer-reviewed papers — including the 2014 Nature paper on
storm-induced sea-ice breakup — are mirrored locally at
Data → Publications.
The WII5 buoys carry an implementation of those algorithms tuned to the
constraints of on-buoy computation (memory, CPU, wake-cycle budget). The
underlying mathematics is hers.
Status: placeholder. WII5 maths source release is pending assessment.
4.1 - Maths Control
Linux Maths Control — runs on Raspberry Pi, BeagleBone Black, Intel Edison, and other embedded Linux options. Services, automation, and a Node debug web app.
The Linux Maths Control package runs on Raspberry Pi, BeagleBone
Black, Intel Edison, and other embedded Linux options. It’s a
distribution image plus a set of services, scripts, and a Node web app.
It’s commonly called the Maths CPU because the maths code hasn’t been
optimised for smaller CPUs — it needs more memory and CPU power than the
AVR can offer.
Any of these embedded Linux hosts is fairly power-hungry, so the Maths
CPU is only powered up for two reasons:
Briefly to calculate the maths — turn raw data into something small
enough to send over satellite.
For debugging — the interactive web service shows and graphs real-time
data while the host is online.
Components:
Linux distribution image (Raspberry Pi, BeagleBone Black, Intel Edison, or other)
Shell scripts and services
C applications (e.g. raw SD-card access)
Node application for debugging
Web UI for real-time graphing
Status: placeholder. Image and source to be released.
5 - Other WII Software
Inventory of WII-family repositories — buoy firmwares, servers, dashboards, maths code, test rigs, and data archives. Possibly available on request; none of them have been individually assessed for release yet.
Beyond the pieces already featured under Firmware,
Server, Analysis, Viewers, and
Onboard Data Processing, the WII project carries a large family of related
repositories — earlier buoy generations, dashboards, server tooling, maths
libraries, test rigs, and data archives.
None of these have been individually assessed yet, so it’s genuinely
unclear which ones can or can’t be released — that’s why they aren’t
already public. Some are clean and would be straightforward; others may
have licensing, customer-specific identifiers, or third-party
dependencies that need looking at first.
If any of them sound useful for your work,get in touch and we’ll review that one and
work out what’s possible. No promises on outcome or timing — but worth
asking.
This page is the inventory.
Buoy firmware
Earlier generations and parallel firmware builds. The current production
firmware is the AVR build documented at Firmware.
WII1_Board — original 2012 AVR buoy board firmware. Modular components
(ADC, GPS, IMU, SD, Temperature) and higher-level modules (Collect, Config,
Maths, Sleep, Storage, WDT). Older project; superseded by WII2/3/5.
WII2_Board — 2014 Scott Base sensor-board firmware. Inclinometer +
MPU9150 + Kistler + GPS + Iridium SBD at 2–8 Hz to SD.
WII5_Buoy — alternative AVR firmware tree. “WII5 = WII3 WDT + WII1
Buoy Combined.” Version 5.5.4 was the 2024 KOPRI deployment build.
WII5_Buoy32 — planned ESP32 (dual-core 32-bit) successor to WII5_Buoy.
Prototype stage.
WII5Sh3d — SparkFun LoRa Gateway ESP32 build of the WII5 buoy
firmware. Same concept as WII5_Buoy, different hardware target.
WII5_Firmware — archive of compiled WII5 buoy .hex binaries, v1.0.0
through v1.0.21, field-deployment ready.
Buoy hardware and companions
WII_Hardware — Arduino board-definition package for the custom WII
board (packages/WII/avr/5.1.0, MegaPro 3.3 V 8 MHz bootloader).
WII_GondolaController — Arduino sketch for the gondola rig.
WII5_RigController — Arduino sketch for the rig deck-side controller.
WII5_Controller — M5StickC PlatformIO firmware: handheld for field
configuration of buoys.
WII5_MiniDisplay — Arduino sketch for a small OLED/TFT status display
with 3 buttons. Companion to the buoys.
Servers, dashboards, UIs
WII3_Server — Node.js Express server (Dockerised). Handles Iridium
inbound, buoy status, user management, REST API. Still in active use
for the 2024 KOPRI deployment at wii.dd.com.au.
WII2Dashboard — Node.js dashboard for the WII2 buoy system, running
on Intel Edison. Modes for photos, wind, GPS, voltage, downloads, console.
WII3_Dashboard — Node.js dashboard for the WII3 buoy. Manages capture,
GPS, anemometer, Iridium, cameras, MPPT, AVR watchdog. UI under right/
(Jade + Gulp).
WII3_RudicsServer — Client/server pair tunnelling TCP over Iridium
RUDICS using SLIP. Buoy-side dials out; AWS-side terminates inbound.
WII5_Buoy_UI — Bootstrap admin-template buoy status web UI
(Bower + Gulp).
WII5_LocalServer — Pi-side ingest server. Receives HELLO requests
from nearby buoys, auto-downloads data + logs via rsync, forwards to
the main server.
WII5_Offline — Offline viewer + XLSX export tool for KOPRI buoy data.
Standalone Node.js app; produces a single redistributable.
Maths and signal processing
WII3_Maths — C wave-analysis library. Significant wave height (Hs),
peak period, wave direction from 2 Hz accelerometer. Compared against
“Arctic Swift” reference measurements. v3.27 current.
WII3_Capture — C data-capture and post-processing programs. Builds
process_data that turns raw IMU/ADS/MPU samples into spectral output.
WII3_Binary — Node.js library for encoding/decoding WII data packets.
Sits between firmware and server/maths tooling. Apache-2.0.
WII5_MathsTools — systemd/service tooling (units, SD device tree,
Bluetooth, multi-WiFi AP config) for the Maths Pi.
WII5_MathsSDCard — Scratch workspace bundling SPI / SD-card example
code (fatfs, spi-tools, spincl) used while developing SD access.
WII5_SD_Block — Custom block-level SD-card library. AVR-side writes
metadata + data to specific SD blocks; Linux-side tool reads them back.
Avoids filesystem overhead.
Test rigs, experiments, debug harnesses
WII2_Test — Stand-alone GPS test sketches (GPSCapture, GPSRaw) from
WII2 bring-up.
WII3_WatchDog — Initial debug Arduino sketch for the WII3 WDT AVR.
Monitors the main Linux controller, controls 3.3 V main power, reads a
DS18B20.
WII5_AnemometerTest — Anemometer test rig. Captures GPS time + 3×
anemometer channels to CSV; calculates speed offline.
WII5_MegaTest — Single-file Arduino sketch for the Mega.
WII5_Memory — Arduino sketch experimenting with serial-debug,
serial-manager, and serial-maths classes.
WII5_Direct_Sparton — Debug sketch talking directly to the Sparton
compass/IMU, isolating it from the full buoy stack.
WII5_Fake_Sparton — Sparton emulator. Replays recorded raw Sparton
data over serial so the buoy can run its IMU pipeline without real
hardware. Perl generate.pl produces the C arrays from captures.
WII5_Sparton_10040 — Working tree of experiments around the Sparton
10040 compass/AHRS. Parallel variant subdirectories.
WII5_Sparton_Experiments — Container for related Sparton trials.
WII5_SDTester — Test sketch verifying WII5_SD_Block correctness.
Used in production-test.
WII5_WatchDog — Placeholder repo (no code).
Client tooling
WII5_Client — CLI for talking to buoys over serial. Dual
implementation: wii5cli.js (Node.js with serialport) and wii5cli.go
(Go port). Used from Pi / Maths-app hosts for manual buoy inspection.
Data archives
Not source code — captured field data preserved for replay and analysis.
WII2_Data — Field captures from WII2: Antarctica 2014-11, Arctic
2015, PreArctic.
WII3_Data — WII3 field captures: FrenchIsland_July2016, NIWA_Test2017,
PortPhillip_July2016, Rig_July2016, plus an rockblock/ Iridium subset.
WII3_TestData — Test-run output and archive logs from WII3 software.
