This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Data streaming from multiple sensors (BLE + UART + TWI)

Hi, I want to use BLE for following situation and I wonder if it is achievable. I have a 3 boards with nrf51822. Two of these boards have mpu6050 sensors connected to nrf51822 via TWI (I2C). These two boards work as BLE peripheral and server. Third board is BLE central and client device. What I want to do is:

  1. read data via I2C from sensors on each peripheral
  2. send data from both peripherals to central via BLE.
  3. send collected data from central via UART (to computer). Generally central works as USB BLE dongle.

The problem might be because i want to send packet of no more than 20 bytes (I know that max 20 bytes per notification is possible) with frequency min 30 Hz (50 Hz is recommended).

Here are my questions:

  1. Is it possible to read 20 bytes from TWI and send it via BLE (peripheral) with mentioned frequency? I'm asking because I read that BLE generally "blocks" uC during his work. But in my situation I first read data and next I send it via BLE so i believe it is not problem.
  2. Is it possible by central to read data from 2 pheripherials via BLE and send it via UART with mentioned frequency ?
  3. How many such peripherals central can handle?
  • If you don't need live data of MPU then you can use external RAM to store data in it and then send it to central.

  • Unfortunately i need to send data in real time.

  • I have not done any work on the central side, but from the peripheral side, I don't think 30hz should be a problem.

    First, I would recommend using the MPU-6500 over the MPU-6050. The main reason is that the 6500 will work with a 1.8V supply, but it is also a better part. If this is a new design you might even consider using the new ICM-206x8, especially if you are power constrained.

    The next thing is to let the DMP hardware on the MPU-6xxx to do some of the work for you. Configure it to dump quaternions to the FIFO at whatever rate you can consume on the BLE side. The DMP hardware will oversample the accel/gyro and provide cleaner data then just reading raw data from the sensor.

    Use gpiote to wake up on interrupt from the MPU-6xxx and trigger the I2C read(s).

    Depending on your latency requirements you may not need to run the connection interval at 20 or 30ms if you are willing to let some of the notifications queue (you can send upto 6/connection interval). Make sure you timestamp the samples when you read them from the sensor, so you can correlate them on the central side. If you need very low latency you might be able to use the FSYNC pin to sync the connection interval to your sampling rate, but I'm not sure how FSYNC interacts with the DMP.

    I am using the MPU-6500 with the nrf51. If I had it do over again I suspect I would use the SPI interface over the I2C. The SPI interface is both faster and lower overhead and I'd imagine it is also lower power/byte.

  • Thanks for answer. My plan was to read raw data with appropriate frequency from each peripheral, send it to the central (and next to computer) and do all 3D real time calculation for each sensor on computer side using my own kalman filter algorithm. I didn't plan to use DMP because I don't know what kind of algorithm it utilizes. I suppose that reading data form sensors and send it to central via BLE is not problem (from the peripheral point of view) but i don't know how to set up the central to be able to collect data from few peripherals and pass it to computer in real time.

  • Yeah it is rather annoying that they treat the DMP as a magical proprietary intellectually property black box without even a high level description of the algorithms used. The whole DMP interface is horribly documented and the code they provide is rather bloated. But it does save a significant amount of power.

    If you aren't going to use the DMP then you might consider doing a two part kalman filter. Oversample the sensors on the peripheral and send kalman filtered data to the central. Then do a second stage fusion operation on the central.

    As long as you don't let the fifo on the MPU-6xxx fill up you can track when the samples where taken, so it doesn't really matter if things like radio events add latency. All that matters is if you get a regular sampling rate at the sensor and can correlate the samples in time.

Related