Descripción del proyecto de controlador de nodo

---

Ponencia realizada por EA5DOM en SYSEA'92.
Publicado en: DIGICLUB Nº 6, Octubre 1992.

---

Hardware y código del Microcontrolador: EA5DOM, LuÍs
Software de terminal para IBM PC: EB5IDF, Manolo
BBS y Sysop para pruebas: EB5HLN, Eduardo

---

1.- ¿Para qué sirve un controlador de nodo?

La idea es que el controlador de nodo sea un sistema de supervisión para cualquier configuración de repetidor digital trabajando en un emplazamiento alejado. La misión de este dispositivo sería proporcionar una mayor flexibilidad a los encargados de su manejo, para así poder solucionar algunos problemas de forma remota (enviar comandos de reset, etc) o en todo caso proporcionar una idea clara de cual es el elemento que esta fallando, para así poder reemplazarlo directamente en un desplazamiento rápido al nodo.

2.- Hardware que se precisa

El proyecto está pensado para trabajar con nodos TheNet en configuración de uno o varios nodos unidos por serie. Para emplear todas las posibilidades del controlador hace falta un hardware adicional. Este consiste en el controlador de nodo en sí y tres cajas más. A saber:

• Una compuesta de dos conectores DIN por cada canal de radio, que se intercala entre la TNC y el equipo. Esta caja proporciona audio de todos los equipos a través de un mezclador al decodificador de DTMF (por tanto se pueden enviar comandos DTMF por cualquier canal) y permite que el controlador de nodo use el PTT y la línea de MIC para transmitir por cualquiera de los canales del nodo.

• Una caja de relés de alimentación. Proporciona conexiones independientes y protección mediante fusible para cada uno de los componentes del nodo (Radios, TNCs, Desconectores, etc). Cada salida tiene un relé que desconecta positivo y negativo cuando se activa.

• Una caja de conexiones serie. Básicamente compuesta de una matriz de conmutación para unir todos los nodos por serie. La caja es manejada por el controlador y permite realizar las siguientes operaciones:
  • Desconectar o conectar cada nodo al enlace serie. De esta forma se puede aislar un nodo de la red troncal con garantías. Eliminando el broadcast por serie en ese nodo no es suficiente, ya que automáticamente genera las rutas al escuchar a los demás a través del puerto serie.

  • Conectar el puerto serie de cualquiera de los nodos directamente al controlador. Esto se lleva a cabo cuando se produce una petición de pasar a MODO TERMINAL mediante el correspondiente comando DTMF. El puerto serie del nodo X se conectara al controlador, y a su vez este reseteará la TNC para trabajar con ese nodo como HOST.

Otras funciones adicionales, como plan de actividad y envío automático de telemetría mediante mensajes en la BBS, se pueden incorporar y ser muy útiles para mejorar la calidad de la red y controlar el entorno del nodo respectivamente. En algunos países, la legislación de packet-radio establece que los nodos deben identificarse periódicamente mediante CW. Por lo tanto pensamos incluir opcionalmente esta posibilidad. Mensajes de "OK" o "R" en CW nos pueden servir para indicar al Sysop que el comando DTMF ha sido recibido correctamente.

Otra fuente de problemas en un nodo suelen ser las tormentas. Hemos montado un desconector mecánico de antena y alimentación, que se activa vía comando DTMF y funciona mediante un temporizador y una batería propia para producir la conexión pasado el tiempo establecido. Este sistema será activado a través del controlador de nodo. Tenemos una idea para hacer un detector de tormentas con un detector de campo electrostático en el controlador. La CPU puede realizar muchas medidas y calcular los valores máximo, mínimo y de pico, enviando estos valores junto con el resto de telemetría. Por tanto esperamos que después de unos días de observación se pueda definir cual es el valor a partir del cual existe peligro de descarga eléctrica, y así activar el desconector de forma automática.

3.- Enviando comandos al controlador de nodo

Las funciones de acceso al controlador de nodo se pueden llevar acabo de dos maneras diferentes:

A)

Empleando tonos DTMF en cualquiera de los canales del nodo. Esto permite enviar ordenes rápidamente de forma rápida y simplemente con un equipo portátil. Las ordenes posibles en este modo son solamente unas pocas, y los códigos DTMF se pueden cambiar posteriormente a través del más complejo (y seguro) modo terminal.

Los comandos DTMF pueden ser:

1.-

Reset del controlador de nodo. Esta secuencia de códigos DTMF se detecta mediante lógica hardware (No interviene la CPU). Por lo tanto este comando es útil en el caso de que el controlador de nodo se quede "colgado". Pensamos emplear un hardware flexible para que esta secuencia se pueda cambiar por remoto, pero que funcione en caso de fallo de la CPU.

