Me estoy tomando la libertad de responder a mi propia pregunta como tengo la mayor parte de lo averiguado y esta es una buena manera de compartir mis hallazgos. Mi agradecimiento a Olin Lathrop, por darme un lugar para empezar y algunas ideas para probar, pero en última instancia, el protocolo resultó bastante diferente de Olin adivinar, por lo tanto me la publicación de esta respuesta.
Actualización: he publicado una pregunta de seguimiento con respecto a los últimos 8 bits, lo que yo no sabía, y Dave Tweed descubierto. Voy a incluir aquí los detalles, por lo que esta respuesta puede funcionar como un protocolo completo de especificaciones, pero ir a ver a Dave respuesta.
Tuve que probar algunas cosas diferentes para obtener esta resuelto, pero estoy bastante seguro de que lo tengo. Curiosamente, no he encontrado nada parecido a este protocolo en otros lugares, pero puede muy bien ser un protocolo común que yo no sé acerca de.
De todos modos, he aquí lo que he encontrado:
Protocolo de codificación
Ambos pulsos y los espacios que se utilizan para codificar los datos. Un pulso largo/espacio es binario de uno (1), y un pulso corto/el espacio es cero binario (0). Los pulsos son enviados utilizando el estándar de consumo de infrarrojos de 38kHz modulación @ 50% ciclo de trabajo.
El pulso/espacio de tiempo es en la pregunta original, pero voy a repetirlas aquí para la integridad:
Bit Pulse Space
-----+---------+---------
0 | 275µs | 285µs
1 | 855µs | 795µs
Todas ±10 µs máx., ±5µs typ.. Esto se basa en muestras capturadas con un analizador lógico en 16MHz; no tengo un osciloscopio, así que no sé exactamente perfil (por ejemplo, tiempos de subida/caída).
Los paquetes se repite mientras las entradas de control son aplicados y parecen estar separadas por un mínimo de 100 ms de diferencia.
La transmisión de paquetes se inicia con un "pulso de 1" preámbulo, que es fija y no se parte de los datos. El siguiente espacio codifica el primer bit de datos de paquetes, y el último pulso codifica el último bit.
Cada paquete es de 32 bits de longitud, y contiene cada entrada, el control remoto puede proporcionar. Los valores se leen como little endian, es decir, MSB primero.
Estructura de datos
A continuación es la estructura básica de los paquetes individuales. Los últimos 8 bits me había confundido, pero que se ha descubierto ahora (ver más abajo).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
--+---------------------------+-----------+---+-------+-----------
P| Yaw | Throttle | Pitch | T | Chan. | Check
P: Preamble (always a pulse-1), T: Trim, Chan.: Channel
Bit Length Description (see note below)
-----------------------------------------------
0 1 Preamble. High 1
1-6 6 Yaw. Range 0-36 for left-right, 17 being neutral
7-14 8 Throttle. Range 0-134
15-20 6 Pitch. Range 0-38 for forward-back, 17 being neutral
21-22 2 Trim. Left = 1, right = 2, no trim = 0
23-26 4 Channel. A = 5, B = 2, C = 8
27-32 6 Check bits
Nota: los Rangos se basan en la más alta de las lecturas que tengo que hacer. El protocolo es capaz de rangos mayores - hasta 255 para el acelerador, el 63 por tono/guiñada - pero tapa a cabo en aproximadamente la mitad de eso.
El valor de tono parece tener una banda muerta de 14-21 (inclusive); sólo los valores por encima o por debajo de realidad hace que el helicóptero de reaccionar. No sé si es el mismo para la guiñada (difícil de decir, ya que el helicóptero es inestable de todos modos, y sólo puede girar ligeramente en sus el propios).
Aquí está en la gráfica de términos (comparar con el gráfico de la pregunta original)
![packet structure]()
Los 6 bits de comprobación se calcula XOR ing todos los valores anteriores. Cada valor se trata de 6 bits. Esto significa que el 2 Msb de los 8 bits del acelerador valor son simplemente ignorados. I. e.
check = yaw ^ (throttle & 0x3F) ^ pitch ^ trim ^ channel
Notas prácticas de
La señal de los tiempos y de modulación no tiene que ser super preciso. Incluso mi Arduino no-en-todo-el momento exacto en que funciona muy bien a pesar de las dudosas de modulación y un poco de ensayo y error en el pulso/espacio de duración en comparación con el verdadero control remoto.
Yo creo - pero no las he probado - que el helicóptero simplemente se aferran a la canal de la primera señal de que se encuentra. Si se deja sin señal durante demasiado tiempo (unos segundos), parece volver a su "búsqueda" de modo, hasta que adquiera una señal de nuevo.
El helicóptero va a ignorar cabeceo y guiñada valores si la aceleración es cero.
El recorte de los comandos se envían sólo una vez por pulsación de botón en el control remoto. Es de suponer que el recorte de valor simplemente incrementos/decrementos de un valor en el helicóptero del propio controlador; no es algo que el control remoto sigue la pista. Por lo que cualquier aplicación de esto probablemente debería ceñirse a ese esquema, y enviar sólo el ocasional moldura izquierda/derecha valor, pero de otra manera predeterminada a un cero recorte de valor en los paquetes.
Yo recomiendo tener un interruptor de la matanza que simplemente pone el acelerador a cero. Esto hará que el helicóptero para caer del cielo, pero sufren menos daño cuando no girar sus motores. Así que si estás a punto de chocar o golpear algo, golpear el interruptor de la matanza para evitar que se salgan los engranajes o a romper las cuchillas.
El control remoto original del IR Led parecen tener un >900 nm de longitud de onda, pero no tengo problemas con el ~850nm LED.
El helicóptero del receptor de INFRARROJOS está bien, pero no es super sensible, de modo que el más brillante de su fuente de IR, mejor que mejor. El control remoto utiliza 3 LEDs en serie, sentado en la 9V ferrocarril en lugar de la de 5V rail utilizados por la lógica. No ha comprobado su consumo de corriente de forma muy precisa, pero yo apuesto a que 50mA.
Los datos de muestra
Aquí hay un montón de paquetes, para cualquiera que esté interesado (sí, yo guión de un decodificador; yo no la mano de decodificar todo esto). El canal a los paquetes que provienen de la misma captura como los gráficos en la pregunta original.
Channel A
Yaw Throttle Pitch Tr Chan Check Description
-----------------------------------------------------------
000100 10000100 000000 00 0101 000101 Left Mid + Throttle
000000 10000110 010001 00 0101 010010 Left Max + Throttle
100001 10000110 000000 00 0101 100010 Right Mid + Throttle
100100 10000100 010001 00 0101 110100 Right Max + Throttle
010001 00000000 001011 00 0101 011111 Forward Min
010001 00000000 000000 00 0101 010100 Forward Max
010001 00000000 011000 00 0101 001100 Back Min
010001 00000000 100101 00 0101 110001 Back Max
010001 00000000 010001 01 0101 010101 Left Trim
010001 00000000 010001 10 0101 100101 Right Trim
010001 00000011 010001 00 0101 000110 Throttle 01 (min)
010001 00010110 010001 00 0101 010011 Throttle 02
010001 00011111 010001 00 0101 011010 Throttle 03
010001 00101111 010001 00 0101 101010 Throttle 04
010001 00111110 010001 00 0101 111011 Throttle 05
010001 01010101 010001 00 0101 010000 Throttle 06
010001 01011111 010001 00 0101 011010 Throttle 07
010001 01101100 010001 00 0101 101001 Throttle 08
010001 01111010 010001 00 0101 111111 Throttle 09
010001 10000101 010001 00 0101 000000 Throttle 10 (max)
Channel B
Yaw Throttle Pitch Tr Chan Check Description
-----------------------------------------------------------
000000 10000110 010001 00 0010 010101 Left Max + Throttle
100100 10000110 010001 00 0010 110001 Right Max + Throttle
010001 00000000 001001 00 0010 011010 Forward Min
010001 00000000 000000 00 0010 010011 Forward Max
010001 00000000 010111 00 0010 000100 Back Min
010001 00000000 100110 00 0010 110101 Back Max
010001 00000000 010001 01 0010 010010 Left Trim
010001 00000000 010001 10 0010 100010 Right Trim
010001 00000001 010001 00 0010 000011 Throttle Min
010001 00110100 010001 00 0010 110110 Throttle Mid
010001 01100111 010001 00 0010 100101 Throttle High
010001 10001111 010001 00 0010 001101 Throttle Max
Channel C
Yaw Throttle Pitch Tr Chan Check Description
-----------------------------------------------------------
000000 10000101 010001 00 1000 011100 Left Max + Throttle
100100 10000101 010001 00 1000 111000 Right Max + Throttle
010001 00000000 001010 00 1000 010011 Forward Min
010001 00000000 000000 00 1000 011001 Forward Max
010001 00000000 010111 00 1000 001110 Back Min
010001 00000000 100110 00 1000 111111 Back Max
010001 00000000 010001 01 1000 011000 Left Trim
010001 00000000 010001 10 1000 101000 Right Trim
010001 00000001 010001 00 1000 001001 Throttle Min
010001 00110100 010001 00 1000 111100 Throttle Mid
010001 01100110 010001 00 1000 101110 Throttle High
010001 10000101 010001 00 1000 001101 Throttle Max
Como se mencionó anteriormente, los últimos 8 bits se han resuelto, pero sólo para la posteridad, aquí están mis pensamientos originales. Siéntase libre de ignorarlo por completo, ya que estaba muy equivocado en mis suposiciones.
Los últimos 8 bits
Los últimos 8 bits de los paquetes son todavía un poco de misterio.
Los 4 bits de bits de 23 a 26, todos parecen estar totalmente determinado por el del control remoto configuración de canal. Cambiar el canal en el control remoto, no altera el protocolo de modulación o en cualquier forma; sólo cambia los 4 bits.
Pero a los 4 bits es el doble de lo que necesita realmente para codificar el ajuste de canal; sólo hay tres canales, por lo que 2 bits es suficiente. Por lo tanto, en la descripción de la estructura del anterior, sólo he etiquetado los 2 primeros bits como "Canal", y a la izquierda los otros dos etiquetados como "X", pero esto es una suposición.
A continuación se muestra un ejemplo de la relevancia de bits para cada canal.
Chan. Bits 23-26
-----+-------------
A | 0 1 0 1
B | 0 0 1 0
C | 1 0 0 0
Básicamente, hay 2 bits más de lo que se necesita para transmitir la configuración de canal. Tal vez, el protocolo tiene 4 conjunto de bits de un lado para permitir más canales más tarde, o por lo que el protocolo puede ser utilizado en completamente diferentes juguetes, pero yo simplemente no lo sé. Para los valores mayores, el protocolo hace uso de bits adicionales que podrían quedar fuera (guiñada/acelerador/pitch puede conseguir con un poco menos cada uno), pero para recortar - que también tiene 3 estados - sólo 2 bits que se utilizan. Por lo que uno podría sospechar que el canal también está a sólo 2 bits, pero de que sale el próximo 2 en paradero desconocido.
La otra posibilidad es que el paquete de la suma de comprobación es de 8 bits de largo, comenzando con la "X bits", y - a través de la suma de comprobación de la magia - que acaba de suceder de alguna manera siempre reflejan la configuración de canal. Pero de nuevo: no sé.
Y hablando de: no tengo idea de cómo los bits de comprobación se forman. Quiero decir, ellos son los bits de comprobación, ya que no corresponden a ninguna de control único de entrada, y el helicóptero no parece responder si puedo jugar con ellos. Supongo que es un CRC de algún tipo, pero no he sido capaz de averiguar. El cheque es de 6-8 bits de largo, dependiendo de cómo se interprete la "X bits", por lo que hay un montón de maneras en que se pueden poner juntos.
