Las comunicaciones digitales - CW
por ON6JC/LU - Villa Carlos Paz, Córdoba, Argentina


Todo el mundo sabrá lo que es el CW (código Morse). En realidad es la forma mas antigua de comunicación digital que esta en uso. Eso no quiere decir que perdió toda su utilidad, por supuesto. 

Como funciona? No hablaremos del telégrafo por cable - al final somos radioaficionados. En nuestro caso, el transmisor es sencillamente 'encendido' mientras que apretamos la llave de morse, y se 'apaga' cuando la soltamos. Podríamos llamar al 
estado 'encendido' 1, y al estado 'apagado' 0... Y tenemos comunicación digital. 

Ahora cual es la gran ventaja del Morse que hace que todavía este en uso? Por supuesto unas de las causas principales es el hecho que hay tantos equipos en servicio todavía. Pero también una razón importante es la gran confiabilidad de ese sistema. Los equipos son relativamente sencillos (y baratos!), y gran parte del sistema depende de la operatividad del operador. 

Para la recepción de CW se necesita un receptor con un oscilador de batido (BFO). Ese oscilador tiene como tarea hacer audible a la señal de CW que no tiene modulación. Al 'batir' la señal recibida con una señal local corrida en frecuencia unos 1000 Hz (1kHz) mediante un circuito llamado 'detector de producto', se obtiene un tono audible con la frecuencia de la diferencia. Realmente, para recibir CW el receptor no necesita nada mas que un BFO, un detector de producto (o mezclador) y un amplificador de audio. Ese tipo de receptor se llama de 'conversión directa' (DC). 

Se puede decir que el espacio que necesita un transmisor dentro de la banda depende de la velocidad que se transmite la información. Por su baja velocidad, CW ocupa una porción muy pequeña. En el receptor de CW se pueden usar filtros muy selectivos, para rechazar otras señales. 

Ahora entonces porque no se siguió utilizando el CW en las comunicaciones mas modernas? La velocidad es solamente una de las razones - aunque quizás la principal. Un operador bueno puede recibir telegrafía a 30 o 40 palabras por minuto. Pero tal operador necesita un entrenamiento de muchos meses para llegar a esa velocidad. Entonces se busco una forma para poder decodificar automáticamente lo recibido. El código Morse, donde casi cada letra tiene un largo distinto, no se presta muy bien para una máquina mecánica que gira siempre con una velocidad constante. Por eso se diseñó el código Baudot para teletipo. 

Otro problema con la decodificación automática del CW es su misma forma de transmisión. En las pausas que existen entre los signos y entre las letras, no se transmite nada. Entonces el receptor tiende a tratar de subir la ganancia automáticamente para mejorar su sensibilidad. Cualquier interferencia que existe en ese intervalo entonces puede disparar a la máquina. Hacer ese control de ganancia mas lento no es una solución muy buena, ya que tiene que compensar los efectos del 'fading' (QSB: variaciones de la señal por condiciones atmosféricas). 

Y otro detalle mas: los operadores manuales no producen un código tan perfecto como lo exige la máquina. Algunos de los programas que decodifican Morse con computadora actualmente, pueden compensar variaciones de velocidad, pero la mayoría tienen problemas cuando el corresponsal transmite 'puntos' y 'rayas' irregulares... Los manipuladores electrónicos han mejorado notablemente la calidad de la transmisión, pero la evolución de las computadoras impuso la necesidad de un código mas apropiado.

Algunos términos:

Comunicaciones digitales - RTTY

Dos problemas a solucionar:

Este último requerimiento no tiene mucha importancia con las computadoras, pero si lo tenia para la decodificación mecánica. Si además podemos aumentar la velocidad - bienvenido sea...

Primero un poco de historia:

En 1874 un francés, Emile Baudot, diseño un sistema de telégrafo que imprime directamente. Para la transmisión definió un código, actualmente en uso, llamado el código Baudot. Hasta fin del siglo 19, la transmisión se efectuaba manualmente, requiriendo dos operadores muy entrenados... 

