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.

Parents
  • 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.

Comment
  • 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.

Children
No Data