Cos'è sACN? Spiegazione di ANSI E1.31

Cosa è realmente sACN

sACN sta per uno standard con un nome molto più lungo: ANSI E1.31-2025, Tecnologia per l'Intrattenimento, protocollo di streaming leggero per il trasporto di DMX512 utilizzando ACN. ACN è l'Architettura per le Reti di Controllo, ANSI E1.17, da cui E1.31 prende in prestito il framing dei pacchetti.

Una piccola curiosità che vale la pena sapere, perché confonde le persone che ne scrivono: l'abbreviazione "sACN" non appare mai nello standard stesso. ESTA la usa informalmente nelle proprie newsletter ("noto anche come sACN"), e tutti nell'industria la dicono, ma non la troverai, né l'espansione "Streaming ACN", scritta nel documento pubblicato. Se vuoi essere preciso, chiamalo ANSI E1.31 e nota che sACN è l'abbreviazione comune.

Lo standard è pubblicato dal Programma di Standard Tecnici di ESTA, lo stesso ente dietro DMX512 (E1.11) e RDM (E1.20). È uno standard nazionale americano aperto: chiunque può scaricarlo e chiunque può implementarlo senza una tassa di licenza. Questa apertura è la principale ragione per cui sACN si è diffuso così rapidamente tra console, nodi, server multimediali e software.

Ciò che fa è ristretto e deliberato. Prende i 512 slot di un universo DMX, li avvolge in un pacchetto UDP con alcuni campi extra e li trasmette attraverso una rete IP. Non configura dispositivi, non scopre apparecchi, né trasmette RDM. Muove i livelli di illuminazione, rapidamente, in molti luoghi contemporaneamente.

Come viaggia sACN: multicast e porta 5568

sACN funziona su UDP sulla porta 5568. Quella porta è correttamente registrata con IANA, sotto il nome del servizio sdt (Session Data Transport), che è un piccolo ma reale segno della maturità dello standard.

La parte intelligente è l'indirizzamento. sACN normalmente utilizza multicast, e il numero dell'universo è costruito direttamente nell'indirizzo multicast:

• I primi due byte sono sempre 239.255.
• Il terzo byte è il high byte del numero dell'universo.
• Il quarto byte è il low byte.

Quindi l'universo 1 è 239.255.0.1, l'universo 2 è 239.255.0.2, e l'universo 300 è 239.255.1.44. C'è anche una forma IPv6, nell'intervallo FF18::83:00:00:00 in su, costruita allo stesso modo dagli ultimi due byte.

Poiché l'indirizzo è derivato dall'universo, un ricevitore non ha bisogno di essere informato da dove provengono i dati. Si unisce semplicemente al gruppo multicast per gli universi che gli interessano, e la rete consegna solo quelli. È per questo che un grande impianto può funzionare su un cavo senza che ogni nodo sia configurato individualmente.

Una sottigliezza di cui lo standard è esplicito: l'universo è identificato dal numero all'interno del pacchetto, non dall'indirizzo su cui è arrivato. Un ricevitore non dovrebbe mai presumere che i due coincidano.

È consentito anche l'unicast, e un ricevitore deve accettare sACN inviato direttamente al proprio indirizzo IP. Il problema è dichiarato chiaramente nello standard: sACN non definisce alcun modo per scoprire quegli indirizzi, quindi con l'unicast si configurano gli IP di destinazione a mano. Va bene per due nodi e doloroso per venti.

Universi: quanti e quali numeri sono vietati

Lo standard consente numeri di universo da 1 a 63999. L'universo 0 è riservato e non deve essere utilizzato, così come tutto ciò che va da 64000 a 65535, con un'eccezione: l'universo 64214 è riservato per la scoperta degli universi.

Due altre regole sorprendono le persone:

• I primi 256 indirizzi multicast IPv4, da 239.255.255.0 a 239.255.255.255, sono riservati da IANA per un altro scopo, quindi i dispositivi E1.31 non devono trasmettere su di essi. Se quegli universi vengono mai utilizzati, devono essere inviati in unicast.
• I numeri sACN partono dall'universo 1, e lo fa anche DMXDesktop, quindi il numero che imposti è il numero che esce. Art-Net è l'eccezione, perché inizia da 0.

