Bluetooth 5 2Mbps Demo with nRF52 Series and Samsung Galaxy S8

Bluetooth 5 - now arriving in smartphones

As we know, Bluetooth 5 was launched last December by the Bluetooth SIG. The nRF52 Series from Nordic have always had Bluetooth 5 and its arrival in the mix for the nRF52 Series and this family of SoCs was designed early on to be able to meet the exciting new features of Bluetooth 5. Smartphones play such a key role in most Bluetooth products that their adoption of new Bluetooth features is always eagerly anticipated, as this is fundamental to the use of new Bluetooth features.

The Big News: Samsung Galaxy S8 supports Bluetooth 5 2Mbps

This is big news because over 90% of all Bluetooth low energy applications have a smartphone as either, a part of their primary use-case, or as a secondary use-case. The phone is part of the application. Therefore, when significant changes come to Bluetooth technology, we cannot really put the benefits into the hands of the public until the phones have support for it. Samsung, the world’s biggest phone maker by volume released their flagship Samsung Galaxy S8 a few weeks ago, and it has Bluetooth 5!

We got our hands on one as fast as we could and decided to make something really cool to demonstrate where Bluetooth 5’s great new features can take us.

Our demo: Moving images over Bluetooth 5

We wanted something that clearly demonstrated what Bluetooth 5’s new high throughput mode means. What could be better than trying to push moving images across a technology associated with simple sensor measurement and actuation communication? Therefore, that is what we did. So check out the video below for yourself, and get excited about the possibilities of Bluetooth 5.

  • I see some odd behavior specifically with the S8 - for some reason it appears to be reserving two bytes of payload. I've tried:

    • Negotiate ATT MTU of 69 and try to send 66 bytes, since there should be 3 bytes of ATT overhead: truncated to 64 bytes
    • Negotiate ATT MTU of 158 and try to send 155 bytes: truncated to 153 bytes

    This doesn't occur on an S7, am I missing a source of overhead?

    All of these tests are done with a PDU max size large enough to fit the ATT packet in one PDU.

  • I also have the ringbuffer errors. How is it possible that main.c uses classes inside (myCamera)? Isn't .c suposed to be compiled with gcc and .cpp with c++?

  • Great job and the potential is unlimited. Thanks for sharing.

  • Has anyone been able to get this to build? I pulled down the code and tried to build it with my version of IAR. I get a bunch of errors that appear to be associated with ringbuffer.h, which appears to be for ringbuffer.cpp.
    The default settings for the project are:

    image description

    If tried to change the project to C++ and it resulted in large number of errors.

    Does it matter where the additional files (found in the cpplib) folder is placed? Do the files in the cpplib folder need to be built differently?

    Please let me know if anyone else has success.


  • Hi all

    I haven't tried making the phone the peripheral, but I doubt this would provide any higher throughput. You don't have to be the master device to end the connection event, either device can just stop ACK'ing the packets. Since most use cases require the phone to be the central I expect the performance to be better in this case.


    1. I think the production chip is expected for a Q1 2018 release.

    2. Yes, the Android app is also available on Github: Android-Image-Transfer-Demo

    Yes, the example should work with any phone back to Bluetooth 4.0. BLE is designed to allow newer devices running a newer version of the standard to communicate with older devices, simply by disabling features not supported on both sides.

    The device list in the app will only show devices advertising the right unique UUID. Unless you have programmed a kit with the image transfer firmware you will not see any devices in the list.

    Best regards