1

Universidad Nacional de Rosario

Facultad de Ciencias Exactas, Ingeniera y Agrimensura
Escuela de Ingeniera Electrnica
Informtica Electrnica





Proyecto Final
Control profesional de iluminacin por
movimiento




Autor/es:

Grupo N A4
Nombre y Apellido N de Legajo
Sergio Roldn R-2822/3
Ezequiel Picca P-/



Corrigi Calificacin




Fecha de realizacin: viernes, 03 de junio de 2011
2

INDICE




INTRODUCCIN... pg. 2
PROTOCOLO DMX512.. pg. 3
CARACTERISTICAS TECNICAS.... pg. 5
PROCEDIMIENTO DE DECODIFICACION.. pg. 8
IMPLEMENTACION. pg. 9
CONCLUSIONES pg. 10

3

Introduccin

Actualmente en el mundo de la iluminacin profesional, dada la necesidad
de controlar distintos tipos de efectos tales como dimmer packs, scanners,
cabezales mviles, mquinas de humo, etc., se ha unificado el control de
los mismos mediante el protocolo DMX512. El mismo permite, mediante
un mismo cable, conectar todos los dispositivos a controlar en serie,
mientas que hace posible el manejo independiente de cada uno de ellos.
Para ello hemos decidido realizar un control prctico mediante movimiento
para los distintos tipos de dispositivos.
Procedemos a realizar la implementacin a base de un estudio detallado del
protocolo DMX512, implementando la UART del microcontrolador, el
conversor AD y el ascelerometro.



4

Protocolo DMX512

El DMX512-A es un protocolo de comunicaciones usado para controlar la
iluminacin de escenarios.
Fue originalmente pensado para usarlo en controladores de enlace y
dimmers de diferentes fabricantes. Sin embargo, pronto se convirti en el
protocolo preferido no slo para controladores de enlace y dimmers, sino
tambin para controlar aparatos de iluminacin como scanners y cabezas
mviles, y dispositivos de efectos especiales como mquinas de humo.
Como el DMX512 es un sistema de transmisin de datos poco confiable, ya
que es unidireccional y no incluye ninguna forma de verificacin y/o
correccin de errores, no dte ser usado para controlar pirotecnia ni ningn
tipo de aplicacin que implique riesgos para la salud.



5

Caractersticas Tcnicas
El DMX512 es un protocolo extremadamente simple, de bajo costo y
relativamente robusto. Gracias a estas ventajas ha ganado una gran
popularidad.
Es un protocolo de transmisin serie asincrnico que no provee ningn tipo
de handshake entre receptor y transmisor, ni ofrece ninguna verificacin de
error, o mecanismo de correccin. Por lo tanto, to es apropiado para
aplicaciones donde la seguridad sea crtica. Como su nombre sugiere, cada
conexin de datos DMX512 soporta hasta 512 canales o dispositivos
distintos. Debido a ello, cuando se necesitan ms de 512 canales de
contropueden utilizarse mltiples universos DMX. Un universo se refiere a
una conexin de datos DMX512 desde la consola, y a todos los dispositivos
en esa conexin. Muchas consolas soportan mltiples universos DMX, pero
deben ser cableados separadamente. Ocasionalmente esto se hace
intencionalmente, para particionar el control en diferentes unidades, por
ejemplo pueden separarse dimmers y luces mviles en diferentes
conexiones an cuando ninguna de las dos use los 512 canales.
Los datos son transmitidos a una tasa de 250kbaud, usando una interfaz
fsica compatible con el estndar de transmisin RS485, sobre dos cables y
una tierra.
Capa de datos
El flujo de datos DMX es transmitido en serie, con una tasa de 250Khz, lo
que significa que cada bit dura 4ps. Los datos se agrupan en paquetes de
hasta 513 bytes (hasta 512 canales ms el Start Code, que como se ver es
el canal 0), llamados slots o frames. El protocolo utiliza un formato de
datos little-endian (es decir, del bit menos significativo al ms
significativo) con 1 bit de start y 2 de stop.
A continuacin se describen los diferentes estados y/o marcas del paquete
DMX.

Idle o situacin sin DMX:

El estado Idle ocurre en ausencia de un paquete DMX vlido, y la salida de
una linea DMX en este estado ser una seal continuamente alta.

