iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We previously explained how iBeacons can be used with Apple Pass Kit to distribute things like coupons, boarding passes, store cards, event tickets, promotions, offers or just information.
We recently came across PassSlot that provides a framework for Apple Pass Kit. It provides a wallet pass designer, redemption system, payment integration and analytics.
There’s recent example code for the M5StickC, usable on almost any ESP32 device, that shows how to advertise iBeacon. The nice thing about this example is that it also shows the iBeacon parameters on the OLED display.
While adding iBeacon advertising to an ESP32 project can make sense, it’s often not the best choice if you only want advertising functionality. Stand alone beacons are more physically robust, use much less power and settings are configurable via ready-made apps rather than fixed in code.
Some beacons can be used to detect a button press. This is useful for lone worker, SOS or paging type applications. There are two main mechanisms:
Keypress Shown in Advertising
Depending on the beacon, this can be setup either to only advertise when the key is pressed (button triggered) or advertising all the time and the advertising changes. The former is better for longer battery life while the latter is better when you need to continuously know the beacon is working.
Advertising can be detected:
Keypress Detected via a GATT Connection
A few beacons allow a keypress to be notified to a connected application. Apps on iOS and Android, applications on single board computers and desktops/laptops can connect to a Bluetooth Service Characteristic to be notified when there’s a key press. Connection suspends advertising and prevents the button device from being seen/connected to from other devices.
| Beacons | via Advertising | GATT Connection | Notes |
|---|---|---|---|
| iBS01, iBS04, iBS01G, iBS01H, iBS01RG,iBS01T, iBS03G, iBS03RG, iBS03T | Yes | No | Button press is in the advertising data. |
| iBS02M2 | Yes | No | Can connect your own button. |
| M52 Plus, M52_SA Plus, M52-PA, U1, UL1 Thin | Yes | No | Button triggered broadcast. |
| S1, i7, D15N, E2, B10, P1 Plus, B7 | Yes | No | Set any of the advertising types to trigger on a button double or triple press |
| F6 Tracker Beacon | No | Yes | via SDK |
| MWL01 | Yes | No | AoA beacon. Button press is in the advertising data. |
| STiE10, STiE9 | No | Yes | Long pressing OFF does not cause the beacon to turn off but instead puts the beacon into ‘SOS’ mode where the configured advertising is stopped and the ‘SOS’ can be detected in the configuration app or your custom app and the ‘SOS’ state cancelled. |
| W2-P5202D3 | Yes | No | Button triggered advertising. |
| FSC-BP103 | Yes | No | Advertises more often. |
| F1, B1 SOS Button, B2 Button, W7, K11, K21, K3 | Yes | No | Advertises differently when button pressed. |
We offer consultancy if you need more project specific advice.
We sometimes get asked how many connections an iBeacon can support? The answer is ‘1’ but it’s often the right answer to the wrong intended question. The intended question is usually “How many receivers can see a beacon?”
Beacons don’t usually connect. They just advertise and can be seen by an infinite number of receivers that include phones, gateways or single board computers such as the Raspberry Pi.
The receivers only usually connect once, during setup via an app, to set the initial iBeacon parameters. When connected, the beacon doesn’t advertise which prevents extra receivers from connecting. Once set up, the app disconnects and the beacon starts advertising again.
Many gadgets and IoT devices need to connect to the Internet via WiFi. The problem is getting the WiFi credentials to the device when it isn’t connected yet. It’s a ‘chicken and egg‘ situation in that you need to connect to the device in order to set the WiFi settings but you can’t connect because you aren’t WiFi connected.
The usual, but complex, way to solve this is for the device itself to initially act as a WiFi router in ‘station mode’ while the user on a phone, laptop or desktop connects and uses a web interface to set the WiFi settings and then reboot. After rebooting, it’s not in station mode and instead connects to the assigned access point. The assigned local network DHCP IP address isn’t known to the user so they have to examine router settings or use some other contrived method to work out the URL to further administer the device.
None of this is simple for most users so alternative mechanisms are preferable. We previously mentioned Android WiFi Direct via Bluetooth and now there’s a new open standard, Improv, for setting up Wi-Fi via Bluetooth LE.
For Improv, the client (web or mobile) application sends the Wi-Fi credentials to the gadget via a defined Bluetooth LE Service (00467768-6228-2272-4663-277478268000). The device connects to the WiFi and returns a URL on the network that can be used to further administer the device.
Under the hood, a Bluetooth Characteristic is used to send a RPC Command to set up the Wi-Fi settings.
The code area of the Improv site has an SDK for JavaScript using Web Bluetooth and an SDK for Android. There’s also a device side library for ESP32 devices.
There’s a new Capacitor plugin for Bluetooth LE. Capacitor is new way to build web apps. Capacitor’s native plugin APIs allow easy access to common functionality, such as Bluetooth, across multiple platforms.
The plugin supports the web, Android and iOS. It allows scanning, GATT connecting, reading, writing and notifications. The source code is available on GitHub.
We have some new variants of the Meeblue M52 available.
There’s a new Mr Beacon podcast with Eason Huang of Minew. It describes how Minew focus mainly on hardware rather than full solutions and how they provide re-branded hardware for many platforms and beacon providers. Steve Statler (Mr Beacon) provides the insight that many of those platforms don’t really want to sell hardware and they are often focussing on software their customers might not necessarily want.
The conversation turns to the growth and challenges of IoT. The main challenges are lack of clarity of return on investiment (ROI), proof of concepts (POC) taking too long and end results not being scalable. Eason identifies that better preparation is required before starting. Steve suggests projects should initially bring in consultants to provide expert and neutral advice.
The podcast resonates with what we do at Beaconzone. We set up Beaconzone because we identified the reliance on subscription-based cloud platforms and beacons locked to platforms was limiting the available information, products and solutions. We set up BeaconZone in 2015 to provide for standalone solutions, using original manufacture beacons, not locked to subscriptions. We use and stock Minew and tens of other manufacturers’ beacons and gateways.
The issues of IoT projects also resonates with what we have seen through providing consultancy. Too many people come to us, too late, with projects that shouldn’t have been started because they had obvious technical limitations or have been developed in a direction that makes them technically or financially non-viable. A small amount of expert advice, early on, can make a huge difference and reduce risk.
Even when organisations know they should seek initial help and contact us, we sometimes find they are reticent about investing what is a relatively small amount of money compared to a failed POC cost. The reason is that these organisations have no experience of using Bluetooth for IoT so don’t know the unknown unknowns. Everything looks feasible until they are deep into the POC. It’s for these situations that we also offer quick, low priced Micro Consultancy.
We have the LW003-B Bluetooth LoRaWAN® Probe in stock that scans for Bluetooth LE devices and sends detected advertising via LoRaWAN®. This extends Bluetooth sensing up to 15Km.
LoRa provides relatively low throughout so it’s important not to send data for unwanted detected devices. The probe provides extensive filtering options to ensure only the data required for specific Bluetooth devices is sent via LoRa:
There’s recent research from Korea on Particle Filtering-Based Indoor Positioning System for Beacon Tag Tracking. The paper looks into how to improve positioning accuracy, reduce system complexity and reduce deployment cost through the use of a Particle Filter-based Indoor Positioning System (PFIPS).
A Kalman Filter is used to preprocess collected Received Signal Strength Indication (RSSI) data followed by a Particle Filter (PF) to approximate the location of a tag which improves the location certainties.
Simulations and experiments showed the system outperformed the legacy indoor positioning systems in terms of location accuracy by 24.1% and achieved median accuracy of 1.16 m.
Read Using Beacons, iBeacons for Real-time Locating Systems (RTLS)