Support – Page 33 – BeaconZone Blog

No-Code and Low-Code Development for Bluetooth Beacons

As mentioned in our article on Using Bluetooth Low Energy (LE), Bluetooth devices such as beacons repeatedly advertising their id and for sensor beacons they advertise their sensor information.

Something needs to listen which is usually a smartphone app, a gateway or a computer such as the Raspberry Pi. These devices process the advertising to show information on a map, in a dashboard or forward on to other systems, possibly as alerts. In the case of a gateway, the information is usually sent to a local server or cloud server. The app, computer or cloud server functionality usually involves custom programming but what if you could do this with no code?

There’s a general move towards using more ‘No-Code’ and ‘Low-Code’ Development. This is where common functionality is wrapped into components that are joined together using a user interface. There are many proprietary examples most of which involve subscriptions, SaaS, lock-in and unknown longevity that makes them unsuitable for enterprise grade solutions. Conversely, we are a fan of Node-RED that provides open source flow-based programming that we have used on customer projects. Don’t be deceived by the user-interface. This is not a toy and is being used in production by many companies.

Node-RED started in 2013 as a side-project by Nick O’Leary and Dave Conway-Jones of IBM’s Emerging Technology Services group. It has since been open-sourced, continually developed and it moved to the JS Foundation in 2016.

Node-RED provides a flow-based editor that allows you wire together just about any type of input, for example, Bluetooth, HTTP, MQTT to any type of output. It also has components to generate a simple UI dashboard with widgets. There’s a large number of nodes including Bluetooth that you can import and use for input, processing and output. You can develop and run on Linux or Windows. Everything is done using a web user interface. You can run on, for example, a Raspberry Pi, AWS, Azure or more usefully for Bluetooth, on edge Linux devices.

We like to use Node-RED on Mini-PC devices, such as Intel NUCs, running Linux. We don’t use Raspberry Pi because running from SD cards eventually becomes unreliable, although a recent feature does allow booting and running from any USB device. The flexibility of the hardware you can use with Node-RED contrasts with many other IoT solutions that end up being obsolete due hardware becoming end of life.

It’s relatively easy to set up a flow to read Bluetooth advertising. It’s also possible to use HTTP or MQTT input to receive and process data from Bluetooth gateways. We have even run AI Machine Learning, for learning and inference, within within a Node-RED flow.

Using tools such as Node-RED is quick and easy compared to coding. Node-RED is free, open-source, stable and is still being improved over time. However, there comes a stage where you eventually need to run code. Some components allow running arbitrary JavaScript to transform data from the input to output of a node. This is sometimes better than trying to connect together and configure lots of nodes to do the same thing.

Another limitation is that it’s not possible to create an installable product with Node-RED. You can export and import project flows which isn’t something you can sell as a product. The output UI is also limiting. You have to design your UI around what’s possible. More complex solutions also end up with very complex flows and sub-flows that get more difficult to understand. While you don’t need to code, you still need someone with similar analysis and problem solving skills.

For high throughput systems you will also hit performance problems. Node-RED is based on Node.js that uses a JavaScript runtime. Compiled languages such as c, c++ and Rust reduce latency, reduce CPU usage by up to 75% and memory usage by up to 95% compared to Javascript. It’s also difficult to move a solution to compiled code should that be needed in the future.

Nevertheless, Node-RED provides a no-code or low-code tool for some one-off solutions that would otherwise be too effort-intensive or expensive.

Choosing a Real Time Locating System (RTLS)

A Real-time locating system (RTLS) automatically tracks the location of objects or people. Beacons, sometimes called tags, are placed on things that move and gateways, sometimes called locators, detect the beacons and send data to software either locally or in the cloud. A user interface shows the current locations.

Most organisations looking for a RTLS for the first time don’t know what aspects of systems are most important. People usually focus on maximum accuracy when, in fact, a system with maximum accuracy involves consequent undesirable compromises. Some suppliers’ marketing also focuses on performance that’s only achievable in a lab or factors that might seem important now but will become less important when other issues are known. In practice, every situation is different and you need to balance factors based on your needs.

Number of Assets

The number of assets you need to track usually has largest influence on the type of system you should consider. All systems are limited by how much data they can process. More accurate systems such as Ultra-Wideband (UWB) and Bluetooth AoA produce more data and hence support a lower maximum number of assets. However, the actual number depends on many factors such as the underlying hardware speed, the network speed (i.e. is local or in the cloud) and settings within the RTLS system itself.

Scalability

