Cómo interpretar los datos del acelerómetro del reloj TI Chronos

Navega tus respuestas
2

He estado intentando durante un tiempo incómodo para averiguar cómo interpretar los datos del acelerómetro inalámbrico de TI Chronos . Desde mi computadora portátil con la radio usb incluida, la leí en python básicamente siguiendo esta recepción, luego la lanzo en una aplicación pyglet para mostrar El vector de aceleración 3D. Se lee como caracteres sin firmar, pero no puedo entender los datos. Tampoco lo he encontrado documentado en ninguna parte. Aquí hay un ejemplo de impresión de mantener el reloj quieto, mientras lo gira entre 1 eje sin problemas. 

[253 245  24 255   6   7   1]
[  0 241  20 255   6   7 255]
[255 229  28 255   6   7 255]
[255 229  25 255   6   7 255]
[  1 229  19 255   6   7 255]
[249 224  21 255   6   7 255]
[254 219  17 255   6   7 255]
[255 218  11 255   6   7   1]
[247 211  15 255   6   7 255]
[251 209  10 255   6   7 255]
[251 212 255 255   6   7 255]
[243 194  16 255   6   7 255]
[243 200   7 255   6   7 255]
[247 197   3 255   6   7   1]
[246 190  10 255   6   7 255]

Obviamente, los primeros 3 bytes son los datos del acelerómetro, y también claramente los números deben estar firmados de alguna manera. Pero, ¿por qué los vectores de fuerza no son suaves? Es más obvio en la visualización de opengl, pero incluso en el pequeño conjunto de datos anterior, se puede observar, por ejemplo, saltar de 255 a 1 en ningún momento. Finalmente, quiero obtener Gs reales de los datos, pero por ahora me conformaré con obtener un vector de fuerza suave que parezca algo coherente con la rotación del reloj. Puntos de bonificación si alguien sabe lo que significan los últimos 4 bytes. Esperemos que esta sea una pregunta de tipo chiphacker.

    
pregunta Imbrondir

3 respuestas

6

Parece que los datos están usando firmados enteros .

Por lo tanto, 255 es -1 y 1 es +1.

Es de suponer que las fuerzas se normalizan en algún lugar, probablemente al tomar una lectura del acelerómetro cuando se inicia el reloj. Después, cualquier aumento en la fuerza es positivo, y la disminución en la fuerza es negativa. Eso parece coincidir exactamente con los datos dados.

    
respondido por el Connor Wolf
2

Uno de los otros bytes se indica si se presiona un botón, hice algún trabajo en este tema hace años ( aquí ) los otros dos solo indican una conexión exitosa y si estás en modo ppt o acc, si recuerdo bien.

También tuve el mismo problema con los valores de salto:

Es casi como que hicieron una dirección 0+ y luego la otra directamente restó su valor de 255. Pensé (pero nunca lo intenté) trazando dx / dy / dz ya que creo que eso daría el movimiento que estás buscando y solo requeriría un suavizado menor.

Si alguien tiene información más detallada, también me gustaría escucharla

    
respondido por el chemicaloliver
1

Compruebe el acelerómetro hoja de datos de la familia que se encuentra en la wiki:

  

Los datos de aceleración se presentan en formato de complemento a 2. A 0 g de aceleración, la salida es idealmente 0h. [sic]

Por supuesto, verá la gravedad como un vector estable de aproximadamente 1 G en la salida. Si tiene el centro de control u otro grafer en funcionamiento, al girar el reloj se mostrará qué ejes se están tirando y en qué dirección.

Si ha instalado el centro de control de TI , también debe tener el Fuentes de firmware tanto para el reloj como para la estación base. La lectura de estos debe indicar exactamente cómo se tratan los datos (casi nada, algunos filtros IIR y envío periódico cuando ACC está activo). Los encabezados de la estación base también contienen información sobre el protocolo entre el host y la estación base.

Los otros ejemplos de programación también pueden ser de alguna ayuda práctica.

En cuanto a los "cuatro bytes adicionales", creo que sus muestras no están sincronizadas. Parece que lo son [4 5 6 0 1 2 3] Tal vez se olvidó de leer la respuesta para el comando de inicio de estación base o algo así. Así que los tres primeros son de una solicitud anterior y los últimos cuatro son de la actual y, como no lee los siete, los tres últimos aparecerán en su próxima lectura, etc. En el orden correcto, los bytes son (IIRC) : un byte de inicio (0xff), comando / respuesta (0x06 = siguen los datos de acceso), longitud del paquete (0x07 = siete bytes incluyendo estos tres), "código de retorno" & & estado del botón (0xff = sin datos), ax, ay, az. Pero puedes encontrar las constantes reales en uno de los encabezados :)

    
respondido por el XTL

Lea otras preguntas en las etiquetas

Pregunta de topología de Charlieplexing CA cuadrada a CA sinusoidal