miércoles, 26 de febrero de 2020

Actualización #01

El protocolo SBUS


Muchos modelos son compatibles con los receptores FrSky porque se conectan a las salidas PWM.
Pero no todos los receptores tienen PWM y los que lo tienen solo pueden sacar 8 canales en lugar de 16. Incluso recomiendan usar dos receptores para lograr 16 canales. Pero la interfaz principal de comunicación es SBUS.

Comunicación

SBUS es un protocolo serial derivado de RS-232 con las siguientes características:

  • Baudrate 100000 no estándar.
  • Lógica invertida.
  • Configuración 8E2
    • 1 bit de inicio
    • 8 bits de datos
    • 1 bit de paridad par
    • 2 bits de parada
El baudrate es muy alto para SoftwareSerial, HardwareSerial no tendría problema en un Arduino.
La lógica invertida significa que los niveles de tensión funcionan al contrario que en RS-232, no es solo que los datos estén invertidos, sino que la forma de señalizar una ráfaga es completamente opuesta. SoftwareSerial permite lógica inversa pero HardwareSerial no, requeriría hardware adicional para invertir la señal.
La configuración 8E2 es una de las posibles en HardwareSerial pero SoftwareSerial está implementado únicamente con 8N1, aunque eso podría cambiar se modifico la librería.

La trama

La información se encapsula en tramas de 25 bytes. Con 1 byte cabecera fijo, 22 bytes de datos, 1 byte de flags y 1 byte final de valor fijo.
Se transmiten 16 canales de 11 bits, eso hace que se mezclen canales en un byte. La estructura resumida es la siguiente. En los flags se incluyen dos canales extra de un bit cada uno, un bit para activar el modo seguro y un bit para indicar trama perdida.

  • Byte 0 : Cabecera valor fijo 0x0F
  • Byte 1 - Byte 22 : Canales 0 a 15
  • Byte 23 : Flags, canales 16 y 17.
  • Byte 24 : Marca de final valor fijo 0x00
Toda esta información está explicada con mayor profundidad en la documentación de GitHub.

Conclusiones y viabilidad

Aquí tenemos el siguiente dilema. SoftwareSerial no soportará un baudrate tan alto y no tiene configuración 8E2 pero sí permite lógica invertida. HardwareSerial no tendría problema con el baudrate ni con la configuración 8E2 pero requiere invertir la señal mediante un circuito.

La hoja de ruta será intentar hacer funcionar SoftwareSerial con 8E2 y el baudrate alto y si no es posible pasar a HarwareSerial diseñando un pequeño inversor.

No soy un experto en operaciones a nivel de bit pero he escrito en C++ el siguiente código demostrando como guardar 16 canales de 11 bits en 22 bytes separados y sacarlos en el proceso inverso.
En un principio hice unas operaciones por cada canal pero en el tercero me dí cuenta del patrón que seguía y creé un pequeño procedimiento estándar que resuelve este problema con cualquier número de canales, bytes por canal y bytes por carácter. (Por defecto: 16, 11, 8)
Adjunto el archivo de prueba.

martes, 25 de febrero de 2020

Actualización #00

#00 : Iniciando el terreno


A la izquierda pueden verse dos receptores FrSky, R9 y X8R. A la derecha dos placas de desarrollo Arduino Uno y Mega. En el centro un mando FrSky X9D.

El objetivo de este proyecto es poder usar cómodamente ese mando para controlar los Arduinos.
Como los receptores tienen al menos una salida SBUS, una librería capaz de comunicarse por ese protocolo podría establecer un enlace con ese mando o cualquiera conectado al receptor.

Los mandos de FrSky utilizan OpenTX que es un firmware libre para transmisores de radio.

Dispositivos

Idealmente me gustaría ser capaz de comunicar el receptor con la placa Arduino mediante un serial software. No todas las placas tienen puertos seriales extras, la mayoría solo tiene el utilizado para la conexión USB.
Todos los receptores actuales de FrSky incorporan un puerto SBUS para comunicarse con el modelo y el protocolo ACCST D16 para comunicarse con el mando.
La mayoría de mando de FrSky acepta ACCST D16, por lo que la compatibilidad es prácticamente completa. 

Existen diversas marcas que comercializan alternativas compatibles con FrSky, por lo que logrando comunicación software serial con un receptor FrSky podría afirmar que Casi cualquier Arduino es compatible con casi cualquier mando radio control.

Planificación

  1. Estudio del protocolo SBUS y viabilidad
  2. Implementación básica de recepción
  3. Recepción y decodificación fiable
  4. Envío de telemetría  fiable
  5. Estandarización en una librería formal
En el proceso se generará la documentación oportuna y una vez terminado la librería será publicada.