Close
0%
0%

SENSEation

Modular sensing platform for research

Public Chat
Similar projects worth following
762 views
0 comments
3 followers
likes
We strive to develop a modular platform for remote measurements that is modular, low cost, reliable and easy to use. We research energy usage and comfort in buildings. Therefore, we start this journey with measurements concerning buildings in mind but we also hope to enable applications in other domains.

We want to perform measurements in remote locations with various sensors. Existing solutions seem to be expensive, offer a limited selection of sensors and require too much expertise with a specific solution from the user. That is why we propose (yet another) solution to overcome the existing limitations.
Our sensor nodes consist of two main complimentary components: a sensor module and a communication module.
The communication module manages the power, triggers the measurement and stores the data (locally and/or on a web server). The sensor module hosts all sensors, reads the sensors and sends the measured data to the communication module. Both modules feature a microcontroller.

The splitting of the sensor node into two parts brings some advantages:
- Independent development of sensor modules and communication modules
- Different communication modules are possible, e.g. local logger, various wireless solutions, etc.
- Sensor specific data can be stored on the sensor module and stays with the sensor, e.g. calibration data
- Overall smaller footprint of electronics compared to an Arduino + shields configuration
- If only one module is updated, the other can be reused

The disadvantages are:
- Higher cost due to the presence of two microcontrollers
- Reduced flexibility compared to Arduino + shields configuration

Goals
- We want to measure with a sampling rate of one measurement every 5 minutes.
- Continuous operation of a sensor kit for 6 month without the need of maintenance.
- Untrained people should be able to deploy sensor kits.
- People with little training can modify the WSN.
- Reusability of modules
- Exchangeability of modules
- Suitable for people with different skill levels in different domains.
- The deployment of a sensor kit should take less than 2 hours

There are many IoT platforms and data loggers that provide similar functionality and much more. However, we have the impression that the multitude of features comes with complexity and high costs. We want to perform a lot of measurements with many different sensors in remote places. That is all. We believe that we can reduce the cost and the required skill level by limiting the range of features and by reusing some components for different measurement campaigns. We hope that the modularity and simplicity of our proposed platform invites people from different domains to profit from our work and enrich the platform with modules that suit their needs.

Spoiler
We developed a communication module featuring an Xbee radio transceiver, an RTC and an SD-card for local storage. Further, we developed about 7 different sensor modules. We manufactured 8 sensor kits, each consisting of 18 sensor nodes, 5 router nodes and 1 cellular gateway. The measured data is sent to an online MySQL database. The sensor kits were deployed in eight buildings. In this project blog, we are going to share our experience developing, manufacturing and deploying the sensor kits in occupied buildings. We are looking forward to your feedback.

BOM_v1.xlsx

Bill of Materials

sheet - 40.08 kB - 05/23/2018 at 14:31

