# Trying to use MUCs to sample data from IMUs over bluetooth at a specific sampling frequency

I am designing a data collecting system and I want to be able to collect the data from both sensors at a rate of 500Hz. I was wondering if anyone could help me calculate/prove this mathematically before I actually by the parts? I want to prove my design before I can purchase the components.

I am using two Rfduinos, two MPU 6050’s and a BLE wireless dongle for the computer. The first Rfduino will recieve data from its IMU and send it to the second IMU. The second Rfduino will also receive data from its IMU and then package both its data and the first Rfduinos data and send it to the computer.

My thought process: If every degree of freedom is 2 bytes. That means 12 bytes from each sensor. So the first RFduino needs to send 12 bytes (Plus an extra 2 bytes most likely too designate what kind of data it is and who is sending it ex. FF, 00), meaning the second Rfduino will need to send 24 bytes (Plus the extra “signature” bytes to allow the computer to interpret the data). If I estimate around 28 bytes sent just to be safe at a rate of 500Hz, that would be 14000 Bytes/s or 112000 bits/s (112000 Baud). Since the bluetooth can communicate at a max rate of 115200 Baud, does that mean I will just be shy of 500Hz sampling rate?

Also, I know the MPU 6050 has a theoretical max sampling rate of 1kHz over I2C but is there a way to determine the actual sampling rate? With fast mode I2C (400kHz), will I be able to sample the IMU’s fast enough for every degree of freedom’s raw data?

In conclusion, can anyone help me determine whether there are any factors that would limit my sampling rate and then help me calculate (or estimate through calculation) the sampling frequency?

Thanks!

EDIT: I am using this to collect raw accelerometer and gyroscope data from different parts of the body. The faster the sampling frequency, seems to mean the more accurate the data because we use the discrete data to create a "continuous" data curve.

Parts:

• The receive/retransmit will add latency so that the two sets of measurements will definitely be taken at different times. It's a bit of an odd setup, why not have both transmitting directly to the host? – pjc50 Jun 13 '16 at 15:21
• Why do you need such a rate? Does the computer need it in realtime? You can sample and pack the data from multiple samples to reduce the overhead. You can even perform some compression, as the consecutive samples are likely to be similar, and thus partially redundant. – Eugene Sh. Jun 13 '16 at 15:27
• @Eugene - Seems like some sort of gesture based controller to me. Probably OP wants both sensor readings in realtime. – Whiskeyjack Jun 13 '16 at 15:31
• @Whiskeyjack I think there could be a problem the OP is not thinking about. The computer side. 500Hz = 2ms per sample from each source. The typical non-realtime OS userspace application will have hard time receiving and processing this information. – Eugene Sh. Jun 13 '16 at 15:36
• Another problem I see is that the ADC on the rfduino is pretty slow, have worked with it before. I wanna say you'll top out at ~1kHz sampling rate. You may want to run some tests to factor in sample and conversion time. – RYS Jun 13 '16 at 15:46