2.-

Desconectar todo el sistema a través del desconector temporizado. Este comando DTMF se detecta por el controlador de nodo y provoca la activación de un dispositivo externo. Hemos montado este hardware empleando un chasis de impresora modificado y cambiando el cabezal por un PL y conector especial para +/- 12V. Un temporizador de 12 horas y una batería interna aseguran la conexión pasado este tiempo.

3.-

Pasar el controlador a modo terminal empleando el NODO X. El NODO X se resetea y su port serie se direcciona al controlador de nodo, con lo que el TheNet arranca como nodo aislado con un HOST. El Sysop se conectará al NODO X y después al HOST. Otra posibilidad (más segura) es la de declarar los indicativos de el/los Sysops y asignarles un comando DTMF diferente a cada uno. En ese caso el controlador de nodo conectará directamente con el indicativo del Sysop de forma automática. Las funciones en modo terminal se explican más adelante.

4.-

Ajuste de Fecha/Hora del reloj en tiempo real. Es una tarea difícil de llevar a cabo desde el modo terminal tal y como está pensado, por tanto quizás sea mejor hacerlo por DTMF.

B)

Mediante el modo terminal (Ver el siguiente punto 4).

4.- Operación en modo terminal

El paso a modo terminal se debe solicitar a través de comando DTMF, pasando a realizarse una conexión normal de AX.25 entre el controlador y el Sysop.

Aun no tenemos totalmente clara esta parte del proyecto, pero pensamos que se podría gestionar de la siguiente manera:

Una vez establecida la conexión, el controlador no enviará ninguna petición de password. Puede ser que se incluya simplemente una elección entre "UPLOAD o DOWNLOAD" y una indicación de fecha/hora para poder comprobar la exactitud del reloj en tiempo real.

En lugar de password, el Sysop deberá enviar un fichero al nodo (UPLOAD) o recibir un fichero entero de configuración que el nodo enviará (DOWNLOAD). Este fichero se generará en un PC empleando para ello un programa especial bajo DOS. Creemos que mandar comandos directamente a un sistema como este supone un gran riesgo de equivocarse y cometer errores (Por ejemplo apagar todos los equipos del nodo !). El empleo de un programa puede hacer que la tarea sea más fácil y fiable. Podemos bajar el fichero de configuración del nodo, desconectar, y así disponer de tiempo indefinido para analizar todos los datos. El contenido de este fichero se describirá mas adelante.

También tenemos una idea para hacer que este fichero de configuración sea fácilmente accesible a todos los sysops o usuarios interesados, ya que este contendrá importantes datos de telemetría que pueden ser extraídos mediante el empleo de una versión especial para usuarios de ese programa. Sobre todo la información referente a datos meteorológicos en el emplazamiento del nodo o cualquier parámetro que midan los transductores del controlador. La velocidad del viento se puede obtener de forma aproximada por la tensión del aéreo-generador.

El proceso consiste en que el controlador cambie a modo terminal a una hora y en un canal especificados, y entonces realice una conexión con la BBS dejando el fichero como mensaje con un destino y ámbito predefinidos. El título del mensaje puede incluir fecha y hora, para que sea incluso posible el análisis automático de estos ficheros.

5.- Fichero de configuración del controlador de nodo

Ya que el fichero de configuración es binario, y para evitar tener que pasar por un protocolo tipo YAPP, seguramente emplearemos algún tipo de conversión de binario a ASCII. Otra posibilidad es emplear formatos tipo INTEL-HEX para subir y bajar los ficheros al nodo.

En cuanto al contenido es este fichero nos encontramos con que las posibilidades de este sistema son muy grandes y existe suficiente margen para permitirse pensar en "lujos" y virguerías. De momento, y como posibilidades mínimas a incluir podemos establecer las siguientes:

A)

Configuración básica: Al igual que en el Setup de un AT, se trata de disponer de una tabla de configuración del sistema, donde se indiquen los periféricos a controlar. En este apartado podemos incluir:

• Descripción de los canales del nodo: Si existe nodo o no para ese port. El máximo serían cuatro nodos totalmente controlados.
• Texto de INFO de cada nodo: El controlador reprogramará cada nodo en cada reset efectuado. Esto nos permite operar con TNC sin batería interna, y por lo tanto los resets son siempre efectivos.
• Parámetros para cada nodo: igual que antes.
• Rutas para cada nodo: igual que antes.
• Tabla de nodos para cada nodo: igual que antes.
• Indicativo de cada nodo y estado del identificador CW (Off/Cada XX min).
• Estado de la caja de desconexión: Apaga o enciende cada equipo. El programa deberá de comprobar (respecto al setup dado) que al menos un equipo de radio debe de estar siempre en marcha.