Break:

El comienzo de un paquete DMX se anuncia poniendo la salida en bajo por
un periodo mnimo de 88us, lo que equivale a 22 bits. Esto se conoce como
Break. El Break puede ser mayor, pero no menor a 88us.

MarkAfter Break (MAB):

6

El MAB sigue inmediatamente al Break, llevando la salida a nivel alto por
un periodo mnimo de 8is o 2 pulsos. Es el MAB el que marca el
comienzo del paquete DMX, y la seal que indica a los receptores que
comiencen la recepcin.

Start Code (SC)

El SC sigue al MAB, y es el comienzo del flujo de datos real y donde todos
los datos de cada canal individual tienen el mismo formato. El Break y el
MAB tienen distintos tiempos, pero comenzando con el SC todos los
frames tienen la misma estructura y tiempo de 11 pulsos o 44]is. El primer
fame puede pensarse como los datos para el canal 0, que en realidad no
existe; este primer fame es el SC.
A continuacin se describe la estructura general de estos frames de datos de
canal:
De los 11 pulsos el primero siempre es bajo, y es llamado bit de
inicio o start.
Esto es seguido por el byte de datos reales (que puede ser 1 de 256
valores, desde 0 a 255).
El frame termina con dos bits en alto, que son los bits de stop y
marcan el final de la informacin del canal.

El canal nmero 0, como ya se dijo es el SC, e indica cuales son los tipos
de datos que siguen. Este es el propsito final del SC, poder separar los
paquetes de datos segn el tipo de receptor.

Mark Time Between Frames (MTBF)

El MTBF puede ir de un poco ms de 0 segundos hasta 1 segundo. Cada
frame de cana tiene el MTBF antes de cada Start Bit. El MTBF es un nivel
alto.
Channel Data (CD)

Los frames de datos de canal (CD) siguen al frame de SC en una forma
lgica de 1 a 512 (o menos) de la manera descripta arriba.

Mark Time Between Packets (MTBP)

Despus que se envan los ltimos bits de stop vlidos de un CD, se ha
completado un paquete entero, y puede comenzar un nuevo paquete con sus
respectivos Break y MAB. Pero antes puede existir un tiempo muerto entre
paquetes (de nivel alto). La longitud de este tiempo puede ser de un poco
ms de 0 segundo hasta 1 segundo.
7

La siguiente figura ilustra cada uno de los puntos descritos anteriormente.


*Break
*Mark Alter Break (MAB)
*Slot o frame
*Bit de start
*Bit de datos menos significativo (LSB)
*Bit de datos ms significativo (MSB)
*Primer bit de stop
*Segundo bit de stop
*Mark Time Between Frames (MTBF)
*Mark Time Between Packets (MTBP) 11 - Tiempo entre Breaks
*Secuencia de reset (Break, MAB y SC)
*Paquete DMX512
*Datos del frame 0 (Start Code - SC)
*Datos del frame 1
*Datos del frame n (Mximo 512)
Un paquete entero tarda aproximadamente 23ms en enviarse, lo que
corresponde a una tasa de refresco de unos 44KHz. Para obtener tasas
mayores pueden enviarse menos canales. Esto se logra simplemente
comenzando un nuevo paquete antes de que se hayan enviado los 512
canales. Existe una longitud mnima de paquete, equivalente a 24 canales.
La mayora de los transmisores envan los 512 canales debido a que
algunos receptores tienen problemas con paquetes ms cortos.

8

Procedimiento de decodificacin

La caracterstica principal del protocolo DMX512 en cuanto a la
decodificacin, es que no es necesario enviar el nmero de canal.
El primer byte despus del START CODE (SC) es tomado
automticamente como el valor del primer canal, el siguiente como el valor
para el segundo canal, y as sucesivamente hasta 512 canales o menos. Es
compromiso del receptor el contar el nmero de canal para saber cul es el
que se est recibiendo. Como en DMX512 no existe deteccin o correccin
de errores, es de vital importancia para el receptor no perder slots, y
descartar paquetes si se detectan errores de framing o buffer overflow.
En la prctica, en el receptor se setea un contador de canal (en software o
hardware). Este contador se resetea automticamente para apuntar al canal
0 cuando se detectan un BREAK y un MAB vlidos. Luego, con el ltimo
bit de stop de cada frame, este contador se incrementa en uno. Por lo tanto
durante el frame de SC la salida del contador lee un 0. Al final del SC
(ltimo bit de stop del frame de SC), la salida del contador se convierte en
uno, dicindole al procesador que el prximo frame contiene los datos para
el canal uno, y as sucesivamente. De esta forma el receptor sabe para qu
canal es vlido el dato actual. Comprendida la decodificacin, que
hallamos en internet procederemos a implementar la solucin inversa para
transmitir.


