Protocol reference

Our loudspeakers are controlled over Ethernet, and this is the same path our own Pro and Rapid apps use. You need no licence, fee or NDA to implement it, and we will give you twelve months’ notice before any breaking change.

The full packet-level specification is published: EDC Speakers Network API (PDF) — framing, every command’s field tables, CRC8 source, the global and preset object definitions, the EEPROM map, signal monitoring, status data and FIR deployment. This page is the orientation; that document is what you code from.

What your software can change

This is the first thing to settle, because it shapes every integration.

Beam design stays in our apps. The cabinet’s DSP executes beams — it runs the FIR filters, crossovers, delays and gains that produce them — but it does not compute them. There is no “set beam to 40° at −12° tilt” command. The Pro app calculates the filter set for a given coverage and writes it to the cabinet; your control system then recalls the result as a preset.

For nearly every integration this is the right division anyway: coverage is designed once at commissioning, and the control system switches between the states the venue actually uses — “lecture”, “assembly”, “evacuation”. If you need beams computed outside the app, talk to us; the coefficient-generation method exists and is not in the published specification.

Transport

Security — read this before you deploy

The protocol has no authentication and no encryption. Any host that can reach a cabinet on UDP 12128 can change its settings, mute it or restart it. That is normal for this class of AV control protocol, and it means your network design carries the security, not the protocol:

• Put loudspeaker control on a dedicated VLAN with no route from general or guest networks.
• Do not expose port 12128 to the internet, and do not port-forward it.
• Where control must cross sites, use a VPN — our apps already support that path.
• In voice-alarm and transport systems, treat the control network as part of the certified system.

We would rather tell you this than have you find it out, and we deploy on closed networks for exactly this reason. A cabinet does carry a lock-out flag that reports whether a given controller is locked out, but it is not a credential.

Packet framing

Every packet is a 10-byte header, then a 4-byte ASCII command, then that command’s data.

Object payloads carry a trailing CRC8 — two variants with different seeds, computed from a lookup table, deliberately cheap for the cabinet’s microcontroller. The table and a C# reference implementation are in the specification.

Command set

Commands are four ASCII bytes. Replies are ACKN (accepted), NACK with a 32-bit reason code, or BACK — a broadcast acknowledgement carrying the sending cabinet’s IP so several controllers can tell whose reply it is.

For a single live change — a mute, a level, an EQ band — use GOBJ/POBJ. For bulk work — pushing a whole configuration or a long FIR filter — use FCMD page writes followed by a forced preset reload.

Discovery

1. Send a broadcast PING.
2. Collect EXPL replies.
3. Repeat two or three times within a second — UDP delivery is not guaranteed and a missed reply looks like a missing loudspeaker.

Each reply identifies the cabinet: firmware version, MAC address, IP address, subnet mask, default gateway, DHCP state, a model-type byte, the lock-out flag, the product identifier and an 81-byte UTF-8 user name. A controller can filter discovered devices by firmware version — sensible if your integration has only been tested against one.

Devices on a different subnet will answer a broadcast ping but cannot be controlled until their addressing is changed. FIPC followed by BOOT does that, both broadcast, without physical access to the cabinet.

Telemetry

This is the strongest part of the protocol, and the reason our cabinets are worth monitoring properly.

Status (STAT), basic — a two-byte summary: fault, thermal-warning or thermal-cut-out state for the main amplifier board and each of the two expansion boards; whether the DSP booted; and whether any LF or HF driver has reported an error.

Status (STAT), detailed — DSP boot state, main supply rail voltage, a temperature reading per amplifier board, standby state, the state of every amplifier IC, and a pass/fail result for every individual transducer — up to nine LF drivers and eighty-one HF drivers. That is per-transducer fault reporting for a whole cabinet in a single request, which is what a voice-alarm or transport operator needs and what almost nothing else in the category offers.

Voltage and temperature come back as raw ADC byte values, with conversion tables in the specification.

Signal monitoring (SMON) — ask once and the cabinet broadcasts signal levels from points through its audio chain for 13 seconds; ask again to extend. Levels are 32-bit integers; convert with dB = 20 × log10(value / 0x01000000), where 0x01000000 is 0 dBFS. Suitable for a meter bridge or a “is audio actually arriving” check — not for guaranteed-delivery logging, since the packets are broadcast UDP.

Firmware

Firmware is updated over UDP using our own Windows utility. It is not part of this protocol and there is no third-party update path. In practice it has not been needed: We have never issued a firmware update in the product’s life to date. Treat the version a cabinet reports as stable, but still filter on it if you have only tested against one build.

Next

• EDC Speakers Network API (PDF) — the full specification.
• Licence — implement it freely; here is that in writing.
• Dante & AES67 — the audio side, which is separate from control.

We do not publish SDKs, plug-ins or ready-made modules for Q-SYS, Crestron or any other control platform, and we do not implement AES70. What we publish is the protocol above. If you build something on it, tell us — it is how you get told before anything changes.