When talking to vendors, it’s important they assess the number assets you will need in the future, as well as now, so as to not outgrow a system. Scalability isn’t only about assets. It also involves the number of gateways, the degree to which they overlap physical areas, thus producing more data for more accuracy, and the scalability of subsequent processing software.

API

The use of RTLS is much like the Internet of Things (IoT) in that everyone wants to get something slightly different out of the data. If you require something other than searching for assets, this means you or your vendor will need to write reports, scripts or use reporting tools such as Grafana to extract insights. The RTLS should have an API, usually using HTTP REST, to extract data. If you have local access to the system, it’s often more flexible and faster if you can also gain direct access to the underlying database for reporting. This also opens up the number of off-the-self reporting tools that can be used.

Most systems have a user interface where you can add and remove beacons and gateways. However, imagine doing this for 1000s of assets. Look for an API to allow you to add, modify and view beacons and gateways programmatically. This allows other programs such as apps, ERP, WMS, your custom systems and scripts to simplify integration.

Flexibility

In reality, systems tend to get re-used for more than one use case as the organisation’s digital maturity grows. Check the system provides suitable access to the data for future uses. Ensure various beacon models are available for those anticipated uses.

Accuracy

As previously mentioned, the best accuracy isn’t always the top consideration. Our article on microlocation accuracy explains the different kinds of system and corresponding accuracy. Note also, that many RTLS have settings that balance accuracy with latency and maximum number of assets.

Latency

Latency is how long it takes to know a new location after something has moved. A shorter latency requires the assets to send data more often thus decreasing asset battery life. More data also implies a fewer maximum number of beacons.

Battery Life

As mentioned, above, the frequency of beacons advertising their location directly impacts beacon battery life. Systems such as UWB and Bluetooth AoA tend to have beacons advertising more often to allow higher accuracy. However, look for beacons that have accelerometers that advertise more often only when moving thus saving battery life.

License Type

Consider if you need a system locally, in the vendor’s cloud or your own cloud. For thousands of assets, reporting frequently for low latency, you will need the system to be local. If you are using SaaS you will also need to consider issues such as the service level agreement (SLA) and the location of the server for privacy requirements such as GDPR. Another issue related to SaaS, particularly with VC start-ups, is the longevity of the solution. Is the vendor going to be providing the platform as long as your project? Some early beacon platforms have already closed. Others have been taken over by large companies that have other agendas.

Security

You need to assess the security of the proposed system. This includes factors such as logins, SSL, secure APIs and the security related to the location/hosting of system.

Price

As well as the headline price, also consider if the solution is financially scalable once you increase the number of assets and gateways. Also determine if future costs are known and acceptable.

Summary

Remember that the ‘best’ RTLS is not the one the vendor claims as best for some arbitrary feature but instead is the one that best suits your needs. You will need to balance the needs of the project with the capability of the RTLS that offers the best fit.

Cisco and Aruba Based Real Time Location Systems (RTLS)

A growing number of WiFi access point vendors such as Cisco and Aruba are offering Real Time Location Systems (RTLS). While using existing hardware might seem compelling, it’s sometimes not practical. Here are some questions to be answered when considering such systems:

Does your site have access points from mixed vendors? If so, the RTLS won’t work across them.
Does your site have enough (overlapping) access points to support the RTLS?
What will be the latency? Hardware providing WiFi access point functionality and Bluetooth scanning can’t provide optimal throughput leading to much lower latency to find items typically in minutes rather than seconds.
What is the location technology? Access point systems use RSSI based locating rather than angle of arrival (AoA) that’s typically accurate to 5m rather than sub 1m. They also don’t provide the the breadth of IoT sensing provided by dedicated-hardware RTLS systems.
What is the maximum number of assets? Non-dedicated hardware doing the scanning for beacons severely reduces throughput and hence the maximum possible number of assets.
Is it SaaS? Are the future subscription costs known? What is the SLA? Where is the server? Does it meet regulatory and your company privacy needs? Does it scale financially with the number of assets? Is the SaaS platform likely to be around as long as your project needs?
What is the vendor competency? Many Aruba and Cisco resellers are more interested and experienced in selling hardware rather than solving RTLS and Bluetooth related problems.

Read about BeaconRTLS™

Read about PrecisionRTLS™

Using Beacons for Activity-Based Costing in Farm Management

The Department of Agricultural and Food Sciences, University of Bologna, Italy has been looking into CANBUS-enabled activity-based costing for leveraging farm management. They have created a methodology that helps farmers to make operational decisions and create data that can be used for input into farm management information systems (FMIS).

