iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We now stock the BlueUp BlueBeacon Sensor. This is one of the most capable sensor beacons we know of with up to 8 advertising slots. It detects temperature, humidity and air pressure. It also supports Quuppa and Eddystone GATT Service.
The two AA batteries (included) last 3.5 years with default settings.
Beacons can be used to detect if things or people are in a zone by either putting beacons on the moving things or having the beacons static in a zone.
For the beacons on things/people approach, a gateway or other scanning device looks for beacons in the vicinity and triggers actions. For the static beacons case, an app on peoples’ phone can detect beacon(s) in a zone and trigger actions.
We have some new beacons in stock that now provide a third way of detecting proximity. They use IR and PIR to detect the proximity of any item coming within range. For IR that’s <50cm and for PIR < 5m. These beacons transmit the current state via Bluetooth that can be picked up by an app or gateway.
It’s expected these beacons will be more suitable for IoT and Industrial scenarios.
We have the Feasycom FSC-BP109 long range beacon back in stock.
This Bluetooth Class 1, CE RED certified beacon transmits, iBeacon and Eddystone, between 1000m and 4000m depending on the receiving device.
There are new iOS and Android apps that allow up to 10 channels that can transmit anything: Eddystone-UID, Eddystone-URL, iBeacon or AltBeacon. You can still set up by sending AT commands through the laptop/desktop USB com port opening up the possibility of the advertising changing programmatically over time, for scenarios such as changing media displays.
This beacon is especially suitable for large open areas such as stadiums where it can replace 10s or 100s of beacons with shorter range.
We have some new and updated Minew beacons in stock. We have the updated i7 and new E7 that have new firmware that supports up to 6 advertising slots that can include iBeacon, Eddystone UID, Eddystone URL, Eddystone TLM, device info and in the case of the new E7, acceleration data. These beacons also use the new Nordic nRF52 for improved battery life.
E7
We also have a version of the E7 with standard Minew iBeacon firmware.
There’s also the new small, light C4 that’s suitable for wearing or on a use on a keyring:
C4
There’s an interesting new article on the Nordic Blogs on Bluetooth 5 Advertising Extensions . It explains how the number of channels is increasing, from 3 in Bluetooth 4.0, allowing larger advertising payloads in one of the 37 other data channels. A single advertising packet can hold up to 255 bytes of data, up from 37 in Bluetooth 4.0. The chaining of packets allows for larger payloads up to 1650 bytes.
As the article mentions, we have to wait until tablets and smartphones support Bluetooth 5. Also, we have to wait for new Beacons with Bluetooth 5.
We have some new documentation for our AnkhMaway customers*. In the Ankhmaway Technical Area we have two new Android examples on:
We also have a new user guide for the iB001W rechargeable wrist beacon.
* Password protected – only available to customers who have purchased products.
Renaud Lifchitz, a security consultant, has some great new slides on Security review of proximity technologies: beacons and physical web.
He mainly concludes that:
The spoofing issue is well known and is a necessary consequence of a broadcast, non-connectable, type mechanism. Fortunately, people mainly only use these things for nefarious purposes when there’s a profit motive. Spoofing beacons rarely benefits anyone.
The beacon passwords thing sometimes happens when beacons are set up using the manufacturer app. This is usually a one-off event, when the beacon is first set up, when the user is usually control who in their surroundings. Hence, it’s very unlikely other people will ‘sniff’ the beacon password.
For Web Bluetooth, GATT communications without a known password is benign. You can’t do much by just connecting to a beacon or Bluetooth device. You usually need a password to change or view security sensitive data.
While it’s good to know these things, it’s very unlikely any of these security observations will ever be a problem. Beacons don’t tend to be used in critical or valuable scenarios so the risk of things being subverted is low. There are much easier, more valuable and higher profile targets for hackers in the shape of servers, desktops, laptops and apps. Even if one of the mechanisms mentioned in the slides were used one day, the consequences, for most scenarios, would be minimal.
There’s a recent story at LA Times on how Newport Beach will monitor drivers’ Bluetooth data to analyze traffic, congestion.
It’s a traffic monitoring system that receives signals from Bluetooth-enabled equipment such as cellphones and in-car hands-free devices, building a real-time picture of motorists’ routes and travel times.
This is a simple example of a real time locating system using Bluetooth devices that are already out there as opposed to, more focused, Bluetooth beacons that are specifically being tracked.
Yes, provided the phones use Windows Phone 10 or later. Prior versions don’t have the necessary APIs to scan for beacons.
There’s also a 3rd party library that abstracts away some of the complications of interpreting the different kinds of advertising (iBeacon, Eddystone). There’s alsoa sample app.
Google have quietly cut much of the usefulness of using Nearby with Beacons. The Google Beacon Tools app previously allowed you to register beacons that advertise an id (not URL), even iBeacon, associating the beacon with either a URL or an app so that Android users receive a notification when they come across a beacon.
The Android Google Beacon Tools app that is used to register Nearby beacons has had some updates. Google have removed the capability to register iBeacons and the app now goes into a provisioning state to connect to the beacon being provisioned:
The Android Beacon Tools app can now only connect to and provision Eddystone GATT service Eddystone-UID and Eddystone-EID beacons otherwise it then shows “Eddystone configuration service not supported by this beacon”:
The majority of beacons, not just ours, don’t support Eddystone GATT service. This severely cuts down the types of beacon that can now be registered with the Beacon Tools app (in our case only 7 beacons).
The Nearby programming API, that you can use to register Nearby beacons in your app, still declares it supports iBeacon so it’s still currently possible to register non Eddystone GATT service beacons but not so easily.
This is going to be a problem for organisations who have used Nearby as an alternative to Eddystone-URL. If they have been relying on the Beacon Tools app rather than using their API via their own app, they won’t be able to register more beacons. This puts them into the difficult position of needing to either purchase Eddystone-GATT Service beacons or write an app that uses the API. However, there must have been some reason to restrict Beacon Tools to only Eddystone Standard GATT beacons and this might, one day, also apply to the API.
To be clear, this doesn’t affect Eddystone-URL. Eddystone-URL never, and still doesn’t need, registration at Google.
Together with the recent removal of Eddystone-URL detection from Chrome for iOS, this sees Google distancing Eddystone from iOS and iBeacon from Android OS. Organisations can still write apps that scan for iBeacon or Android and Eddystone on iOS. However, for some unknown reason Google no longer wants to support this in their own apps and tools.
