NovaP/1 — a 16-byte header every Novaterra sensor organ agreed to speak, and a receiver that doesn't exist yet

A wire protocol is easy to over-claim: write a spec document, call it "the standard," and let the reader assume a whole device family is already talking to each other over it. This report tries to say exactly how much of that is true today, and how much is still a document.

What it was

NovaP/1 is a binary wire format designed to carry sensor data — ternary band coefficients, heart-rate readings, gesture "marker" events, and eventually audio — off any Novaterra wearable and onto a receiver, with no JSON, no generic RPC framework, and (by design) no human-readable intermediate format anywhere on the wire. The frame layout is small and fully specified: a fixed 16-byte, big-endian header — a 4-byte magic (NVP1), a 1-byte message type, a 1-byte channel ID, a 16-bit length, and a 64-bit microsecond timestamp — followed by a variable-length payload and a 2-byte CRC-16-CCITT checksum. Message types 0x00–0x08 are reserved for the spec itself (ternary coefficients, threshold updates, glyph text, heartbeat, mute/unmute, a channel-descriptor JSON blob sent rarely for debugging, a voice-activity flag, and time-sync), 0x09–0xEF are reserved for future v1 extensions, and 0xF0–0xFE are left open for a device to define its own extensions — Hush uses 0xF0 for its "Marker" event, for instance. Channel IDs work the same way: 0x00–0x05 are spec-defined (camera, through wake-word), and each device claims its own block above that — Hush uses 0x10–0x14 for CSI, seismocardiography, skin temperature, BLE-neighbour scanning, and a Muse-headband reply channel; Conch, a separate Novaterra earpiece project, reserves 0x20–0x2F. A time-sync exchange (offset = ((T0+T2)/2) - T1) is specified to keep devices and receiver loosely aligned, re-run roughly every 30 seconds. Versioning is forward- stable by convention: an NVP1 receiver is expected to silently discard message types it doesn't recognise, and a breaking change is expected to bump the magic to NVP2 rather than reinterpret existing bytes.

The spec's own stated audience is explicitly wider than one device: it names "the necklace sensor codec, downstream NovaTerra Studio, [and] an external dolphin-pack producer" as example implementers, and the wider Novaterra product overview states plainly that Hush, Conch, and three more planned organs (Optic, Pulse, Band) are all meant to speak it — "Same NovaP. Same Twin. Different organ."

What we built

🔬Research

One real, running encoder, and one real, disclosed gap on the receiving end. Hush's bench implementation frames its camera stream and heart-rate channel exactly per this spec, on real ESP32 hardware, streaming to a Python receiver over Wi-Fi TCP — the measured throughput (96×96 greyscale capture, Walsh-Hadamard transform, ternary threshold, five-trit packing, streamed as NVP1 camera frames) is 15.8 fps, taken directly off a real serial-console log: CAM len=410 trits=2050 nonzero=1432 rate=15.8fps. That's not a simulated or projected number — it's what the frame counter on a real board says.

What isn't built: the spec's own designated reference implementation, a Rust receiver crate meant to live in the wavetrinity runtime (sensor_ingest.rs). The spec's own text is candid about this — it says that crate "will land... at the W5 wire-up stage," and that "until then," the written protocol document itself is "the binding contract." In plain terms: there is no canonical NovaP/1 decoder yet, only a bench Python script written to unblock one team's own testing, and the spec document standing in for the thing it describes.

Adoption across the family is real but partial. Hush's own team didn't start with NovaP/1 — an earlier design council record shows they had built a homegrown protocol, internally called "NTP/1," before a later council deprecated it in favour of adopting NovaP/1 as the shared, external spec, on the explicit reasoning that "the receiver is the customer" — i.e. a format two teams have to agree on is worth more than one team's locally-optimal choice. Conch, a separate earpiece project, backs that up with real evidence: it reserves its own NovaP channel range under the same spec in its own design council. Optic, Pulse, and Band — the other three planned organs — have a reserved channel range named in the product overview and nothing else; no architecture document, no code.

What we learned — including the honest gaps

• A frame format that's cheap to specify precisely is exactly the kind of thing that gets built first and proven fastest. A 16-byte header with a CRC is a small, checkable design surface — writing it down and getting one encoder to emit it correctly on real hardware is a genuinely lower bar than building a shared receiver runtime, which is why the encoder side is real and the receiver side isn't.
• "The receiver is the customer" is a real design principle with one real data point behind it, not a proven pattern yet. Hush switching away from its own homegrown NTP/1 is a good sign — a team choosing the harder, shared spec over the easier, bespoke one usually means the shared spec is worth something. But one team's course-correction plus one other team's channel-range reservation is not the same as two independent teams' software actually agreeing on the wire.
• "Spec-first, implementation-later" is disclosed honestly, not hidden. The document's own language — "until then, the protocol spec... is the binding contract" — says outright that the receiver crate doesn't exist. That's the right way to write a spec ahead of its reference implementation; it just means the claim "NovaP/1 is a shared, working protocol" is currently carried by one encoder and one document, not by a tested round trip between independent codebases.

Where it went / status

Active bench research. The frame format is specified precisely and proven by one real encoder on real hardware; the shared receiver runtime named in the spec's own text has not been built, and only one other device (Conch) has taken the concrete step of reserving space under the format. Tiered research throughout — this report treats "a spec named for a family" and "a protocol a family actually speaks" as different claims, and is careful about which one the evidence currently supports.