OMEGA.

Why OMEGA Exists.

Live ocean data is scarce. The instruments that gather it (official scientific moorings) are expensive, so there are very few of them. For most stretches of coast there is no real-time measurement at all: OMEGA pulls live Argo CTD casts via ERDDAP, which costs nothing next to building its own $20k floats.

The aim is to let a lab, harbor, school or sailing community monitor its own stretch of water. Local sensors can record temperature, air pressure and position, while public feeds provide a wider view. Putting both on the same map makes it easier to investigate a change without treating a forecast as a measurement.

Readings from OMEGA hardware carry a digital signature. A receiver can check which node signed a reading and whether the message changed in transit. That helps independent operators share data; it does not establish that a sensor is calibrated or that its measurement is correct.

What OMEGA Standardizes

The ocean is the least instrumented part of the planet, and the instruments that exist rarely compose. A moored buoy, a university glider, a harbor sensor, and a satellite product each produce readings in their own format, with their own identifiers, on their own server. Combining them is bespoke integration work that every group repeats, every time.

The constraint underneath is connectivity. Marine deployments lose their link routinely and for long periods, so an architecture that assumes an end to end path either fails or pushes operators toward expensive satellite backhaul. Cost follows from there: professional oceanographic instrumentation prices most potential contributors out of participating at all, including municipalities, small research groups, and community organizations.

OMEGA standardizes the observation, not the equipment. Every reading, whether it comes from a $40 ESP32 sensor or from a Copernicus model sample, is normalized into one self describing envelope carrying origin identity, sample time and position, typed measurements with units, and provenance. Metric names map to CF standard names, the shared vocabulary used across climate and forecast data, so two readings are semantically comparable and not merely transferable. A device joins the network by emitting that structure, and no OMEGA code has to run on the device itself.

One model covers sensing, vehicles, and acoustics. One identity scheme, envelope, storage model, and command vocabulary covers environmental sensors, autonomous surface vessels, ROVs, and acoustic links. Only the environmental sensors exist as hardware today. The single model is deliberate, so the vehicles and acoustic links arrive already compatible with the sensors that exist now.

The gateway is local first: the full system runs on a Raspberry Pi with no internet connection. Optional third party data providers are credential gated, and when one is unavailable it reports its absence and supplies no value, so a missing provider shows up as a gap in the response and never as a substituted number.

A reference gateway runs continuously, ingesting live data from roughly forty public sources including NOAA weather buoys, DART tsunami stations, tide gauges, marine forecasts, and space weather, alongside an archive of several hundred thousand normalized measurements. The observation envelope is published as a normative specification and a JSON Schema, with a conformance kit and client SDKs alongside it. An analysis layer provides spectral analysis, cross correlation, coherence, trend and changepoint detection, calibration drift monitoring, and model validation against measurements taken in the water. Correctness is enforced by 1,491 automated tests, and the deployed instance re-verifies its own published guarantees nightly, alerting only on failure.

Results from testing and analysis

Start with results. One came from an OMEGA board on the bench. The other two came from OMEGA's analysis code running over public NOAA and Copernicus data. Each one is written up in full on the pages that follow.

The meaning of a reading is kept apart from how it travels.

In OMEGA, a reading means the same thing no matter how it reached you: by radio, by cable, or over the internet. The data's meaning (its envelope) is kept separate from the exact format it happens to travel in (its wire form).

That single decision is what makes OMEGA open: Adapters for an 8-channel receiver, SignalK, and The Things Network feed the same ingest contract with no protocol changes. The 8-channel receiver has run against live traffic. The envelope standardizes identity, time, location, and payload, while the format shifts to fit each link: a dense 84-byte packet over radio, plain JSON over the internet, other formats for specialized receivers.

The map interface

One Reading's Full Path.

The Hard Problems.

Each problem below came up in practice, and each one lists the fix that shipped.

What the Live Map Shows.

