Hackeando una Flying3D FY-Q7

Hace unos días llegó a mis manos una radio de radiocontrol Flying3D FY-Q7, modelo que al parecer viene incluida en un kit junto con algunos multicópteros de la misma marca. La radio está muy limitada en funciones, pudiendo utilizarse casi exclusivamente con los aparatos con los que viene, pero para un ala fija es muy limitada, sin poder ajustar canales, dual rates, expos… y sin mezclas, con lo que habría que olvidarse de alas volantes o colas en V, etc, además de no sportar múltiples modelos. Su propietario me preguntaba si sería posible hacer algo con ella…

Pero mirando la radio, basta un momento para darse cuenta de que su aspecto es clavado a la Turnigy i6 (también vendida bajo la marca FlySky), salvo porque tiene menos interruptores, pero palpando las pegatinas embellecedoras, se notan los agujeros… y después de retirar los tornillos y abrirla, comparando el PCB con imágenes de la Turnigy encontradas en internet, vemos que es la misma radio.

Turnigy, al contrario de Flying3D (primera vez que veo esa marca por cierto), saca actualizaciones de firmware para su radio, que se puede flashear con un simple conversor USB-serie conectado a los pines del puerto trainer, iniciando la radio en modo bootloader,  y ejecutando una aplicación del fabricante para realizar el proceso (Aplicación para windows pero que funciona perfectamente en Linux bajo Wine si enlazamos el dispotivo COM a nuestro puerto serie-USB). Manos a la obra. Inicio la radio en modo bootloader siguiendo las instrucciones para la Turnigy (trim de throttle abajo, trim de timón derecha y encender) y parece que se enciende pero no sale nada en pantalla, así que parece que funciona, conecto el conversor USB-Serie a los pines indicados, y ejecuto la aplicación de Turnigy. Después de intercambiar los pines TX y RX (ups!) parece que la detecta al conectar y aparece una versión de firmware en pantalla. Bien, le doy a actualizar, se transfieren datos durante unos segundos y… nada, la radio no vuelve a dar señales de vida. Depués de varios intentos no consigo que ejecute el nuevo firmware, así que empiezo a mirar otras opciones. La suposición es que el bootloader de Flying3D debe flashear el firmware en otra posición de memoria de la que espera el firmware de Turnigy, al ser este mucho más simple, porque por lo demás el hardware es idéntico (salvo la falta de dos interruptores que simplemente no están, aunque están sus conexiones). Pero al abrir la radio, ya había visto que había un conector SWD (Single Wire Debugging)  para la CPU de la radio, un Kinetis ARM Cortex M0 de Freescale.

Asi que buscando información por internet, encontré la página del proyecto https://github.com/benb0jangles/FlySky-i6-Mod-, un repositorio con modificaciones a los firmwares originales de Turnigy, con mejoras como más canales, más interruptores, etc. En este repositorio veo los volcados completos de la flash de la CPU usando el interfaz SWD, así que supongo que podré flashearla completamente, incluyendo el bootloader de Turnigy y asunto arreglado. Afortunadamente tengo un interfaz STLink V2 (un clon barato de Aliexpress), que se puede usar con OpenOCD para flashear estas CPUs.

Lo primero es crear una configuración de OpenOCD para esta CPU e interfaz:

frskyi6-jlink.cfg:

source [find interface/jlink.cfg]
transport select swd

set CHIPNAME MKLx
source [find target/klx.cfg]

Y lanzar OpenOCD definiendo los bancos de memoria de este chip:

  $ openocd -f frskyi6-jlink.cfg -c "flash bank MKLx.pflash kinetis 0x00000000 0x0000ffff 0 4 MKLx.cpu" -c init

Una vez lanzado, nos conectamos por telnet (locallhost 4444) a este OpenOCD y ejecutamos los siguientes comandos para borrar la memoria y flashear el firmware completo original de Turnigy descargado del proyecto FlySky-i6-Mod-:

> kinetis mdm mass_erase
> reset halt
> program tgyi6_ori.bin 0

Pero… problemas. No se por qué, pero con mi configuración no me deja programar completamente la flash del Kinetis, no se si es por el interfaz STLink o si hay algún problema con la versión que uso de OpenOCD, pero por más que lo intento cambiando las velocidades del SWD, borrando y programando por bloques de memoria flash, probando todas las opciones de bloqueo y desprotección de la memoria, etc, no consigo flashear los 64K del firmware original y siempre me da error a media escritura.

Haciendo algunas pruebas con los comandos de escritura de OpenOCD, veo que si es posible escribir en la flash que guarda los datos y que en las pruebas puedo programar hasta 4K sin problemas, así que me viene a la mente la posibilidad de cortar el firmware esperando que el bootloader se grabe correctamente y que luego pueda subir el resto del firmware con el procedimiento de actualización por el puerto USB-serie. Asi que usando el comando dd voy cortando trozos del firmware original y flasheándolo a ver en que momento el bootloader responde desde el puerto serie.

$ dd if=tgi6_ori.bin of=tgi_ori-rev-bin bs=1K count=4

Flasheo una versión de 4K y el flasheado es correcto, pero el bootloader no responde por el puerto serie, pruebo con 8K, flashea pero tampoco hay respuesta, pruebo con 16K…

Y eureka! Además de flashear los 16K sin problema, cuando ejecuto la aplicación de Turnigy conectado por el puerto serie…

Me detecta una versión de firmware en la radio, con lo que el bootloader está activo, le doy a programar y recibo el saludo del firmware de Turnigy ejecutándose en la radio.

Ya de paso pruebo a instalar un interruptor extra instalándolo en uno de los agujeros ocultos y conectando su pin intermedio a uno de los pines libres en el conector de los interruptores existente, y reconocido por el firmware a la primera).

