Hola,
Estoy pensando en poner varios acelerómetros conectados con un arduino UNO y leyendo la información mediante I2C.
La pregunta que tengo es cómo hacer la sincronización de los datos, pues entiendo que ambos sensores irán conectados a la mismas partes del arduino (el arduino leerá del mismo puerto ambos sensores). ¿Ambos datos llegarán de forma síncrona? ¿Cómo compruebo esto?
Gracias,
Un saludo,
si tu acelerómetro es I2C, tendrá unos pads o pines donde puedes cambiar la dirección. supongamos que tenga 3 A0 A1 y A2. Poniendo en 0 o 1 o mejor dicho unido a GND o VCC tendras 8 opciones posibles
Cada sensor con una dirección distinta será para el bus un dspositivo que responderá solo a dicha dirección.
Pero en lugar de hablar en el aire, precisa que sensor es?
El sensor es este: http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf
De todas formas, mi pregunta no iba referida al sensor, si no al I2C del arduino... Quiero saber si me puedo fiar de que los datos que me llegan de ambos sensores han sido tomados en el mismo instante temporal.
Nada puede leerse en el mismo instante porque cada acceso requiere algunos tiempo.
El manual (de paso lee las normas y colocale las etiquetas de enlace correspondientes en tu post #2), dice que el sensor entrega datos a una velocidad de muestreo de entre 12.5 a 3200 Hz.
Aunque el reloj de una comunicación SPI puede funcionar a 5Mhz
Use of the 3200 Hz and 1600 Hz output data rates is only recommended with SPI communication rates greater than or equal to 2 MHz. The 800 Hz output data rate is recommended only for communication speeds greater than or equal to 400 kHz, and the remaining data rates scale proportionally. For example, the minimum recommended communication speed for a 200 Hz output data rate is 100 kHz. Operation at an output data rate
above the recommended maximum may result in undesirable effects on the acceleration data, including missing samples or additional noise.
Ahi estan expresadas las limitaciones. Y por ende con las limitaciones de velocidad tmb los tiempos posibles para 1 o mas sensores.
En modo I2C recomiendan 100khz hasta un máximo de 400Khz
Las limitaciones son
> Due to communication speed limitations, the maximum output data rate when using 400 kHz I2C is 800 Hz and scales linearly with a change in the I2C communication speed. For example, using I2C at 100 kHz would limit the maximum ODR to 200 Hz
Asi que puedes esperar un máximo de 800hz o 1.25mseg o como malo 5 mseg
Ahi tienes tus tiempos posibles
Gracias por la respuesta.
No sé si no he llegado a entenderla bien o no se ha entendido bien mi pregunta. Ya sé que en el mismo instante exacto no van a tomar las muestras, pero como mucho deberían tener un desfase entre ellas de 1/Fm. Mi problema es que quiero que ambos sensores estén muestreando y enviando datos a la vez. Esto supone que el arduino tendrá que registrar ambas entradas (a pesar de que estén llegando en tiempos distintos) y procesarla mediante la comunicación SPI. Las velocidades que se muestran en el datasheet, aseguran la comunicación (que lleguen los paquetes) pero no me asegura que me lleguen de forma síncrona.
Lo que quiero saber es que no van a llegar 2 muestras del primer sensor, luego una del segundo sensor,... y así sucesivamente, si no que será 1 muestra del primero, 1 muestra del segundo,... y que corresponderán al mismo instante temporal (aproximadamente, y que no estarán tomadas con un desfase significativo ya que quiero guardar los datos de ambos sensores para procesarlos posteriormente y necesito conocer esta sincronización).
Mi pregunta va enfocada al arduino (comunicación SPI), no a los sensores.
Vamos de nuevo.
Ya que arduino debe accesar cada sensor en cada ciclo, no hay modo de que tu recibas los datos en misma marca temporal salvo... con una pequeña diferencia lo hagas usando SPI y que los sensores esten en cascada.
Entonces si son dos imagina que leeras 16 bits. La orden de lectura sera simultanea pero debido a que los bits deben serializarse estos insumiran algunos useg de diferencia o mejor dicho n ciclos reloj donde el reloj será la del clock SPI que estes usando. Supongamos 1Mhz entonces N useg de diferencia.
Eso es lo mejor que puedes lograr y a los efectos prácticos a menos que hables de un trabajo científico con propagación de error creo que hilas demasiado fino en ese punto.
Entonces... como el sensor no tiene inteligencia (al menos no estos por ahora) no pueden tomar una muestra y almacenarla para luego reportarla cuando tu lo solicites, eso sería lo ideal. Si eso necesitas yo usaría un par de micros ATtiny que hicieran esa tarea sincronizados de algun modo por tu arduino y que cuando tu lo solicites el valor devuelto sea el que pediste y no interesará ese defasaje temporal.
Eso es lo que se me ocurre ahora.
Vale, gracias!
Sí, a eso me refería, si se puede asegurar que el desfase sea 1/Fm o muy pequeño (en este ejemplo que has puesto de 1MHz vs 1kHz del sensor, sería asumible).
¿Cómo aseguro esto, entonces? ¿Las peticiones de los datos las hace el arduino, o el arduino es sólo un listener que cuando recibe datos los procesa?
Perdón si son preguntas algo básicas pero nunca he trabajado con i2c y este factor es clave para el proyecto en el que estoy.
mariocotorillas:
... que el desfase sea 1/Fm o muy pequeño ...
Ya me disculpareis: ¿Que es "1/Fm"?
Saludos
Fm es la frecuencia de muestreo. En tiempo, el máximo step que puedes alcanzar es 1/Fm (Tiempo de muestreo).
Bueno establece entonces la Fm para hablar en concreto
Hi,
Voy hacer una sugerencia. Creo que estas trantando cruzar el rio y no tienes el puente todavia. Ahora mismo esta contruyendo un projectos que tienes dudas a saber. Normalmente cuando se desarolla un projectos hay desconocidas. De la unica forma que puedes saber si trabaja vas a tener que hacer pruebas y pruebas para saber si eso que estas buscando trabaja o no. Haz algunas pruebas leyendos los sensores y ve los resultados. Adjunto un link para que veas como el I2C trabaja.
surbyte:
Bueno establece entonces la Fm para hablar en concreto
Creo que no hace falta ser tan agresivo al hablar... Las preguntas genéricas también aportan conocimiento a la comunidad. Además, para mi última pregunta (¿Las peticiones de los datos las hace el arduino, o el arduino es sólo un listener que cuando recibe datos los procesa?) no es necesario saber la Fm.
De todas formas no sé a qué velocidad será capaz de procesar los datos el arduino, sé que su reloj interno es de 16MHz y puede trabajar a varios cientos de miles de baudios... por lo que podemos asumir que será bastante mayor al orden de 1KHz que actuan los sensores. Aunque, como he dicho, esto no es relevante para saber cuál es el protocolo que se sigue en las comunicaciones I2C.
tauro0221:
Hi,
Voy hacer una sugerencia. Creo que estas trantando cruzar el rio y no tienes el puente todavia. Ahora mismo esta contruyendo un projectos que tienes dudas a saber. Normalmente cuando se desarolla un projectos hay desconocidas. De la unica forma que puedes saber si trabaja vas a tener que hacer pruebas y pruebas para saber si eso que estas buscando trabaja o no. Haz algunas pruebas leyendos los sensores y ve los resultados. Adjunto un link para que veas como el I2C trabaja.
Gracias Tauro! Me ha quedado algo más claro la parte de I2C. De hecho, clarifica el ejemplo de tener paquetes pequeños con un clock mayor. Aún así, no sé si sería capaz de hacer las dos peticiones a ambos sensores seguidas y que el desfase no sea significativo para mi problema. Si alguien tiene alguna idea o a trabajado en entornos similares, agradecería su respuesta 
Y claro que al final tendré que hacer mil pruebas para comprobar el funcionamiento, pero no quiero gastar un dinero del proyecto en un sensor o en unos materiales que no son buenos ya en la base teórica. Por eso estoy haciendo estas cuestiones, para poder elegir mejor un primer entorno de pruebas e intentar no fallar en la elección de componentes 
PD: Perdón por la parrafada, he dejado en negrita las dudas que sigo teniendo. Gracias por contestar 
mariocotorillas:
Las preguntas genéricas también aportan conocimiento a la comunidad. Además, para mi última pregunta (¿Las peticiones de los datos las hace el arduino, o el arduino es sólo un listener que cuando recibe datos los procesa?) no es necesario saber la Fm.
He estado investigando la cuestión de los acelerómetros desde un par de pisos más arriba (para una cuestión de análisis de vibraciones -FFT- en estructuras de hormigón).
No creo que este tipo de sensores que tú estás valorando tengan la posibilidad de sincronizarse, y menos a frecuencias de decenas de kHz ...
Lo que si hay son soluciones que tienen más electrónica incorporada -amén de los acelerómetros- y que, imagino, sincronizan de una forma u otra las medidas ... échale un vistazo a ver si tienen que ver con lo tuyo:
http://bitscope.com/product/BS10/
Saludos
Gracias por la aportación! Suena muy interesante, pero lamentablemente para el proyecto no tengo tanto presupuesto. Primero tengo que sacar algunas conclusiones con un prototipo low cost.
Los sensores no trabajan a decenas de kHz, trabajan a 800Hz-1KHz aprox. Siendo que con el arduino se pueden alcanzar centenas de kbaudios en la transmisión de datos, ¿Crees que sería muy significativo no cogerlos en el mismo instante exacto?
Hi,
No creo que mencionas de que se trata tu projecto y que quires lograr hacer. Si nos dice de que se trata tendriamos una mejor idea de si es posible lo que estas tratando de desarollar.
mariocotorillas:
Los sensores no trabajan a decenas de kHz, trabajan a 800Hz-1KHz aprox. Siendo que con el arduino se pueden alcanzar centenas de kbaudios en la transmisión de datos, ¿Crees que sería muy significativo no cogerlos en el mismo instante exacto?
Hola,
Pues depende de lo que estés haciendo. De todas de todas formas, y aunque no aporte nada en la solución (o sí), también depende de lo que entiendas por "instante exacto"; si el SPI va a semejantes velocidades (que va), el error que introduciría el decalaje de los envíos desde los diferentes sensores es del orden de mS ... Me da la sensación de que los posibles tiempos internos en el sensor suponen incertidumbres mayores porque, ¿en qué instante se ha producido la lectura que a ti te llega en el instante "t"?; o, peor aún, ¿en que instante había esa aceleración que a ti te llega en "t" y el sensor ha acondicionado para envío en "t-dt"?...
(Es verdad lo que dice tauro; ¿por qué no nos dices cuál es la aplicación?).
Saludos.
Hola, gracias por las respuestas!
Se trata de medir la vibración de una maquína, necesito dos acelerómetros (uno pegado a la máquina y otro fuera que sólo capte el ruido de las señales para poder combinar ambas captaciones y eliminar este ruido).
Para combinar ambas señales necesito que estén sincronizadas a la hora de captar los datos.
Y porque no usas acelerómetros piezoeléctricos. Eso no se mide con sensores I2C.
Con los acelerómetros piezoeléctricos como tienen salida analógica los leeras con diferencia de 100 useg máximo.
Mucho mas simple!!
Hi,
En linea con lo que surbyte te sugerio aqui adjunto un link donde explica como leer vibracions.
Sí, es cierto. Estuve buscando cuales eran los mejores tipos de acelerómetros para medir y es cierto que son los piezoeléctricos. Sin embargo, al menos los que yo he encontrado, son más caros. Hicimos una prueba con un móvil (con el acelerómetro interno) y funcionó más o menos, se veía que iba un poco justo de frecuencia, pero se veía el movimiento. Según vi, depende que tipo de vibración, con llegar en torno a 1kHz de Fm es suficiente para captar bien la señal.
Por eso me decidí por ese tipo de sensores y por eso preguntaba por las dudas de i2c en el otro post.