Download

  • Sensor Network History – Third Iteration (current)

    Mario Freia day ago 0 comments

    By now, I got a bit of experience with deploying and operating sensor networks. The major improvements of this iteration are:

    • Modular platform
    • Battery powered sensor nodes (with optional mains adapter)
    • Modular composition of sensor nodes
    • Microcontroller based gateway
    • SMD components for PCB
    • Nice 3D-printed cases
    • Xbee for communication between nodes
    • Router nodes
    • GSM for data transfer
    • MySQL tables for data storage (with PHP interface)

    The following aspects remain unchanged from the last iteration:

    The sensor nodes of the third iteration of the sensor network were split into two modules. The main module takes care or power supply and communication and the sensor module interfaces the sensors and relays the sensor readings to the main modules. This allows separating the hardware and software development of the sensors from the rest of the sensor network.

    The main module features an ATmega328p, an Xbee, SD-card, RTC, LiPo-battery, power jack for mains adapters and connectors to the sensor module. The measurement interval is set on the main module. When it is time to take a measurement, the RTC would trigger and interrupt on the microcontroller and the power to the sensor module is enabled. The sensor module then reads out the sensor and sends the data via serial to the main module. Then the power to the sensor board is again disabled. The measurement data is sent to the Gateway via Xbee. The measurement data can in addition stored on the SD-card of the main module with a time stamp from the RTC.

    The sensor modules generally consists of an Atmega328p, connectors to the main board and various sensors. When the power to the sensor module is turned on, it reads out the sensor data and puts the data in unified payload format for convenient data transmission and insertion into the database. Available sensor nodes are:

    • Air temperature and relative humidity (SHT31)
    • 2 temperatures (2xDS18B20)
    • Heat flux (gSKIN-XO667C)
    • CO2 concentration (S8)
    • Luminosity (TSL2561)
    • Windows opening times (reed switch)
    • Pulse counter (electric pulses or light pulses, to interface electricity, oil and gas meters)

    Router nodes still consist of an Xbee on a SparkFun Xbee Explorer board powered by a mains adapter.

    For the gateway, I chose an Adafruit Feather 32u4 Fona. It is Arduino compatible and features a GSM modem. The Xbee is connected to the Feather Fona via a simple custom PCB. The image below shows from left to right two sensor modules, a gateway and a router node.

    With some support from students during development and production, we manufactured eight sensor kits with 18 sensor nodes each, plus some spare ones, about 150 in total. The sensor kits were deployed in eight single-family buildings. Some of the results can be found here: https://www.sciencedirect.com/science/article/pii/S1876610217329077

    The installation of a sensor node took on average seven minutes per node. This is a huge improvement compared to 45 minutes with the previous version. The batteries lasted 10-12 month for most nodes. Exceptions were the nodes for windows opening times. The nodes for pulse counting and CO2 were powered by mains adapter. During the deployment, I observed some issues with the gateway, leading to some data loss.

    In summary

    • When it works, it is really awesome
    • Everything is on GitHub
    • Quick and easy sensor deployment
    • Sensor node has to many features leading to complexity and cost Gateway is not reliable enough (interference & occupant interaction)

  • Sensor Network History 2 – Second Iteration

    Mario Frei08/02/2018 at 12:54 0 comments

    For the second iteration of the sensor network, I tried to make the sensor nodes universal and smaller. I integrated more sensors and switched from on-site internet to cellular. The sensor nodes were still powered with wall plugs. An Arduino Pro Mini was chosen as a microcontroller unit and Xbees were used for wireless communication. The sensor selection was as following:

    • Temperatures (2x DS18B20)
    • Electric pulses (electricity meters, oil flow meters)
    • Luminosity (TSL2561)
    • Air temperature and relative humidity (SHT15)
    • Small voltages (pyranometers, heat flux sensors, Opamp: ADA4528-1)
    • Current clamp

    The sensors were only used in certain combinations, e.g. two temperature sensors and a heat flux sensor for u-value measurement. The combination of the sensors had to be set with a rotary switch on the sensor node PCB. The gateway consisted of a Raspberry Pi, a USB-GSM-modem, an Xbee, USB memory stick and a powered USB hub. The data was stored on the memory stick and in an online MySQL table. I chose a Raspberry Pi in order to have more computational power for having room to add more features. This version of the sensor network was deployed in four different case studies. Some of the results can be found here: https://infoscience.epfl.ch/record/213293/files/10_FREI.pdf

    Now to the interesting part, the issues:

    • The sensor nodes still relied on cords for power. It took up to 45 minutes to install and cable manage a single sensor node.
    • Although, sensor nodes became more flexible, it was almost impossible to integrate new sensors to the system. Moreover, for the measurement range for small voltage was limited, leading to different resistor network configurations for heat flux sensors and pyranometers.
    • The PCB is all through-hole, requiring to considerable time for manufacturing.
    • The amplification circuit for small voltages was quite crude.
    • The operating system of the Raspberry Pi runs on an SD card. Corruption of the SD-card lead to several failures, including loss of data. After these incidents, the memory stick was added and the operating system was set in a read-only mode. The read-only mode was cumbersome to enable and disable, which made changes to the python code on the Raspberry Pi cumbersome as well.
    • Finding a USB-GSM modem that works with the Raspberry Pi was a bit of a gamble. An additional challenge was that USB-GSM modems of the same type but from different production lots or revisions did not work with the same setup. The difference between the modems could only been seen through software when plugged in.
    • The USB-GSM modem requires more current than the Raspberry Pi can deliver, which made a powered USB-hub necessary, adding to the cost and complexity of the wiring.
    • The 3D printed cases were brittle.
    • The Raspberry Pi caused more problems than it solved.
    • The power cables are a major burden during installation.
    • Sensor nodes are still not flexible enough.
    • Xbees work very well given that enough router nodes are deployed.
    • Storing the data in MySQL tables works well.
    • The size of sensor nodes is ok.

    In summary:

    • The Raspberry Pi caused more problems than it solved.
    • The power cables are a major burden during installation.
    • Sensor nodes are still not flexible enough.
    • Xbees work very well given that enough router nodes are deployed.
    • Storing the data in MySQL tables works well.
    • The size of sensor nodes is ok.

  • Sensor Network History 1 – First Iteration

    Mario Frei07/24/2018 at 10:52 0 comments

    The wireless sensor kit presented on this project site is preceded by two iterations. The first iteration was completed before I joined the team. It used Arduino Unos and Xbee shields. The sensors were directly soldered to the Xbee shields. There were a few different sensor node configurations:

    • Air temperature and relative humidity (SHT15)
    • Air temperature, relative humidity and luminosity (SHT15, TSL2561)
    • Supply temperature and return temperature (of radiators) (DS18B20)
    • Oil flow (pulses), supply temperature, return temperatures and (heating system) (DS18B20)
    • Electricity consumption (pulses) (never worked properly)
    • Weather station (never worked properly)

    The gateway consisted of an Arduino Mega with an Xbee shield and an Ethernet Shield for internet access. As a failover measure, the gateway was also equipped with an SD-card and real time clock for offline logging. The measured data was sent from the sensor nodes to the gateway and from there to an online MySQL database. Although, the communication was wireless, the all components still relied on cables for power.

    Router nodes, which bridged larger distances between sensor nodes and gateway, consisted of an Xbee, which was powered by a mains adapter.

    This sensor network was prototyped in a few weeks, deployed in a mixed use building in Switzerland, and delivered live measurement data. The results can be found here: https://www.sciencedirect.com/science/article/pii/S0306261914006060

    Because all sensor nodes and router nodes relied on mains adapter, there was a lot of cable management that needed to be done during installation. Another down side was that for every sensor combination a new Arduino shield needed to be designed.

    In summary:

    • The sensor network was developed very fast.
    • Live measurement data could be collected.
    • Limitations: Cables, selection of sensors, relies on on-site internet access

    Source: https://www.sciencedirect.com/science/article/pii/S0306261914006060

  • Motivation 2 – Gathering Measured Data

    Mario Frei07/16/2018 at 08:07 0 comments

    There are two options for gathering measured data from remote locations: data loggers and sensor networks. Below, I listed my impressions on some of the solutions and their pros and cons. Some of the impressions outlined lead to the decision to start a new wireless sensor framework, and some of the impressions were gathered during the development.

    • Academic WSN (e.g. Mica, Telos, Wispes)
      • + Mesh networking
      • + Battery powered
      • + Tested
      • – Seem to be out dated / not active
      • – Not really open source
      • – Small community
      • – Seem to be complicated
        • Meant for electrical engineers
        • Meant for research on wireless networks and not on the measured data
      • – Rather expensive
    • Commercial WSN (e.g. Libelium, Advanticsys)
      • + Battery powered
      • + Mesh networking
      • + Flexibility regarding internet access (Libelium)
      • + Flexibility regarding sensor choice (Libelium)
      • + Lots of documentation (Libelium)
      • + Tested
      • – Expensive
      • – Not really open source
    • Commercial data loggers (e.g. Testo, Hobo)
      • + Battery operation
      • + Tested
      • – They are data loggers: You only know after the measurement, whether it was successful or not.
      • – Limited selection of sensors from one supplier. You may need products from multiple suppliers
      • – Expensive despite limited functionality
      • Not open source
    • Academic data loggers (e.g. OSBSS, Cave Pearl)
      • + Arduino based
      • + Tutorials available
      • + Battery powered
      • – Still in prototyping stage
      • – Not modular
      • – They are data logger (see above)
    • Arduino + Shields / Proto-boards (e.g. Arduino, Moteino)
      • + Huge community
      • + Open source
      • + Modular sensor arrangement is possible
      • – Not clear if battery operation is possible
      • – Time for Manufacturing
      • – Still rather expensive
      • – Larger form factor
      • – Not tested
    • Custom Arduino based solution
      • + Potentially cheaper
      • + Huge community, since it is based on the Arduino ecosystem
      • + Potentially fast(er) to manufacture (if SMD parts are used)
      • + Potentially small (enough) form factor
      • + Virtually infinite flexibility (if modular)
      • – Risks: reliability, manufacturing

    Despite the plethora of papers on WSNs, I could not find a framework that is truly open source and simple enough that I would dare do tinker with it. This led me to think that there is a niche for a simple and modular framework for remote measurements. Although, our research field is buildings, I could imagine that it could be used in other fields.

    I would like to mention two academic data logger projects, which inspired me to publish our work on GitHub and on hackaday.io:

    Both provide source files, build instructions and tutorials. Check them out!

    If there is a modular open-source framework for remote measurements that I am not aware of, let me know in the comments.

  • Motivation 1 - Background

    Mario Frei07/11/2018 at 11:54 0 comments

    Buildings account for about 40% of the primary energy use in the EU and US. The life span of buildings lies between 50 and 100 years. This is why approximately 60% of the current building stock will still be in use by 2050. This means that any endeavor to reduce the energy consumption needs to include buildings, in particular retrofitting of existing buildings.

    However, with buildings there is the issue of the performance gap, which occurs when the calculated energy demand differs from the measured energy demand of a building. For building retrofits, the performance gap can be separated in two effects: the prebound effect and the rebound effect. The prebound effect occurs with old building that are in need of a refurbishment. There, the energy consumption is usually overestimated, i.e. the actual buildings consumes less energy than what the calculation would suggest. The rebound effect appears in new buildings or newly retrofitted buildings. In these cases, the measured energy consumption is usually higher than what the calculation suggests. The reasons for these differences are erroneous assumptions of the building properties, occupants and building systems (e.g. set points, occupancy, material properties, aging of materials, etc.).

    These effects lead to imprecise building assessments, which necessitate large safety factor for retrofit measures.

    We argue that visual inspections of the building could be complemented with on-site measurements. With measurements, we can replace estimations needed for the calculations by measuring building parameters and occupant behavior. For this, we developed a wireless sensor kit that can be deployed in occupied buildings to gather information about the actual state of the building.

    For more information on the performance gap can be found here.

View all 5 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates