He buscado un poco en este foro con respecto al giroscopio L3G4200D, y no he visto este problema mencionado, pero he visto a otros hablar de ello en otros foros. Veo un gran valor extraño en mi salida cuando el giroscopio está parado. Desafortunadamente, nadie parece haber podido responder por qué es así, así que pensé en preguntar
Entonces, estoy recolectando datos del giroscopio usando i2c a 400kHz (modo rápido), recolectando los datos del giroscopio usando lectura multibyte (seis bytes a la vez). Muestreo a 100Hz (también probé los mejores 800Hz), también probé con el filtrado activado y desactivado a diferentes valores. No estoy usando el pin de interrupción, pero estoy usando el atributo 'actualización de datos de bloque' en el GYRCTRLREG4, por lo que los datos no se envían hasta que se leen tanto LSB como MSB. 2000dps completos y no hizo nada con el FIFO. Puedo publicar mis valores de registro exactos si me ayuda, pero creo que la mayoría de ustedes no tendrá la hoja de datos a mano.
La imagen de abajo muestra mi problema. Los datos que se emiten son buenos, se calculan correctamente (que yo sepa) y el ruido general es muy aceptable. Pero luego noté que estos molestos 'blips' aparecían al azar cuando el dispositivo está parado. Si lo dejo quieto durante un par de segundos, obtendré uno de estos picos, siempre igual a alrededor de 250-255 (por lo tanto ~ 18 cuando se convierte, usando '(salida * 70) / 1000'). Los picos, como digo, son aleatorios, pueden aparecer en cualquier plano (en la imagen de abajo puedes ver el primer pico en el plano X, el segundo en Y), siempre alrededor del mismo valor, y uno, dos o todos tres pueden suceder al mismo tiempo. El valor grande es solo para una sola muestra, luego vuelve a la normalidad.
Vi en otro hilo en alguna parte que debería estar usando la función de espera de datos de bloque en GYRCTRLREG4, como mencioné antes, pero sin cambios. He reducido el problema a ser cuando el MSB es cero o más alto, es decir, un número positivo, luego, cuando se combinan el MSB y el LSB, obtengo estos números grandes. Por ejemplo, tomo los dos bytes necesarios para el plano X, obtengo un -6 en el LSB, y un 0 en el MSB, combinándolos me da 250, luego la conversión da (250 * 70) / 1000 = 17.5 dps ( es decir, demasiado grande para estacionaria / incorrecta). En la misma muestra, los dos bytes para el plano Y son -3 LSB y -1 MSN, combinándolos da -3, y la conversión da -0.21 (es decir, esperado / correcto).
He estado en este problema durante días ahora, también estoy viendo un poco de estos picos aleatorios con mi magnetómetro, ¿así que estoy pensando que soy yo quien lee el dispositivo (a través de i2c) incorrectamente?
Cualquier sugerencia o cosas para probar son realmente bienvenidas!
Respuestas:
Debido a que está observando un problema similar con su magnetómetro, supongo que tiene un problema en el bus I2C. Si bien podría ser un problema de código debido a la operación intermitente, primero verificaría cómo está conectado el bus. Algunas cosas para verificar / probar:
Si no está utilizando resistencias pull-up externas, pruebe las resistencias pull-up de 10K en SDA y SCL. El pull-up interno en la mayoría de los microcontroladores no será lo suficientemente fuerte.
Si es posible, reduzca la longitud del bus tanto como sea posible e intente mantenerlo alejado de las señales de alta velocidad.
Si usa una placa de prueba, intente mantener las conexiones lo más directas posible para evitar un exceso de capacitancia.
Si está utilizando placas prototipo que ya incluyen resistencias pull-up, pueden estar terminando en paralelo y, de hecho, puede tener un valor de resistencia pull-up demasiado bajo.
Si puede organizar el acceso a un alcance que sería ideal para asegurarse de que el reloj y las líneas de datos se vean bien y cuadradas y no estén demasiado sesgadas.
Si esos pasos no funcionan, Texas Instruments tiene el informe de la aplicación de resolución de problemas del protocolo de bus I2C que detalla más sobre el cálculo de las resistencias pull-up y los problemas que puede encontrar con la capacitancia.
fuente
Lo que puede estar sucediendo es que se está tomando una nueva muestra entre leer el LSB y el MSB. Entonces, si MSB = 0 y LSB = -4, debería obtener 252, o aproximadamente 1g. Si la siguiente lectura es MSB = 1 y LSB = 2, debería obtener 258, lo cual es razonable. El problema es cuando para 1 muestra solo el MSB se ha actualizado a 1 y el LSB todavía es -4, obtienes 508, aproximadamente 2g, que podría ser este problema.
Se supone que BDU en CTRL_REG4 previene esto. ¿Quizás lea ese registro del sensor y asegúrese de que la retención de bloque esté habilitada?
fuente
prueba con un filtro mediano y estos picos se desvanecerán.
Consulte mi pregunta aquí en StackExchange y luego lea esta publicación sobre el mismo problema
fuente