iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
Minew has a new video showcasing the G1:
The G1 gateway collects advertising data from iBeacon, Eddystone, Bluetooth LE sensor and other Bluetooth LE devices and sends it to your server by HTTP(S) or MQTT/ using WiFi or Ethernet.
More information:
Available Gateways
Beacon Proximity and Sensing for the Internet of Things (IoT)
Beacons in Industry and the 4th Industrial Revolution (4IR)
The demise of Google Nearby prompted some commentators to declare the death of beacons. However, here at BeaconZone we are actually seeing a resurgence of the use of beacons in retail.
Gone are the unsolicited notifications and gone are the ‘get rich quick’ marketers. The scenarios that remain tend to use beacons as an adjunct to something else rather than being the main solution itself. For example, they are used to provide triggering in CloseComm‘s WiFi onboarding app used by Subway, McDonalds, BurgerKing and CircleK and NCR.
Beacons are being rolled out to many food retailers, particularly in the USA. They are also taking new physical forms as witnessed by Mr Beacon:
If you are looking for more innovative uses of beacons in retail, take a look at Alibaba’s Fashion AI concept store as mentioned in the latest Wired (UK):
RFID and Beacons are used to detect items picked up during shopping so that customers can collect what they have looked at, have accessories automatically selected and view what’s in stock. Once they are home, a virtual wardrobe allows customers to buy anything they saw in store.
Beacons can also be used to enable audit compliance. Eric West, Head of Strategy at IMS has a useful free pdf on takeaways from GroceryShop, the retail industry conference. The pdf also mentions the use of beacons in lighting to drive location-based messages and wayfinding. Also:
“Amazon’s 2017 acquisition of WholeFoods was a “tipping point” that ensured all grocery players were speeding up their digital plans.”
Read about Beacons for Marketing
We mentioned Wiliot last March and since then their R&D team has created early engineering samples that prove it’s possible to create a battery-less Bluetooth LE beacon harvesting energy from radio frequencies (RF).
The Wiliot device looks more like a RFID tag than a traditional beacon in that it’s supplied as a very thin PVC inlay sheet containing the chip and wire antenna together. The thin form factor, no battery and the relatively low cost will allow it to be manufactured into or stuck onto clothing and packaging that will provide for many new usecases.
Producing such a device isn’t easy as it can’t use existing System On a Chip (SoC) devices as produced by Nordic, Dialog and Texas Instruments (TI) because they are too large and use too much power. Wiliot has had to create their own SoC from the ground up, including software tools to develop and program the devices. We have been told it will be a year before Wilot has all the components in place for commercial rollout. Meanwhile, selected organisations can join the Early Advantage Program (EAP). There’s a new a product overview (PDF below) that explains the EAP and the main usecases, connected packaging, connected apparel, logistics and asset tracking:
Wiliot already have Early Advantage Program (EAP) agreements in place with over a dozen brands including top fashion brands, a telco, appliance companies, a furniture brand and packaging companies.
AI machine learning is a great partner for sensor beacon data because it allows you to make sense of data that’s often complex and contains noise. Instead of difficult traditional filtering and algorithmic analysis of the data you train a model using existing data. The model is then used to detect, classify and predict. When training the model, machine learning can pick up on nuances of the data that a human programmer wouldn’t see by analysing the data.
One of the problems with the AI machine learning approach is that you use the resultant model but can’t look inside to see how it works. You can’t say why the model has classified something some way or why it has predicted something. This can make it difficult for us humans to trust the output or understand what the model was ‘thinking’ when the classifications or predictions end up being incorrect. It also makes it impossible to provide rationales in situations such as ‘right to know’ legislation or causation auditing.
A new way to solve this problem is use of what are known as counterfactuals. Every model has inputs, in our case sensor beacon data and perhaps additional contextual data. It’s possible to apply different values to inputs to find tipping points in the model. A simple example from acceleration xyz sensor data might be that a ‘falling’ indicator is based on z going over a certain value. Counterfactuals are generic statements that explain not how the model works but how it behaves. Recently, Google announced their What-If tool that can be used to derive such insights from TensorFlow models.
Read about Machine Learning and Beacons
If you work in IT and particularly if you have knowledge of programming, you will know it’s best to be informed of data rather than repeatedly request changes.
Repeatedly requesting changes, called polling, wastes resources when there’s no data returned. It also doesn’t get the data as soon it is available as you have to wait for the next poll.
A feature of our BeaconServer™ and BeaconRTLS™ is that they offer change stream data on all database data. Change stream is a standard web (HTTP(S)) protocol that provides data to systems and apps as and when it becomes available. The client sets up a long running HTTP connection and then receives updates.
The stream looks something like:
First you get an ‘ok’ followed by data as and when it becomes available. The above only shows a generic iBeacon. When used with sensor beacons this also includes all decoded data such as movement, temperature, humidity, air pressure, light and magnetism (hall effect), proximity (short range IR and PIR) and fall detection.
BeaconServer™ and BeaconRTLS™ provide REST based insert, update, query and change stream on all data allowing external systems and apps to fully use the system. This can also be authenticated via HTTP header tokens to prevent unauthorised access.
An example of use of the change stream is BeaconRTLS™ itself. The web UI uses the change stream to asynchronously update the UI with no flicker or redraw. All data, including beacons, locations and alerts are obtained asynchronously from the server (image below not live at it needs login):
We see some companies only after they have gone a long way down a particular road only to discover they made a big mistake early on. It might be, for example, they have heavily committed to the wrong beacon, wrong platform or have assumed something on one of the mobile platforms. They didn’t do their research. Often we can help them get on the right track but sometimes not.
At the other end of the research scale we have other companies who ask us “Will beacons work in an xyz environment?” where xyz has ranged, for example, from underground on the tube for the police to inside cars for a car retailer. Taking this further, we also get many, what we call, “armchair entrepreneurs” who want to work everything out before even looking at a beacon.
While we have a lot of expertise and provide advice through consultancy, it’s often the case that there are some aspects that are unknown until things are tried for real in the actual environment. Wireless solutions can be very fickle.
A lot can be learned about beacons, Bluetooth and the environment by buying one inexpensive beacon and trying things out. In the case of software, try implementing a thin slice through the proposed system touching on the perceived risky or unknown areas. Experiment before committing. Don’t go all in buying thousands of beacons and commissioning full custom software until you are confident things will work.
Consider a Feasibility Study
Most beacons provide a battery level % indication that’s visible in advertising and/or the manufacturer configuration app. It’s also usually visible via a Bluetooth Service Characteristic.
Some observations:
Here’s an example for Energizer Lithium AA:
For a typical CR2032 Lithium coin cell:
A consequence of the above factors is that you can’t estimate battery life by looking at battery percentage over time. You need to measure current use. We have a previous blog post on this topic.
Battery level can only be used as an indication that the battery is low and should be changed.
A problem with navigation in vehicles is that location can be lost in radio-shadows such as in tunnels and in tree covered areas. ChoonSung Nam and Dong-Ryeol Shin of Sungkyunkwan University, Suwon, Korea have a new paper on Vehicle location measurement method for radio-shadow area through iBeacon.
Beacons are placed at the side of the road and instead of advertising unique ids in the form of iBeacon or Eddystone, they advertise absolute Global Positioning System location data. Together with the received signal strength (RSSI) this allows the vehicle to better determine the location.
Following on from Google to Stop Serving Android Nearby Notifications, today we have retired EddystoneCMS.
If you want to use beacons for marketing you now need to have an app that listens for iBeacon or Eddystone advertising. In some ways this is better than the discontinued Nearby notifications. For marketers it is more:
However, this is at the cost of requiring the user to install an app. Marketing using beacons is best retro-fitted into existing apps rather than within marketing specific apps for which you will need a large incentive for consumers to install.
In our previous article iBeacon Microlocation Accuracy, we wrote about ways of using beacon RSSI to determine location. However, what if you were to use and combine beacon RSSI with other ways of locating to create a hybrid method? This is the topic of a new research Unsupervised Indoor Localization Based on Smartphone Sensors, iBeacon and Wi-Fi by Jing Chen Yi Zhang and Wei Xue of Jiangnan University, School of Internet of Thing Engineering, China.
The paper describes UILoc a system combining dead reckoning, iBeacons and Wi-Fi to achieve an average localisation error is about 1.1 m.
The paper also compares the trajectories obtained using different localisation schemes:
