Bluetooth Low Energy and the Internet of Things

Did you ever “reinvent yourself” at some time in your life? I did, I went from the nerd in high school who wore cargo shorts and high socks to a less nerdy college student who had regular socks and shorts with the fashionable number of pockets. By the end of college, I had learned “social skills” and was finally ready to enter society as the best, or at least acceptable, version of me. People aren’t the only things that need reinvention, so do technologies like Bluetooth. Bluetooth created a new protocol in 2011 called Bluetooth 4.0, much more advanced than the classic Bluetooth. That has now been rebranded into IoT Bluetooth Low Energy (BLE) or Bluetooth Smart. This refreshed protocol has also added some new network types to its arsenal including BLE beacon based connections and mesh communications. Both of these technologies have their place in the world of a smart BLE device and can be used to realize many goals of the Internet of Things (IoT).

What is Bluetooth LE

We’re all well acquainted with Bluetooth, named after an ancient Danish king, and now famous for connecting wireless headsets with our phones. You may be less familiar, though, with Bluetooth low energy. So how low energy is Bluetooth LE and how does it achieve that low power operation?

The name is fairly self-explanatory, so the question becomes, “exactly how low power is BLE?” This paper from Aalto University in Finland answers that for us. In order to determine the total power consumption of Bluetooth low energy, the researchers first determined how much energy was used to connect the each module. They measured the power required to communicate different amounts of data after the transmitter and receiver were connected. In their experiments, energy usage increased stepwise with the amount of data being transferred. These power requirements start to flatten out around 500 KB/J. As it turns out WiFi is more energy efficient, operating in a range from 20 - 240 KB/J. There are a variety of problems with using WiFi for the IoT, though, such as only being able to connect to the single WiFi network at a time. Your user doesn’t want to disconnect from the Internet in general in order to interact with your IoT network. BLE allows users to stay connected to the world at large while also interacting with smart devices.

Besides, the lower power usage of BLE is more than enough for a IoT application. Using the BLE protocol you can run applications on devices powered by batteries for several years. No one wants to replace thousands of batteries on infrastructure sensors (that could be in places like sewers). That’s why engineers are developing things like Low Power Wide Area Networks (LPWANs). It’s also why so many companies are working on low power memory like CBRAM and spin wave, and new approaches to managing that memory. Now let’s look at two of the primary network configurations for BLE.

Bluetooth beacons can help you give location-specific information to your users.

Beacon Bluetooth

When Bluetooth emerged, only 1 to 1 connections were possible. I could connect my speaker to my headphones or my phone to your phone, but I couldn’t connect to a wider network of devices using Bluetooth. That problem was solved with the advent of Bluetooth “beacons.”

Bluetooth beacons connect multiple devices to the same network through one controller, the beacon. This configuration allows you to gather data from multiple sensors or provide connectivity to many devices using one point of contact. Thus this kind of network allows BLE to be used for an IoT ecosystem.

Not only do beacons connect gadgets to one another, they can also determine their locations. One of the most uses of this feature is by retailers to provide location-specific ads to shoppers. This could have near endless applications, from openings doors based on proximity to turning on lights in rooms when someone enters.

While Bluetooth beacons have some great applications, they do have their shortcomings. They suffer from the same problem that Bluetooth has always had, limited range. If you have a large store where you want to use beacons you’ll have to place them all over the walls. That leads us to another issue, beacons are unsightly. No retailer wants to put tons of ugly little hockey puck type things on their walls. Lastly, these networks can be difficult to operate. These controllers can interfere with one another and the system has to be carefully maintained. All of these problems led Bluetooth to develop another network configuration, mesh.

Bluetooth’s mesh protocol makes it a much more applicable for the IoT.

Bluetooth Mesh

Mesh networks are Bluetooth’s answer to their critics. Bluetooth’s mesh protocol allows devices to communicate directly rather than through a central node, removing the need for unsightly beacons. It also helps fix Bluetooth’s range and complexity problems.

Bluetooth’s mesh networking allows each connected IoT device to send or receive information. Instead of connecting everything through a central beacon, devices can get commands from and send data to each other. This configuration instantly eliminates beacons, meaning customers won’t have to plaster them all over the walls.