Ha costado un poco, pero hemos pasado de una radio totalmente limitada, a una radio que se puede utilizar con múltiples modelos, con receptores baratos de Turnigy, y que incluso soporta telemetría. Espero que os sirva de ayuda.

ASHAB NearSpaceOne

Desde hace unos meses un grupo de aficionados a la electrónica abierta y fabricación digital que nos conocimos alrededor de fabLAB Asturias, estamos desarrollando un proyecto de misión de alta altitud usando globos meteorológicos. La idea era participar en Global Space Balloon Challenge, un concurso abierto e internacional consistente en precisamente en la realización de estas misiones para promocionar la investigación y la experimentación científica por la ciudadanía, usando un entorno tan atractivo como es el acercamiento al espacio.

Este proyecto lo hemos llamado ASHAB (Asturias High Altitude Ballooning), y NS1 (Near Space One) a nuestra primera misión.

La misión básicamente  consiste en poner a prueba la base de los sistemas que pensamos emplear para futuras misiones: ordenador de a bordo, comunicaciones, imagen, sistema de recuperación y estaciones de tierra. A partir de esta primera misión, esperamos poder probar ideas más técnicas y sistemas más complejos, pero primero vamos a intentarlo con lo básico. Para registrar el vuelo, llevaremos varias cámaras HD y sensores, y la ultima adición es una cámara 360º que esperemos consiga unas imágenes increibles de toda la misión.

Todo el proyecto es por supuesto abierto. Estamos compartiendo los diseños y el código tanto en el wiki del grupo, como en repositorios online como github, y el contenido generado (datos, imágenes, vídeos) será también publicado con licencias libres una vez realizada la misión.

Para más información, podeis consultar la web y el wiki.

FCDControl

Después de mucho tiempo sin postear, subo una pequeña actualización con algo de lo que he estado haciendo ultimamente.

He vuelto a retomar la radioafición, y en serio, ahora tengo la licencia EA1IDZ, y ya llevo buenas experiencias con DX, antenas caseras, satélites, e incluso un contacto con la ISS.

Entre otras cosas, he estado trasteando con una FunCube Dongle, una SDR (software Defined Radio), muy compacta y con un gran espectro (de 64 a 1700MHz), que me ha permitido escuchar muchas bajantes de satélites, decodificar APRS, y jugar con GNURadio, una de las suites más impresionantes que he usado de software libre.

Como siempre, echaba de menos una aplicación para linea de comandos para controlar la FunCube Dongle, asi que me puse manos a la obra. Basándome en el código de la aplicación gráfica, no fue difícil hacer una herramienta básica para seleccionar la frecuencia, correción y ver el estado de la radio. Depués de publicarlo en la lista de correo del proyecto FunCube, he recibido incluso un parche para configurar la ganancia del LNA, y otras cosillas.

El código está disponible en Gitorious, y ya de paso comentar que a partir de ahora, las cosas que desarrolle las iré subiendo ahi, he aprovechado para subir varios de mis proyectos. Podeis echar un vistazo en https://gitorious.org/~ladecadence

Espero postear de nuevo con más asiduidad, ahora que ya tenemos server dedicado  (gracias a vieju.net!) y que tengo bastantes cosas en el tintero.

Saludos.

Connect – Arduino + Ruby + FTP + lindenScript + OpenSIM

Esta semana he asistido al taller Connect, en el centro de arte LABoral, ya soy un veterano de ellos. Este curso/taller trataba sobre la interconexión de hardware/software a través de diversos protocolos… serial, usb, midi, osc… arduino, processing, puredata, php, python… muy divertido.

captura-opensim.pngEntre todo lo que fuimos haciendo, mis pequeños proyectos durante el curso han sido un teletenis (al estilo clasico del PONG de los 70) en processing, cuyas raquetas respondian a dos potenciometros conectados a un arduino… vamos, como el original pero con un backend high-tech.

Pero el otro proyectillo que surgió, junto con Pablo de Soto, y que acabó siendo bastante interesante, fue la idea de tomar datos del mundo real e insertarlos en un mundo sintético en tiempo real, siendo los cambios paralelos en ambos entornos.

Pues nada, instalé un servidor de OpenSim (el software liberado que corre en los servidores de Second Life), y empezamos a jugar con lindenScript, el lenguaje de scripting de este motor, sintaxis similar a C… sin problema. Asi, encontramos el llHTTPRequest… la mitad ya estaba hecho.

Con un SquidBee, recogemos los datos de luminosidad, humedad y temperatura del entorno real, y despues de transformarlos en valores “humanos” (% de luminosidad y humedad, y ºC de temperatura) los enviamos por el puerto USB/Serie a un PC, ejecutando un script en Ruby, que crea un archivo de texto con estos datos y lo sube a un ftp cada 10 segundos.

Luego desde el mundo de OpenSim, tenemos un scrip asociado a un objeto, que cada 10 segundos también, hace un HTTPRequest a la url donde se sube el fichero, lo descarga y lo parsea extrayendo los datos que usamos para modificar el estado de este objeto. En este caso, es la “Farola” (palo con una bola roja encima), que cambia de color con la temperatura (de negro si es menor de 15º a 100% rojo si es superior a 30º), y de opacidad con la luminosidad (transparente a 0% de luminosidad a opaco con el 100%). El sensor de humedad se nos estropeó, asi que no hicimos nada con el.

La idea ahora es aplicar estos cambios globalmente en el mundo virtual, de manera que podamos cambiar el estado del dia virtual dependiendo del dia real, etc. Pero ha sido interesante este primer paso.