As an example, a study showing a tractor active for 59% of the time was idling for 25% of the time. Fuel and labour costs represented from 63% to 71% of the total cost per hectare. The tractor was equipped with a CANBUS logger and Bluetooth beacons on several tractor implements to automatically recognise agricultural operations. The data was processed to classify jobs by position (field, farm, or road) and operating state (moving, fieldwork, or idling).

With such systems, farmers can determine the economic impact of farm activities and compare historical data with previous farm practices or competitors’ activities. This helps farmers make more intelligent decisions regarding crop, land and farm operations management.

The Bluetooth Technology for Linux Developers Study Guide

The Bluetooth SIG has a new Bluetooth Technology for Linux Developers Study Guide. It explains how Bluetooth is implemented in hardware as part of the main board or added using a USB dongle. The Bluetooth stack runs as a system service using BlueZ. BlueZ is accessed via inter-process communication (IPC) via D-Bus, a message-based system service. Applications use D-Bus and hence BlueZ.

While the study guide is helpful, we suggest you also explore the Bluetooth APIs available from your chosen programming language. We have never had to program at the D-Bus level. Take a look at the Node, Javascript, Arduino, c, c++, Rust, Python and Java Bluetooth APIs and libraries.

Angle of Arrival Accuracy Improvement

There’s new research from Department of Electrical and Information Engineering, Bari, Italy on A Linear Technique for Artifacts Correction and Compensation in Phase Interferometric Angle of Arrival Estimation that can be used with Bluetooth AoA Direction Finding.

The paper first discusses the main causes of error in AoA systems. This includes signal path length mismatches as avoided by the CoreHW AoA Hardware printed circuit board (PCB) tracks and mutual RF coupling effects that act on the antenna array.

The researchers devised and proved a technique to process IQ data to reduce systematic errors and first-order (linear) coupling effects. After a calibration phase they manged to reduce average absolute errors by more than a half in one test case more than a quarter in a second case.

Research on techniques such as this will make Bluetooth direction finding even more accurate.

Read about PrecisionRTLS™

Programmable Beacons

Many people come to us asking for “programmable beacons” when in fact they want beacons with configurable iBeacon UUID, major and minor. All beacons allow the UUID, major and minor to be changed, usually via an iOS and/or Android app and sometimes via USB/UART for changing the values, over time, via a program. This is changing the settings rather than programming.

Truly programmable beacons are those where the internal software can be updated. The beacon contains a system on a chip that’s small computer running code to implement the beacon functionality. In most cases, the software can be updated via pads on the PCB:

Programming requires use of a programmer:

It can be difficult to program larger numbers so a custom-made jig is used:

It’s not possible to see and update the existing code in a beacon. Any newly uploaded program has to be created from scratch using c/c++ code. This is called embedded programming, is non-trivial and takes of the order of months.

Read about Beaconzone custom solutions

Using RTLS to Determine Human Behaviours

Our BeaconRTLS™ and PrecisionRTLS™ produce a lot of historical data. How this data is used varies considerably from project to project. One use of the data is for determining human behaviour. For example, consumer behaviour, workplace safety behaviour, developmental child behaviour or other health-based analysis.

There’s recent research into Indoor Location Data for Tracking Human Behaviours: A Scoping Review that’s meta research in that it’s an analysis of past RTLS-based human behaviour research. The Canadian researchers looked into the varied ways behaviour can be extracted from RTLS data and the features that can extracted. They examined 79 studies using RTLS data to describe aspects of human behaviour. The most common use was to monitor health status, followed by analysing consumer behaviours, increasing safety, operational efficiency and investigating developmental child behaviours.

The main behaviour features were found to be dwell time, trajectory and proximity. While many papers were able to detect features and hence behaviours, few continued to clinically validate their findings. Beyond activity recognition, few took the opportunity to create models for use in their respective fields, for example, “detecting abnormal behaviours in older adults”. Such models might be used to provide useable baselines for behaviour and health monitoring.

The paper mentions using different locating technologies for different granularity. More specifically, RFID and IR technologies provide too low a level of granularity in location tracking that can prevent extraction of behaviours or continuous movement patterns. Conversely, UWB needs constant battery changing or recharging that can make data collection difficult.

The researchers conclude that while RTLS technologies provide a valuable tool to analyse patterns of human behaviours, future studies should use more complex feature analysis methods to make more of the richness of location-based data.

Managing Bluetooth LE Advertising Congestion

Bluetooth LE advertising congestion happens when there are too many Bluetooth devices in an area. As we will show, this rarely happens but with new Bluetooth technologies this situation is becoming more likely. We provide some ways to mitigate congestion.

