bluefruit NRF52 max connection interval speed (connInterval)

Question

I've got an Adafruit Bluefruit NRF52 hooked up to the Adafruit BNO055 9-axis orientation sensor, gathering 3 axis of absolute orientation plus 3 axis of acceleration (6 floats in total) and sending over Bluetooth through bleuart. I need the bleuart to update every 7.5 milliseconds with a new line of values, but when I run it, it doesn't print more than about 20 lines new lines of values every second. Essentially I need values to update as quickly as possible, as I am measuring very high speed, high fidelity movement.

At the start of each line I also have three digit number, which represents the calibration status of each sensor on the IMU. Each printed line looks something like:

303 68.69   4.19    -2.19   -0.12   0.14    -0.40

I am currently streaming to my iphone with the latest iOs version, which in theory can handle 7.5ms intervals.

I've read that a solution may be to buffer the values and send over in a larger chunk at larger connection intervals, but am unsure on how to do this.

My relevant Arduino code is below:

Bluefruit.setConnIntervalMS(7.5, 20);

void loop()
{
    imu::Vector<3> accel = 
    bno.getVector(Adafruit_BNO055::VECTOR_LINEARACCEL);

    /* Get a new sensor event */
    sensors_event_t event;
    bno.getEvent(&event);

    /* Display the floating point data */
    bleuart.print(event.orientation.x);
    bleuart.print("\t");
    bleuart.print(event.orientation.y);
    bleuart.print("\t");
    bleuart.print(event.orientation.z);
    bleuart.print("\t");

    /* Display the floating point data for Linear Acceleration */
    bleuart.print(accel.x());
    bleuart.print("\t");
    bleuart.print(accel.y());
    bleuart.print("\t");
    bleuart.print(accel.z());
    bleuart.print("\n");
}

Answer 1

iOS doesn't actually support a 7.5ms connection interval. Check the connection parameters section (11.6) in the Apple developer guidelines. Just because you are specifying a CI that low doesn't mean that you'll actually get it. In this scenario the nRF52 is the slave and only requests an interval that low from the master (your phone). The master, if it so wishes, can completely disregard the request you make.

You'd be better off, as you've already eluded to, buffering your data and sending it via a custom characteristic. Figure out how many bytes you need and maybe you can pack a couple of readings into a single BLE write. If you're really struggling with throughput then you'll need a custom service with multiple characteristics. I recently worked on a project that streams 8 channels of data (~125Hz/16-bit) over BLE with three characteristics and this is bordering on the maximum throughput you can achieve.

As an aside: judging data throughput by the amount of lines printed per second is a big no no. Print functions typically have huge overheads and will drastically affect your measured throughput in a negative way.

Let me know if I can help further.