Sensor beacons provide a quick and easy way to obtain data for AI machine learning. They provide a way of measuring physical processes to provide for detection and prediction.
Beacons detect movement (accelerometer), movement (started/stopped moving), button press, temperature, humidity, air pressure, light level, open/closed (magnetic hall effect), proximity (PIR), proximity (cm range), fall detection, smoke and natural gas. The open/closed (magnetic hall effect) is particularly useful as it can be used on a multitude of physical things for scenarios that require digitising counts, presence and physical status.
The data is sent via Bluetooth rather than via cables which means there’s no soldering or physical construction. The Bluetooth data can be read by smartphones, gateways or any devices that have Bluetooth LE. From there it can be stored in files for reading into machine learning.
Such data is often complex and it’s difficult for a human to devise a conventional programming algorithm to extract insights. This is where AI machine learning excels. In simple terms, it reads in recorded data to find patterns in the data. The result of this learning is a model. The model is then used during inference to classify or predict situations based on new incoming data.
The above shows some output from accelerometer data fed into one of our models. The numbers are distinct features found over the time series as opposed to a single x,y,z sample. For example ’54’ might be a peak and ’61’ a trough. More complex features are also detectable such as ‘120’ being the movement of the acceleration sensor in a circle. This is the basis for machine learning classification and detection.
It’s also possible to perform prediction. Performing additional machine learning (yes, machine learning on machine learning!) on the features to produce a new model tells us what usually happens after what. When we feed in new data to this model we can predict what is about to happen.
The problem with sensor data is there can be a lot of it. It’s inefficient and slow to detect events when this processing at the server. We create so called Edge solutions that do this processing closer to the place of detection.
When people think about IoT sensors they tend to envisage, for experimenters, discrete electronic components connected to single board computers (SBC) or for industrial, custom sensors connected to microcontrollers.
The problem for experimenters is the solution is fragile and needs to be evolved into a custom electronic design before it can be used in production. For industrial solutions, they tend to be proprietary, require deeply invasive installation and very expensive.
Sensor beacons provide an easy, ready-made solution that have the following advantages:
They provide a solution that’s equally as good for experimentation as it is for the final production
Moko has a new video showing the H4 waterproof sensor beacon being tested. It first shows the beacon being submerged in water after which the temperature and humidity is shown in the accompanying management app.
It’s unusual to have a beacon that’s both waterproof and can report temperature and humidity because a hole is usually needed to allow allow passing of temperature and humidity to the sensor on the printed circuit board. The H4 solves this problem by having the sensor in a small cage at the side of the case.
The beacon also has a logging function stores up to 4000 historical temperature and humidity values.
The system automatically monitors vine stress to provide real-time surveillance and alerts. It identifies specific areas for irrigation, thereby saving water, energy and time.
The Bluetooth iBeacon protocol is used to relay temperature, humidity, UV levels and soil moisture levels. The authors modified the standard iBeacon protocol, using the existing iBeacon minor and major fields to encode the telemetry data.
Beacons don’t generally need to store data because they are just sending out their unique id. However, sensor beacons do sense values over time that you might want to collect later via, for example, an app coming close to the beacon. Specialist devices such as social distancing beacons need to store close contacts for later collection.
Beacons use a System on a Chip (SoC), such as the Nordic nRF51, that includes memory. Most of the memory is used for the internal functioning of the beacon. Newer versions of SoC, for example the Nordic nRF52, have more memory that allows data to be stored.
There are some sensor logger beacons that store sensor values but this tends to be restricted to temperature logging.
There’s a getting started guide that explains how this is setup and provides screens showing how it works.
This allows not just for sensing telematics about the vehicles themselves but also about other assets or people. For example, if people carry beacons it’s possible to know who is driving or is in a vehicle. If you tag equipment usually stored in a vehicle you can determine where it is or if it is about to be removed from a vehicle. For temperature sensitive goods, such as medicines, you can continuously audit temperature compliance. It’s also possible to provide for location specific triggering, for example, producing work orders when a vehicle reaches an exact point whether or not there’s GPS coverage.