Why Z-RAY Uses Its Own Radio Protocol (And Why That's Not the Obvious Choice)

By Dr Dominik Ostrowski, MIET — Founder and embedded-systems engineer, Think Radio

I have a rule for radio engineering that I've relied on for over a decade: find every way a design can fail, before you look for the one way it works. It sounds pessimistic, but it isn't — it's the only honest way to build something that has to work in a room full of other people's wifi, Bluetooth, and whatever else is fighting for the same airwaves. Z-RAY's wireless protocol is the direct product of that rule, and it didn't start life as a lighting product at all.

Where this actually started

In 2012 I was developing the radio system for a company called Blendology — a tap-to-connect conference badge. Each badge has an accelerometer, and tapping two badges together is the synchronisation signal. From there, each badge randomly decides whether it's going to transmit or receive, and attempts to send (or catch) a heavily encrypted key over radio.

Here's the problem that shaped everything downstream: when a radio message fails to arrive, you don't know why. Both badges might have picked the same role. The agreed frequency might have been sitting under someone's wifi or Bluetooth traffic. There's no diagnostic available in the moment — so instead of trying to diagnose it, the badges just retry. Every 10 milliseconds, each badge re-randomises its Tx/Rx role and steps to the next frequency in a pre-agreed hopping sequence, for up to 20 attempts. The odds of two badges repeatedly choosing the same role, on every attempt, while simultaneously stepping through a wide spread of frequencies, become vanishingly small. A successful receive gets acknowledged with the key sent back the other way.

Every badge tap also advances the encryption, so what two badges exchange is an untraceable tag that only resolves to an identity once it's uploaded to Blendology's server — the badges themselves hold no user data, so there's nothing on the hardware worth stealing even if you got hold of one. It also means a contact can be revoked after the fact, which matters more than it sounds like it should — it's overcome real privacy objections and made the system commercially viable. I drafted the patents behind it myself. It's still a live product, and Think Radio still does contract engineering work for Blendology today, improving the same badge system.

We launched it at SXSW in 2012, and that's where Z-RAY actually began — not on a lighting company's whiteboard, but from a Dutch festival-wristband executive walking up to the stand and asking, roughly: can you make a wristband version of this, and can you make it light up? Blendology had no interest in chasing that idea. I did.

Why a wrist-worn wireless light needs its own radio, too

A wrist-worn device demanded the same three things the badge system did — real power efficiency, extremely low and predictable latency, and very high reliability — in an environment thick with competing signals. That combination narrows the field fast, and it lands you on the same place it landed me in 2012: Nordic Semiconductor's bare-metal radio hardware, with a proprietary protocol built directly on top of it rather than a general-purpose wireless standard carrying overhead you don't need and can't fully control.

What's genuinely different about Z-RAY is the traffic pattern. Blendology is one badge talking to one other badge. Z-RAY is one STATION-X talking to many Z-RAYs at once — a multicast problem, with more data flowing than a badge tap ever needed, and it has to keep working even if a second, completely unrelated STATION-X/Z-RAY rig gets set up in range at the next stage over.

The fix borrows the same fast-frequency-hopping principle as the badge system, but with one important addition: every single STATION-X runs a completely unique hopping sequence. If two independent systems happen to collide on a frequency, the sequences diverge afterward, so that collision doesn't repeat on the next hop, or the one after. Two rigs can share a room and largely ignore each other.

Encryption that does two jobs at once

Not every wireless lighting system on the market encrypts its radio packets. Z-RAY does — everything in the packet is encrypted. And it's a full hardware-AES encryption-key/session-key set-up. If I could hack that - I could make my fortune telling the banks how to prevent it!

A consequence of this hardware encryption is a point that can easily be undersold. Because the hop sequence is derived from encrypted, session-specific data, an outside observer can't predict where the next packet is going to land, and they can't read what's in the packets they do intercept. That's protection against deliberate interference or eavesdropping, not just the accidental kind — a distinction that matters more the more this technology shows up in venues where reliability isn't optional.

A Z-RAY joining a system has to sit and listen on a single frequency until it catches one packet — that's what lets it lock onto both the hop sequence and the repeat interval, which is a fixed n-millisecond interval. That's deliberately a multiple of standard DMX's own refresh rate, so there's headroom for several packet repeats inside the time a lighting console expects an update, rather than running right at the wire.

One more piece that only makes sense on a wireless link: every packet can be data-compressed. Wired DMX can't add compression without breaking backwards compatibility with thirty years of existing hardware — it's stuck with the protocol as originally specified. A wireless link answering to nobody's legacy cabling standard doesn't have that constraint, so Z-RAY simply uses it.

Built on-site, not just on the bench

None of this stayed theoretical. Z-RAY's protocol has had a lot of real-world battle-testing at events like EMF Camp and multiple EMOM shows — exactly the kind of RF-hostile environment (dense crowds, dozens of other wireless devices, walls, moving bodies) that a bench test in an empty room can't reproduce. The "find every way it fails first" approach isn't a slogan; it's the reason the frequency-hopping sequence, the role-negotiation logic, and the encryption scheme all exist in the form they do. Each one is a direct answer to a specific failure mode that showed up in testing or in a real venue, not a feature added because it looked good on a spec sheet.

The buyer-facing version of all this

Most people asking "is wireless DMX reliable enough for a live show" don't want the engineering detail above — they want to know it won't drop out mid-set. The honest answer is that reliability isn't something you get by hoping the radio behaves; it's something you get by assuming, from the start, that any given packet might fail for reasons you can't observe in the moment, and designing a system that recovers from that in milliseconds without anyone in the room noticing. That's what a decade of doing this, first with conference badges and now with stage lighting, has actually taught me.