III Seminario Sound&Lite

di Andrea Mordenti

Dopo aver masticato e digerito il DMX 512, ci accorgiamo che è quasi ora di mandarlo in pensione. Vediamo quindi come sarà possibile, in futuro, la comunicazione tra le console sempre più computerizzate e i proiettori sempre più intelligenti.

Nuovi protocolli di comunicazione

Abbiamo visto che il DMX è un flusso di segnali che va sempre e solo in una direzione (dalla console ai device) attraverso tre fili (2 conduttori + schermo). Fu previsto su un connettore a 5 poli perché si pensava di utilizzare i due poli aggiuntivi in un secondo momento per implementare la comunicazione inversa (dal device alla console). Nel tempo si è visto che sarebbe stato estremamente costoso ricablare tutto il DMX mondiale sostituendo i cavi esistenti con nuovi cavi a 4 conduttori + schermo e l’industria ha così cercato varie soluzioni per ovviare al problema. Il primo passo verso una nuova forma di comunicazione tra gli apparecchi è il protocollo definito come RDM (Remote Device Management). È un protocollo di tipo bi-direzionale “condiviso” nella trasmissione dati DMX512 e nella stessa rete fisica. Cambiando opportunamente lo start code (praticamente dicendo agli apparecchi “la sequenza che segue NON è DMX”) si possono sottrarre porzioni di banda al DMX per inviare segnali diversi alle macchine. Questi segnali possono porre delle domande agli apparecchi, ed è chiaro che gli apparecchi devono essere in grado di rispondere (RDM‑ready). La comunicazione avviene quindi in tutte quelle aree del protocollo DMX in cui non avviene alcuna comunicazione significativa, ciò evita di togliere priorità trasmissiva al DMX. L’RDM può essere abilitato o disabilitato in qualsiasi momento operativo, qualora si desideri dare priorità assoluta alla trasmissione dati DMX; allo stesso modo l’operatore può fermare la comunicazione DMX ed utilizzare tutta la banda per interrogare le macchine via RDM ed aspettare la risposta.

Per poter utilizzare l’RDM occorrono quindi console e proiettori in grado di riconoscere e utilizzare questo linguaggio, splitter e buffer dedicati e, condizione essenziale, ciascun apparecchio deve avere un ID unico (UID, da non confondere con l’indirizzo DMX che è assegnabile dall’utente) determinato dall’azienda costruttrice. I campi di utilizzo dell’RDM sono vari e prevedono di poter fare una scansione del sistema per l’individuazione del numero e tipo di apparecchi collegati, il remote addressing e la navigazione nei menu dei device, il controllo dello stato dei proiettori e l’eventuale comunicazione di errori, altre funzioni custom fornite dal costruttore come controllo delle ventole, ricalibrazione di parti meccaniche, monitor dello stato della lampada, delle temperature, ecc. Un possibile scenario potrebbe essere di avere un operatore con una console che si occupa della gestione dell’illuminazione dell’evento ed un secondo operatore con un PC nella stessa rete DMX che, sfruttando gli spazi in cui la comunicazione DMX non è significativa, mantiene il controllo dei parametri fisici dei proiettori via RDM.

Nella rapida evoluzione dei sistemi si pone però l’esigenza di un protocollo di comunicazione completamente nuovo, basato sui principi di comunicazione delle reti Ethernet. Un protocollo di comunicazione di rete è una comunicazione seriale, bi‑direzionale, interattiva di trasmissione di dati discreti. Permette il collegamento di molte macchine, non solo computer, in una rete in cui ognuno ha un indirizzo specifico che si chiama IP.

Il software di rete è fatto a strati (layer), ogni strato implementa funzionalità ben precise e si interfaccia solo con gli strati immediatamente sopra e sotto. Questo permette di semplificare le interazioni fra le componenti del software e, se le interfacce fra i layer sono ben definite, di utilizzare insieme apparati ed implementazioni diverse dei protocolli. Esistono diversi protocolli di rete, noi ci limiteremo ad analizzare il protocollo più usato, ossia il TCP/IP. Il Transmission Control Protocol / Internet Protocol (TCP/IP) è un software di rete, disponibile per tutti i sistemi operativi, che permette alle applicazioni di comunicare tramite un protocollo instradabile, lo stesso usato su Internet.

Il TCP/IP è sviluppato su base empirica e la sua struttura a layer non è ben precisa; si possono ad ogni modo distinguere 4 strati:

1- Lo strato delle applicazioni che non è trattato dal TCP/IP.

2- Uno strato di trasporto TCP che definisce come i dati sono suddivisi in pacchetti e passati agli strati inferiori, come i pacchetti in arrivo sono riassemblati, come si comunica all’altra macchina che i pacchetti sono stati ricevuti e come pacchetti persi vengono ritrasmessi (questo è molto importante, alla base del protocollo c’è proprio il concetto di invio di pacchetti di dati e di attesa della risposta; il TCP continuerà ad inviare un pacchetto specifico finché non riceverà risposta dall’apparecchio associato a quell’indirizzo); specifica inoltre come si stabilisce e si termina una connessione. Esiste anche l’UDP (User Datagram Protocol) utilizzato al posto del TCP per comunicazioni brevi che non prevedono un vero controllo della connessione ma un semplice invio di pacchetti, senza attesa di risposta; l’unidirezionalità dell’UDP lo rende più veloce del TCP e lo assimila in qualche modo al DMX, con il vantaggio che, dato che il software di comunicazione non aspetta la risposta dal software con cui comunica, non ci sono problemi di sovraccarico di segnali se un device si dovesse guastare.

