¡Hola! Me presento como un amante de la música, de los cielos y del sonido bien sonado.

Soy técnico electrónico y, por más de 13 años, formo parte del departamento de I+D+I de Fonestar, donde se han diseñado numerosos equipos relacionados con el envío de audio a través de la red de datos, entre otros. Mi función en dicho departamento ha estado relacionada con el mundo del hardware y ha sido, desde el montaje de prototipos PCB, hasta el ensamblado final de los equipos, pasando por el testeo de los mismos.

Aunque en ese departamento todos tenemos que estar pendientes de la iteración de los equipos con el resto del entorno, mi papel ha estado ampliamente relacionado con el de beta tester.

Todos nuestros equipos se fabrican íntegramente en nuestras instalaciones. Y una de mis funciones, como intermediario entre I+D y departamento de producción, es la de establecer la forma más ágil y correcta de fabricar dichos equipos, dando asimismo, apoyo a producción cuando se requiere.

Por otro lado, también me encargo de la reparación de las placas electrónicas de nuestros equipos.

Formo parte del servicio de atención al cliente y doy asistencia técnica a clientes que se encuentran in situ en las instalaciones y les surgen dudas con los equipos.

Sin lugar a duda, ver que las cosas que haces salen bien. Y con esto me refiero a lo que me concierne respecto a la puesta en marcha de una placa de prototipo para un equipo. En ocasiones es una fase compleja en la que un mínimo fallo o componente erróneo puede suponer muchas horas de detección a la hora de probarla. Ver cómo las cosas funcionan a la primera sin duda es lo más gratificante. Y, en su defecto, encontrar la causa de un incorrecto funcionamiento en las fases previas de prototipado, también es toda una satisfacción.

Otra de las cosas que me dan el subidón, es cuando en una instalación de un cliente las cosas se han complicado con algún asunto relativamente enrevesado, en ocasiones de redes y en otras debido a poltergeist por los que a veces te tiras de los pelos diciendo… ¡no puede ser! Pero tras aplicar una buena dosis de perseverancia, acaba saliendo el demonio para nunca volver.

Desde mi punto de vista, todo cliente con el que he tratado ha mostrado gran interés y ha tomado nuestra solución de audio sobre IP como un gran avance para sus necesidades.

Yo entré en esta empresa bastante joven, habiendo instalado megafonía con líneas de 100 voltios en unas pocas ocasiones previas a mi incorporación. Cuando llegué aquí, no conocía esta forma de enviar audio y verdaderamente me voló la cabeza ir viendo poco a poco lo bien que terminó funcionando nuestro primer reproductor de streams de audio AIP-3010. Los años han pasado y el mercado ya ha ido adoptando poco a poco sistemas de audio basados en IP como principales soluciones. Pero por aquel entonces no tenía parangón.

Los dispositivos que hay en las redes cada vez son más complejos. Por poner un ejemplo, hace varios años los switches que se ponían en las instalaciones solían ser no gestionados. Pero de hace un tiempo para acá, viene siendo cada vez más frecuente que sean gestionados y cada vez con más parámetros a controlar. En estos casos a veces nos encontramos con “zancadillas” cuando un switch de estos tiene desactivadas ciertas funciones básicas para el correcto funcionamiento de nuestros equipos. Son cosas que con los switches “tontos” no nos ocurrían. Por ello, es importante cada cierto tiempo ponerse al día sobre qué tipos de equipos están vigentes y, si hace falta, comprarlos y hacer pruebas nosotros en el laboratorio, como ha sido en un caso muy reciente.

Y esa es la suerte que he tenido, la de tener a los mejores siempre a mi lado y haber estado perfectamente engranados todos para que la fluidez en la resolución de fallos fuera total.
Ha sido todo un lujo que salieran primeras versiones de equipos y que una gran parte de las funciones de equipos fueran como la seda. Pero cuando no ha sido así, me ha bastado con detectar el error, decírselo a un compañero o anotarlo en un chat de incidencias, y normalmente en menos de un día, tenerlo arreglado y con una nueva actualización de equipo subida para probar. He de decir que algunos casos han sido complejos y que en ocasiones la detección ha sido de lo más laborioso y caprichoso. Esos errores dan más pereza, pero cuando se encuentran… ¡te puedes imaginar el chute de adrenalina que da! Jejeje

Siempre hay que empezar por el principio. Quién no se ha sentido molesto cuando ha llamado a la operadora de internet y lo primero que le han preguntado es… ¿tiene el router encendido?

En este caso no llegamos a ese punto ni mucho menos, pero cuando se trata de equipos que funcionan sobre IP, hay mucha infraestructura que los rodea y, para evitar posibles disgustos, es recomendable hacer las preguntas básicas inicialmente. Cosas como si el equipo tiene IP fija o dinámica, si cuentan con un router que tiene servidor DHCP activado, o si los equipos están separados por varios switches, pueden dar muchas pistas que, si te ahorras preguntar, quizás luego te toque estar más tiempo dando vueltas. Por otra parte, los clientes con más conocimientos en estos áreas lo entienden perfectamente e incluso lo agradecen.

