We have the new ASensor beacon in stock. This is our smallest sensor beacon measuring only 37.3mm x 37.3mm x 7mm and it uses the power efficient Dialog DA14580 that gives up to 1.5 years from a CR2025 battery.
The beacon supports iBeacon, Eddystone or sensor advertising. For sensor mode, the temperature, acceleration and battery level are in the advertising data.
We now have the AprilBrother Wireless iBeacon Receiver in stock.
The Wireless iBeacon Receiver receives (any manufacturer) beacon advertising broadcasts and sends them on via MQTT via your WiFi access point. It can scan for multiple beacons at the same time and provides updates up to 1 per second.
This device can be used to monitor the health of beacons or in other usecases whether beacons have come into range or out of range. It can also be used with sensor beacons in IoT-type scenarios.
An interesting beacon has appeared on Kickstarter that’s not just technically interesting but has a high likelihood of coming to fruition because it has been created by someone who has already delivered twice on Kickstarter.
Another aspect of the beacon that’s different is that it can act as a Bluetooth master as well as slave. Most beacons are slaves in that things connect to them. The puck beacon can do the connecting and connect to other Bluetooth devices such as other Pucks. This allows for mesh style networking or can be used to cause the beacon behaviour to change depending on the status of other Bluetooth devices in the vicinity.
The hardware, software, libraries and documentation are all Open Source that future-proofs any ideas based on this beacon should the developer be no longer be able to support the product or if your design needs to move outside the original hardware and software scope.
We hope to stock this beacon when it becomes available.
We like Nag Murty’s tweet where he says…
“Think ibeacons are only for retail? How about using an ibeacon as a health coach”
The Product Hunt web site video shows how he is using beacons to prompt himself to do more healthy things.
Nag doesn’t share how he does this but it’s fairly simple to implement. You can use just about any beacon with AutomateIt on Android or Proximitask on iOS to create a notification when you pass a beacon.
We have the new iGS01 Bluetooth WiFi gateway in stock. This gateway automatically detects iBeacon and Eddystone beacons and passes on the raw advertising data via WiFi to your desktop, server or cloud service. It can be used to create systems that do things when they detect beacons or when beacons are no longer present. Alternatively it can be used to monitor beacon battery levels or sensor data where these are present in the Bluetooth advertising data.
Advertising data can be filtered by RSSI and advertising data pattern. The data can be sent via HTTP (POST), TCP or MQTT. The unit is powered by standard micro-USB.
The iGS01 provides a software-free way of getting beacon sensor data into the cloud for IoT applications.
We now have the white version of the iB003N-PA in stock. The iB003-PA is our longest range beacon and can reach up to 300m in open space. Other features of this beacon include motion triggered broadcast, accelerometer sensor (in advertising data), the ability to send iBeacon & Eddystone simultaneously and waterproofing.
We check beacons as they come into stock because we invariably get a few that are dead on arrival. We had a faulty iB003N-PA this time so this gave us the opportunity to open one up. Here’s the pcb:
The largest chip is the N51822 SoC found in many beacons. At the very top is the PCB antenna. The thing on wires in the middle is the buzzer. The chip at the top is the RFAXIS X2401C 2.4GHz RF front end that gives this beacon its long range.
Since we have started selling the AKMW-iB003N-SHT and AKMW-iB004N PLUS SHT we have been getting a few questions regarding accessing the temperature and humidity data.
You should first read the manufacturer’s SHT20 User Guide (username and password supplied with your beacon).
If you are connecting via GATT to read the sensor data then you will need to set the beacon to be always connectable. The way to do this is (for some strange reason) only shown in the iB001M user guide:
So if you wish to transmit iBeacon and remain connectable, set the value to 0x82. Note that if you subsequently set the beacon ‘on’ or ‘off’ in the ‘simple’ configuration screen, accessed via the spanner icon (Android) or Configure option (on iOS), then this will overwrite your set value.
However, you might instead consider reading the sensor data from the advertising data which a) is much easier to program and b) uses much less beacon battery power and c) allows multiple apps to see the data at the same time.
UPDATE: There’s now an iOS example app in the BeaconZone AnkhMaway technical area.
Google quietly announced Nearby with beacons yesterday. Up until now, beacons have always needed an app to scan for them. Even with Eddystone-URL, an app is needed in the form of Chrome on iOS or Android or the Physical Web app. Google Nearby bakes the beacon scanning and notifications into the OS, more specifically, inside Google Play Services so no app is needed.
The developer site explains how to set up Nearby beacons. The important thing to know is that Google Nearby has nothing to do with Eddystone-URL. Instead you should use Eddystone-UID or Eddystone-EID, even if your final destination is a URL. You then register the beacon with Google.
The user still needs Bluetooth and location on in order for Nearby beacons to be detected. Also, it relies on Google Play Services which won’t be available on forked versions of Android such as the Kindle Fire. It’s also not yet clear what version of Play Services is needed and the current status of rollout.
Something that will detrimentally affect uptake is the fact that this is all Android specific. There’s no equivalent on iOS so companies looking for a universal solution will still need to use Edddystone-URL or iBeacon with Android and iOS apps.
The site for the forthcoming The Hitchhiker’s Guide to The Beacosystem book has a new video interview with Jeff Russakow, CEO of Gimbal. Here are some insights from the interview.
Most beacon projects need an app. Gimbal is partnering with companies such as Shazam to get Beacon detection working on larger numbers of phones and then convincing those users to install a more specific app for a for more immersive experience. This made us wonder whether Eddystone-URL/the Physical Web could also provide this function. Could Eddystone URL be used to convince the user to install a specific app for a for more immersive experience?
Jeff talks of providing experiences rather than coupons. Experience is not a coupon. It’s important to know your customer (through context, including via beacons), before pushing coupons.
The video mentions some interesting usecases for banks. There are also a large range of things that can be done automatically for users when they reach a location. Beacons can also be used to provide analytics. Not analytics about triggered coupons or experiences but web analytics for the physical world. Simply knowing where people are and what they are doing can aid other business processes.
The conclusion is that beacon technology is relatively mature but under-commercialised. It offers new, varied opportunities, especially outside the marketing world. We agree with Jeff’s view is that industry could do with more thought leadership.
Some manufacturers over-sell the capabilities of their beacons and pre-sales literature sometimes mentions features that are only available via manufacturing customisation. They are sort of saying it’s possible, but you will find you have to pay a lot extra for a custom version. We only list the features actually provided by the beacons we sell.