3- Uno strato di rete che specifica come i pacchetti vengono inviati a destinazione e quindi come sono fatti gli indirizzi di rete ed il routing.

4- Uno strato fisico che specifica come i dati sono trasmessi sul mezzo fisico: abbiamo ad esempio i protocolli ethernet, per collegare le macchine ai cavi di una rete locale (LAN), o i protocolli IEEE 802.11 per le reti wireless; questo strato non è descritto dal TCP/IP.

Per effettuare la trasmissione dei dati si procede in questo modo: l’applicazione, che è associata ad una certa porta del TCP, passa i suoi dati allo strato TCP; il TCP spezza i dati in pacchetti, aggiunge davanti ad essi un header, con i numeri di porta e tutti i dati che servono per il collegamento e poi passa i pacchetti allo strato IP; lo strato IP aggiunge il suo header, con i numeri IP delle macchine di origine e destinazione dei dati e passa il pacchetto allo strato fisico; lo strato fisico (ad esempio Ethernet per trasmettere sulla LAN) aggiunge un header con gli indirizzi fisici delle schede di rete e codifica il pacchetto in segnali elettrici adatti al cavo sui cui devono viaggiare.

Alla struttura a strati del TCP/IP corrisponde quindi una struttura “a cipolla” del pacchetto, in cui il pacchetto Ethernet contiene (incapsula) un pacchetto IP, che contiene un pacchetto TCP, che a sua volta contiene i dati delle applicazioni.

Arrivato a destinazione, il pacchetto segue l’iter inverso: la scheda Ethernet della macchina di destinazione preleva il pacchetto, riconosce il suo numero Ethernet, quindi sa che il pacchetto è per lei, toglie l’header Ethernet e passa il pacchetto allo strato IP; lo strato IP esamina (e toglie) l’header IP, quindi passa il pacchetto al TCP; il TCP riordina i pacchetti e li organizza in uno stream che viene associato alla porta TCP relativa alla applicazione che deve ricevere i dati.

Ogni strato opera come se avesse un collegamento diretto con lo strato corrispondente sull’altra macchina ed ignora tutto il resto: le applicazioni ignorano tutto il marchingegno per il trasporto, come se si parlassero direttamente; il TCP non vede cosa fanno le applicazioni, ma regola solo il collegamento con l’altra macchina come se interagisse solo con lo strato TCP remoto; lo strato IP si occupa solo del fatto che il pacchetto viaggi attraverso i router in modo corretto.

Il layer fisico per questo tipo di comunicazione è specifico, il cosiddetto “twisted pair” (UTP): cavi simili a quelli usati per i telefoni, utilizzabili con una lunghezza massima di circa 100 metri, dopo di che il segnale va rigenerato utilizzando un hub o uno switch (l’hub rigenera il segnale e rispedisce tutti i pacchetti in ogni uscita, lo switch legge gli indirizzi IP dei pacchetti che riceve e invia i pacchetti solo alla porta a cui quell’IP fa riferimento).

Ogni cavo UTP contiene 4 coppie di fili e, per minimizzare le interferenze, ogni coppia è avvolta su se stessa; il segnale è codificato come differenza di tensione fra i 2 fili della coppia. Una coppia si usa per trasmettere, una per ricevere. Questa tecnologia è stata sviluppata inizialmente per velocità a 10 Mbit/sec, ma oggi arriva a 100 Mbit/sec (con cavi detti di categoria 5) e si iniziano a diffondere connessioni a 1000 Mbit dove si usano tutte e 4 le coppie di fili.

Basato sul TCP/IP (o meglio sull’UDP) è il protocollo Art‑Net, creato dall’azienda britannica Artistic License in assenza di uno standard universalmente accettato, per ampliare la possibilità di utilizzo del DMX512 utilizzando la comune tecnologia di rete. La struttura empirica del protocollo consente la gestione di 256 universi DMX. Il layer fisico di banda comparata ne assicura 40, ma attraverso un sistema di compressione di dati del protocollo stesso si possono controllare sino a 60 universi.

Le ragioni del successo che sta avendo il protocollo Art‑Net si trovano nel fatto che utilizza apparecchi e tecnologie a basso costo e di facile accesso e può essere trasportato attraverso strutture già cablate in modo standard, con possibilità di superare grandi barriere fisiche attraverso tecnologie Wi-Fi, linee dedicate ADSL, ISDN, VPN, ecc. Quindi non è necessario cambiare le schede DMX dei device e allo stesso tempo si possono utilizzare tutte le apparecchiature in commercio per le reti di tipo Ethernet.

Altre aziende hanno poi sviluppato protocolli proprietari simili ma tutti basati sullo stesso concetto: la console emette un segnale di rete che viene convertito attraverso l’apparecchio specifico di quel protocollo nel numero di universi DMX necessario.

Oggi ci troviamo in una situazione analoga a quanto avveniva negli anni precedenti la standardizzazione del DMX512, in cui ogni azienda sviluppava il suo standard di comunicazione digitale console‑device; la registrazione del protocollo da parte della USITT mise fine al proliferare di standard diversi. Nel futuro la potenza della banda passante dell’Ethernet permetterà applicazioni ancora superiori e diversificate, pensiamo al pixel mapping dove ogni singolo pixel di uno schermo può essere considerato un canale DMX e gestito in autonomia.

Nel prossimo numero tratteremo nei dettagli alcune delle tecniche di programmazione utilizzate per programmare uno show luci.