iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We have the new Arduino BLEPad in stock. It’s a small wearable ‘Lilypad’ style board that includes a DA14580 BLE module for communication via Bluetooth 4.0 (LE) as per our other beacons.
BLEPad 31mm x 31mm
The BLEPad differs to other LilyPad boards in that the ATmega32u4 has built-in USB communication, eliminating the need for a separate USB-to-serial adapter. This allows the BLEPad to appear to a connected computer as a mouse and keyboard, in addition to a virtual (CDC) serial / COM port.
We have the new ABKey01 beacon in stock. This beacon is different in that it can send out extra beacon advertising for 30 seconds when the button is pressed.
This beacon is based on the low power DA14580 SoC which means the CR2032 battery (not included) can last up to 1.5 years.
For a while now, we have had enquiries from companies interested in our BeaconRTLS but not wanting the whole thing. In some scenarios such as IoT, machine learning and even locating you just want to collect data and not visualise it on maps/plans. Also, our BeaconRTLS™ was found to be overkill for small scale projects that don’t need the extremely high throughput.
Today, we have released BeaconServer™. It’s a ready-made system to collect multi-location beacon advertising data and make it available to other people, systems and apps. It allows you to collect, save and query beacon data without any coding.
BeaconServer™ comes in the form of a self install. Please see the BeaconServer web site for more information.
We have the new AprilBrother BLE Gateway V4 in stock. This is the first gateway to support both WiFi and Ethernet.
Another first is that it sends advertising to your server using the efficient MessagePack JSON format.
When creating apps to discover beacons, there’s often the temptation to use cross platform tools to create both iOS and Android apps at the same time. Such tools are often based on web (WebView screen) technologies and Javascript.
The first problem you will encounter is that few of the cross platform tools support Bluetooth. Even if they do, they don’t support it to the degree required to implicitly use the latest iOS and Android Bluetooth APIs. This is one of the main problems with cross platform in that functionality always trails the underlying native OS functionality.
Another problem is that there’s no one Android browser upon which the WebViews are based. Niels Leenheer has a (old but still relevant) set of slides that explains how browsers vary across Android versions, devices and phone manufacturers. The consequence of this is that getting any non-trivial WebView-based app to work across many device types is very difficult.
The next problem is functionality. It not only lags the underlying OS functionality in the use of APIs but also features are absent. This often requires some native coding which causes the app to become more of a Frankenstein creation with consequent unexpected complexities.
For best performance and OS look and feel you have to use native development. It’s possible for hybrid apps to look and feel like Android and iOS but it takes a lot of effort due to the previously mentioned browser fragmentation. It’s possible to get near-native app performance by replacing (bundling) a better Javascript interpretor. However, these extra complexities are what you were trying to avoid by using the cross platform framework in the first place.
If the above doesn’t persuade you, even Mark Zuckerberg regretted using web technologies in apps in 2015. This didn’t stop others trying. There are some detailed posts on Medium explaining how AirBnB is moving back to native development and how the difficulties are not just technical but also organisational.
If you are writing apps or getting apps written we recommend you save yourself some grief and write them using native code.
Benedict Evans of Andreessen Horowitz, a venture capital firm in Silicon Valley, has a thought-provoking blog post on Ways to Think About Machine Learning.
Benedict asks what new things machine learning (ML) could enable. What important problems might it actually be able to solve? There are (too) many examples of machine learning being used to analyse images, audio and text, usually using the same example data. However, the main question for organisations is how can they use ML? What should they look for in data? What can be done?
Much of the emphasis is currently on making use of existing captured data. However, such data is often trapped in siloed company departments and usually needs copious amounts of pre-processing to make it suitable for machine learning.
We believe some easier-to-exploit and more profound opportunities exist if you use new data from sensors attached to physical things to create new data. Data from physical things can provide deeper insights than existing company administrative data. The data can also be captured in more suitable formats and can be shared rather than stored by protectionist company departments.
For example, let’s take movement xyz that’s just one aspect of movement that can be detected by beacons. Machine learning allows use of accelerometer xyz motor vibration to predict the motor is about to fail. Human posture, recorded as xyz allows detection that patients are overly-wobbly and might be due for a fall. The same human posture information can be used to classify sports moves and fine tune player movement. xyz from a vehicle can be used to classify how well a person is driving and hence allow insurers provide behavioural based insurance. xyz from human movement might even allow that movement to uniquely identify a person and be used as a form of identification. The possibilities and opportunities are extensive.
As previously mentioned, the above examples are just one aspect of movement. If you also consider movement between zones, movement from stationary and fall detection itself, more usecases become evident. Sensor beacons also allow measuring of temperature, humidity, air pressure, light and magnetism (hall effect), proximity and heart rate. There are so many possibilities it can seem difficult to know where to start.
One solution is to look at your business rather than technical solutions or even machine learning. Don’t expect or look for a ready-made solution or product as the most appropriate machine learning solutions will usually need be custom and proprietary to your company. Start by looking for aspects of your business that are currently very costly or very risky. How might more ‘intelligence’ be used to cut these costs or reduce these risks?
Practical examples are How might we use less fuel? How might we use less people? How might we concentrate on the types of work that are least risky? How might be preempt costly or risky situations? How might we predict stoppages or over-runs?
Next, use your organisation domain experts to assess what data might be needed to measure data associated with these situations. Humans often have insight that patterns in particular data types will help classify and predict situations. They just can work out the patterns. That’s where machine learning excels.
When people think about beacons they often imagine them being detected in smartphone apps. This post explores other devices that can also see beacons allowing for different interaction possibilities and new scenarios.
Apps – Apps aren’t limited to just smartphone apps. You can run apps on TV boxes that run Android. Just make sure they have Bluetooth 4.3 or later.
Gateways – Gateways are small single pupose devices that look for beacons and send the information on via MQTT or REST (HTTP) to any server. This allows web servers to see beacons.
Desktops and Laptops – PC/Mac devices with built-in Bluetooth or dongles can see beacons.
Walky Talkies – Motorola manufacture the MOTOTRBO range of digital radios that can detect iBeacons and show their location on a map.
Raspberry Pi – This has Bluetooth and can be used to detect beacons.
AndroidThings – This special IOT version of Android can run apps that detect beacons and store and/or forward information to other devices.
Arduino – Arduino boards often have Bluetooth and can do things based on the presence of beacons.
Pixl.js – The manufacturer of the Puck.js also supplies a device with a screen that can detect and interact with beacons.
Single Board Computers (SBC) have an advantage over gateways in that data can be cached locally when there isn’t an Internet connection. They can also make decisions locally and send out alerts directly rather than having to rely on a server. This is so called ‘IoT Edge’ computing.
Last February we wrote about the progress of Bluetooth 5 in recent smartphones. A few months on and Nordic Semiconductor, the company that produces the System on a Chip (SoC) used in most beacons, has a new blog post on Bluetooth 5 in Smartphones and how we are about to experience a tipping point in support for Bluetooth 5.
The final observation from the article is:
Even if sticking to previous incarnations of Bluetooth may look like the right choice, the marketing power of Bluetooth 5, regardless of whether it’s needed or not, is likely to help companies differentiate products and increase sales.
This is true. Some companies currently claiming Bluetooth 5 support in products don’t actually use Bluetooth 5 yet but instead offer an upgrade path to Bluetooth 5.
Some sensor beacons can be used to monitor temperature. The first thing to consider when comparing temperature beacons is whether they have a dedicated hardware temperature sensor. Some beacons have a temperature sensor inside the main chip (System on a Chip – SoC) that’s less accurate and has less precision. The sensor is mainly there to give an indication of the chip temperature, not the ambient (outside the beacon) temperature. Most beacons only transmit for the order of 1ms every 10 to 5 seconds and enter a very low power state the remainder of the time. This means they not only use low power but don’t significantly heat the SoC. This means the SoC roughly tracks the outside temperature.
In our sensor beacon listings, when we say a beacon has a temperature sensing it has a separate hardware sensor, usually the Sensirion SHT20, providing more accuracy and precision than the sensor in a SoC. Some of our beacons, such as the Minew i3 and i7 have an internal SoC temperature sensor that’s readable but we don’t classify that as a sensor beacon.
The next thing to consider is the casing. In order to quickly track ambient temperature, the casing needs to be open somewhere and usually have a hole. Beacons that say they are waterproof and have temperature sensing won’t track ambient temperature well.
We have had customers use temperature sensing beacons in scientific situations and where they need to periodically calibrate sensing equipment. How do you calibrate temperature sensor beacons? The SHT20 is has a long term drift of only <0.04 deg C/year (the humidity reading vaies difts by <0.5%RH/year) so it doesn’t need calibration for most situations. However, if you need better than this, or check calibration, you will need to periodically calibrate in the software of the device (usually an app) that receives the beacon sensor data.
Last April we asked if the Physical Web was dead and mentioned that a group of people, led by Agustin Musi from Switzerland, was contemplating creating PhysicalWeb2. The Physical Web Association (PHWA) has now been created as a non-profit association with the goal of driving the development, community, and adoption of the Physical Web. The PHWA is now accepting memberships.
A refreshed TestFlight version of the PhyWeb iOS app is available to members. This new app will be promoted via advertising and the press. In time, the PHWA aims to develop a native app kit to add the Physical Web to existing apps, develop brand-neutral apps for iOS and Android and host a metadata service as, presumably, a substitute for the google Physical Web Proxy.