En 1907 se formo una compañía en Estados Unidos, llamada 'Morkrum Company' que después se convertiría en la famosa 'Teletype Co', dedicándose al desarrollo de máquinas para la decodificación del código Baudot. En Inglaterra se forma la 'Creed Company' que en 1927 empezó a diseñar su primera máquina para teletipo. En Alemania la empresa 'Kleinschmidt' fue una de las primeras a dedicarse al teletipo.

Todos esas máquinas infernales eran una joya de diseño mecánico y algunas han prestado servicio durante mas de 30 años, 24 horas por día. Mi primer teletipo, un Creed modelo 7B, comprado por el equivalente de 10 dólares en surplus, cumplió 42 
años... sus mas de 1500 partes y 20 kilos! 

Todos esas máquinas fueron desarrolladas para uso en servicio terrestre por cable. Necesitaban fuentes de 100 a 150 voltios corriente continua para la excitación de las bobinas. 

Ahora a la actualidad:

Empecemos por lo mas difícil. Los códigos que usaremos tienen que tener el mismo largo. En teletipo por cable, entre caracteres, el circuito queda con una corriente constante. Ese estado se llama 'Mark' (1). La transmisión se realiza por 'cortes de corriente' (Space, 0). Cuando empieza un caracter, se interrumpe durante un lapso corto (22 ms) la corriente marcando así el arranque (Start) (0). Luego siguen 5 intervalos iguales (también de 22 ms) donde la presencia o no de la corriente (0/1) 
forma el caracter. Y por último sigue un intervalo algo mas largo (Stop, 32 ms), con la corriente presente (Mark). Luego sigue eventualmente el próximo caracter. 

Los 5 intervalos nos permiten formar 32 combinaciones diferentes. Eso ni siquiera alcanza para representar 26 letras, 10 dígitos, y algunos signos. Menos si necesitamos además comandos especiales para controlar el avance del papel (Line Feed, LF) y el retorno del carro al margen izquierdo (Carriage Return, CR). Por eso dos códigos fueron asignados para elegir dos juegos de caracteres, similar al uso de 'Mayúsculas' en el teclado de la máquina a escribir. Se asigno un código para cambiar a 'LETTERS' (letras) y código para volver a 'FIGURES' (números). Para escribir ON6JC habría que teclear entonces: O N <FGRS> 6 <LTRS> J C. Las computadoras detectan automáticamente la diferencia e insertan los comandos necesarios. 

Un caracter toma entonces: 

Start Interv1 Interv2 Interv3 Interv4 Interv5 Stop
22 + 22 + 22 + 22 + 22 + 22 + 32 = 164ms

Resulta en mas o menos 6 caracteres por segundo, o unas 60 palabras por minuto. La velocidad se expresa en 'Bauds', y es el número de intervalos (mas cortos) que se transmiten por segundo. En nuestro caso sería 1/0.022 = 45.45 Bauds, la velocidad mas utilizada entre radioaficionados. Comercialmente se utilizan además 50, 56, 74 y 100 Bauds. 

El problema de las pausas de transmisión de CW se soluciona muy fácil: se deja la portadora continuamente en el aire. Por supuesto necesitamos transferir la información de alguna forma. Tenemos que elegir un modo de modulación. Modulación de amplitud 
no se presta muy bien para la transmisión de datos, por sus sensibilidad a ruido, QSB etc. Entonces nos queda solamente modulación en frecuencia. 

La modulación elegida, FSK, desplaza la frecuencia cuando se transmite el 'Mark' por un valor que varia según el servicio. Los radioaficionados utilizan únicamente 170 Hz de desplazamiento. El 'Mark' corresponde normalmente con la frecuencia mas alta, el 
'Space' con la mas baja. Por ejemplo: Mark en 14.10017 MHz y Space en 14.10000 MHz. 

Para la recepción utilizamos de nuevo el receptor de CW con su oscilador de batido. En lugar de generarnos un solo tono cuando hay portadora, escuchamos ahora dos tonos, uno correspondiente a Mark, el otro a Space, desplazados uno al otro por 170 Hz. Normalmente se sintoniza el receptor de tal forma que los tonos que resultan son 2125 Hz y 2295 Hz. Luego se convierten los tonos en 1 y 0, y la computadora se encarga de decodificar la información. 

