iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
Ericsson, who actively participated in the definition of the architecture and the development of the mesh profile specification, have a new article on Bluetooth mesh networking.
The article explains how the mesh network was designed and architected to provide for reliable throughput when there’s a large number of nodes. They also talk about a building automation usecase that they created to test the implementation.
Read more about Bluetooth mesh on our web site.
In most cases you can place your beacons and they ‘just work’. However, what if you suspect things aren’t working due to other devices using the same 2.4GHz radio spectrum? It’s possible to use specialist test equipment and spectrum analysers but these are very expensive.
A new, recent article by Mark Hughes describes Troubleshooting Tools for Your Next Bluetooth LE Project: Ubertooth and the Nordic nRF Sniffer.
It shows how to use inexpensive dongles on Mac, Linux, and Windows to intercept and analyse Bluetooth LE packets.
The same day we posted about the research paper on Bluetooth Mesh networks, the Bluetooth SIG happened to announce the public availability of their Bluetooth Mesh.
There are lots of marketing articles saying what will be possible and at the other end of the scale, mesh networking specifications that explain how it works. However, to implement these things, we need something in between marketing and specs that works with real hardware.
Today, there’s a new article on the Nordic InfoCenter blog that explains, in simpler terms, how the Bluetooth mesh works and introduces the Nordic SDK.
As we mentioned in our previous article, Bluetooth LE mesh networks tend to leave the application layer to the developer. This is so that mesh network can be used in many scenarios in many vertical industries. However, what’s particularly interesting with the Nordic SDK is that they have implemented some of the application level:
For beacons:
“We have therefore created a Beacon API as part of the Mesh SDK to do concurrent Beaconing and mesh networking”
Taking a look at the part of the SDK for beacons, there’s an API to define the device as a beacon with an advertising payload and advertising interval. The payload is up to the developer. While this falls short of defining APIs for the iBeacon and Eddystone beacon types, it provides a baseline for manufacturers and 3rd party solution providers such as ourselves to create new beacon products and solutions.
There’s a new research paper by Seyed Mahdi Darroudi and Carles Gomez of Department of Network Engineering, Universitat Politècnica de Catalunya, Castelldefels 08860, Spain on Bluetooth Low Energy Mesh Networks: A Survey (pdf).
It gives a consolidated view of mesh Bluetooth LE networks. It explains how Bluetooth LE was originally designed for a star network topology with limited range. While Bluetooth 5 increases the range, there are still scenarios that require longer range which can be solved by networking devices into a mesh. The paper covers current standard, academic and proprietary mesh networks and discusses the merits of flooding-based vs routing-based solutions.
One omission is FruityMesh that isn’t discussed in the paper. Another omission is discussion of battery/power use. One of the main features of Bluetooth LE is low power. This comes about because devices only transmit for about 1ms every period, where a period is typically 100ms to 1s. Once devices have to talk to each other, the transmission time goes up with a consequent increase of battery power. In practice, battery driven mesh networks end up having high latency and/or very low data throughput in order to conserve power.
Another consideration is what goes on top of Bluetooth LE mesh networks. The application layer is often left to the developer. For example, facilities to manage meshes of iBeacon/Eddystone beacons don’t exist. The application level ends up being proprietary and complex.
We have a limited number of the new USB FSC-BP109 long range beacon in stock.
This beacon transmits, iBeacon and Eddystone, between 1000m and 4000m depending on the receiving device.
Beacons vary in their range. The smaller battery beacons tend to have smaller 30m to 50m ranges to make the most of battery life. Larger battery beacons tend to have ranges up to 100m. Then there’s longer range beacons with ranges over 150m.
One thing to understand is what can block signals. In our experience, when a signal gets blocked, there’s no point trying beacons with longer ranges in the hope they will push the signal through the physical obstructions. Longer range beacons only work long range when there is unobstructed line of sight.
Nordic, who supply the System On a Chip (SoC) in many beacons, have recently released the nRF52810 SoC.
Nordic already offer the nRF52840 and nRF52832 but while these have been suitable for use in Bluetooth 5 beacons they are over-specified and hence too expensive for use in most beacons. The nRF52810 solves this problem by providing a reduced feature set that makes this SoC typically 25% less expensive. Nordic say:
“The nRF52810 represents the most accessible, single-chip Bluetooth 5 solution available on the market today.”
A post on the Nordic devzone explains the main differences between the nRF52810 and nRF52832. It’s mainly removal NFC and other peripherals that aren’t important for beacons.
The nRF52810 supports Bluetooth 5 high speed and advertising extensions but, interestingly, not long range. It’s expected that the removal of the redundant peripherals should also improve power and hence battery use.
TheGoodTraveller has a new post on how they have been using Eddystone beacons to get more web site traffic and hence more sales. Their article,
Three Lessons We Learned Selling Something that People Don’t Understand describes their experiments in engaging travellers at San Diego International Airport. They concluded that discovery is best achieved through signage and beacons:
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.
There are types of working where workers work alone without close or direct supervision. Employers have a legal duty of care to monitor such employees so that they can detect accidents, illness and, in some cases, an attack.
There are some rudimentary systems in place, particularly on sites such as airports, that use short range (1cm) RFID tags that workers have to periodically ‘check in’ to. With beacons, workers don’t have to check in and much of this is now automated. It also works at much larger ranges up to 300m.
Our BeaconRTLS system maps lone workers. Alerts can be created that show when people haven’t changed zone for a configurable amount of time. It’s also possible to trigger alerts when people enter or leave zones or when they press an ’emergency’ button on the beacon.
What’s more, the system can be used to map assets as well as people and when used with sensor beacons can detect and alert based on environmental factors such as temperature, humidity or whether doors are open or closed.
Contact us about BeaconRTLS.