A mesh network also greatly extends the range of Bluetooth. Before you would need to be in range of the device you wanted to connect to, or close to a beacon. With this system you can connect to an end device through other devices. This kind of networking doesn’t require a lot of maintenance, as you don’t have to deal with carefully calibrated stationary nodes.

This makes Bluetooth perfect for the IoT. Developers have been searching for a great way to create an extensive low power network for IoT sensors. With a mesh, each sensor you place in your system extends the range of the network. You just have to make sure no sensor is off by itself out of range. Digikey gives a great example of how to implement this kind of network through lightbulbs. Let’s say you have a warehouse full of sensors that need to be connected. You can put a BLE enabled light bulb in each socket and saturate your area with a network. There’s no way any sensor you place in that warehouse will lose connectivity.

Bluetooth came out with guns blazing at the beginning, becoming the protocol of choice for wireless audio. As the years have passed, though, Bluetooth has lost some of its dazzle.Using beacons to increase connectivity helped, but they have too many faults to be widely used in the IoT. Meshes, however, promise to solve all of the traditional problems with Bluetooth and bring it back into favor.

Now that you have the perfect protocol to connect devices, it’s time to design some gizmos. When you need to access an easy-to-use PCB layout tool that includes everything needed to build high-quality manufacturable circuit boards, look no further than CircuitMaker. In addition to easy-to-use PCB design software, all CircuitMaker users have access to a personal workspace on the Altium 365 platform. You can upload and store your design data in the cloud, and you can easily view your projects via your web browser in a secure platform.

Don’t ask for accuracy, ask for automation!

 

The ultimate goal of an intelligent automation use-case is to automate certain business decisions and lengthy back-end processes.

As introduced in an earlier article, there are 3 main components of intelligent automation:

• Read – Extracting data from documents
• Reason – Defining the next steps to process those documents (decisions such as: pay the invoice, forward request to correct department, flag fraud, etc.)
• Rely on – Trusting the AI-based decisions to automate the document handling process and free up time from human operators

In our “Read” article, we touched upon the advantages of AI-based data capture (or AI-based OCR) over traditional techniques.

In the “Reason” article, we explain the typical business challenges we solve with Machine Learning techniques to understand the context of and the language used in the document.

One of the most compelling questions in AI today, is how to make humans and machines work in symbiosis so that they each build on each other’s strengths and complement each other’s weaknesses.

In Intelligent Automation, value is created not by “getting predictions right”, but rather by also knowing when those predictions are right (and especially when they are not!). It’s all about trusting the machine, which brings us to our last R: Rely-on.

After reading this post, you’ll be able to explain the difference between ‘accuracy’ and (calibrated) ‘confidence’ and, more importantly, why the focus for AI models should shift from accuracy to automation.

Intelligent Automation: expectations versus reality

Customers today have higher standards for companies than 10 years ago. They expect instant user experiences: faster responses; shorter delivery times, more relevant and personalized offers, etc., all tailored to their needs.

This is why businesses are looking for AI technology solutions to help them automate time-consuming back-office processes. Their expectation is to boost the employee’s performance by leveraging human intelligence with artificial intelligence. But the reality today is that a 100% automation level of a task by AI is still very elusive.

The AI dream

Today there are many reasons why the expectations for this level of 100% automation are not realistic. Reasons include for example poor input quality, underestimation of the ambiguity of the problem, too many exceptions, or AI models which are not trained well enough, among others.

For example, let’s take a look at the 3 documents below. Everyone would agree that the 1^st document is an invoice and the 2^nd document a receipt. But what about the 3^rd document, the parking fine? Is it an invoice, a receipt or yet something different?

In such a case, you’d want the AI to double-check with a human. This is also called an “edge-case”, or a situation in which it is not immediately clear whether to choose one class or the other.

The reality of AI today

Whatever the reason, today, almost every solution needs a combination of humans and artificial intelligence. Some cases are easier for the machine to understand and automatically process. Others can be too complex, needing a human helping hand.

To prevent and avoid such AI-based automation pitfalls, it is crucial to determine which cases a human should verify manually.