Ahora, y las desventajas? En presencia de errores en la transferencia - ya sea QSB, ruido etc... - no hay forma de darse cuenta. En el caso de texto el asunto no es tan grave - el idioma tiene bastante redundancia para permitir muchos errores. Pero en el caso de datos numéricos, no hay corrección... Además si la máquina perdió uno de los caracteres de control (LTRS o FGRS), sigue escribiendo en el modo equivocado. 

Términos técnicos:

 

Comunicaciones digitales - AMTOR

Durante muchos años el RTTY fue aceptado con sus falencias por falta de alternativas... Hasta que la electrónica permitió construir circuitos digitales compactos. Entonces -
principalmente para uso en servicios marítimos y telégrafos - se diseño un circuito que permitió control sobre la exactitud de lo recibido. El sistema se llamaba básicamente TOR (Teletype on radio), y genero varios sistemas relacionados, como el SITOR y el
AMTOR (Amateur TOR). El circuito controladora se instalo originalmente entre el receptor de radio y el teletipo mecánico. 

Como podemos transmitir un caracter de una forma que el destinatario se puede dar cuenta si fue recibido correcto o no? El código original Baudot no permite errores en sus 32 combinaciones - si uno de los 5 intervalos cambia de valor, el resultado es otro código válido. Se dice que este código no tiene redundancia, ya que no permite ningún tipo de deformación. 

Para generar un código redundante, tenemos que agregar mas 'bits' (o intervalos), que no tienen otra función que hacer el código controlable. En TOR se agregan dos bits a los 5 del Baudot. La cantidad de códigos válidos en total es (casi) igual que el código Baudot. La cantidad de combinaciones posibles con 7 bits es 128 (2^7). De ellos solo 34 (32 de Baudot + 2 nuevos) son válidos (mas o menos 25%). 

Como es el protocolo? En el modo ARQ, la estación que esta transmitiendo información, la transmite en grupos de tres caracteres cada uno, y luego espera la confirmación del destinatario. Ese contesta alternadamente - mientras todo va bien - con dos códigos especiales llamados C1 y C2. Supongamos que dos estaciones están comunicando, y que estación A 'tiene la palabra': 

Estación A Estación B Comentario
[THE] ----> [THE] Recibió bien,
<---- C1  confirmo.
[ QU]  ----> [ QU] Recibió bien,
<---- C2  confirmo.
[ICK] ----> [I_K] Recibió mal,
<---- C2  repito C2.
[ICK] ----> [ICK] Ok,
<---- C1  confirmo.

Por supuesto es bien posible que el código de confirmación se pierda en el 'aire'... Entonces, la estación transmisora (llamada MASTER), al no recibir confirmación de la otra estación (SLAVE) manda un bloque de tres caracteres especiales RQ (ReQuest):

Estación A Estación B Comentario
[ BR] ----> [ RO] Recibió bien, confirma
<---- C2
[OWN] ----> [ QU] Recibió bien, confirma
? X--- C1 No llega la confirmación...
[rrr] ----> [rrr] Que paso? [ReQ ReQ ReQ]
<---- C1 Aaaah, entonces repito C1
[ FO] ----> [ FO] Ok, confirma
<---- C2

La llamada a una estación se realiza mediante dos bloquecitos de tres caracteres compuestos así:

[Car1 ReQuest Car2] [Car3 Car4 ReQuest]

Los caracteres pueden ser o el código de la estación llamada, normalmente cuatro letras de la característica, o pueden ser CQCQ, para hacer una llamada general. Cuando la estación que llama recibe dos códigos consecutivos de confirmación correctos, arranca la comunicación. 

Por supuesto que hay mas... Hay un protocolo para pasar la palabra de una estación a otra, para recuperarse de perdida de señal, etc etc... Pero la descripción completa cae fuera del marco de este boletín. La descripción completa del protocolo, por G3PLX (el 'papá' del AMTOR) consta de 7 páginas. 

