La red Mesh o red malla inalámbrica, posibilita la conexión vía radiofrecuencia entre equipos que estén dentro del rango de alcance por medio de nodos. Recibe este nombre porque los equipos se interconectan con otros, formando una especie de rejilla o malla.
Una de las principales ventajas de dicha red es que no posee un nodo central, por ese motivo no se corre el riesgo de que se produzca una “caída”.
En el probable caso en el que se cortarse la conexión de uno de los nodos, la información llegará a su destino por una vía alterna brindando mayor seguridad, ya que los demás sostienen la conectividad entre sí.
La existencia y propagación de dispositivos que soportan una conexión inalámbrica ha contribuido a que este tipo de red brinde un sistema con mayor seguridad.
La C de M cuenta con equipos conectados en una red mesh propia (enlaces RF, ethernet / gprs 3g/2g ) los mismos tienen dispositivos que, aparte de notificar sucesos de manera inmediata, actúan como repetidores. Los paneles de alarma que forman parte de la red funcionan como nodos y de esta manera contribuyen con su expansión optimizando su estabilidad y mejorando la seguridad. Actualmente se encuentran en funcionamiento las receptoras compatibles para las Mesh que se comercializan en Argentina.
Ya está activa una modificación en el funcionamiento de la APP Tahachi, ahora se pueden seleccionar por grupos las señales que el usuario podrá ver en la APP sobre eventos, ya sean: de emergencias, técnicas, control de horario, etc. Esto le permitirá al asociado decidir qué es lo que él desea que su cliente vea en la App.
Podrá acceder a la selección de los grupos en: soft Admin, solapa de configuraciones, operadores Tahachi.
En el manual Tahachi para minorista encontrará detalladamete la explicación de como realizar la selección de los grupos y que eventos integran cada uno.
También se incorporó un buscador por nombre o apellido, en el manual se detalla cómo realizar dicha búsqueda.
Los avances tecnológicos permanentemente generan cambios y es por eso que hoy contamos, entre otras cosas, con las líneas telefónicas digitalizadas. Si bien Telecom las ha implementado desde hace un tiempo, actualmente la situación es más compleja ya que al incorporarse al grupo de Fibertel los trabajos se han incrementado, se agregan sectores digitalizados y esto ha ocasionado muchos problemas. Las líneas digitalizadas no están adaptadas a los protocolos de transmisión de los sistemas de alarma, por lo tanto el resultado varía de acuerdo a los equipos que utilizan y a los niveles de compactación que pueden cambiar según la cantidad de tráfico. Esto hace que los problemas se manifiesten de distintas maneras.
Si bien las líneas de nuestras receptoras son 100% analógicas (según nos informó Telecom) esto no incide en el resultado, ya que la digitalización puede estar en la línea del abonado o en un tramo de enlace intermedio, lo cual sucede en la mayoría de los casos.
ALTERATIVAS PARA SOLUCIONAR PROBLEMAS
Si en una cuenta surgen los problemas mencionados, como primera medida, se debe probar el PROTOCOLO SIA, este no es por DTMF sino que es FSK, si bien en el 70% de los casos el resultado ha sido positivo, nos encontramos con el inconveniente de que no todos los paneles tienen disponible este protocolo.
Al realizar este cambio en la programación del Panel, no es necesario modificar nada en el Soft de monitoreo ya que los códigos del PROTOCOLO SIA y los de CONTACT ID son estandarizados y ambos se encuentran en la plantilla AUTOMATICA la cual se carga por defecto.
Si el panel no cuenta con SIA o si no funciona, se deberán agregar módulos de transmisión alternativos como los GPRS.
Otras de las soluciones que hemos puesto en funcionamiento es una RED RADIAL/GPRS MESH para lo cual en breve los convocaremos y les brindaremos una charla explicativa.
Señales ” No se recibieron datos” o “Datos no interpretables”
Todas las receptoras de primera marca generan un evento cuando a una señal no se la puede interpretar, son eventos internos, al que nosotros traducimos como “No se recibieron datos” o “Datos no interpretables”, la receptora lo genera en la cuenta 0000.
Desde hace más de 3 años estamos analizando esta situación, por eso programamos en nuestro software una característica que no posee ninguno de los softwares que están utilizando otras estaciones de monitoreo. Cuando entra una señal que la receptora no puede interpretar, la asociamos con la cuenta a través del Caller ID en las estaciones que no cuentan con nuestro software o no tienen el servicio del Caller ID en las líneas entrantes, todos estos errores de comunicación se envían a la cuenta 0000 que es a donde las receptoras dirigen las señales sin identificación por defecto.
Para verificar la problemática grabamos cientos de llamadas desde el lugar de origen y en la línea entrante de la receptora y detectamos distintos tipos de errores de la decodificación en destino. Cuando informamos esto a Telecom, no sólo nos confirmaron nuestras observaciones, sino que también nos comentaron que otras empresas de monitoreo, incluida ADT, efectuaron reclamos frente a los cuales ellos no puede dar soluciones.
COMO SE MANIFIESTAN ESTAS IRREGULARIDADES
Enumeramos algunos de los distintos tipos de errores que detectamos en nuestras grabaciones:
Uno de los errores (en la actualidad el menos frecuente) se detectó en centrales digitalizadas de empresas y de cooperativas en pueblos, modifica los tonos de Handshake y Kiss off lo que hace que el Panel no envíe el evento o se quede enviándolo en forma reiterada hasta dar error
Otro de los errores fue detectado, en la mayoría de los casos, en llamadas que provienen desde localidades del interior, se manifiesta con la agrupación de dos o más DTMF, o sea, dígitos que transmite el protocolo Contact ID, por ejemplo: en el origen se escucha bien el protocolo pero en destino llegan menos dígitos y algunos de mayor duración, esto fue planteado al personal de Telecom y ellos lo atribuyeron a la velocidad del discado del panel de alarma, en un evento generado por el panel en Contact ID, la secuencia de los DTMF son mucho más rápidos que el discado manual o el Redial de un aparato telefónico común, cuando se manifiesta este defecto, ninguna señal llega bien, se interpretaran como ” No se recibieron datos” o “Datos no interpretables” siempre y cuando sea una cuenta que en algún momento funciono bien, ya que si es una cuenta nueva, no está registrado el Caller ID de la línea del abonado, por lo tanto el Soft no lo puede asociar y mandara los eventos a la cuenta 0000
El error más común detectado actualmente, produce un “eco” al final de cada DTMF de los dígitos del Contact ID, esto sucede de manera aleatoria, es decir, ocurre en algunas llamadas. También se produce cuando ingresan varias señales en una misma llamada, las dos o tres primeras ingresan correctamente, pero en las siguientes aparece el “eco” y no se interpreta más. Aún no hemos recibido explicaciones de porqué y cuándo sucede.
Las grabaciones de escucha se efectuaron directamente en la línea de teléfono, por lo tanto el problema no es del panel ni de la receptora sino que se produce en el trayecto entre la línea del abonado y la de la receptora.
UN PROBLEMA EN TODO EL PAÍS
En el grupo de empresas que trabajan con nosotros hay más de 10 receptoras telefónicas distribuidas en distintas localidades del país. En la Ciudad de Córdoba contamos con 3 receptoras en distintos barrios que administran 32 líneas de teléfono y el promedio de error es similar en las 3, éste ronda el 9%. En la ciudad de Santa Fe existen 4 líneas de teléfonos y tienen un error promedio del 4%, esto se debe a que el nivel de digitalización en esa ciudad es menor que en Córdoba.
El evento de falta de test NO ES UN EVENTO DE EMERGENCIA por lo tanto es de BAJA PRIORIDAD. No hay tiempo estipulado para dar aviso, factores como inclemencias climatológicas lo condicionan, por tal motivo se prioriza el aviso de emergencias.
En ocasiones, cuando se quiere mejorar la seguridad del control del enlace, se disminuye la periodicidad de los Test Periódicos, lo cual provoca, en muchos casos, faltantes de test no importantes producto de la inestabilidad del vínculo utilizado.
Por este motivo, los Test Periódicos que hayan sido programados en intervalos menores a 12 hs. se procederán en la segunda faltante de Test.
Para que el Soft funcione correctamente y de esta manera evitarle confusiones a la Operadora, se deberá colocar el doble de periodicidad en los datos de la cuenta, de lo que el técnico programó en el panel. Por ejemplo: test programado en el panel cada 6 hs en el intervalo de test, en el soft se debe colocar 730 min (360 x 2 + 10 de tolerancia).
Sr, Asociado:
Le recordamos que usted podrá acceder a más información acerca de las novedades a través de los e-mails que se envían periódicamente a su correo electrónico. Este newsletter representa una síntesis de los cambios implementados por alarmas Keeper.
