Discovery and polling: how Sig-Net finds things

If you've used Art-Net, you already know the broad shape of Sig-Net's discovery mechanism. The Manager shouts "is anyone there?", everyone replies "yes, here's my name and what I am", and the Manager keeps a table of devices it knows about. ArtPoll, basically.

Sig-Net keeps that simplicity but adds a few useful tricks.

The basic poll cycle

Every three seconds, by default, the Manager multicasts a poll packet on a dedicated discovery address. Every Node that hears it checks whether its TUID falls in the requested range, waits a small random delay (so a hundred fixtures don't all reply at once and clobber the network), and then sends back a small reply containing its TUID, its product code, and a magic number called the change-count.

The change-count is a 16-bit counter that bumps by one every time anything about the Node's configuration changes — a new universe assignment, a label edit, an IP change, an RDM transaction with side-effects. It's the heart of Sig-Net's "stay in sync without a broker" trick: the Manager just compares the change-count it received with what it had cached, and if the new one is higher, it knows it missed something and follows up with a more detailed query.

Four levels of detail

When the Manager polls, it can ask for one of four levels of information:

HEARTBEAT is the smallest — just "are you alive?" plus the change-count. This is what runs every three seconds in normal operation.

CONFIG asks for the heartbeat plus current configuration state: every endpoint's universe, label, direction, status, failover behaviour and so on. This is what the Manager fires when it spots a change-count discrepancy.

FULL adds firmware version, IP settings, MAC address, supported features, and the list of every TID the device implements. Usually only requested at startup or on a manual "refresh" command.

EXTENDED adds diagnostic data — security event counters, freeform diagnostic messages — for when something is going wrong and you want to know everything.

This means routine background polling is small and cheap. The big detailed queries only happen when there's a reason for them.

On-boot announcement

When any device powers up — Manager, Sender, Node, Visualiser — it doesn't wait for the next poll cycle. It transmits a single proactive announcement to the network reply group with everything a Manager needs to recognise it: TUID, role, endpoint count, firmware version, OTW capability. So a fixture that boots in the middle of a polling gap shows up on the patch screen instantly.

Lost Mode

If a Node hasn't heard a valid poll from any Manager for three consecutive cycles (about nine seconds), it concludes that the management network has gone offline and enters "Lost Mode". Two things happen.

First — and this matters — the Node keeps doing its actual job. Levels still come in, DMX still goes out, RDM still works. Stream loss is evaluated independently from management loss: even if every Manager on the network drops offline, the rig will keep running whatever the active Senders are streaming.

Second, the Node starts shouting on a special "node_lost" multicast address. Any Manager that comes online later — a backup desk being plugged in, a engineer's laptop joining the network — will see that broadcast and immediately know about every orphaned fixture, with no manual rediscovery required.

If a Manager that is tracking a Node sees that same Node on the lost address, it knows there's a one-way routing problem somewhere. That's a useful diagnostic.

Next post: RDM, sync, and timecode — the rest of the show traffic that isn't levels.

This series is based on v1.0 of the Sig-Net spec - visit Sig-Net.net for any updates.