Lo que si falta describir es el modo 'broadcast' para transmisión de boletines, donde no hay corresponsal para la confirmación. En este caso, la estación transmisora transmite dos veces la misma información, ahora en grupos de 4 caracteres cada uno. El receptor elegirá de los dos grupos el que recibió correctamente. Este modo se llama 'FEC'. Para poder sincronizar con el grupo 1 y 2 correctamente, la estación transmite al
principio del mensaje, y luego por lo mínimo una vez cada 100 caracteres transmitido, una secuencia de sincronización.

Para compensar la perdida de velocidad, tanto por la necesidad de esperar cada vez la confirmación como los dos bits agregados, AMTOR transmite mas rápido que RTTY: un intervalo dura 10 ms, correspondiendo a 100 Bauds. Además no se transmiten ni el START ni el STOP del código Baudot. Entonces un grupo tarda 10 ms x 7 (bits/caracter) x 3 = 210 ms. Entre grupos, el master siempre espera durante 240 ms para la respuesta del slave. De no recibir a tiempo la confirmación, transmite la secuencia [rrr]. El resultado es un ciclo de 210 + 240 = 450 ms para cada 3 letras, o nuevamente 6 letras por segundo, parecido a RTTY. 

Rendimiento de AMTOR: En la primera columna un número que indica el porcentaje que el canal es 'utilizable' (QRM, QSB etc...) En la segunda columna es el porcentaje del mensaje transmitido que se recibió correctamente:

Calidad del canal Calidad de recepción Tiempo tomado
100 % 100.0 % 1.00
90 % 99.8 % 1.11
80 % 99.8 % 1.25
50 % 99.2 % 2.00
30 % 98.2 % 3.30
10 % 93.0 % 10.00
5 % 85.2 % 20.00

Desventajas: dos veces por segundo el transmisor pasa a transmisión. Para transmisores con rele es una prueba para la paciencia del operador y para los reles. Además el tiempo entre grupos es pequeño, y alcanza, en condiciones optimas, justo para 20000 km. AMTOR por Oscar 13 no es posible, ya que la distancia supera mucho ese valor (35000 km ida y vuelta, 70000 en total). La confirmación no llegaría a tiempo. No todos los transmisores son lo bastante rápido en conmutación para acomodar contactos en AMTOR. Y la velocidad sigue baja. 

Términos técnicos:

Comunicaciones digitales - Packet Radio 

Llegamos a lo 'nuestro'... El packet esta regido por un conjunto de reglas y normas. Las normas de transmisión varían de banda en banda y determinan los tonos utilizados, la velocidad de transmisión etc. 

El contenido de la transmisión, el 'protocolo', se llama AX.25. Es un 'subset', o una parte, de la norma X.25 de CCITT que fue desarrollada para la comunicación digital. Entre otros esta usado en la red ARPAC en Argentina. Esta norma prevé varios modos
de trabajo, donde una estación puede ser 'Master' o 'Slave'. En el caso de la norma para radioaficionados, ninguno de las dos estaciones tiene 'privilegios'. Se trata de un modo llamado 'modo asíncrono balanceado'. Balanceado dado que ambas estaciones
tienen los mismo privilegios, asíncrono por la forma de intercambiar mensajes y confirmaciones. 

La estación no se llama mas 'estación' o 'módem'... Ahora se llama TNC. El TNC puede ser implementado por separado, como el Kantronics o el TNC2, o puede estar completamente contenido en el programa de la computadora, como el programa Digicom para la Commodore 64/128. El TNC se encargará de que la información se
intercambie correctamente según el protocolo AX.25. 

En HF se utilizan 300 Bauds, y un desplazamiento de 200 Hz entre el 'Mark' y el 'Space'. En VHF se estandardizó 1200 Bauds, y tonos de 1200 y 2200 Hz, derivados de la norma Bell para módems de teléfono. Además de estos 1200 Bauds, se están utilizando, especialmente en bandas mas altas (430 MHz, 1290 MHz) velocidades mucho mas elevadas. En EEUU han desarrollado módems que llegan hasta 56000 Bauds! 

