Interfaces
The WII6 cloud
Most people only ever see the WII6 cloud. It receives every Iridium message, decodes it against the format registry, and keeps the raw bytes beside the decoded result. Members of a deployment see their buoys on a map, each capture’s spectrum and direction, and battery and temperature over time. They can download a date range as CSV, JSON or a ZIP archive.
Deployments: every project in the store, with its buoys, its capture count and the date of its most recent data. The bench rigs are a deployment like any other.
One deployment: the fleet on satellite imagery, and a row per buoy with its mode, wave height, battery, temperature and when it was last heard.
One buoy: state at a glance, the drift track, and wave height and period over the whole deployment. The Captures, Messages, Status and Download tabs sit under it, with one time window across all of them.
One capture: significant wave height, peak period and direction, the wave energy spectrum, direction by frequency, the spectral moments and the quality flags. When the buoy was asked to send the 2 Hz record, it is shown below.
Status: the firmware versions and modes a buoy has run, battery against internal temperature, and the battery trend over the window. With a low-battery level set for the deployment, the trend becomes a days-to-low estimate.
Commands are queued in the cloud, delivered in the reply to the buoy’s next message, and marked done when the buoy reports them run. The owner of a deployment sets the standing mode and the capture period, asks for a temporary mode for an hour, asks for the status, or asks for one more cycle straight after the next transmit, which is how a second message is got soon after asking for a capture’s 2 Hz record. A command cannot wake a sleeping buoy; it waits in the queue until the buoy next transmits.
Commands: the standing mode, the period and a temporary mode on the left; on the right the queue, each command with who sent it, when it reached the buoy and what came back.
Each message carries the buoy’s clock drift, so a fleet’s clocks are watched from the cloud. A WII6 buoy on the bench posts the same binary message over WiFi that it would send over Iridium, and the cloud handles it the same way.
The WII6 cloud runs at console.wii6.au, on the same OGLAS platform as Digital Dimensions’ other remote monitoring products, and it holds every deployment since 2016 in its original form. The earlier histories are on the heritage page. Access is per deployment. A demo deployment, cut from two real buoys, is at demo.wii6.au; ask us for a login.
The dashboard on the buoy
The pages below are the buoy’s own web dashboard, used for development, bench testing and checking a buoy on deck before deployment. These screenshots are from a development board on the bench, a week into a run of hourly captures posted to the cloud, with the main processor asleep between them.
The buoy carries an ESP32-S3 whose only job is the dashboard and the WiFi link. Power it on and it puts up a WiFi network and a single page: GNSS, motion sensor, Iridium, temperature, card, power, the upload to the cloud and the state of the link, refreshed once a second. It works on a phone on the deck and on a laptop on the bench, and it works when the WiFi is marginal, because it polls when the live socket cannot connect.
The overview: every subsystem as a tile, with its state and how old the reading is. The banner says the main processor is asleep and when its next slot is; wake ends the sleep now.
Capture: start a capture and watch it fill, 40,960 frames at 64 Hz in ten minutes and forty seconds, with the maths running as the frames arrive and the result at the end. Below it the live trace: acceleration, roll and pitch, and heading.
The Capture tab is how a buoy is checked on the ice before the team leaves it: someone picks it up, tilts it and watches the trace respond.
Mode: the cycle the buoy runs, its settings, and the blocks each mode sends, with the message size each set comes to.
The Mode tab holds the deployment’s settings as the buoy keeps them: the standing mode, how often to capture, to send a position and to report, how many times to retry a capture that failed to send, and a temporary mode that applies for a set time and then expires. Under it is the block editor: which parts of the result each mode sends, and what that comes to in bytes.
Records: every record on the card, its state, its result, the message built from it, and the files it is made of.
The Records tab lists the card one record a row, and from any row the result, the message or a file can be opened or sent again. The Files tab browses the card directory by directory and downloads a file over the link. The Iridium tab drives the RockBLOCK 9704 modem: begin, signal, identify, a message typed by hand, and a spy on every line to and from the modem. The Console tab reaches the main processor’s shell, so anything the firmware can do is one command away, with the buoy’s own log streaming beside it.
The whole dashboard is one page compiled into the debug processor’s flash. It needs no installation or internet connection. The debug processor is powered down during deployment.
The command shell
Under the dashboard is a text protocol between the two processors that a
person can drive from a serial terminal as well: status, imu start 64,
sat signal, sd ls, or any Zephyr shell command. Adding a subsystem to
the firmware makes it reachable from the browser with no change to the
dashboard, because the dashboard forwards commands it does not parse.
Your own tools
If you would rather work from files, everything the cloud shows is also in the data store: plain directories you copy with rsync, formats documented and versioned, and the same decoders the cloud uses available as a command-line tool. See formats and tools for how to obtain the documentation and decoders.