9

Implementacin

Una vez comprendido el protocolo, utilizaremos la UART del
microcontrolador para realizar la comunicacin. Primero calculamos los
baudios de modo que cada bit sea de aproximadamente 4micro segundos.
Luego utilizaremos el RTC para lograr los tiempos deseados al principio de
cada paquete de 512 datos, para luego en conjunto con la UART enviar
cada dato correspondiente a cada canal mediante una rutina de Refresh
continuamente.
Utilizaremos un buffer de datos de cada canal, en el cual almacenamos y
cambiamos el dato correspondiente, segn se desee.
Utilizando el acelermetro, buscaremos la posicin del kit segn las
lecturas del conversor AD, las cual las obtenemos de una funcin que nos
indica el valor de X, Y y Z en cada momento. Una vez obtenidos los datos
los comparamos con un margen de posible error y luego procedemos a
incrementar o decrementar los datos del buffer segn corresponda.
Ya que la posicin solo tiene 3 variables X, Y y Z. Utilizaremos los
botones para seleccionar los distintos canales a controlar. Hemos decidido
por practicidad controlar solo 2 canales a la vez, luego con los botones
cambiaremos de canales. El primer canal apuntado ser indicado mediante
los leds del kit.
Finalmente utilizaremos un botn de black out el cual resetea todos los
dispositivos a cero, haciendo un back up de sus condiciones en ese instante
para que si luego se vuelve a presionar el botn recupere sus datos
anteriores.


10

Conclusin

Logramos adaptar perfectamente la UART del kit a protocolo sin mayores
problemas. Se pueden controlar todos los canales muy bien, incluso los ms
altos (orden de 500). El kit nos presento ciertas limitaciones en cuanto a la
comunicacin del usuario, ya que no dispone de muchos botones, ni un
display como interfaz grafica para el usuario. Sin embargo, para usuarios
profesionales familiarizado con los dispositivos a controlar, resulta un
modo de utilizacin muy sencillo y de fcil aprendizaje.
Finalmente este proyecto se podra ampliar agregando display y otras
interfaces para programar distintas escenas y lograr un funcionamiento
automtico como sucede en las consolas profecionales.


11

Capa fsica - Protocolo RS485
La seal de DMX512 es transmitida a travs de la interfaz estndar de la
industria conocida como E1A485, o ms familiarmente RS485.
El estndar RS485 define las caractersticas elctricas de transmisin sobre
un par diferencial. Por lo tanto se usan tres cables para transmitir la seal
digital:
El cable de seal + (+s)
El cable de seal - (-s)
El cable de tierra o neutro (0V)
Una seal digital alta (1) es transmitida cuando el cable +s tiene un
potencial mayor que el cable -s. Una seal digital baja (0) es transmitida
cuando el cable +s tiene un potencial menor que el cable -s. Es la diferencia
entre los dos cables lo que importa, no la diferencia entre cada uno de ellos
y el neutro. Ms an, el cable de tierra puede no estar presente en absoluto
en algunas instalaciones EIA485.
Los niveles alto y bajo estn definidos claramente por el estndar RS485.
La tensin de cualquiera de los dos cables respecto al neutro puede estar
entre +12V y -7V. Para que el receptor detecte un cambio de estado, el
estndar dice que el diferencial debe ser de al menos 200mV. Lo bueno
acerca de la operacin en modo diferencial es que, como se dijo
anteriormente, lo que importa es la diferencia relativa entre ios dos cables.
El cable de tierra generalmente se usa slo como malla en los cables
mallados que se usan para la transmisin de DMX512. Esto trae beneficios
respecto al ruido, ya que el mismo se introduce por igual (misma amplitud
y fase) en los dos cables, y cuando el receptor obtiene el diferencial lo
anula.