Modalidad basada en AX.25, sucesora del Packet Radio de los años 90.
Permite en tiempo real, enviar por radio, información geoposicionada que sea de utilidad.
Funciona a 1200 bps, y es bastante robusto para usuarios en movimiento (vehículos)
Si estás pensando en instalar o actualizar tu software Direwolf y ya de paso, la versión del sistema operativo a Raspberry Pi OS v12 (Bookworm), te vas a encontrar una pequeña sorpresa, al no poder utilizar las Entradas/Salidas GPIO como hasta ahora.
Todo se debe a un cambio motivado por una mejora de la seguridad de la Raspberry Pi, por el que no permite acceder directamente en modo escritura a las entradas/salidas de GPIO, utilizados habitualmente para sacar la señal de PTT y en algunos casos la de DCD.
La primera solución que encontré, se basaba en desactualizar el firmware de la Raspberry. Claro. Vamos a una versión anterior en la que no se protegían… y todo vuelve a funcionar. Pero así, también dejamos de tener parches de seguridad que seguramente sea interesante tener.
En éste tiempo, como el problema se ha generalizado, los programadores ya han sacado una (e incluso dos) versión de desarrollo con las modificaciones necesarias, y es lo que os voy a contar.
A partir de ahora, para acceder al GPIO tendremos que hacerlo a través de la librería gpiod.
Lo primero es instalarla, para ello lo haremos de la forma habitual:
$ sudo apt install gpiod
No voy a entrar más en gpiod ya que nuestro objetivo, es que Direwolf pueda hacer PTT.
Para instalar la versión de Direwolf necesaria para que funcione todo, tendremos que seleccionar el hilo «DEV ó development» y no el «STABLE» que hasta ahora sonaba como la mejor opción para todos aquellos que no queríamos emociones fuertes… Esto se hace con el comando:
$ git checkout dev
Este comando, lo damos justo después del git clone ya de sobra conocido.
En mi caso, tenía ya gpiod instalado, pero faltaban las librerías, por lo que salía el error al hacer el cmake. Si te pasa ésto, instala con el comando:
$ sudo apt-get install libgpiod-dev
Solo me resta indicar, qué es lo que pondremos en el fichero de configuración, para que todo ésto funcione correctamente.
Deberemos sustituir la línea donde indicamos por que pin sacamos el PTT, escribiendo lo siguiente:
PTT GPIOD gpiochip0 25
El ejemplo, es para usar la linea 25 del GPIO. Si tienes otra, pones lo que corresponda.
Con la línea de DCD, que es de salida también, ocurre exactamente lo mismo.
En éste momento, ya está publicado Direwolf v1.8-DEV que es la que usaremos. De todas formas, igual cuando leas todo ésto, ya se ha pasado al canal estable esta implementación de gpiod (suena lo más posible…), así que comprueba cual es la versión más reciente, trata de usarla, y si no funciona, haz lo que he detallado.
La mensajería en APRS (a través de la Red APRS-IS) es un asunto que requiere un conjunto de componentes configurados para que lleguen los mensajes a su destino.
La presente información toma como base un artículo de Lynn KJ4ERJ traduciéndolo y adaptándolo con información actual.
URL original: http://aprsisce.wikidot.com/doc:aprs-messaging-explained
Como sabrás, APRS utiliza tramas UI de Packet Radio (AX25) para funcionar. Son tramas sin conexión, sin orden entre ellas y sin garantizar que lleguen al destino. Básicamente en APRS una estación lanza una transmisión al aire y no tiene la certeza de que sea recibida por otra estación. Esto es correcto para un sistema de balizas, pero no es bueno para utilizarlo como mensajería. APRS utiliza unas «vías (path)» similares a las que usábamos en Packet Radio, pero puede contener alias para saber los indicativos de los digipeaters por los que ha pasado.
Bien. Un mensaje APRS se manda como una trama sin identificar (UI) pero el destinatario del mensaje, no está en la cabecera de AX.25, sino en los datos que le siguen, delimitado por el símbolo de dos puntos «:» (por ejemplo :EB2DJB-7:). Se pueden mandar solicitando una confirmación de recepción o no. Si se pide confirmación (ACK) el emisor del mensaje, pondrá «{xxxxx» al final del mensaje de texto. La confirmación será otra trama diferente enviada por el destinatario del mensaje dirigido al emisor del mensaje con el texto «ackxxxxx».
SIMPLEX en Radio… 144.800 Mhz.
El escenario mas sencillo, son dos estaciones que se escuchan entre si en radio: la estación emisora lanza el mensaje APRS. El receptor tiene que escuchar la trama, decodificarla correctamente en algún tipo de TNC (AX.25 lleva checksum para verificar que el contenido es correcto), y opcionalmente crear un mensaje de confirmación «ack» que enviar al remitente por radio RF, que éste tendrá que recibir, decodificar correctamente y casarla con el mensaje original, para así mostrar al remitente, que su mensaje ha sido recibido. El cliente APRS incorporará un número de reintentos hasta que escuche el ack. …y ¡¡éste es el caso mas sencilo!!…
A través de APRS-IS (el lado Internet del APRS)
No hay un servidor central APRS como algunos piensan. APRS-IS es una red de servidores donde las tramas APRS fluyen entre ellos en tiempo real y sin que éstos almacenen la información. Sitios como aprs.fi ó findu.com no son parte de APRS-IS, solo monitorizan el tráfico que circula entre los servidores APRS-IS, la almacenan en una base de datos y la muestran a los usuarios.
Para poder enviar información a un servidor APRS-IS es obligatorio configurar un PASSCODE que es diferente según el indicativo. Si tienes puesto -1 o uno que no sea el tuyo, el servidor rechazará todas las tramas que mande el iGate. Y esto, también afecta a la mensajería.
Por lo tanto, enviar un mensaje APRS desde una estación conectada a un APRS-IS a otra estación conectada a otro servidor APRS-IS es como la situación en simplex descrita arriba, pero sin necesitar TNC y evitando la repetición por haber recibido un checksum erroneo. Así que el servidor APRS-IS únicamente entrega «buenas» tramas. Además, el receptor del mensaje, tiene que estar conectado. Aún no hay la posibilidad de almacenamiento en la Red de APRS.
¿Como funciona en sentido RF -> IS? ¿Qué es un iGate? ¿Cómo influye en la mensajería?
Un iGate es una estación de APRS con equipo de radio (RF) que escucha las tramas en radio (144.800 Mhz), las decodifica, valida su checksum y las inyecta a un servidor APRS-IS para su difusión.
La red de servidores, dispone de un sistema para detectar información duplicada (una trama que haya llegado a dos iGates diferentes) y en el caso de los mensajes, ocurre lo mismo… por lo tanto todos los mensajes están presentes en la red, siempre que lo haya escuchado al menos un iGate. Ésta es la parte receptora de un iGate, y en la mayor parte de los casos funciona correctamente.
La otra parte, es la pasarela del servidor de Internet a Radio (IS -> RF). Cualquier información (no solo los mensajes) puede configurarse para que salga en radio en un iGate determinado. Pero ten en cuenta, que el servidor APRS-IS es mucho más rápido que una conexión AX.25 a 1200 baudios, por lo tanto, no va a poder salir toda (aparte que tampoco es el objetivo), así que no todos los mensajes salen a Radio.
El iGate, mira que estaciones han sido escuchadas en Radio, mantiene una lista (habitualmente, los últimos 30 minutos), y únicamente los mensajes escuchados en un servidor APRS-IS cuyo destinatario esté en la lista, serán pasados al puerto de Radio.
Así que para que una estación APRS-IS envíe un mensaje a otra estación en Radio, el software cliente APRS crea el mensaje y lo inyecta al servidor APRS-IS. Este mensaje se difunde a todos los servidores APRS-IS, y los iGates conectados comprobarán a ver si va dirigido a una estación que ha escuchado recientemente, caso en el que emitirá la trama en Radio. Si son varios los iGates que le han escuchado, saldrá por todos ellos. Bueno, concretamente, no todos los iGates sino aquellos que hayan sido configurados para pasar mensajes de Internet a RF.
Una vez que el mensaje está en Radio, la estación receptora tiene que escuchar la trama, decodificarla, validar el checksum y devolver un ACK si lo ha pedido el remitente. Esta parte, es idéntica al caso RF Simplex descrito anteriormente, pero en este caso el ACK tiene que escucharlo un iGate (puede ser cualquiera, no necesariamente el que ha emitido el mensaje), decodificarlo, validar e inyectar la trama de nuevo en la Red APRS-IS para que la estación emisora lo reciba y pare de repetir el mensaje.
Así que para el sentido APRS-IS -> RF, necesitamos al menos un iGate bidireccional que haya escuchado a la estación destino recientemente.
La secuencia completa
Imaginemos dos estaciones, una en Bilbao (origen) y otra Vitoria-Gasteiz (destino). No es escuchan en radio y no hay un digipeater que escuchen ambas. Por lo tanto, necesitaría el apoyo de la Red APRS-IS.
Sería así:
La estación origen crea el mensaje APRS para el destino.
Un iGate lo escucha, decodifica, verifica checksum y lo inyecta a un servidor APRS-IS
El mensaje llega a toda la Red de servidores, incluso al que está conectado el iGate de destino.
Con suerte, ese iGate ha escuchado recientemente una trama de la estación destino y éste iGate está configurado para pasar los mensajes de Internet a Radio.
El iGate transmite el mensaje en radio en destino
Con suerte, el receptor del mensaje lo escucha, lo decodifica, verifica checksum y lo visualiza al operador.
Como la mayor parte de las veces, se piden ACKs, la estación receptora crea el mensaje de confirmación ACK y lo envía por Radio.
Repetir el paso 2 en Vitoria-Gasteiz
Repetir el paso 3 en Bilbao
Repetir el paso 4 en Bilbao
Repertir el paso 5
Repetir el paso 6 pero no lo muestra al operador, solo marca el mesaje como recibido, y para de retransmitirlo.
Asi que ya ves que para que todo ésto funcione tiene que:
Haber iGates instalados
estar configurados correctamente (pasar mensajes de Internet a RF)
escuchar las tramas sin errores de checksum
Ahora, imagínate todo ese «paseo» para cada mensaje de una conversación por mensajería, y podrás valorar el milagro que los QSO’s por APRS representan.
Todo el mundo lo llama por el modelo, ya que el nombre es impronunciable. Llega el primer walky chino con APRS y Bluetooth integrado.
Mejor nos fijamos más en sus prestaciones… que en el nombre.
Lleva GPS, que se utiliza para que envíe las tramas APRS (solo dispone de módem a 1200 bps), y lo mejor, es que decodifica las transmisiones APRS.
Incluye, barómetros, altímetro (igual lo calcula por el GPS), Bluetooth compatible con Android y iPhone (datos y audio), se puede cargar la batería por conector micro-USB (¡¡Bien!!), batería de 2.500 mAh y las funciones clásicas de los walkies que traen APRS.
El precio en Aliexpress, sobre los 158 euros puesto en casa.
Ah! Y como no podía faltar… trae linterna en la parte inferior.
Faltan pocos días, para que nos juntemos en Ávila un año más, para que nos saludemos con decenas de Radioaficionados, y veamos miles. Sin duda es un punto de encuentro, que sirve para poner en valor nuestra afición, hacia nosotros y hacia la sociedad.
El domingo por la mañana, a las 11:00 en la Sala 2, hablaré de algo en lo que vengo pensando desde hace ya bastante tiempo.
El fondo de la cuestión, es retomar esa buena costumbre que teníamos los radioaficionados de hablar entre nosotros, cuando estamos conduciendo. Sigo pensando que es una herramienta valiosa que fomenta la unión entre nosotros, y quizás en algún momento, sirva para evitar algún que otro sustillo.
¿Hablo del canal 19 de Banda Ciudadana? Bueno, no estaría de más poder «darle leña»a esa forma sencilla y barata de comunicarnos. Pero lo que quiero poner encima de la mesa, es las posibilidades que tienen las emisoras actuales de Radioaficionados, a ayudar a que nos «encontremos» en las bandas de VHF y UHF.
Esto no es algo que yo, porque haya tenido una super-hiper-mega-idea pueda lograr hacer que funcione… sino que tiene que ser algo en el que nos involucremos todos.
Hablaré de SOSEUS, una pasarela que programé hace ya algunos años, y que está creando alertas, de todos aquellos avisos de tráfico que se emiten desde la dirección de tráfico del departamento de Seguridad del Gobierno Vasco… alertas que llegan en APRS hasta las emisoras que llevamos en los coches, y nos dicen esa incidencia, a que distancia respecto a nuestra posición actual, en que dirección y en que vía y punto kilométrico se ha producido.
Los Radioaficionados, tenemos que ser capaces de mejorar lo que ya hay y mostrarlo a la sociedad.
Tres pinceladas, y una propuesta… Domingo a las 11:00 en Iberradio.
Ayer sucedió el milagro. No se explicar el cómo, porque me pilló al volante y no me lo esperaba.
De un tiempo a ésta parte, tengo en mente tratar de fomentar el uso de APRS en local (sin digis) para anunciar la frecuencia en la que estamos a la escucha, y así poder hablar (sí… he dicho hablar…) en simplex con otros colegas próximos en la zona. Es algo que hace años, y sobre todo en la banda de CB-27 se hacía, que se ha perdido ya el hábito ya no solo de hablar, sino de (incluso) llevar una emisora en el coche.
El caso es que estaba saliendo de viaje por Cantabria, y escuché que me llamaba un colega EB1I?? (no recuerdo su indicativo).
Al momento pensé ¡Ha tenido que saber que estoy QRV aquí, por las balizas de APRS que estoy tirando… y así me lo hizo saber en el primer cambio.
Estaba a escasos Kms. me vió y decidió llamarme. Charlamos poco, lo típico de «donde estás», a donde voy, y terminamos con un «ya hablaremos cualquier día de éstos».
Tras el breve comunicado, me quedé pensando… ¡Esta es exactamente la situación que me gustaría fomentar!.
Estoy desarrollando el plan, y si los organizadores de Iberradio lo tienen a bien, lo contaré en el encuentro de Septiembre.
Lo que voy a contar no es nuevo. Data del 2006, así que al ritmo que van los cambios, se puede hasta considerar que es «viejo». Pero como supone un cambio, respecto a lo que se contaba cuando se creó el APRS, quiero traerlo aquí, de una manera clara y concisa.
Voy a hablar del Paradigma N-N, que es la especificación que se recomienda utilizar desde hace 13 años, y que la mayoría cumplen… aunque hay otros que no.
El APRS, lo inventó Bob WB4APR en 1982. La primera transmisión fue en 1984 y el objetivo era seguir las posiciones de los participantes en una carrera de caballos, utilizando AX25, un protocolo que comenzaba a utilizarse masivamente en aquella década y que se llamó popularmente Packet Radio.
La diferencia fundamental frente al Packet Radio, es que no utiliza un «modo conectado» es decir, que para transmitir info, no requiere de una conexión previa. Dicho de otro modo, en APRS se lanzan balizas, sin un destinatario concreto.
En aquel momento, solo existía el «modo radio», internet estaba naciendo, y para que las balizas tuviesen un poco de visibilidad, había que instalar repetidores de aprs en los montes (digipeaters) y Bob desarrolló un sistema para controlar cuantos «saltos» daban las informaciones que enviábamos.
Por lo tanto, era normal, trabajar incluso a 7 saltos. Así se consiguió un sistema fiable, basado 100 % en la frecuencia de APRS 144.800 Mhz.
Con la expansión de Internet, se le dió «la vuelta» a todo ésto, y con la llegada de los servidores de APRS en Internet (denominados APRS-IS) y de los necesarios «IGates» (que son las pasarelas entre radio y los APRS-IS) se buscaba recortar al máximo los saltos que daban nuestras tramas, ya que entonces, el objetivo era que nos escuchara un Igate… y listo. Así, se liberaba notablemente el uso de la frecuencia 144.800, en favor de «mas huecos» para que las estaciones móviles pudiesen transmitir su posición.
La especificación de ésta nueva forma de usar el APRS, se denominó «Paradigma n-N» y es el que hoy en día se mantiene.
No me voy a meter de lleno en él, porque mi objetivo es dar cuatro pinceladas que se os queden grabadas, ya que me parece fundamental.
Lo primero, es que las estaciones fijas, lancen su baliza (en radio) cada 30 minutos como poco. No tiene ningún sentido que una estación que no se mueve, esté cada 5 minutos diciendo donde está. Lo mismo es aplicable a objetos fijos que se creen desde éstas estaciones.
El punto que hace referencia a limitar la expansión vía Radio de nuestras balizas (en móvil) va relacionado con el nombre del paradigma. Y dice, que como máximo se utilice el WIDE2-2 en la difusión. Esa configuración, haría que nuestra baliza daría 3 saltos como mucho, y se vería repetida en el primer digi como WIDE2-2, en el segundo como WIDE2-1 y el en tercero como WIDE2 (o lo que es lo mismo WIDE2-0 ). Hay muchos que hoy en día salen con WIDE2-1 por lo que tendría una difusión máxima de 2 saltos.
Teniendo en cuenta, que la mayoría de digipeaters a día de hoy, son igates también, casi casi es como para decir que con un salto es suficiente.
En mi caso, las balizas que emito en móvil, salen con un WIDE1-1 que es un término con un significado especial, y es que si lo incluimos en el path, le decimos al digi que incluya su indicativo en la lista del path, por lo que así podemos saber viendo la trama en cualquier punto, por que digis ha viajado.
Para mí, con un salto, es suficiente, ya que si el digi que me escucha no es pasarela a Internet, al repetirlo éste, le escucharía otra estacion que sea pasarela y… misión cumplida. Mínima ocupación de canal, máxima eficacia
Repito que el objetivo es ocupar lo menos posible el canal Radio. Es importante saber, que hay algunos trackers de APRS, que no tienen receptor, así que no saben si 144.800 Mhz está libre u ocupado por lo que si la mayor parte del tiempo, la frecuencia está en silencio, tendrán una mayor probabilidad de éxito al transmitir sus balizas. Otros, no tienen receptor pero sí que pueden saber si está el canal ocupado, con un sistema muy básico de detección de portadora.
Y hasta aquí llega. No voy a ahondar más, ya que quiero fijar esas dos ideas, que no son nada nuevas, pero seguro que más de uno es la primera vez que lo leen.
Se llama FalconSAT-3, es un satélite tipo PACSAT y porta un digipeater de APRS y una BBS que utilizan AX-25 a 9.600 bps.
¿Hay alguien que aún no ha escuchado alguna vez a la Estación Espacial Internacional en APRS? ¡Pues no es la única!
Resulta bastante sencillo de poder escuchar, e incluso utilizarlo. Con un equipo (walky o emisora) bibanda que disponga de TNC a 9600 (como el Kenwood TM-D710) únicamente tendrás que sintonizar su frecuencia, y esperar un pase.
Pero si tienes un SDR, podrás escucharlo
Para saber cuando hay pases, puedes utilizas, por ejemplo, la web «heavens above»
Durante 10 años, éste satélite fue utilizado por la aviación del ejército norteamericano para diversos experimentos y desde 2017, está abierto para Radioaficionados. Por lo tanto, lleva 12 años en órbita.
Recepción de FalconSat-3 con SDR#
Tip: Envía un mensaje en APRS a: SAT30776 y recibirás una respuesta con la hora del próximo pase desde tu QTH. Así de fácil.
