Las radios FrSky obtienen los datos de telemetría mediante sensores colocados en el aeromodelo (avión, dron o similar) conectados a través de un sistema propio denominado SmartPort (SPort). Dichos sensores, de velocidad, altitud, voltaje, etc se conectan a un bus que termina en el receptor, quien recopila los datos, añade el de intensidad de señal (RSSI) y los manda a la emisora. Obviamente nuestro receptor tiene que ser compatible SPort.

Estos datos de telemetría, una vez en la emisora, tienen muchas utilidades. El de RSSI es probablemente el más conocido e importante, porque permite a las emisoras avisarnos de cuando la señal entra en zona crítica. Otros usos, más o menos peculiares, pasan por avisos de pérdida/ganancia de altura, distancia, modo de vuelo, etc. E incluso la de permitir tomar decisiones automáticas en base a los datos ofrecidos por la telemetría, como por ejemplo la vuelta a casa o el aterrizaje en caso de darse determinados factores, a veces cruzados.

En este artículo vamos a describir en detalle una capacidad de las controladoras de vuelo Pixhawk (y supongo que también versiones anteriores de APM) para integrarse en el bus Sport e inyectar una buena cantidad de datos propios, como son los de posición GPS, inclinaciones, velocidades, etc. Esta magnífica capacidad se vuelve especialmente interesante si además tratamos los datos enviados con un espectacular script programado en Lua al efecto: Yaapu FrSky Telemetry Script. Con Yaapu transformaremos nuestra radio FrSky en una auténtico cockpit.

La telemetría «Passthrough FrSky«

Telemetría Smartport con sensores conectados en BUS + Pixhawk inyectando paquetes propios en la red.

El protocolo Passthrough FrSky Telemetry Protocol es un protocolo opensource para el envío de datos de telemetría. Inyecta paquetes de 32 bits en el canal propio para la telemetría de FrSky: SmartPort. En teoría si nuestro receptor soporta SmartPort, soporta telemetría Passthrough.

La ventaja de estos paquetes de telemetría es que no están relacionados con el resto de sensores SmartPort, que deben ser descubiertos previamente y que siguen normas particulares de FrSky. Pixhawk también puede simular sensores individuales de telemetría SmartPort, pero en mi caso me ha dado muchos problemas al depender directamente de cambios en FrSky.

La telemetría passthrough es generada directamente por Pixhawk con los datos de sus sensores, elabora paquetes con información en bruto (raw, sin convertir a nada y sin tener que identificar sensor individual alguno) que inyecta junto al resto de mensajes de telemetría SmartPort de FrSky. Estos paquetes pasan desapercibidos para los algoritmos de FrSky, que los ignoran. Sin embargo pueden ser descodificados por nuestra emisora siempre que esté funcionando con OpenTx y ejecutando el script Yaapu, escrito en Lua.

Los paquetes de telemetría Passthrough FrSky viajan por el bus SmartPort, utilizando su infraestructura, pero pasando desapercibidos para el sistema de telemetría de FrSky. Cuando llegan a la emisora, pueden ser leídos por un script programado al efecto.

El script Yaapu, por su parte, puede optativamente emular sensores SmartPort individuales con la información recibida, lo cual nos facilita mucho las cosas a la hora de acceder a esta información desde otro script de Lua. La razón es que leer bits de paquetes en bruto no es tarea trivial, pero existe una sencilla función en Lua para leer sensores SmartPort que no distingue si son reales de si son una mera simulación.

Los paquetes de 32 bits llevan diferente tipo de información dependiendo de su ID. A modo de información son:

Data ID Description Unit Bits Comments
0800 GPS LATLNG (1Hz) Alternating transmission of latitude and longitude
Latitude degrees 32
Longitude degrees 32
5000 Text messages (sent 3x whenever a msg is in queue) 32 Sending 4 characters at a time
severity N/A 3 Severity on MSB of the last three bytes of the last chunk
text N/A 28
5001 AP STATUS (2Hz)
Flight mode N/A 5
Simple & supersimple N/A 2
Land_complete flag N/A 1
Armed flag N/A 1
Battery failsafe flag N/A 1
EKF failsafe N/A 2
5002 GPS STATUS (1Hz)
Num sats # of sats 4 Limit to 15 max
GPS fix N/A 2 NO_GPS = 0, NO_FIX = 1, GPS_OK_FIX_2D = 2, GPS_OK_FIX_3D >= 3
Horizontal dilution of precision 10^x 1
decimeters 7
Vertical dilution of precision 10^x 1
decimeters 7
Altitude MSL 10^x 2
decimeters 7
+/- 1
5003 BATT (1Hz)
Batt voltage deci Volts (Vx10) 9
Current draw 10^x 1
deci Amps (Ax10) 7
Total current draw since start-up mAh 15 limit to 32767 (0x7FFF) since value is stored on 15 bits
5004 HOME (2Hz)
Distance between home loc and copter 10^x 2
meters 10
Angle from front of vehicle to the direction of home 3 degrees 7
Altitude between home loc and copter 10^x 2
decimeters 10
+/- 1
5005 VELANDYAW (2Hz)
Vertical velocity 10^x 1
decimeters/s 7
+/- 1
Horizontal velocity 10^x 1
decimeters/s 7
Yaw .2 degrees 11
5006 ATTIANDRNG (Max Hz)
Roll .2 degrees 11
Pitch .2 degrees 10
Rangefinder distance 10^x 1
centimeters 10
5007 PARAMS (sent 3x each at init) N/A 8 Reserve first 8 bits for param ID
1. MAV_TYPE N/A 8
2. battery pack capacity mAh 24
3. reserve battery capacity to trigger failsafe mAh 24
4.low battery voltage to trigger failsafe centi Volts (Vx100) 24