Bluetooth LE advertising transmits periodically the period of which is configurable from typically 100ms to about 10 seconds.

Bluetooth LE advertising (from Bluetooth SIG)

If two Bluetooth devices happen to transmit at the same time, it’s like two people shouting at the same time. The signal is corrupted, the receiver can’t make sense of the signal and it is lost. This usually doesn’t matter because it’s likely the signal is seen the next time it is sent. The random advDelay in the above diagram ensures that the two sends don’t clash again. It’s very unlikely advertisers clash in the first instance because the transmit duration is very small compared to the advertising period. The above diagram isn’t to scale. Here’s an oscilloscope trace showing some real timing:

The advertising duration is very small, of the order of 1 to 2 ms (milliseconds). Advertising is also sent three times, on three different radio frequencies, so that if one is blocked, the radio signal might be heard on one of the others. All this means that advertising collisions rarely occur.

However, there are some newer Bluetooth protocols that as they are starting to roll out, are making collisisons more likely:

Bluetooth 5 advertising extensions – This allows advertising of more data, that takes longer than the typical 1 to 2 ms and hence increases congestion.
Bluetooth longer range – This transmits further thus effectively increasing the number of beacons advertising in a given area.
Bluetooth Mesh – This works by having relay beacons listen and re-transmit advertising, usually several times, to improve reliability.
Bluetooth direction finding – This also has longer advertising to send a constant tone extension (CTE) that is received by AoA hardware. However, of more affect is advertising more frequently. While beacons on assets used to advertise typically every second or longer, direction finding tends to use faster advertising to improve latency.

You can check how many devices are advertising by using a scanning app on Android. We recommend Nordic Semiconductor’s nRF Connect because it can decode the latest Bluetooth protocols. Use Android for full visibility because Apple made the poor design decision to obfuscate iBeacon advertising to coerce developers to only use the Apple iBeacon-specific APIs. Apple also hides devices’ MAC addresses making them more difficult to physically identify.

If you have a problem with congestion you might be tempted to increase the transmission power or advertise more often to increase the chances of being seen. However, this is counter-productive because you will be increasing congestion, especially if your devices are the main contributor to the congestion.

Instead:

Lower the transmit power so that beacons cover a smaller area. You can fine tune this using nRF Connect to measure the distance you need rather than needlessly advertising further. This will also conserve battery life.
Increase the advertising period to make collisions less likely.
Increase the receiver scanning period to make detections more likely.
Seek out and remove unwanted devices advertising too frequently, such as fitness devices, smartphones, displays and even cars.

Need more help? Consider our consultancy services.

Asset Tracking For Manufacturers

Today’s just-in-time and busy manufacturing processes means that manual tracking of pallets for inbound and outbound shipments often can’t keep pace with the speed of production. Production and assembly requires the quick locating of components. Delays and inaccuracies due to lost components lead to increased costs, employee frustration and ultimately customer disappointment.

Competitive pressures are also driving the need to reduce labour thus reducing the capacity to manually search for items. Customisation using configured options and demand-driven production is also increasing the degree of inbound component searching that exacerbates the problems.

Even those companies using legacy tracking solutions find that location is only as good as the last barcode or RFID scan. Humans get lazy, make mistakes and don’t scan, causing pallets, crates and boxes to get lost. Many RFID readers don’t work reliably near metal components. Relying on a system that can’t find just a few items can be worse that a manual system that works but is slower. Bluetooth asset tracking solves these problems because the location is automatically collected in real-time and is continually updated.

Asset tracking can be applied to items such as components, pallets, cases, tools, returnable assets such as racks and cages as well as items on loan to ensure they are returned on time. It can improve worker safety and provide alerts in cases of congestion, perimeter deviation and lone worker distress. It can ensure forklifts are being fully utilised, are taking an optimum route, haven’t crashed into racking and haven’t gone out of an area.

The real-time visibility allows connected systems to generate confirmation and exception alerts and automatically trigger shipping processes, replacing costly manual workflows. Tracking outputs also allows confirmation that the correct things are loaded on the correct transport.

A Bluetooth-based real time location system (RTLS) increases visibility and allows the manufacturing process to adapt in real-time to short term business needs. It provides cost savings, greater efficiency and business intelligence that can be used to derive larger scale changes based on data rather than gut instinct. Overall reporting of input and outputs provides input to management reporting to monitor the business.

Read about BeaconRTLS™
Read about PrecisionRTLS™