Claro. Recuerdo un caso que me tuvo bastante tiempo pegado al teléfono. Y es que resulta que una vez hablando con un instalador que estaba en un colegio instalando equipos AIP, le sucedió una cosa que ninguno de los dos nos imaginábamos. Por un lado, él había probado los equipos en su laboratorio antes de llevarlos al cole. Pero una vez allí, los conectaba en un switch y no los veía. En primer lugar, tras realizar las típicas comprobaciones y seguir sin poder verse los equipos en la aplicación, solo quedaba de comprobar si en el firewall de Windows defender las conexiones TCP y UDP de los equipos estuvieran permitidas. Al ser un PC de colegio público, el administrador había capado el acceso al firewall, por lo que hubo que probar con otro PC. Una vez se detectó que ese era el motivo, el instalador quitó el switch donde tenía todos los equipos conectados y conectó el cable ethernet de ese PC en una toma de roseta, y un equipo AIP en otra toma justo al lado. El equipo de nuevo pasó a no verse tampoco. Al comprobar si se hacían “ping”, vimos que tampoco, pero las IP que adquirían los equipos parecían estar en la misma subred. Me lo invento, uno podría tener la IP 192.168.1.120 y el otro la 192.168.1.34.

Tras mucho rato, acabé detectando que las puertas de enlace de esos equipos eran diferentes y es que resultaba que cada roseta pertenecía a dos routers diferentes y a dos líneas de red independientes, cada una de un ISP distinto. La vida me dio que los routers tuvieran IP’s distintas, porque bien podrían haber tenido la misma y entonces es probable que me hubiera acabado saliendo un sarpullido.

Los peores errores son cuando se juntan varios casos por los que no se detecten nuestros equipos, pero esta tenía el aliciente de algo no esperado por ninguno. Quizás también por teléfono se complique un poco este tipo de detecciones y a veces parezca que estés dando palos de ciego.

El ABC de todo desarrollo de equipos conlleva una elaboración de lo que se denomina “Changelog”. Internamente, nosotros tenemos una serie de procedimientos para registrar las pruebas que realizamos, pero el fichero donde se detalla cuál ha sido el cambio o mejora en cada actualización es el Changelog. De forma interna nosotros podemos anotar uno más detallado y el que se cuelga en la web, uno más resumido y simplificado.

Si bien es cierto que no es muy frecuente que un cliente lea el Changelog, alguna vez se ha dado el caso de que un instalador se supiera los cambios que había en el mismo, y hablando con él por teléfono te los fuera contando. ¡Las ansias por solucionar un caso a veces te llevan a hacer cosas tan desesperadas como leerte un triste Changelog! Jejeje

En nuestro caso, es vital para saber en qué momento se tocó algo que pudiera estar relacionado con un posible error actual y que, antes por lo que fuera, no ocurría.

Desde luego, todo esto va muy deprisa a veces. Siempre lees artículos o revistas donde descubres nuevas tecnologías, aunque bien es cierto que muchas de ellas te sirvan para saber que existen, están ahí y son una opción. Muchas veces no puedes aplicar a tus equipos todo lo nuevo que aparezca en el mercado, dado que nunca acabarías de desarrollar la solución pensada originalmente. Por ello, hay que saber enfocar el tiro, elegir la que creas que va a aportar gran valor añadido al mercado y trabajar y depurar sobre ella.

Otra cosa, por ejemplo, como decía antes sobre el caso particular de switches, es la aparición de nuevos estándares que tengan que ver con el manejo del tráfico que usen tus equipos. En ese caso, sí conviene estar a la última para que no te pille de imprevisto cuando se empiecen a usar en el mercado. Leer características nuevas de routers, switches y todo elemento que conforme una red y dedicarle tiempo a enterarse qué significan, siempre va a ser una ayuda a futuro.

Mi recomendación personal es que no le tengan miedo. Uno de los motivos que a mucha gente del mundo de la megafonía tradicional (línea de 100V, baja impedancia, etc…) le puede echar para atrás el hecho de utilizar esta solución para sus instalaciones, es que asocia la tecnología IP a algo muy intangible y complejo.

Mi consejo es que, aquel que sienta curiosidad, se compre un router neutro por 15 euros, ponga un PC en una de sus bocas, un dispositivo que funcione por IP en otra boca, y cacharree en casa.

En YouTube hay numerosos cursos que en pocas horas explican los conceptos básicos para entender la comunicación entre dispositivos a través de este protocolo.

Mismamente, en Fonestar contamos con un plan formativo totalmente gratuito llamado Fonestar Academy, en el que uno de sus módulos trata el asunto de redes, dando las pinceladas básicas y necesarias para poder poner en funcionamiento nuestros equipos AIP y en general, para poder entender cualquier dispositivo que funcione por IP.