Last March we took a closer look at Bluetooth 5 and concluded there are tradeoffs between long range, high speed, legacy (today’s) phone compatibility and efficient battery.
We are starting to see corresponding development APIs appear for devices that will detect Bluetooth 5 beacons. Android (O) has a new setPreferredPhy call that allows apps to choose the PHY modes mentioned in our previous article.
As expected, high speed and long range are mutually exclusive and if you want to remain compatible with older (current) beacons then you can’t have the high speed or long range. Long range and high speed are only supported if the hardware supports it which means old (current) smartphones won’t get Bluetooth 5 support through a software upgrade.
The availability of the Android API raises new questions. Our understanding is that PHY is a low level thing and that the Bluetooth hardware can only work in one PHY mode at a time. If so, what if an app changes the PHY? Does this switch for all apps? What are implications? For example, what if one app, for example an existing app, needs to use older beacons in compatibility mode while another app wants to use Bluetooth 5 long range beacons? Maybe we are wrong and the underlying Bluetooth 5 firmware somehow multi-tasks PHY modes? Finally, how does the app know the device is Bluetooth 5 capable? It remains to be seen how the fragmentation of capability and behaviour is going to be workable on a typical app. Will most apps end up defaulting to compatibility mode, the long range and high speed only being used for special cases (devices)? In any case, we can see it’s likely that Bluetooth 5 is going to complicate beacon app development.
28/6 UPDATE: In response to this post, Martin Woolley of the Bluetooth SIG answered all our questions! Hardware, hence Android O, can have several PHY modes active at the same time provided the underlying device supports this.