RASPBERRY PI para APRS Como muchos sabran, se han puesto muy de moda estas diminutas plaquetas que terminan siendo una microcomputadora. Las mismas tienen la capacidad de correr varias versiones de Linux y bajo el, podemos correr programas que nos permitan configuar IGATES ,DIGIPEATERS y TRACKERS de APRS, que es lo que nos interesa. En este sencillo tutorial voy a tratar de explicarles mi humilde experiencia personal al respecto, ya que toda la bibliografía que hay , esta en Ingles y muchos no logran interpretarla correctamente. Basicamente se debe entender que al estar diseñadas para correr en Linux, tenemos que estar familiarizados con los entornos bajo “línea de comandos” mas que los graficos. Cualquiera que haya jugado un poco con el viejo MS-DOS de Windows, se podrá adaptar fácilmente. Todos los que nacieron desde Windows 95 en adelante, talvez se les torne un poco cuesta arriba. Lo primero que hay que hacer es bajar una “imagen” de la versión de Linux que hagamos correr en nuestra Raspberry desde los mismos servidores de su fabricante (https://www.raspberrypi.org/downloads/) y copiarla dentro de una memoria SD ( para la versión B) o micro SD (versión B+).El tamaño de las mismas deben ser de POR LO MENOS 8Gb.La versión recomendada y que utiliza la mayoría es RASPBIAN. Copiar una imagen BOOTEABLE no es lo mismo que copiar cualquier archivo. Por lo tanto hay que utilizar un programa especial para hacerlo. El mismo se llama WIN32Diskimager. En el hay que seleccionar el archivo des-zipeado que descargamos del vinculo anterior (.img) y elegir el dispositivo extraíble (SD o micro SD) que vayamos a utilizar, luego de esto hay que darle al botón WRITE: Dependiendo de la velocidad del puerto USB que usen para llegar a la memoria SD, es lo que demorara en copiarse (entre 15 minutos y una hora). Una vez que tenemos la imagen RASPBIAN, en nuestra tarjeta de memoria, la insertamos en su bahía de la Raspberry PI y le damos alimentación para que arranque. Lo que muchos se preguntaran es…como veo el arranque?... Bueno, la Raspberry viene preparada para conectarla a un Teclado y Mouse USB y a cualquier monitor que tenga entrada HDMI. La pantalla de booteo es mas o menos asi… Una vez que termina el booteo, debería arrancar el entorno grafico de manera automática Si les aparece esto, significa que el RASPBIAN se instalo correctamente y la memoria bootea bien. Ahora deben apagarla , desconectandole la alimentación directamente y agregarle una conexión de red a internet via Ethernet (a travez del conector RJ45 que trae la placa). Raspbian trae DHCP activado por defecto, por lo que al arrancar la placa de vuelta, vuestro router debería haberle asignado una IP de LAN local y tener conexión a internet. Para probar si tenemos conexión a internet, abrimos el programa “LXterminal” (como el CMD de Windows) y tiramos el siguiente comando: Sudo apt-get update Este comando realiza un update del RASPBIAN que instalamos previamente, siempre y cuando la conexión a internet funcione. Luego de finalizado el primero hay que correr el siguiente comando : Sudo apt-get upgrade Este ultimo realiza un upgrade total de la Raspberry y es lo que necesitamos para que después corra bien todo lo que vamos agregar sobre APRS. Vale aclarar que Raspbian viene con un usuario por defecto que se llama PI y su password RASPBERRY (en minúsculas) y una vez que estamos en el ,tenemos que activar el usuario ROOT asignándole un password: Sudo passwd root Cuando les pida un password, le ponen el que quieran y a partir de ese momento entraran como root, con el password que le pusieron. Los passwords de “pi” y “root” se pueden cambiar en cualquier momento solo corriendo “passwd” en LXterminal. Es importante tener el usuario root activo, ya que mas adelante verán que es el único que nos permitirá realizar ciertos cambios fundamentales para que funcionen los programas de APRS. A partir de este momento, ya estaríamos en condiciones de activar el servicio RDP (Remote desktop protocol) para poder gestionar nuestra Raspberry desde cualquier PC con Windows usando el viejo y conocido “ESCRITORIO REMOTO”.Esto nos permitirá liberarnos del teclado , mouse y monitor conectados directamente al Pi. Para esto debemos correr el siguiente comando en la raspberry: Sudo apt-get install xrdp Una vez finalizada la instalación de damos “reboot”.Cuando la raspberry haya inicializado nuevamente, vamos a nuestro router de red local (LAN) y buscamos en su tabla DHCP , que ip le asigno en la misma (por ejemplo 192.168.1.5) y esta es la ip que vamos a cargar en el escritorio remoto de Windows para entrar…si todo esta bien , nos debería aparecer la siguiente ventana: En la ventana de logueo podemos usar cualquiera de los usuarios que tenemos “pi” o “root” con su correspondiente password. Ahora ya estamos gestionando nuestra Raspberry desde una PC con Windows y por lo tanto podemos sacar todos los periféricos para estar mas comodos. Con alimentación y cable de red, alcanzara para llegar a ella. Hasta aquí, vimos como dejar la raspberry completamente funcional, ahora viene lo que mas nos interesa y esto es, como correr programas de APRS en ella. Existen 2 programas…uno se llama XASTIR y corre bajo entorno grafico (es un emulo de UIVIEW32), se le pueden cargar mapas georeferenciados o que directamente los baje de internet de manera online (esto lo hace mucho mas lento).El segundo se lo conoce como APRX. Este solo corre bajo línea de comandos, pero es mucho mas rápido que el primero (Ideal para Igates y Digipeaters). Antes de utilizar cualquiera de los 2, debemos elegir si vamos a trabajar directamente con audio y un emulador tipo AGWPE o si utilizaremos un TNC de verdad (con un modem incorporado) . SOUNDMODEM: Si vamos a trabajar por audio, hay que tener en cuenta que las Raspberry NO TRAEN entradas (LINE-IN o MIC). Por lo cual les recomiendo se consigan un adaptador de audio USB que les permitirá suplir este faltante. El que les recomiendo y se que Linux reconoce automáticamente es este: Se consigue en Mercadolibre aqui en Argentina fácilmente a un costo de $50 aprox.- Si decidieran trabajar por audio con el adaptador que les mostre antes, van a tener que instalar el SOUNDMODEM en versión Linux. el mismo lo descargan de la siguiente forma: Sudo apt-get install soundmodem Una vez instalado se lo configura corriendo el comando: Sudo apt-get install alsamixergui Este ultimo es el driver para manejar nuestro adaptador de audio USB. Ahora corremos el siguiente comando que nos permitirá configurar el SOUNDMODEM para emular un TNC por audio: Soundmodemconfig Se les abrirá la siguente ventana grafica, donde tendrán que ir completando todos los casilleros de la forma que les muestro a continuación: Si todo lo anterior quedo bien configurado, corremos el comando: Soundmodem & Y en nuestra ventana de LXterminal nos aparecerá esto: Si algo quedo mal, nos avisara con un mensaje de error: Recordar que para todas estas configuraciónes hay que estar logueado como ROOT. Ahora solo quedaría instalar los paquetes de X25 en nuestra PI con estos comandos: Sudo apt-get install ax25-tools Sudo apt-get install ax25-apps Con esto ya tendríamos todo listo para instalar XASTIR o APRX, pero previamente vamos a ver la opción con TNC completo. TNC PI (TNC-X): Si en cambio, nos decidimos por utilizar el TNC Pi (http://tnc-x.com/TNCPi.htm) : Deberan insertarlo en el bus GPIO de la Raspberry y editar los archivos de configuración para AX25 de la siguiente forma: En el directorio /etc/ax25/ habrá un archivo que se llama axports. Se lo edita como un archivo de texto con el programa Leftpad y se agregan dos líneas: 1 LU1XXX-1 19200 236 2 TNC 1 2 LU1XXX-2 19200 236 2 TNC 2 En el campo “LU” va la distintiva que quieran utilizar. Los 19200 es la velocidad en baudios que soporta el TNC-Pi. Los valores 236 y 2 son de paclen y maxframe respectivamente. Es importante no dejar líneas en blanco en este archivo, antes de guardarlo. Paso siguiente hay que hacer el “attach” del protocolo AX25 sobre el puerto serial que trae la Raspberry en su bus GPIO de la siguiente forma: sudo kissattach /dev/ttyAMA0 1 10.1.1.1 Con esto quedaría preparado el TNC-Pi, para comunicarse con la Raspberry. INSTALANDO Y CONFIGURANDO XASTIR: Sea que hayan elegido el Soundmodem o el TNC-Pi, ahora falta un programa que los utilice. Empezamos por el Xastir con entorno grafico.Primero de todo habrá que instalarlo con: Sudo apt-get install xastir Luego de un rato que dura la instalación ya podemos arrancarlo desde el entorno grafico o simplemente llamarlo des una ventana de terminal con el comando: Xastir & Si arranca bien les presentara la siguiente pantalla: Para configurarlo con nuestra señal distintiva deben acceder a: File ? Configure? Station Les abrirá esta ventana: Aquí ponen la señal distintiva + SSID , Latitud, Longitud , icono de la estación , datos de la misma y comentario. Luego vamos a la parte de temporización en: File? Configure? Timing Donde les aparece esta otra pantalla: Aquí lo mas importante es el “Posit TX Interval” que es cada cuantos minutos emitirán vuestra baliza tanto por internet como por RF (si tienen el TNC-Pi). Ahora llega la parte de configurar las interfaces entrando en: De esta pantalla lo mas importante es el TNC PORT. Para este ejemplo lo vemos configurado para el SOUNDMODEM por eso dice /dev/soundmodem0. Si en cambio utilizaramos el TNC Pi, allí iria /dev/ttyAMA0. Ahora agregamos el servidor de internet al que nos conectaremos junto con el PASSCODE en: Interface ? Interface control ? add ? Internet Server Si quieren cargar mapas deberan entrar en: MAPS Y elegir mapas ONLINE (de internet) u OFFLINE (los que tengan georeferenciados en la memoria SD). Una vez hecho todo estos, le dan un reboot a la raspberry y cuando vuelve arrancar, levantan nuevamente XASTIR. Si tienen conectado un equipo de radio tanto sea por audio directamente a travez del adaptador USB o con el TNC-Pi, tendrían que empezar a ver el trafico en la ventana View – Incoming data Alli podrán ver los datos via RF solamente, via Internet solamente o ambos. Tambien pueden ver Boletines y mensjaerias en : View – Bulletins o View – Message traffic Si el mapa esta centrado y con el zoom adecuado, deberian ir apareciendo los iconos de las estaciones que se escuchen via RF o por internet, hasta llenar toda la pantalla. (similar a un Uiview32). Por ultimo cabe la posibilidad de agregar un GPS externo y utilizar el XASTIR como TRACKER. Yo no he explorado esta posibilidad pero les paso como se haría. Deben volver a entrar en: Interface ? Interface control ? add ? Serial GPS Como verán en este ejemplo, utiliza el /dev/ttyAMA0, pero esto no podría ser porque ya lo estamos utilizando para el TNC-Pi. Por lo tanto debemos conseguir un adaptador SERIAL –USB como este: Luego solo habría que reemplazar en STAND ALONE GPS PORT, el /dev/ttyAMA0 por /dev/ttyUSB0. El resto se deja como aparece en la captura. INSTALANDO Y CONFIGURANDO APRX: El APRX es un programa que no tiene entorno grafico, por lo cual solo sirve como IGATE o DIGIPEATER. Como este programa es muy especifico, no se puede descargar de los repositorios de Raspberry.org, por lo cual no podemos usar el comando APT-GET. Hay que descargar el programa de la pagina de su autor y luego moverlo al directorio TMP, para luego darle install. h??????://h????.??????????????.??????/??h2??????/????????/ $cd /tmp $wget http://ham.zmailer.org/oh2mqk/aprx/aprx-2.07.svn593.tar.gz $tar -xvzf aprx-2.07.svn593.tar.gz $cd aprx-2.07.svn593 $./configure $make clean && make && make install $mkdir –p /var/log/aprx Una vez instalado tienen que ir a /etc y editar el archivo “aprx.conf” con el Leftpad y dentro de el, se realizan todos los ajustes. Les paso uno y verán que el mismo archivo, les va dando ejemplos y explicando (esta en ingles pero se entiende) lo que tienen que cargar para cada función (Igate o Digi) y para que se conecte a Internet. Una vez que terminan de configurar este archivo, para lanzarlo desde una terminal (LXterminal) deben escribir $aprx –ddv La opción DDV, les va permitir hacer un debug y ver si hay algún error.Sino con poner APRX &, el programa quedara corriendo en batch, aunque cierren la ventana de terminal. APRX.CONF # # Simple sample configuration file for the APRX-2 -- an APRS iGate and Digipeater # # This configuration is structured with Apache HTTPD style tags # which then contain subsystem parameters. # # # For simple case, you need to adjust 4 things: # - Mycall parameter # - Select correct type of interface (ax25-device or serial-device) # - Optionally set a beacon telling where this system is # - Optionally enable digipeater with or without tx-igate # # # # Define the parameters in following order: # 1) ** zero or one # 2) ** zero or one # 3) ** there can be multiple! # 4) ** zero to many # 5) ** zero to many # 6) ** zero to many (at most one for each Tx) # # # Global macro for simplified callsign definition: # Usable for 99+% of cases. # mycall KI6ZHD # The aprsis login parameter: # Station callsignSSID used for relaying APRS frames into APRS-IS. # Use this only to define other callsign for APRS\-IS login. # #login OTHERCALL-7 # login defaults to $mycall # APRS-IS server name and optional portnumber. # # WARNING: Do not change from default port number [14580] # unless you are absolutely certain you want # something else, and you allow that something # else also affect your tx-igate behaviour! # #server rotate.aprs2.net #server euro.aprs2.net #server asia.aprs2.net server noam.aprs2.net #server soam.aprs2.net #server aunz.aprs2.net # Some APRS-IS servers tell every about 20 seconds to all contact # ports that they are there and alive. Others are just silent. # Default value is 3*"heartbeat" + some --> 120 (seconds) # #heartbeat-timeout 0 # Disabler of heartbeat timeout # APRS-IS server may support some filter commands. # See: http://www.aprs-is.net/javAPRSFilter.aspx # # You can define the filter as single long quoted string, or as # many short segments with explaining comments following them. # # Usability of these filters for a Tx-iGate is dubious, but # they exist in case you for example want to Tx-iGate packets # from some source callsigns in all cases even when they are # not in your local area. # #filter "possibly multiple filter specs in quotes" # #filter "m/100" # My-Range filter: positions within 100 km from my location #filter "f/OH2XYZ-3/50" # Friend-Range filter: 50 km of friend's last beacon position # pidfile is UNIX way to tell that others that this program is # running with given process-id number. This has compiled-in # default value of: pidfile /var/run/aprx.pid # pidfile /var/run/aprx.pid # rflog defines a rotatable file into which all RF-received packets # are logged. The host system can rotate it at any time without # need to signal the aprx that the file has been moved. # rflog /var/log/aprx/aprx-rf.log # aprxlog defines a rotatable file into which most important # events on APRS-IS connection are logged, namely connects and # disconnects. The host system can rotate it at any time without # need to signal the aprx that the file has been moved. # aprxlog /var/log/aprx/aprx.log # dprslog defines a rotatable file into which most important # events on DPRS receiver gateways are logged. # The host system can rotate it at any time without need to # signal the aprx that the file has been moved. # #dprslog /var/log/aprx/dprs.log # erlangfile defines a mmap():able binary file, which stores # running sums of interfaces upon which the channel erlang # estimator runs, and collects data. # Depending on the system, it may be running on a filesystem # that actually retains data over reboots, or it may not. # With this backing store, the system does not loose cumulating # erlang data over the current period, if the restart is quick, # and does not stradle any exact minute. # (Do restarts at 15 seconds over an even minute..) # This file is around 0.7 MB per each interface talking APRS. # If this file is not defined and it can not be created, # internal non-persistent in-memory storage will be used. # # Built-in default value is: /var/run/aprx.state # #erlangfile /var/run/aprx.state # *********** Multiple definitions can follow ********* # ax25-device Lists AX.25 ports by their callsigns that in Linux # systems receive APRS packets. If none are defined, # or the system is not Linux, the AX.25 network receiver # is not enabled. Used technologies need at least # Linux kernel 2.4.x # # tx-ok Boolean telling if this device is able to transmit. # # ax25-device $mycall ax25-device $mycall #tx-ok false # transmitter enable defaults to false tx-ok true alias KI6ZHD-5,SCLARA # # The TNC serial options. Parameters are: # - /dev/ttyUSB1 -- tty device # - 19200 -- baud rate, supported ones are: # 1200, 2400, 4800, 9600, 19200, 38400 # - 8n1 -- 8-bits, no parity, one stop-bit, # no other supported modes # - "KISS" - plain basic KISS mode # - "XORSUM" alias "BPQCRC" - KISS with BPQ "CRC" byte # - "SMACK" alias "CRC16" - KISS with real CRC # - "FLEXNET" - KISS with real CRC # - "TNC2" - TNC2 monitor format # - "DPRS" - DPRS (RX) GW # # # serial-device /dev/ttyUSB0 19200 8n1 KISS # #callsign $mycall # callsign defaults to $mycall # #tx-ok false # transmitter enable defaults to false # # # serial-device /dev/ttyUSB1 19200 8n1 TNC2 # #callsign $mycall # callsign defaults to $mycall # #tx-ok false # TNC2 monitor can not have transmitter # # # serial-device /dev/ttyUSB1 19200 8n1 DPRS # callsign dprsgwcallsign # must define actual callsign # #tx-ok false # DPRS monitor can not do transmit # # *********** Multiple definitions can follow ********* # # Beacons are sent out to radio transmitters AND/OR APRSIS. # Default if "both", other modes are settable. # #beaconmode { aprsis | both | radio } beaconmode aprsis # # Beacons are sent from a circullar transmission queue, total cycle time # of that queue is 20 minutes by default, and beacons are "evenly" # distributed along it. Actual intervals are randomized to be anything # in between 80% and 100% of the cycle-size / number-of-beacons. # First beacon is sent out 30 seconds after system start. # Tune the cycle-size to be suitable to your number of defined beacons. # cycle-size 30m # # Basic beaconed thing is positional message of type "!": # #beacon symbol "R&" lat "0000.00N" lon "00000.00E" comment "Rx-only iGate" # 121 59.98 is the front lawn # 122 00.00 is at the rear round table #beacon object "Packet N" symbol "/n" lat "3720.62N" lon "12159.98W" comment "145.050 full service AX.25 Packet digi/pbbs/node" #beacon object "PAARA FD" symbol "/;" lat "3729.69N" lon "12210.22W" comment "Drive up talk in - N6NFI 145.230- pl:100.0" beacon object "KI6ZHD-1" symbol "/n" lat "3720.61N" lon "12159.99W" comment "145.050 full service packet digi/pbbs/node" # #Following are basic options: # 'symbol' no default, must be defined! # 'lat' coordinate latitude: ddmm.mmN (no default!) # 'lon' coordinate longitude: dddmm.mmE (no default!) # 'comment' optional tail part of the item, default is nothing # # Sample symbols: # R& is for "Rx-only iGate" # I& is for "Tx-iGate" # /# is for "Digipeater" # I# is for "Tx-iGate + Digipeater"" # #Additional options are: # 'srccall' parameter sets claimed origination address. # 'dstcall' sets destination address, default "APRXnn" # 'interface' parameter picks an interface (must be "tx-ok true" type) # 'via' sets radio distribution pattern, default: none. # 'timefix' On APRS messages with HMS timestamp (hour:min:sec), the # system fixes appropriate field with transmit time timestamp. # # Message type is by default '!', which is positional no timestamp format. # Other possible formats are definable with options: # 'type' Single character setting type: ! = / @, default: ! # 'item' Defines a name of Item (')') type beacons. # 'object' Defines a name of Object (';') type beacons. # # 'file' option tells a file at which a _raw_ APRS message content is # expected to be found as first line of text. Line ending newline # is removed, and no escapes are supported. The timefix is # available, though probably should not be used. # No \-processing is done on read text line. # # The parameter sets can vary: # a) 'srccall nnn-n dstcall "string" symbol "R&" lat "ddmm.mmN" lon "dddmm.mmE" [comment "any text"] # b) 'srccall nnn-n dstcall "string" raw "string"' # # The a) form flags on some of possible syntax errors in parameters. # It will also create only "!" type messages. The dest parameter # defaults to "APRS", but can be used to give other destinations. # The via parameter can be used to add other keywords, like "NOGATE". # # Writing correct RAW format beacon message is very hard, # which is evidenced by the frequency of bad syntax texts # people so often put there... If you can not be persuaded # not to do it, then at least VERIFY the beacon result on # web service like findu.com, or aprs.fi # # Do remember that the \ -character has special treatment in the # Aprx configuration parser. If you want a '\' on APRS content, # then you encode it on configuration file as: '\\' # # Stranger combinations with explicite "transmit this to interface X": # #beacon file /tmp/wxbeacon.txt #beacon interface N0CALL-3 srccall N0CALL-3 \ # raw "!0000.00NR00000.00E&Rx-only iGate" #beacon interface N0CALL-3 srccall N0CALL-3 \ # raw "!0000.00NI00000.00E&Tx-iGate" #beacon interface $mycall symbol "R&" lat "0000.00N" lon "00000.00E" \ # comment "Rx-only iGate" #beacon interface $mycall symbol "I&" lat "0000.00N" lon "00000.00E" \ # comment "Tx-iGate" # # *********** definition(s) follow ********* # # The system will always send telemetry for all of its interfaces # to APRSIS, but there is an option to define telemetry to be sent # to radio channel by using following sections for each transmitter # that is wanted to send out the telemetry. # # transmitter - callsign referring to # via - optional via-path, only 1 callsign! # source - one or more of callsigns for which # the telemetry transmission is wanted for # # # transmitter $mycall # via TRACE1-1 # source $mycall # # *********** definition(s) follow ********* # # The digipeater definitions tell transmitters that receive # AX.25 packets from possibly multiple sources, and then what # to do on the AX.25 headers of those messages. # # There is one transmitter per digipeater -- and inversely, there # can be at most one digipeater for each transmitter. # # In each digipeater there is at least one , usually same # as the transmitter. You may use same on multiple # s. Using multiple instances of same on # a single does not crash the system, but it can cause # packet duplication in case of non-APRS protocols (like AX.25 CONS) # # Use only at most two levels of viscous-delay in your . # Immediate sending is by "0", and a delayed sending is any value # from 1 to 9. This system does not correctly support other than # immediate sending and one level of delay. # # Note: In order to igate correct when multiple receivers and # transmitters are used on single channel, the # definitions of each radio port must have associated # "igate-group N" parameter which has N of value 1 to 3. # See the aprx-manual.pdf for details. # (Default software compilation allows you to have up to # three channels of APRS operation.) # transmitter $mycall # #ratelimit 60 120 # default: average 60 packets/minute, # # # burst max 120 packets/minute # # # source $mycall # # #relay-type digipeated # default mode is "digipeated" # # viscous-delay 0 # no viscous delay for RF->RF digipeating # # ratelimit 60 120 # default: average 60 packets/minute, # # # burst max 120 packets/minute # ## filter a/la/lo/la/lo # service area filter # ## filter -b/CALL # always block these # # # # Diversity receiver which combines to the primary # # Tx/Rx transmitter. There can be as many of these # # as you can connect on this machine. source $mycall # # #relay-type digipeated # default mode is "digipeated" # # viscous-delay 0 # no viscous delay for RF->RF digipeating # # ratelimit 60 120 # default: average 60 packets/minute, # # # burst max 120 packets/minute # ## filter a/la/lo/la/lo # service area filter # ## filter -b/CALL # always block these # # # # APRSIS source adds a TX-IGATE behaviour # # source APRSIS # # relay-type third-party # Must define this for APRSIS source! # # viscous-delay 5 # Recommendation: 5 seconds delay to give # # # RF delivery time make itself known. # # ratelimit 60 120 # default: average 60 packets/minute, # # # burst max 120 packets/minute # ## filter a/la/lo/la/lo # service area filter # ## filter -b/CALL # always block these # # # # # # DPRS source adds a DPRS->APRS RF gate # # interface DPRS # # ratelimit 60 120 # default: average 60 packets/minute, # # # burst max 120 packets/minute # # relay-type third-party # Must define this for DPRS source! # # Todo lo que no este con el # adelante son comentarios y no van a correr en el programa. Las líneas de programa configurables son las que no tienen el # adelante. Tienen que guardar los cambios que hagan, antes de volver a correr APRX y listo. Eso es todo por ahora. espero que con estas paginas, les sea mas sencillo entrar en el mundo Raspberry Pi (en todas sus versiones) aplicado al APRS. 73’s y buenos paquetes de datos!!! LU8APD