Cable convertidor

Las características técnicas del protocolo serial SmartPort de FrSky lo hacen inicialmente incompatible con la señal de un puerto serial de Pixhawk. Por lo tanto resulta imposible conectar directamente la Pixhawk a nuestro bus SPort, hay que utilizar un cable convertidor que veremos más adelante.

La diferencias entre el protocolo serie de SPort y el de Pixhawk son:

Señal serial SmartPort FrSky Puerto Serial Pixhawk
VOLTAJE Señal a 3.3V Señal a 3.3V aunque tolera 5V.
RS232 / TTL Señal a 3.3V invertida (voltaje alto es 0 y bajo es 1). Sigue el protocolo RS232, aunque aparentemente sin voltajes negativos:

Logic     RS232       SPort
0         +15V         3.3V
1         -15V          0V

Señal a 3.3V sin invertir. Sigue el protocolo TTL.
VELOCIDAD 57.600 baudios 57.600 baudios, aunque configurable a varios tipos de velocidad.
CABLES Toda la información viaja por un solo cable Dispone de cables independientes para RX y para TX.

El convertidor RS232 a TTL

El MAX3232CSE

FrSky FUL-1


Aunque el voltaje de trabajo de ambos sistemas es el mismo, la señal serie de FrSky está invertida. Para invertir / des-invertir la señal necesitaremos un RS232 TTL level converter. El MAX3232CSE en concreto parece que funciona a la perfección aunque no lo he probado. FrSky vende su propio convertidor RS232 <-> TTL, el denominado FUL-1.

Podemos ver ambos en las imágenes superiores.

El diodo

FrSky SPC cable

La señal de SmartPort viaja sólo por un cable, por lo que es necesario juntar RX y TX. Para ello utilizaremos un diodo, que sólo permitirá que la señal vaya en un sentido y siempre y cuando en el cable no exista tensión de otra comunicación. FrSky también nos lo vende y lo llama SPC cable, aunque es simplemente un diodo soldado a una placa con el cable de regalo.

El montaje DIY

Tenemos 3 opciones para montar nuestro cable convertidor:

  1. El MAX3232CSE + diodo
  2. El FUL-1 + SPC de FrSky
  3. Adquiriendo una solución ya montada y completa.

Advierto que las probabilidades de éxito se incrementan conforme nos acercamos a la solución ya montada.

Solución MAX3232CSE + diodo

MAX3232CSE con diodo entre RX y TX. Ojo, retirar el VCC de la Pixhawk.

Esta solución la he probado, pero con modelos MAX3232 que probablemente no eran «CSE». No me ha funcionado. Importante reseñar que hay que retirar el cable VCC de la Pixhawk para no meter la tensión del Smartport dentro de la PX.

Solución FrSky: FUL-1 + SPC cable

FUL-1 + SPC cable

Esta es una de las soluciones propuestas por la web de Ardupilot. Es importante destacar que el cable convertidor está alimentado ÚNICAMENTE por el propio VCC del puerto de telemetría de la PX, no por el VCC del cable del SmartPort. Ambos cables están conectados y no conviene meter tensiones externas en la PX. A mí no me gusta esta solución.

En mi caso he optado justo por lo contrario: alimentar el conjunto con el VCC del SmartPort, y retirar el cable VCC del puerto de telemetría de la PX. De esta manera aligeramos el consumo de la PX. En mi caso, además, el sistema RADIO-TELEMETRÍA está alimentado independientemente a la controladora de vuelo, y conviene que siga siendo así, con circuitos independientes:

Solución cable ya montado

Cable telemetría «yaapu»

Lo venden en diferentes tiendas de Internet y responden a diversos diseños que en realidad es lo que ya hemos visto. De nuevo retirar el VCC de la Pixhawk.

Advertencia: peligro de fundir el MAX3232

