Is it possible to get data from sensors at the same timing

GoogleGroups
1

Hello everyone,

I have a project about earthquake and i’m using accelerometer sensors to measure earthquake data. But I have a problem with that.

I want to measure two accelerometer sensors that support I2C with Beaglebone Black at the same time but these sensors will be different I2C port and
The timing is so important for me. I have to take all data from sensors at the same time. I readed some article about that situation and mostly people using
MCU that support RTOS but I’m using Linux kernel.

So is it possible with software ? and how should i do ?

Thank you for responses.

2

You don't mention which sensors you are using, but normally they have
some sort of mechanism to start a conversion or measure a sample
triggered via the I2C bus. Also, the I2C bus typically isn't real
high-speed, so you can "bit-bang" it with the CPU. Just write some code
that triggers samples on both sensors at the same time.

If timing is _really_ important, you can use the PRU to do the I2C
bit-banging instead of the ARM core.

Note you may need to modify the pins used for the I2C bus. If you want
to start the conversions at exactly the same time, the bits used for the
I2C bus should be in the same GPIO bank.

3

Hi,

As Charles mentioned, you did not tell which sensors you are using.

Why could not the sensors be on the same bus ?
On the same bus, you could broadcast a message to start conversion.
see http://www.i2c-bus.org/addressing/general-call-address/

Derek Moloy got interesting videos too : https://www.youtube.com/watch?v=8C2zk6B-eLU

That said, I am also working on time critical AD conversion for accelerometers in order to measure displacement, thus integration of accelerometers data and I need to have a precise time interval.
I first tried using Gpio from userland but timing was out of control.
This is why I’m trying to use the PRUs units to control the ADCs

Regards,

Cedric

4

I’ve done some work with GPIO handshaking from a user space program, and I’ve watched the process with a logic analyser: I see the user space program running about 70% of the time with several msec gaps about every 10 msec. I also see some longer gaps (up to 120 msec!) every now and then. Don’t even try to do data collection with under 200 msec latency requirements from unmodified linux user space. There are some kernel mods you can get that will cut that down to about 60 usec. A better way to go is to use a PRU (which is why they are there) or to write a timer-based interrupt driver. That’s what you need to do to collect data at regular intervals, like for an FFT.

As for the simultaneous collection issue, the I2C broadcast command is the way to go if your devices support a broadcast CONVERT command followed by individual READ commands. Or maybe your sensors can all CONVERT on receiving a single GPIO signal?