A partir de la versión 1.84 de UI-View32, G4IDE incorpora un nuevo auxiliar que permite registrar historiales, logs y telemetría de forma independiente para estaciones preseleccionadas. Hasta ahora sólo disponíamos del registro de todo lo que acontecía en el canal durante un lapso determinado. Pero para analizar o, simplemente para curiosear "por donde anduvo alguien" esa habilidad nos lo pone fácil. Ejemplo: guardar los datos de una estación meteorológica durante un lapso de tiempo para luego analizar la evolución. De paso se han añadido nuevas posibilidades en la visualización de los log.

Por lo que respecta a tramas de telemetría, son contadísimas las estaciones que las facilitan. Es una de las habilidades poco aprovechadas del sistema. Ahora no solo es posible guardar ese tipo específico de tramas para analizarlas luego, p.e. con un programa especializado o "a mano". sino que que además UI-View32 las decodifica. Tales tramas tienen diversos formatos, el principal es el de datos que está compuesto por un número de secuencia (000 a 999 y vuelta a empezar), cinco valores analógicos (000-255) y 8 bits binarios. Ejemplo:

Aquí el número se secuencia es el 144 (generalmente en orden creciente), los valores analógicos 135, 096, 004, 038, 118, y los binarios: 00010011.

Para poder descifrar el sentido y verdadero valor de cada uno de esos datos la estación remitente nos tiene que facilitar las claves. Ello lo puede hacer automáticamente: el protocolo tiene previstos tres tipos más de tramas de telemetría:

Con UI-View es posible actualizar automáticamente etiquetas, ecuaciones, etc. así que las remita el corresponsal o bien hacerlo manualmente, siempre y cuando conozcamos su verdadero sentido y valor.

Según el protocolo los valores analógicos finales se determinan por la ecuación: Ax2(2=cuadrado) + Bx + C.

Para el ejemplo anterior supongamos que hemos recibido las correspondientes tramas para el cálculo automático o que conocemos previamente que el primer valor analógico (135) es la lectura en voltios de la tensión de una batería y que la ecuación es 0,0.1,0. Por tanto el valor final sería:0+135x0.1+0=13.5 voltios. Si el segundo valor analógico (096) representase el estado de carga de esa misma batería y la ecuación fuese 0,0.0392,0, el resultado final sería: 0+96x0.0392+0=3.763 amperios. Supongamos que el tercer valor es otra magnitud cuya ecuación es 0,2,50. El resultado sería 0+4x2+50=58.

En cuanto a los datos binarios aparte de etiquetarlos, también se puede predeterminar si el valor 0/1 es normal (no/si) o invertido (0=si, 1=no). Pueden albergar información de estados: abierto/cerrado, verdadero/falso (estado de puertas, alimentación red/batería, detección de presencia, etc.)

Algunos de los últimos satélites para radioaficionados ya están empleando ese protocolo para sus datos de telemetría, importantísimos para poder determinar el estado de "salud del pájaro" y tomar decisiones oportunas para alargar su vida.

En tierra también nos puede ser de gran utilidad: sobretodo en aquellos equipamientos tales como repetidores, digis, nodos, etc, ubicados en sitios remotos, especialmente si están alimentados por sistemas autónomos (paneles solares, aerogeneradores, etc.). O para aportar datos extra de una estación meteorológica que el protocolo básico no recoge. Eso por citar un par de ejemplos pero podríamos recibir información de temperaturas (interior, de los pasos de potencia, etc), potencia de salida, ROE,  señal recibida, desviación y un largo etcétera solo echándole un poco de imaginación y unos pocos componentes .

La telemetría es una de las habilidades menos explotadas del sistema APRS, a pesar de su indudable interés. ¿Será que hay demasiado "usuario" y poco "cacharrero"? Probablemente un inconveniente sea la falta de desarrollos (kits, TNC, etc). Que yo sepa solo Kantronics incorpora en alguna versión (KPC3+) capacidades para ello. Algo he leído (muy por encima) acerca de DigiNed. Pic-Encoder también puede usarse, pero hay que añadirle conversores A/D. Hay algunos desarrollos (alguno comercial) por ahí, pero son poco conocidos por estos lares. 

Ahora el desarrollo de Antoni Navarro, EA3CNO cubre un vacío. Por fin alguien desde EA deja de ser receptor "pasivo" de la modalidad para aportar unos circuitos de indudable interés. ¡Aprovechemos la ocasión!

Última modificación: 29/12/2002
Administrador: ea3dxr@amsat.org