Teensy 3.1 and multiple mpu-6050

Status
Not open for further replies.

SantiCA

New member
Hi to all!

I am a regular Arduino user, and I need to collect data simultaneously from 15 mpu-6050 sensors and send this data to a computer via bluetooth.
My first thought was to put an Arduino pro mini per mpu-6050 sensor and somehow coordinate the signals from each Arduino in the computer. Then I realised teensy 3.1 has a lot of analog entries and maybe this is a better option.

I was wondering if this is possible with a single teensy 3.1 card, or maybe is too much to handle.

Thanks in advance!:)
 
Hi to all!

I am a regular Arduino user, and I need to collect data simultaneously from 15 mpu-6050 sensors and send this data to a computer via bluetooth.
My first thought was to put an Arduino pro mini per mpu-6050 sensor and somehow coordinate the signals from each Arduino in the computer. Then I realised teensy 3.1 has a lot of analog entries and maybe this is a better option.

I was wondering if this is possible with a single teensy 3.1 card, or maybe is too much to handle.

Thanks in advance!:)

No, a single Teensy can handle this. But it has nothing to do with analog..

Here: http://playground.arduino.cc/Main/MPU-6050#multiple is a trick mentioned: (switching AD0)

The MPU data-interface is an I2C Bus. Don't forget external I2C-pullup-resistors and level-shifters - it depends on the breakout-board you use wether you need them or not.

May i ask, why you need 15 sensors ? Can you tell more about your project ? I'm curious :)
 
Last edited:
Thanks for your response!

Sorry, I said analog but i meant I2C. I2C needs 2 signals to work, but I assume you can share the clock signal for all the devices, is this correct?
I'm very new to I2C devices and I may sound a bit dumb, my apologies in advance... :(

My intention is to get the Euler angles for several body segments of a person, something like an interactive suit, and I need the system to be as small as possible, so it isn't too much intrusive for the person using it.

The trick mentioned in arduino playground is interesting, but they didn't try it with mpu-6050, so I don't know if that's a solution...:confused:
 
Ok, from briefly scanning the article, it should work on the Teensy, and you would need 1 digital output pin per sensor. I2c is a shared bus where each device has an address, and the master puts the address in the request, and only the device that matches the address will respond. The 'trick' is that the sensor has one pin that can switch address from 0x68 to 0x69, depending on whether the address is high or low. Normally this would mean would only be able to have 2 devices on the i2c bus. On the teensy 3.1/3.2/LC, you have 2 separate i2c buses, so you might be able to only support 4 devices normally.

You would use digitalWrite on all of the pins controlling the address, writing LOW to the one you want to talk to, and HIGH to the other devices. This means the one device you wrote LOW to will be address 0x68, and the others will be 0x69. You only send out commands to 0x68, so only the one device responds. Then you turn that wire to HIGH, and set the next one to LOW, and read that.

Now, i2c buses are meant to be fairly small, and whether you would be able to cram all 16 devices onto the same bus without getting electrical interference, I dunno.

As Frank B mentions, an alternative is to use an i2c multiplexer such as: https://www.adafruit.com/products/2717. This particular device can multiplex 8 different i2c buses. Since the sensor normally only has 1 address bit, you could put 2 sensors on each bus on the multipexer, or 16 devices per multiplexer. As I mentioned, recent Teensys now have 2 i2c buses, so using 2 multiplexers, you could potentially have up to 32 sensors on the Teensy without using any additional pins to control the address.

<edit>
The article you posted mentioned using a voltage divider on the Arduino to get the data pin voltages down from 5v. Given the Teensy runs at 3.3v, you probably don't need a voltage divider on the Teensy.

However, if you were planning to power the sensors from the Teensy 3.3v bus, be sure to calculate whether the Teensy can supply enough power to power all of the sensors and your communication devices. You might need an external voltage converter to convert to 3.3v to supply enough power (Teensy 3.2 should be able to supply 250mA, the 3.1 185mA, and the LC 120mA).

Another thing to consider, the i2c bus is a sequential device. If you have 16 sensors, by the time you've read all 16 devices, some period of time has elapsed, and so the last sensor will be at a delta from the first sensor. Whether it is enough to make a difference, I dunno.
 
