I was at a conference on Friday at the Institute for Sustainability, Newcastle University (who fund my PhD research). I gave a 2-minute talk on the project I have been working on for the past year: “BuildAX”. I thought I should write a bit on how this evolved.
Building Monitoring
BuildAX is a fully open-source hardware and software platform for monitoring of environmental conditions in buildings- i.e. temperature, humidity, incident light and so on.
The project is part of the OpenMovement project, a range of hardware designed and developed at Culture Lab to assist various research projects (and distributed Axivity for other people who want to use them).
The original generation of the BuildAX building sensors were developed as part of the EPSRC-funded TEDDI project. As that project was coming to a close, we met with our collaborators from ESRU at the University of Strathclyde (Joe Clarke & Jon Hand) to discuss what the issues were with the first-generation sensors.
As with any first-gen tech, there were quite a number of problems (which I had also experienced using the sensors for my undergraduate final year project): battery life, signal range, and accuracy being the main ones.
The second generation sensors needed to have a low unit cost, address the problems of v1, and be really simple to deploy. The BuildAX v2 hardware was designed by Karim Ladha at Culture Lab with this in mind.
Design Iteration 2
Warning: technical details follow!
The short battery life of generation 1 of the BuildAX sensor platform was mostly due to the presence of two relatively high current components on the board- the radio receiver, and the microphone used for sound level metering.
V1 operated a 2.4GHz “MiWi” mesh network. The bi-directional nature of this radio protocol was a significant source of power consumption as the radio had to remain on (all the time) to receive acknowledgements.
The new BuildAX sensors operate on the 433MHz ISM band, and are broadcast-only. Not having a receiver onboard means that there is no guaranteed delivery- instead, radio packets are kept very short (32 bytes over a few ms) so that the probability of a collision is kept low. We’ve seen pretty good performance from this radio protocol- up to a 100m range (through walls) in our building in Newcastle upon Tyne. (We have seen issues with range in Strathclyde though, as their location had a noisier radio spectrum. I’ll write about this another time).
The other significant power draw of the v1 sensors was that they included a microphone for sound-level metering- even though the design was as low power as possible for this feature, the MEMS microphone is still a comparatively hungry component due to its bias current of around 180μA. This was therefore removed from the basic BuildAX v2 sensor, but we may later look at a separate solution as the platform can support multiple types of sensor device.
With these modifications, the estimated battery life of v2 is over a year. In fact, the highest power draw is the LED which lights when the PIR sensor is triggered. In low-traffic areas (or with the LED configured off), battery life could be even longer.
The other sensors remain on the board, and we’ve tested them to check they conform to the ratings on the component datasheets. These are: temperature, humidity, light and PIR sensors, with the new addition of a magnetic switch for determining the open/closed status of windows and doors. The full specification for the sensor hardware can be found in the documentation.
A side note: a competitor in the low-power building sensing field is the Crossbow TelosB- this is a more generalised solution (possibly better if you’re interested in hacking around on that level) but the battery life of these motes doesn’t come close.
Data Logger/Router (“LRS”)
The other major component introduced in v2 was the Logger/Router/Server, or “LRS” for short. This was intended to address the “ease of use” need, as previously, a separate computer with a USB receiver node was required to receive data from the sensor nodes.
The logger supports up to 20 sensor nodes, and provides a bridge over to the TCP/IP network so that users can view data in real time in a web page- this is the part of the project where I was most heavily involved. Data from the sensors is logged to an SD card in a compact binary format, which can be retrieved remotely via the fetch interface.
For applications with a larger number of sensor nodes (100+, 1k+ …who knows?) the router will log data, but will be unable to decrypt it on the fly due to memory constraints- it can be decrypted offline at a later date.
We weren’t able to make the router as cheaply as we’d have liked. Originally, it was designed to take a GSM modem, and support backwards compatibility with the old v1 sensors. Due to the low production volume, the manufacturing cost went up so those components aren’t actually placed on the PCB. For more technical users who want to forego the ease-of-use of the router for better reconfigurability, we also made a USB dongle for direct connection to a computer (which can also be manufactured more cheaply).
Current Uses
BuildAX has already been deployed in social housing in Glasgow by our collaborators at the University of Strathclyde. We have also secured a new EPSRC Project, “Pervasive sensing for collaborative facilities management”. As part of this, BuildAX sensors will be deployed in buildings (including, potentially, the Scottish Parliament).
In Newcastle, I’ve deployed BuildAX in a restaurant business close to the rail station to help them collect data on the temperature & humidity of their council-owned premises. We’re hoping it might be possible to use this at a later date to help convince the council to pay for building modifications to correct the problems they are having.
I’m also working with the facilities managers at Newcastle University to get some deployments going around campus, where it can be used, for example, to assist with heating complaints or check if motion-activated lighting in corridors is working correctly. We can get much finer grained sensing than provided by the BMS, and the BAX sensors are significantly easier to retrofit into office buildings.
Future
As part of my PhD, I’m looking to work with tenants or businesses in Newcastle who have some complaint about their housing/building conditions. I’m currently thinking about how to make a BuildAX “kit” which would be loaned out to tenants who need to collect data to create a discussion with their landlord towards improving their housing.
I’ve also been talking to Phil James at the Newcastle Urban Observatory, an “open data” initiative displaying sensor data collected from the city. It’d be great if we could provide some sensors to integrate into their project, or other research projects.