La scoperta in sACN è limitata ed è importante comprenderla prima di cercare una funzionalità che non esiste. Le sorgenti annunciano quali universi stanno trasmettendo inviando un elenco sull'universo 64214 ogni 10 secondi. Questo consente a uno strumento di monitoraggio di mostrare cosa c'è sulla rete senza unirsi a ogni gruppo multicast. Ma non c'è scoperta dei dispositivi in sACN: nulla ti dice quali nodi esistono, come si chiamano o come configurarli. Se desideri questo, hai bisogno di Art-Net o RDMnet.

Priorità: come sACN decide quale sorgente vince

Questa è la funzionalità che rende sACN attraente per qualsiasi cosa debba continuare a funzionare. Ogni pacchetto dati sACN porta un valore di priorità da 0 a 200. Una sorgente che non supporta la priorità variabile deve inviare 100, ed è per questo che 100 è il valore predefinito quasi ovunque.

La regola è semplice: per un dato universo, un ricevitore che riceve dati da più sorgenti tratta la priorità più alta come i dati definitivi. Numeri più alti vincono. Quindi una console di backup che trasmette a priorità 90 rimane silenziosa sotto una console principale a 100 e prende il controllo non appena la console principale si ferma. Nessun cambio, nessun patching, nessun input dell'operatore.

La priorità si applica per universo, non per canale. La priorità slot per slot è un meccanismo separato che E1.31 menziona ma non definisce.

Cosa succede quando due sorgenti si pareggiano alla priorità più alta è dove le implementazioni differiscono, e lo standard è onesto al riguardo. Definisce due comportamenti, merge (combinando i dati, comunemente la priorità più alta prevale per slot) e arbitration (scegliendo una sorgente), e richiede a ogni dispositivo di documentare quale utilizza, quanti sorgenti può gestire e cosa fa quando quel limite viene superato. Non impone un algoritmo.

Fornisce un forte avvertimento e questa è una buona regola anche per il design del rig: i progettisti sono "molto fortemente scoraggiati" da algoritmi che producono risultati diversi dallo stesso insieme di sorgenti in occasioni diverse, come accettare qualsiasi sorgente apparsa per prima. L'esito dipende quindi dall'ordine in cui le cose sono state accese, che è l'ultima cosa che vuoi in un giorno di spettacolo.

In DMXDesktop, la priorità è impostata per universo, da 1 a 200, con un valore predefinito di 100.

Cosa succede quando i dati si fermano

sACN funziona su UDP, che lo standard afferma chiaramente non offre alcun riconoscimento e nessuna garanzia che i pacchetti arrivino. Quindi la domanda interessante non è se i pacchetti vengano persi, ma cosa fa un ricevitore riguardo al silenzio.

Tre regole governano questo:

• Timeout per perdita di dati: 2,5 secondi. Se un ricevitore non sente nulla da una sorgente su un universo per 2,5 secondi, quella sorgente e quell'universo sono considerati disconnessi. Nella revisione del 2025 questo conta solo i pacchetti dati, quindi una sorgente che invia ancora pacchetti di sincronizzazione o scoperta, ma nessun dato, scadrà comunque.
• Keep-alive: ogni 800 a 1000 millisecondi. Una sorgente che non ha nulla di nuovo da dire non deve continuare a inviare dati in rete. Invia tre pacchetti identici, poi torna a un singolo pacchetto keep-alive circa una volta al secondo, il che è sufficiente per rimanere all'interno della finestra di 2,5 secondi.
• Chiusura pulita: il flag Stream_Terminated. Piuttosto che semplicemente rimanere in silenzio e lasciare che i ricevitori aspettino il timeout, una sorgente che ha finito imposta un flag in tre pacchetti finali. I ricevitori trattano questo come una disconnessione immediata e intenzionale piuttosto che come un errore.

Questa è la parte che quasi tutti sbagliano. Chiedi a una stanza di persone nel settore dell'illuminazione cosa dovrebbe fare un nodo quando i dati si fermano, e la maggior parte dirà che mantiene l'ultimo aspetto. Lo standard dice il contrario: un gateway deve fornire una modalità in cui, in caso di perdita di dati da tutte le sorgenti di un universo, smisura immediatamente la trasmissione di DMX512. La modalità hold-last-look è consentita come modalità aggiuntiva, non come quella richiesta. Se il tuo impianto si spegne quando un laptop va in standby, questo è un comportamento conforme, non un errore, e la soluzione è configurare il nodo, non incolpare il software.