Last edited:
On the teensy 3.1/3.2/LC, you have 2 separate i2c buses, so you might be able to only support 4 devices normally.

Michael - I normally use pins 18 & 19 for I2C communication, but why are the other two I2C lines (16 & 17) greyed out on the T3.1/3.2 pinout card?
 
Pins 16 & 17 are alternates for pins 18 & 19 for the same i2c bus. The second i2c bus on the 3.1/3.2 are pads #29 (SCL1) and #30 (SDA1) underneath the Teensy (on the card, the underneath pads are on the other side of the card). In order to use the 2nd i2c bus (or the alternate pins on the first i2c bus), you need to use the improved i2c library documented in this thread: https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3.

On the LC, the second i2c bus is on pins #23 (SCL1) and #22 (SDA1).

Like the main i2c bus, you will need pull-up resistors for the alternate i2c bus.
 
Pins 16 & 17 are alternates for pins 18 & 19 for the same i2c bus. The second i2c bus on the 3.1/3.2 are pads #29 (SCL1) and #30 (SDA1) underneath the Teensy (on the card, the underneath pads are on the other side of the card). In order to use the 2nd i2c bus (or the alternate pins on the first i2c bus), you need to use the improved i2c library documented in this thread: https://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3.

On the LC, the second i2c bus is on pins #23 (SCL1) and #22 (SDA1).

Like the main i2c bus, you will need pull-up resistors for the alternate i2c bus.

Wonderful information Michael. Thanks very much for sharing it!
 
The TCA9548A I2C multiplexer can be ganged 8x in principle since each chip takes one of eight I2C addresses by selecting HIGH or LOW on three address pins. Most breakout boards allow selection of these, Adafruit's allows all eight addresses, my breakout board only allows two, so sixteen I2C devices with the same I2C address can be used (with two of the multiplexer boards). I do have a variant with solder pads for changing two address pins for 4 x 8 = 32 I2C devices. Mine has the (4K7) pullup resistors already on the TCA9548A board. This is useful even if your I2C sensor board already has 10 K pullups on it since with long (~1 m) wires, the signal can be noisy or develop latency.

Of course, my boards are the appallingly smallest!
 
My thought is: Mpu6050 is a sensor that requires some calculations, since the raw data is not usable as it comes out of the sensor. Particularly, I use Jeff Rowbergs' code that is known to be the best algorithm to make a good use of this sensor. If I connect 15 sensors to the same board, with the multiplexer and all the calculations, Im afraid the output data could take too much time, since I want the data of all the sensors to be coordinated...

On the other hand putting one Arduino Pro mini per sensor is not too expensive, is an easy solution (I wouldn't have to write too much code) and I think it would improve the performance. The only problem I see is the power supply, I don't know if this system would consume too much power...

(My apologies for my bad english :p)
 
Jeff's code was the first open-source library to make use of the DMP (not really necessary for most applications), is a very popular library but is not currently supported (try sending an e-mail to Jeff!) and I find the coding style somewhat opaque and the library hard to use, so I wrote my own smaller but easier to understand and use sketch for Arduino and Teensiduino. Invensense has since published their version of an MPU6050 driver for ARM processors, but the same comments apply, at least to opaqueness and usability.

With the Teensy 3.1 operating at 72 MHz, you have plenty of processing power to handle 15 data streams. My advice is to use the TCA9548A I2C multiplexer, make use of the MPU6050 FIFO to store 512 bytes of accel and gyro data on each (comes with a time stamp, which you can use to coordinate) and burst read in sequence for scaling to and output from the Teensy 3.X, one will do!

I highly recommend Brian's Teensy 3.1-specific i2c_t3.h library since using the MPU6050 you can run the i2c communication speed at 1 MHz or even higher if your lines are high enough gauge and not too long (> 1 m). Can't really do this on a Pro Mini.

If for some reason you find this set up not working for you, you could always add more processors. But I don't think this will be necessary.
 
If you go to multiple MCU's depending on the cost/quality mini pro you buy - you could use Teensy LC's and have more ram and power and easily handle twice the sensors for same or less net cost, easily do all the pre-processing and then just push the data to the master the same way but not have a mixed processor set.
 
Status
Not open for further replies.
Back
Top