B)

Setup de DTMF:

• Secuencia de códigos para el comando de reset del controlador.
• Secuencia de códigos para el desconector general del sistema.
• Secuencia de códigos para petición de paso a modo terminal.
• Secuencia de códigos para ajuste del reloj en tiempo real.
• Si se emplea la opción de auto-conexión en el modo terminal, se debe de incluir una lista de indicativos autorizados como sysops, y su número de identificación.

C)

Tabla de actividad de la red: Se trata de generar una tabla de actividad de los nodos a lo largo de un periodo aproximado de una semana. De esta forma podemos programar los tiempos de encendido o apagado de los nodos y/o de su enlace serie con los demás en saltos aproximados de una hora. Solamente se apaga la TNC, dejando el equipo de radio activo para poder recibir los comandos DTMF.

D)

Setup de telemetría:

• Indicativo de la BBS a conectar de forma automática para dejar ficheros.
• Puerto a emplear para la conexión.
• Hora a la que se realiza la conexión (en principio diaria).
• Número de reintentos.
• Destino de los mensajes (Ej: ALL@NODTLM ).
• Tiempo de muestreo para cada uno de los canales A/D.
• Valor de disparo del medidor de campo electrostático.

El fichero enviado por el nodo contendrá todos los datos indicados por motivos de comprobación, así como los datos de telemetría capturados en las últimas 24 horas. También se enviará un log de actividad en el que se indiquen cuantas peticiones de modo terminal y comandos DTMF se han recibido, así como la hora.

7.- Sistema de seguridad para acceso al controlador

Para evitar el empleo de un password que de alguna manera tenga que ser enviado por el Sysop, se puede desarrollar este basándose en un algoritmo de doble llave. Uno de los códigos está instalado en el programa (EPROM) del controlador, mientras que el código correspondiente es generado por el programa de configuración (solamente la versión para Sysop).

Esto asegura el que aun en caso de que el programa de configuración se difunda, no se puedan generar ficheros válidos para el nodo sin conocer el código de este. Esta opción está aun por estudiar, pero es la alternativa más probable.

8.- Resumen

Hay que tener muy en cuenta que lo hasta aquí comentado forma un borrador de lo que será el proyecto final, en el que hemos incluido todas aquellas opciones que nos parecen interesantes y dignas de ser estudiadas. Más tarde, a la hora de implementarlas en el circuito final, habrá que desestimar algunas e incluir otras nuevas. De momento hemos tenido experiencias con el control del nodo mediante comandos DTMF, y la caja de desconexión esta actualmente instalada, con lo que vamos a poder comprobar su efectividad.

Vamos a emplear la tarjeta VersaBoard (basada en el 8051) como hardware básico. El decodificador de tonos DTMF, generador de CW, transductores para la telemetría y demás circuitos irán instalados en una segunda tarjeta. La VersaBoard es una placa diseñada con el propósito de servir como plataforma para diversos proyectos. Ha sido diseñada por JAMSAT (AMSAT Japón) y su primera aplicación es el TrakBox; una unidad autónoma para control de antenas y equipos en estaciones de satélite. Los responsables del proyecto TrakBox han visto de muy buen grado nuestra iniciativa, ya que el controlador de nodo era algo en lo que también pensaron al desarrollar la VersaBoard.

Otra posibilidad aun por estudiar sería la de sustituir el hardware necesario para conmutar puertos serie y líneas de audio por más puertos I/O en la placa extra que se diseñe para funcionar con la VersaBoard.

Debido a las enormes posibilidades que ofrecen las configuraciones de nodos basados en PC, como el TheNetNode de Nord><Link, y dado que este proyecto esta orientado a nodos TheNet en TNC nos surge la necesidad de revisarlo. Queremos que el mismo proyecto pueda tener diferentes configuraciones de hardware y que el software sea lo suficientemente flexible como para permitir su funcionamiento tanto con nodos TheNet como con TheNetNode. En este último caso la idea sería disponer de un monitor del estado del PC que nos permita incluso solucionar problemas de arranque por remoto (errores de setup, etc) que de otra forma implicarían una subida al nodo. También contamos con la colaboración del DIGIGRUP-EA3 en este proyecto, así como el interés de la TAPR y JAMSAT para su posible distribución en forma de kit en todo el mundo.

---

NOTA: Este fichero también se encuentra disponible en Inglés. Solicitarlo a:

Luis, EA5DOM @ EA5VDR.EAV.ESP.EU ó EA5DOM @ UO22
Avda Jaime I, 12-6
03500 Benidorm

Benidorm, Julio 1992