Suporte Broadcast - Projeto Kaleido

Kaleido X16, é o multiview da Miranda (empresa do grupo Grass Valley), que serve para monitorar 16 entradas de sinais de áudio e vídeo em uma só tela de monitoração.

Esse equipamento é usado no meu trabalho para monitorar sinais importantes que fazem parte da cadeia de transmissão, produção e retorno de transmissão.

Uma das primeiras coisas que notei ao começar a trabalhar dentro da Central Técnica foi a disposição das bancadas, que é em formato de "L". Onde a monitoração do multiview fica perpendicular aos computadores que usamos para outros tipos de monitoração, para ação nos sistemas da cadeia de transmissão e produção áudio-visual e para ação nos servidores de MAM. Ou seja, o multiview passa boa parte do tempo fora do nosso campo de visão.

Partindo desse problema, um de meus colegas sugeriu um alarme sonoro, para produzir um "beep" em caso de problema. Com isso, a gerência de engenharia pediu para que fosse pesquisado uma forma de se fazer isso usando o próprio Kaleido.

Abraçando essa causa, comecei a pesquisar as formas de comunicação que existem no Kaleido, para ver se existe alguma saída dedicada ao envio desse tipo de informação.

Foram observados dois meios de comunicação para esse tipo de informação: a saída GPI e a saída serial RS-422.

As limitações de equipamento e de tempo para estudo acabaram tornando-se um fator muito grande para se descartar a comunicação serial. Assim, após pensar bastante, decidi prosseguir o projeto usando a comunicação GPI.

Foi estudado o manual de usuário do Kaleido e aprendido a produzir ações nele em consequência de uma eventual mudança de estado em suas entradas de áudio e vídeo.

Foi estudo o manual de instalações do Kaleido e aprendido o funcionamento do circuito GPI (ou pelo menos pensamos que sabíamos seu funcionamento. Vou explicar mais tarde).

Partindo para a prática, batemos no primeiro grande problema. Os Inputs e Outputs do GPI no Kaleido, não correspondiam com os que podiam ser configurados nas ações através do seu software de acesso (XEdit).

Após muito se pesquisar e não se achar solução, resolvi entrar em contato com o desenvolvedor do Kaleido. A engenheira que me atendeu, Verônica, mostrou-se muito solicita e fui super bem atendido.

Conversando com a Verônica, descobri que estava entrando no XEdit com o modelo errado do Kaleido. Ela ensinou a mudar o modelo no XEdit e pronto! Parece simples, não? Mas na prática não é tão intuitivo assim fazer isso.

Continuando o desenvolvido do projeto, testamos algumas ações e parecia que tudo seria muito simples daqui para frente. Foi aí que esbarramos no segundo grande problema. Criamos uma ação para que, em caso houvesse ausência de sinal, uma informação fosse enviada no GPI OUT 1. O problema era que nada saia. Nenhuma tensão era medida, ficava sempre em zero volts. Nenhum outro GPI OUT que era configurado enviava alguma informação. Enquanto isso, testando ações usando o GPI IN, tudo funcionava perfeitamente.

Após muita pesquisa, voltei a entrar em contato com a Verônica, que agora já posso chamar de santa. Conversando com ela e com o representante da Grass Valley de São Paulo, Guilherme, vi que estava tendo uma compreensão equivocada do circuito de GPI OUT. Ao invés de uma tensão de saída tínhamos uma resistência. Ou seja, o circuito ora funcionava como uma resistência infinita (em caso de normalidade), ora como uma resistência de 1K (em caso de problema). Pronto! Era tudo que precisávamos. Agora era só adicionar uma fonte externa para ser chaveada nesse circuito.

Resolvido isso, iniciamos a fase de construção do alarme sonoro. A princípio, para teste, usei um brinquedo da minha filha, que o cachorro comeu boa parte, mas a parte que ficou intacta ainda produz um som extravagante, para ser o alarme.

Foi bem engraçado ouvir o alarme durante os testes. Até porque a tensão da fonte não alimentava o circuito do brinquedo com a voltagem suficiente e o som ficava bem estranho. Parecia som de gato morrendo.

Brincadeiras a parte, fizemos vários testes, onde o alarme tocaria em caso de "Video Loss", "Video Freeze" e "Video Black". Com isso, observamos algumas necessidades.

A primeira necessidade notada foi que, as vezes, "Video Freeze" e "Video Black" fazem parte da programação que está sendo exibida. Do jeito que o alarme estava montado, estávamos tendo uma frequência muito grande de falso alarmes.

A solução que propus para esse problema foi a de temporizar a saída do alarme para essas condições, construindo um circuito temporizador para que o alarme toque apenas se o problema persistisse por um determinado intervalo de tempo (uns 10 ou 15 segundos).

Enquanto tentava fazer o temporizador, fui aperfeiçoando o alarme esteticamente, para que ficasse apresentável na bancada do setor.

Como disse antes, o circuito de GPI OUT funcionava como uma resistência de 1K, mas não é bem uma resistência de 1K, então fazer um circuito temporizador, usando esse chaveamento em série no circuito, tornou-se bem complexo. Usei um CI 555 e consegui um bom resultado, mas não estava satisfatório. Queríamos uma solução mais simples.

Sabe aqueles momentos em que, enquanto se está conversando sobre um determinado problema, alguém fala alguma coisa que acaba de dando uma luz para a solução. Então, aconteceu exatamente isso.

Um colega falou: devia ter como fazer isso por script. Foi aí que pensei: pow! O Kaleido usa a sintaxe JavaScript para configurar suas ações... e tem como criar ação customizada... pronto! É só adicionar um "sleep" nas linhas de comando e temos nosso temporizador!

Resolvido essa questão do temporizador, partimos para a segunda necessidade observada: O alarme tocava constantemente, desde o início do problema até a normalização.

A principio estava pensando em fazer um circuito de "beep" simples com o CI 555, como mostrado na figura abaixo.

Onde no lugar do led e da resistência colocaríamos um circuito com um buzzer. Mas agora com a ferramenta JavaScript na mão, foi só adicionar um condicional para ligar o GPI OUT e desligar meio segundo depois.

Os testes foram perfeitos. A frequência de falsos alarmes reduziram em 90% e o alarme já estava pronto para ser usado de forma satisfatória.

Este projeto deixa alguns pontos que devem ser futuramente aprimorados:

1- Infelizmente ainda não encontramos uma forma de reduzir em 100% a quantidade de falsos alarmes, pois existem conteúdos de diversas fontes sendo exibidas. Mas tenho algumas ideias de como aprimorar o alarme para que essa frequência fique mais próxima disso.
A mais promissora é estudar a programação e condicionar o tempo do temporizador (o "sleep") ao horário dos programas.

2- Ao criar várias ações, ou seja, 48 ações (Três por input do Kaleido), uma para "Video Loss", uma para "Video Black" e uma para "Video Freeze", foi observado que o tempo de resposta do Kaleido não ficou bem definido. O temporizador, quando definido para 10 segundos, as vezes demora em torno de 20 segundos as vezes em torno de 30 segundos. Isso não se mostrou um grande problema nos testes, mas é algo que precisa ser melhor compreendido. Talvez seja uma limitação do equipamento talvez um conflito nas ações criadas.

3- Alarme para o caso de "Audio Silense" deve ser adicionado futuramente.

Para concluir, agradeço a todos os colegas que me apoiaram e deram suas ideias e suas sinceras opiniões. Sem eles esse projeto não teria sido possível.