Sincronizzazione, dati di anteprima e i flag delle opzioni

Ogni pacchetto sACN porta un piccolo campo opzioni con tre flag definiti, e spiegano diversi comportamenti che potresti aver visto senza sapere perché.

• Preview_Data. I dati contrassegnati con questo flag sono per visualizzatori e anteprime di server multimediali e non devono guidare l'output dal vivo. È così che un designer può eseguire uno stream di pre-visualizzazione sulla stessa rete senza illuminare la stanza.
• Stream_Terminated. La chiusura pulita descritta sopra.
• Force_Synchronization. Controlla cosa fa un ricevitore sincronizzato se la sincronizzazione viene persa: si blocca fino al ritorno, o continua ad aggiornarsi con nuovi pacchetti.

La sincronizzazione degli universi esiste per i casi in cui diversi universi devono cambiare nello stesso istante, come i pannelli LED, i server multimediali e i dimmer veloci, dove pochi millisecondi di ritardo sono visibili. La sorgente decide: inserisce un indirizzo di sincronizzazione nei suoi pacchetti dati e i ricevitori trattengono quei dati fino all'arrivo del pacchetto di sincronizzazione corrispondente.

Due note pratiche. Il supporto per la sincronizzazione è opzionale per i ricevitori, mentre i pacchetti dati e di scoperta non lo sono, quindi non puoi assumere che un nodo lo implementi. E DMXDesktop attualmente non utilizza pacchetti di sincronizzazione: trasmette pacchetti dati normalmente, che è ciò su cui funziona la stragrande maggioranza degli impianti.

Cosa serve alla tua rete

sACN è poco esigente, ma il multicast ha alcuni requisiti che spiegano silenziosamente la maggior parte delle storie "funziona alla mia scrivania ma non al locale".

• Supporto IGMP. Lo standard richiede ai ricevitori di supportare IGMP versione 2 su IPv4 (o MLD versione 1 su IPv6). È così che un dispositivo comunica alla rete quali gruppi multicast desidera. Su uno switch non gestito di piccole dimensioni, tutto viene inondato su ogni porta e funziona semplicemente. Su una rete gestita più grande, è necessario configurare correttamente IGMP snooping, con un querier presente, altrimenti il traffico sarà inondato ovunque o completamente bloccato.
• Cablaggio, non wireless. Il multicast su WiFi viene fornito a basse velocità di dati ed è facilmente interrotto. Usalo per un tablet di controllo remoto, non per un percorso dati di illuminazione.
• Regole del firewall. La porta UDP 5568 in entrata deve essere aperta su qualsiasi macchina che riceve sACN, e su Windows l'interfaccia deve essere quella che pensi sia. I laptop con più adattatori, inclusi quelli virtuali da software VPN, inviano frequentemente dalla porta sbagliata.
• Frequenza dei fotogrammi. Lo standard stabilisce che le sorgenti non devono superare la massima frequenza di aggiornamento DMX512, che E1.11 fissa a 44 aggiornamenti al secondo per un pacchetto completo da 513 slot, a meno che l'utente non abiliti deliberatamente frequenze più elevate su un universo senza gateway DMX. DMXDesktop emette a 40 Hz per impostazione predefinita e può essere impostato tra 10 e 44 Hz.

sACN, Art-Net e RDM: cosa non fa sACN

Due domande sorgono costantemente, e entrambe hanno risposte chiare.

sACN trasporta RDM? No. E1.31 non definisce alcun meccanismo per RDM, quindi nessun prodotto può offrire RDM su sACN, indipendentemente da come viene commercializzato. RDM su una rete è uno standard diverso, RDMnet (ANSI E1.33). RDM su Art-Net esiste anche, ma è un'estensione di Artistic Licence piuttosto che uno standard ESTA. In DMXDesktop, RDM funziona su interfacce USB e su Art-Net.

sACN è migliore di Art-Net? Risolvono problemi sovrapposti in modo diverso. sACN ha priorità, indirizzamento multicast e uno standard formale dietro di esso. Art-Net ha scoperta dei dispositivi, configurazione dei nodi e RDM. Molti impianti utilizzano entrambi contemporaneamente, il che è esattamente ciò che Art-Net 4 prevede. C'è un confronto completo affiancato nella guida Art-Net vs sACN.

Problemi comuni di sACN

Quasi ogni errore sACN è uno di questi.