The biggest misconception in Intelligent Automation

Many people talk about ‘Accuracy’ when they actually mean ‘Automation’. These are two different concepts. In what follows we will elaborate on the difference between both and why this is so important from a business perspective.

Why high accuracy rates alone won’t help you reach Intelligent Automation

Let’s start by answering the question what accuracy means for a cognitive automation use case. “Accuracy” describes how many predictions, of all the predictions the machine made, are correct or accurate when tested on unseen data.

So, when we say that the AI solution has a 90% accuracy rate, we’re saying that 10 out of 100 documents are incorrect. The accuracy is a property of any AI model.

“Automation” is defined as the % of cases that goes from IN to OUT via the automated flow. This is a choice that needs to be made.

Now the question is: how do you know which of those documents are the 10 documents a human operator should still verify for mistakes?

That’s where calibrated confidences come into the picture. Calibration implies having the model tone down or increase its prediction confidence. Sometimes it is underconfident while it is correct, other times it might be overconfident and incorrect, and thus in need of a correction in confidence.

Calibration implies changing the algorithms’ confidence to match its correctness. The machine needs to say with each prediction whether it is certain or not that it will be correct: this is a Yes / No flag. ‘Yes’ means a human still needs to check what the machine has predicted and correct if needed.

Let’s take a look at two AI models, which one would you prefer?

Consider AI model A, 90% accuracy and no calibrated confidence flag.	Consider AI model B, 80% accuracy and with a well-calibrated confidence flag.
Since there is no yes/no flag, you cannot choose which cases to look at; it’s all or nothing.   100% automation, but with 10% errors in the output	Flagged cases are looked at by a human operator.   80% automation, and no errors in the output

Almost every company prefers model B: it best fulfils the automation need, even though it has lower accuracy. Model B brings significant business value, whereas model A does not!

Confidence levels in practice for Intelligent Document Processing

However, practically, how does the system know when to confidently flag a document for review or not? At Contract.fit, we do this by working with confidence scores.

A raw confidence score, or uncertainty, is a percentage (0-100%), that indicates whether the machine is not sure at all, somewhat sure or very sure about the correctness of a prediction.  These raw scores are calculated by the different AI-models taking into account all sort of underlying features related to pattern, context, position or logical relations.

Every prediction has its own raw score: classification & splitting of documents, extraction of fields, extraction of line items and classification of line items. Various algorithms could then be applied to transfer the raw scores into a calibrated confidence score.

We have conducted in-house research to make our AI models more trustworthy, relaying calibrated confidences and giving them the ability to reliably communicate uncertainty.  If you’re interested in reading more about the research, you can read our paper on predictive uncertainty for probabilistic novelty detection in text classification.

In the json output below, you can see a document prediction of with 94% calibrated confidence and a tax amount prediction with 95% calibrated confidence.

These individual confidence scores per prediction are used to set one confidence flag, or as we call it, a flag_for_review (FFR) at the document level. If True, the document is flagged for a manual review. If False, the document does not need a manual review and can go in full STP (Straight Through Processing). 

What happens in the back is that the confidence score for each prediction is compared to the confidence threshold.

The confidence threshold is a setting that can be configured for each field individually. If for every prediction, the confidence score is higher than the threshold, the document does not need to be manually reviewed and the flag_for_review is set to False. This is the last field in the example above.

This makes it a lot easier for our users, as you don’t need to worry about each individual confidence level (even though it is still possible to review them in the json output). We take this burden away for our customers by ‘rolling up’ the confidence information in a flag_for_review.

In the Contract.fit Solution, confidence thresholds can be configured via the front-end. For our API-only clients, this can be consulted and patched via the corresponding API endpoint.

How to build a business case for your intelligent automation project

As illustrated above, the most important parameter for any intelligent automation business case is the percentage of automation, which is the driver for the savings potential. What is the percentage of automation we can achieve?

Or: “Out of 100 documents, how many do NOT need to be checked by a human?”

And how do you quantify the efficiency that can be realized with this automation. We do this, together with our customers, in two different ways:

• As an amount in staff costs if our customers would reduce the team.
• As an increased percentage of additional work that could be done, if they keep the same team.