La información se transmite en 'paquetes'. Además de la información, se transmite un 'header' o encabezamiento, y un 'trailer', o terminación. Ese header contiene el indicativo del originador del mensaje, el indicativo del destinatario, y eventualmente las características de los 'digipeaters' (mas sobre los digipeaters luego). Luego contiene un caracter que indica el tipo de paquete, que puede ser un paquete de información, de
confirmación y mas todavía... Sigue un numero de 0 a 7 que va indicando el número de secuencia del paquete. Sigue la información, y al final sigue un código que permite el control sobre el contenido recibido, con una certeza de mas de 1000 veces la de AMTOR.

Hay tres tipos de paquetes:

El formato de los 'frames' (cuadros) (U) y (S) es igual:

(S) o (U) frame (I) frame Comentario
01111110 01111110 'Flag' de sincronismo
10011000 (L) 10011000 Indicativo de la
10101010 (U) 10101010 estación de destino
01100010 (1) 01100010
10101100 (V) 10101100
10010010 (I) 10010010 LU1VIP-0
10100000 (P) 10100000 (Estación principal,
11100000 (-0) 11100000 (SSID) el -0 no aparece)
10011110 (O) 10011110 Indicativo de origen
10011100 (N) 10011100
01101100 (6) 01101100
10010100 (J) 10010100
10000110 (C) 10000110 ON6JC-0
01000001 (espac) 01000001 Siempre 6 caracteres,
01100000 (-0) 01100000 (SSID) si faltan rellenar.
CONTROL CONTROL Un byte de control
---- PID Número de secuencia
---- <datos> Información
FCS(1) FCS(1)
FCS(2) FCS(2) 'Suma' de control para
01111110 01111110 control de integridad
Termina con otro Flag

Si hay repetidoras (digipeaters) en el camino, se agregan las características entre origen y destino. 

La transmisión de los datos no contiene Start ni Stop como el AMTOR. Los caracteres consisten de 8 intervalos ahora (bits), todos disponibles para transmitir información, permitiendo hasta 256 posibilidades o caracteres diferentes. En lugar del venerable código Baudot se eligió el código ASCII, que define los caracteres y funciones especiales para combinaciones 0 hasta 127. 

Para los que buscan el código ASCII en la tabla: el código fue desplazado una posición hacia la izquierda, y se agrego un '0' en el lugar a la derecha. De esa forma se puede detectar la última característica de la cadena, ya que en el SSID de la última característica el bit de la derecha es un '1'. 

(U) frames tienen como función principal establecer o cortar una comunicación. El campo de Control determina la función:

(SABM) Solicita al destinatario de conectarse si posible
(DISC) Solicita la desconexión
(DM) Se transmite cuando un corresponsal manda información, pero la conexión ya se había cortado.
(UA) Confirma el pedido de conexión o desconexión pedido por la otra estación.
(FRMR) Rechaza un frame, pero sin conocer el numero del paquete que se espera.
(UI) Información sin numerar: Balizas etc.

(S) frames manejan la transferencia de datos mientras que la conexión esta establecida y funcionando. También el control tiene varios significados:

(RR) Confirmación de recepción correcta.
(RNR) El receptor no esta listo para recibir - espere.
(REJ) Un paquete fue mal recibido o estaba fuera de secuencia.

Como ya mencionamos antes, cada mensaje de información lleva un número de 0 a 7 (y luego vuelve a 0)... Eso le permite a los (S) frames de informar al originador, el mensaje confirmado o rechazado. Siempre se incluye el numero del próximo mensaje que se espera, por ejemplo: si recibimos un paquete con numero 5, lo confirmamos con RR6. 

Otro vez el protocolo tiene mas secretos de lo que podemos describir en el marco de este boletín. Para los interesados en los detalles la obra de referencia es una publicación de la ARRL:

AX.25 AMATEUR PACKET-RADIO LINK-LAYER PROTOCOL
(Version 2.0, October 1984)

Esta publicación contiene todas las definiciones de la versión 2.0 del protocolo utilizado.

Un QSO (corto) podria ser asi:

ON6JC to LU1VIP ctl SABM ! Pedido de conexión
LU1VIP to ON6JC ctl UA ! Confirmación
ON6JC to LU1VIP ctl I05 ! Encabezado del mensaje
Hola VIP, como andas... ! Texto del mensaje
LU1VIP to ON6JC ctl RR6 ! Confirmación
ON6JC to LU1VIP ctl I06 ! Encabezado del mensaje
Hay nieve ya en Bariloche? ! Mensaje...
--------xxxx------ ! Interferencia, pasan
! FRACK segundos...
ON6JC to LU1VIP ctl RR0 !* Manda algo para que
LU1VIP to ON6JC ctl RR6 !* LU1VIP contesta con
ON6JC to LU1VIP ctl I06 ! el numero anterior
Hay nieve ya en Bariloche? ! Entonces ON6JC repite
LU1VIP to ON6JC ctl RR7 ! y LU1VIP confirma.
LU1VIP to ON6JC ctl I70 ! Ahora LU1VIP manda
Hola John... Todo bien ! dos paquetes juntos,
LU1VIP to ON6JC ctl I71 ! de los cuales ON6JC
por aqui... ! recibe solo el segundo
ON6JC to LU1VIP ctl REJ1 ! Entonces ON6JC nota
LU1VIP to ON6JC ctl I70 ! que algo anduvo mal,
Hola John... Todo bien ! y rechaza el segundo
LU1VIP to ON6JC ctl I71 ! paquete, haciendo
por aqui...  ! repetir a LU1VIP...
ON6JC to LU1VIP ctl RR2 ! Ahora si entro bien.
LU1VIP to ON6JC ctl I72 ! Algo mas viene...
Tengo que irme, John...
LU1VIP to ON6JC ctl I73
Hasta mas tarde!
ON6JC to LU1VIP ctl RR4 ! Confirma
ON6JC to LU1VIP ctl I07
Ok. Christian... Chau... ! No queda otro remedio
ON6JC to LU1VIP ctl DISC ! que desconectar,...
LU1VIP to ON6JC ctl UA ! LU1VIP confirma la desconexión.

La secuencia marcada con !* es típico para estaciones que utilizan la versión 2 del AX.25. Regularmente aparecen algunos que por error utilizan la versión 1, menos sofisticada. En tal caso ON6JC no preguntaría si LU1VIP recibió bien mediante el RR0, sino directamente repite el mensaje entero - una clara pérdida de tiempo, ya que puede ser que LU1VIP recibió bien el mensaje y que la confirmación se perdió por la interferencia. 

Aquí siguen algunas abreviaciones... 

Comunicaciones digitales - Nodos y digipeaters

En realidad la estación de cada aficionado - que trabaja en packet, por supuesto - es un nodo... Solamente que es este caso se habla de un 'nodo terminal', ya que la información no se retransmite. 

El digipeater (contracción de Digital Repeater) es parecido a la repetidora en VHF. La única diferencia es que la repetidora recibe un 'paquete' y lo retransmite. Solo lo retransmite si lo recibió correctamente. Supongamos dos estaciones (ON6JC y LU1VIP) que están utilizando a LU3AGJ como repetidora. La repetidora de Juan se llama LU3AGJ-1. Entonces el QSO se ve asi:

ON6JC LU3AGJ-1 LU1VIP
Paquete1....... (1)
........Paquete1........ (2)
(3)........Confirmacion1 
.......Confirmacion1..... (4)
Paquete2.......
........Paquete2........
........Confirmacion2
.......Confirmacion2.....

Vemos que, para que un mensaje se reciba correctamente, y la confirmación llega correctamente, hay 4 transferencias que tienen ejecutarse sin problemas. Además - ya que se supone que ON6JC y LU1VIP no se escuchan entre si, sino no utilizarían al digipeater - es posible que LU3AGJ-1 reciba datos de las dos estaciones simultáneamente. Esto se llama una 'colisión'. 

El uso de digipeaters estaba previsto en la norma AX.25, pero con la condición que el uso en el futuro seria reemplazado por una forma de 'repetición' mas eficiente. 

Podemos enlazar digipeaters para cubrir mas distancia. En HF casi imposible y completamente impráctico. Aun con un solo digipeater la comunicación resulta demasiado poco confiable para justificarse. Con dos digis tendríamos 6 (!) transferencias que tienen que ejecutarse sin error... 

El 'nodo' es una repetidora 'inteligente'. En lugar de comportarse como una repetidora, se comporta mas como una estación automática. Para utilizarla, el usuario se conecta con el nodo como si fuera una estación común. Luego le da al nodo el comando para que ese se conecta al corresponsal. Una vez conectado la comunicación se ve así: 

(Ahora usamos LU3AGJ-4, el nodo de Juan...)

ON6JC LU3AGJ-4 LU1VIP
Paquete1....... (1)
.......Confirmacion1 (2)
Paquete1......... (1)
(2).........Confirmacion1
Paquete2.......
.......Confirmacion2
Paquete2.........
.........Confirmacion2

La gran diferencia se nota: El mensaje se confirma en seguida. El paquete original no tiene que llegar el destino para que el originador reciba su Ok... El nodo almacena un número de paquetes y se 'hace responsable' de la transferencia al destino. Cuando
no tiene mas memoria disponible, el nodo le informa al originador de los mensajes de 'esperar un poco' (código RNR).

Otro detalle: ON6JC se conecto con LU3AGJ-4... Cuando le da a LU3AGJ-4 la orden de conectarse a su vez con LU1VIP, LU3AGJ último toma la 'personalidad' de ON6JC, utilizando la característica ON6JC-15 para hacer la conexión. Entonces el enlace se ve en realidad como si dos QSO se desarrollan independientemente:

ON6JC LU3AGJ-4 ON6JC-15 LU1VIP
Paquete1....... (1)
.......Confirmacion1 (2)
Paquete1......... (1)
(2).........Confirmacion1
Paquete2.......
.......Confirmacion2
Paquete2.........
.........Confirmacion2

Al igual que con digipeaters, podemos enlazar nodos. Cada vez hay que hacer la conexión. El primer nodo utiliza con el segundo ON6JC-15. El segundo con el tercero ON6JC-14, el tercer nodo con el destinatario ON6JC-13...:

ON6JC --> LU3AGJ-4
ON6JC-15 --> LU1VIP-4
ON6JC-14 --> etc.....

En HF, enlaces involucrando mas de un nodo son imprácticos. La eficiencia de un nodo se estima 6 veces mas alta que la de un digipeater! 

Existen ahora dos tipos de nodos: Los dedicados al trabajo de nodo, y los llamados 'KaNodes'. Esos últimos permiten al dueño el uso normal del TNC simultáneamente con el trabajo como nodo. Los nodos dedicados están especializados en el trabajo como  tal. Donde esta la ventaja de este tipo entonces? Dado el 'tiempo libre' que disponen, estos TNC se dedican a mantener datos de otros nodos que están al alcance. Mantienen una lista de las características, y además de la calidad del enlace. 

Para realizar ese trabajo, regularmente, pasan mensajes entre si para controlar la 'propagación'. Un sistema con nodos que ha estado trabajando un tiempo, contiene un mapa de todas las combinaciones posibles, dentro de su alcance. Entonces si me conecto con LSR (el nodo en Pampa de Achala), le podría pedir que me conecte con LU3AGJ en el nodo de LU8DYF. El nodo LSR sabrá como buscar el camino óptimo para llegar al destino. (Lastima que no hay lo bastantes nodos en el camino entre Buenos Aires y Córdoba!)

Los Kanodes no tienen ese mapeo automático, pero si mantienen una lista de estaciones escuchadas, para ayudar la elegir la conexión. 

Estaciones con la posibilidad de actuar como Kanode, normalmente se identifican regularmente como (ej.): 

CE3DWJ CE3DWJ-1/D CE3DWJ-3/G CE3DWJ-2/B CE3DWJ-4/N

Donde: 

Mas información técnica en la serie de boletines de LU4AEY. Agradezco los comentarios de CX7BY, LU1YDM, LU1OGG, LU6EXG, OA4BJ.