Internet of Things

Why are we using LoRaWAN?

When we started Beringar we spent a lot of time with clients in the health sector understanding their space utilisation needs. We discovered that to use IoT in the National Health Service in the UK we would have to find a way to get the data out without touching the buildings data infrastructure. So, no wired or Wi-fi connections were possible, partly due to data security concerns and partly due to spotty Wi-Fi that sometimes was there and worked and sometimes did not. A constraint was introduced to our way of working that we had to overcome.

As we have discovered, constraints are our friend. They force us to think of inventive ways to overcome them and usually lead to a better product in the end. This constraint led us to focus on LPWAN technologies as a potential data transmission solution (in turn leading to new constraints around data packet size) and to prototyping using LoRaWAN.

Why LoRaWAN? Well, it was a technology that we could find willing experts to help us with and had the benefit of flexibility compared to SigFox. We wanted to send data every minute and SigFox would not allow us to do that. LPWAN technology also had the benefit of great range and the ability to work from deep in the bowels of a building. Something that we knew that 3G or 4G would not be able to cope with from our initial tests. This choice meant we could get the data out of the building securely and reliably.

Making the choice to work with LoRaWAN meant that we needed to really focus on the data that was important and package it in a way that could let us fulfil the demand to count and position people in a building, report the environment and understand space utilisation. All in a few bytes transmitted once per minute. As I mentioned, constraints force creativity, so we found a way to package this information in a few different message types and stayed within the duty cycle limits for LoRaWAN. This choice reduced our data transmission, storage and management headache a lot.

The other benefit of LoRaWAN, as we have discovered, is the ability for us to be in control of the deployment. We choose how many gateways and when they will be installed. We manage the network and ensure that we deliver a high quality service. This is important in the overall end to end service we deliver to the customer. No waiting for a telco to roll out in that area and no service provider help desk to worry about if something is not right. This choice helped with speed to market and quality of service.

So LoRaWAN has challenges - its radio being the principle one. Doing large scale firmware updates is not trivial and we always have the issue of occasional dropped packets - but the pros outweigh the cons. It’s fast to deploy; you’re in control; it’s quite reliable; it has great range with low cost hardware and you can remain independent of the large carriers. There is a lot to like.

What do you use to get data out for your IoT deployment and what are the pros and cons?


Main image credit: Ryan Stefan via Unsplash

To be battery powered or not battery powered - that is the question

While undertaking the R&D work to develop the Beringar Hex, we really wanted to find a way to minimise the management headache that IoT devices can create. Powering the device was very close to the top of that list, so we went and listened to potential customers that had used battery powered devices in the past to gauge the size of the issue. Many had believed the battery life estimates they were given by suppliers, only to discover that, as one put it “we should have invested in Duracell - we seem to be constantly buying batteries!”.

In the end, we opted for a powered device in the end, based on the power-hungry nature of machine vision and the premise that our goal was for our data to become part of the operational model of a building. To do this it needs to become part of the building structure, so power shouldn’t be an issue. That said, we have a number of cases where battery powered devices are in demand. These include trials, proof of concept deployments, short term surveys and unit testing. So, we are still looking for that “perfect battery” that can provide long deployment potential and be easy to manage.

I read an article this morning about the 10 Things the Perfect IoT Battery Should Do and wondered just how far away we are from that perfect battery.

  1. Pack a lot of power into a small space

  2. Efficiently deliver that power quickly, and/or incrementally, as needed for a particular application, without degrading battery capacity

  3. Be easily recharged in a variety of ways, including wirelessly, such as over Wi-Fi networks

  4. Make it simple to remotely monitor battery output, remaining battery life, as well as overall battery health

  5. Avoid self-discharge to hold their charge for extend time periods, even under adverse environmental conditions

  6. Be able to be recharged many times, in a variety of ways, without affecting battery capacity

  7. Avoid emitting waste heat that could cause problems

  8. Last a long time to avoid the need for premature disposal, and be environmentally friendly when finally retired

  9. Be inexpensive enough to allow for widespread deployment in many kinds of IoT devices

  10. Use a flexible design that makes it easy for IoT device makers to incorporate in a wide variety of products

Given we are all experiencing peace dividends from the self-driving car revolution at the moment, perhaps that battery emerge in the next 2-3 years?

Well, with advances in materials such as graphene, we can deal with #1, #2 and #3 - pack a lot of power into a small space, efficiently deliver power, be easily (and quickly) recharged without affecting battery capacity (#6) Indeed, from our discussions with some of the world’s most eminent graphene specialists, we are going to see a huge increase in battery capacity and longevity (#7 and #8) coupled with a reduction in weight and an ability to sculpt units to match the device design more closely (#10). With advances in cloud technology and connectivity, such as LoRaWAN networks, we can easily monitor overall battery health (#4). So, that leaves #5 and #9 to deal with. Perhaps we will see that perfect battery sooner than we think.

Do we need smart construction to get smart buildings?

In a report dating back to June 2016, McKinsey & Company looked at the changes needed to improve productivity in the global construction industry (Imagining construction’s digital future). The industry employs 7% of the global workforce, and with a staggering $10 trillion spent each year on new infrastructure, even tiny changes in productivity will have marked effects on both jobs and sector value. But, according to figures presented by Antony Slumbers in a tweet today, the construction industry spends around 1% on R&D compared to tech companies like Amazon who spend 12%. Clearly, there is scope to spend more to achieve greater productivity returns.

Screenshot 2019-01-10 at 11.30.38.png

In our view, truly smart buildings are started on the drawing board. So, if the necessary step of getting them out of the ground is “dumb”, how can we possibly create a smart building? How can we know, for example, that it was built according to the plans; with the materials specified; in weather conditions that were optimum; by people that knew what they were doing, and; were safe while doing it? What impact would this data have on the ongoing use, management and maintenance of the asset? Do we have the spec sheet and is it performing according to spec? If it were a software or hardware package we would, so do we need the same for our buildings along with the mechanisms to check performance against spec?

We think we do, with digital platforms and sensors used before, during and after construction will provide that certainty and a whole lot more besides. The five trends highlighted by McKinsey are really all about platform and sensing capabilities for construction that generate data and insights that can be used to accelerate the build and/or increase the durability of the final output.

Think use pattern feedback; materials durability; occupant satisfaction; repair rates; scheduled vs unscheduled maintenance; thermal and acoustic performance; energy consumption; operational costs. Imagine these statistics being available to the designer, construction firm, lender, developer, owner, occupier and user of the building and think about how quickly innovation would happen once the building is smart from inception.

Creating a UK Health Estate fit for Productivity, Productivity, Productivity

Creating a UK Health Estate fit for Productivity, Productivity, Productivity

Sir Robert Naylor’s report on the future of the NHS estate highlights many issues facing the organisation as it tries to meet the demand of delivering more sophisticated and successful health care to a growing and ageing population. It shows that the NHS estate can be a enabler of more productive healthcare.