Una de las unidades montadas con FUL-1 + SPC cable, funcionando perfectamente, un día se fundió nada más conectar la lipo. Investigando por Internet llegué a la conclusión de que podrían haber sido dos cosas:

  • Un chip integrado en FUL-1 defectuoso.
  • Conectar el FUL-1 a la Pixhawk sin conectarlo al SmartPort.

A día de hoy no tengo respuesta para ese incidente.

Configuración de Pixhawk (Mission Planner)

Parámetros Pixhawk

Sólo hay que modificar el parámetro SERIALX_PROTOCOL (donde X es 1 ó 2 según el puerto de telemetría usado) a 10 (Passthrough FrSky Telemetry Protocol).

Parece que el resto de parámetros se autoconfigura a los parámetros requeridos por el protocolo (velocidad, SR parameters,…)

Yaapu Telemetry Script

Yaapu Telemetry Lua Script funcionando en una Horus X10

Para poder leer los paquetes de información inyectados por Pixhawk en la telemetría SmartPort necesitamos OpenTx en nuestra emisora y el script Lua que los decodifique: el Yaapu Telemetry Script.

Instalación de Yaapu en Horus X10

Aunque la instalación está perfectamente explicada aquí, vamos a resumir los pasos para esta emisora con pantalla a color. En las Taranis no debería haber mucha diferencia, salvo que las pantallas no ofrecerán una imagen tan espectacular.

Copiar a nuestra tarjeta SD los siguientes directorios:
  1. /SCRIPTS/YAAPU
  2. /SOUNDS/yaapu0
  3. WIDGETS/Yaapu
Para ejecutarlo como widget en la pantalla de Horus:

Basado en las instrucciones oficiales.

  1. El tema debe ser el «Azul»:
  2. Añadimos una pantalla de telemetría (signo «+»)
  3. Elegimos la pantalla sin dividir y quitamos topbar y sliders+trims
  4. Setup widgets. Nos aparecerá una pantalla vacía:
  5. Seleccionamos el Yaapu:
  6. Volvemos a la pantalla de telemetría y añadimos otra pantalla vacía sin dividir, seleccionamos otra vez Yaapu como widget, pero ahora entramos en Widget Settings con una presión larga de la rueda. Seleccionamos que es la pantalla 2:
  7. Esta pantalla contendrá los mensajes de nuestra Pixhawk
  8. Salimos, apagamos la radio y la volvemos a encender. Conectamos nuestra Pixhawk y el receptor de radio para que Yaapu comience a recibir telemetría.

A parte de la pantalla principal de telemetría (la 1) tenemos otra mucho menos espectacular (la 2) pero inmensamente útil: la consola de mensajes de nuestra Pixhawk:

La segunda pantalla de Yaapu es la consola de mensajes de Pixhawk

Descubrimiento de sensores tipo SmartPort emulados por Yaapu

Como ya había comentado, el «Passthrough FrSky Telemetry Protocol» es un protocolo que utiliza el medio físico del SPort pero que no se mezcla con él, no crea sensores virtuales del sistema SPort. Sin embargo, Yaapu puede emularlos directamente en nuestra emisora.

¿Y para qué? Acceder al paquetes de datos del protocolo Passthrough no es tarea trivial desde el punto de vista de la programación. Sin embargo acceder desde Lua a sensores SPort es tremendamente sencillo.  Si vamos a programar en Lua y vamos a necesitar leer los datos de la telemetría Passthrough, este es nuestro caso.

Para recrear estos sensores virtuales seguiremos estos pasos:

  1. Entramos en la pantalla de telemetría y pulsamos a descubrir nuevos sensores. No paramos el descubrimiento:
  2. Nos vamos a la pantalla principal de Yaapu y, con el descubrimiento de sensores activo, volvemos a la pantalla de telemetría. Deberían haber aparecido nuevos sensores. Paramos el descubrimiento. Los sensores se desactivaran mientras estemos en esa pantalla y ofrecerán datos mientras el script esté en ejecución.
Configuración de Yaapu

Yaapu maneja algunas variables que pueden ser modificadas. Para ello:

  1. Entramos en la tarjeta SD y ejecutamos /SCRIPTS/YAAPU/menu.lua
  2. Cualquier cambio en la configuración es guardado inmediatamente:

El script estará ejecutándose independientemente de la pantalla de telemetría visualizada, recibiendo en todo momento alertas sonoras.

Modificación del script Yaapu para que publique más sensores

Yaapu publica una serie de sensores que probablemente será más que suficiente para el usuario medio. Sin embargo se echa de menos alguno, como la distancia al punto de partida, muy interesante para programar nuestros propias advertencias de distancia.

Habría que modificar el script, programarlo convenientemente y volverlo a compilar. Dejo esta tarea para algún capítulo posterior.