The map keeps measurements and forecasts distinct. A missing sensor reading leaves a visible gap. Model data can still provide context in its own layer, but it does not fill that gap. For OMEGA hardware, a digital signature also lets a receiver check the message's source and integrity.

An Open, Multi-Operator Network.

OMEGA runs as an open network of independently-run gateways. Identity is rooted in cryptography, and joining is zero-config: a gateway mints its own key, and that key is its credential.

Why Python over Go or Rust?

For a telemetry gateway handling raw binary bytes, compiled languages like Rust or Go look like the obvious choice. OMEGA runs on Python anyway, and the reason is who uses it.

Why SQLite over PostgreSQL?

OMEGA stores everything in a single SQLite file, with no database server and no container around it, which at sea is the safer bet.

The Constraint: the gateway often runs on a Raspberry-Pi-class board on a pitching vessel, where waves over the solar panel can cut power without warning; and SD cards are notorious for corrupting under exactly that abuse.

The Decision: a Docker daemon with a PostgreSQL volume is a lot of moving machinery to trust to a fragile SD card. SQLite compiles directly into the Python process (no daemon at all) and the whole database is one physical .db file, so a field operator can copy omega.db to a USB stick and hold a complete, air-gapped backup of the entire deployment. Write-ahead mode (PRAGMA journal_mode=WAL) removes SQLite's classic locking limits, so a reader and a writer no longer block each other.

Why a 3D Globe on the GPU?

OMEGA renders the map the way a video game does: hand all the points to the graphics card (the GPU) at once. A normal web map (like Leaflet) draws every dot as its own little web-page element, which holds up for a few dozen pins and grinds the browser to a halt once you pile on thousands of historical readings..

The Decision: the portal uses a self-hosted CesiumJS 3D globe that bypasses the browser's DOM, passing coordinate buffers directly to the GPU via WebGL. It renders on change, so a laptop stays responsive, with time-stepped overlays for playing history back.

Status: the 3D digital twin (DTO v3) is partial and in-flight; first load is currently on the order of 30–60 seconds. Pushing into the millions-of-points regime via a Deck.gl layer is a roadmap goal, not shipped today.

import { DeckGL } from '@deck.gl/react';
import { ScatterplotLayer } from '@deck.gl/layers';

// Roadmap sketch: a GPU point layer for dense historical telemetry
function TelemetryMap({ data }) {
  const layer = new ScatterplotLayer({
    id: 'telemetry-layer',
    data,
    // WebGL bypasses the DOM and injects directly to the GPU
    getPosition: d => [d.longitude, d.latitude],
    getFillColor: d => {
      // Color map based on raw temperature
      if (d.temperature > 25) return [239, 68, 68]; // Red
      return [59, 130, 246]; // Blue
    },
    getRadius: d => 10,
    radiusUnits: 'pixels',
    pickable: true
  });

  return (
    <DeckGL
      initialViewState={{ longitude: -157, latitude: 21, zoom: 6 }}
      controller={true}
      layers={[layer]}
    />
  );
}

Let Operators Add Their Own Formulas, Safely.

Operators frequently need custom derived metrics (e.g., dewpoint, heat index, density) calculated on the fly without writing backend code. The naive approach is running Python's eval() on the server, which is a serious code-injection vulnerability on a public gateway.

The Solution: The backend implements a custom Abstract Syntax Tree (AST) interpreter for derived metrics. It parses and validates mathematical formulas at definition time, explicitly allowing only numeric literals and a whitelisted set of math operations (sqrt, sin, log). Attribute access, function calls, and import tricks are rejected at parse time. Operators get full mathematical expressiveness, and anything outside that whitelist never runs.

Where the Stack Stands.

A plain read of where the stack is strong and where it isn't: the protocol, gateway, and portal carry field evidence, the mesh has been demonstrated on the bench across about six boards and more than one LoRa radio family, including multi-hop relaying, and the alternate bearers and the edge firmware's field-hardening are the least mature parts.