Modular sensing platform for research

Public Chat
Similar projects worth following
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

- 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.

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.


Bill of Materials

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


  • Deployment 3 - Incidents

    Mario Frei12/02/2019 at 13:08 0 comments

    During the deployment and retrieving of the sensor nodes, two notable incidents happened that affected the occupants negatively. Two more incidents affected only the data acquisition In the first incident, a freezer stopped working in the night after the sensor deployment. For the installation of a router node, I unplugged the freezer, inserted a multi-plug, plugged in the freezer and the router node. After the installation of all sensors, I notified the building owner of the procedure and even opened the freezer door to demonstrate that it was still working. To me, it is unclear if the unplugging was the cause of the freezer thawing or if it was just an unlucky coincidence. However, the building owner was able to eat all the contents in a timely fashion. So besides the inconvenience, there was no damage. The freezer continued to work after the incident.

    The second incident happened during the removal of a sensor network. The gateway of the WSN was plugged into a multi-plug together with the building owner’s modem. To retrieve the multiplug, I unplugged the modem, removed the multiplug and plugged the modem in again. However, the modem refused to work again. The building owner was working from home and was less than amused. The modem was replaced by the internet provider without charge. The internet provider stated that unplugging and re-plugging the modem is acceptable and should not corrupt the modem. Nevertheless, it caused some inconvenience for the case study participants, which was compensated with a bottle of wine and some chocolate.

    In one instance, the heating system reached its end of life and was replaced by a new one. In this process, the sensor nodes attached to the heating system were discarded together with the heating system. This had also the consequence that for this building, we were only able to acquire a limited amount of heating data. All other sensors nodes could be retrieved intact.

    After the measurement campaign, I left the sensor nodes operating as they were in our office space, in order to assess the battery lifetime. During this time, a fourth incident happened. The admin from our institution took the webserver down because the responsible person from our time left the institution. This took all sensors offline and would have been very inconvenient during the campaign. However, after a few emails, the server was up again, and all sensor nodes would resume reporting measurement data.

    In the beginning, we had the concern that pets might interfere with the cables from the sensor nodes. However, pets never caused an issue with the sensor network.

  • Deployment 2 – Energy Metering

    Mario Frei03/12/2019 at 14:42 0 comments

    In Switzerland, the electricity is provided by the municipalities. This results in a large variety of electricity meters present in the buildings. Ideally, the electricity meters would have a visibly pulsing LED that indicates the energy consumption. That was the case for a few buildings. Sometimes the LED was infrared. However, in some cases, the electricity meters were old analog meters, which could not be interfaced easily. In anticipation of the problem, I called a few electricity suppliers about that issue. Some providers offered to replace the old meters on demand and for free since they would replace the electricity meters anyways eventually. Other providers would refuse to cooperate.

    Electricity meters caused an additional issue. The detection of the LED flash worked in the lab but did not work in the buildings. It turned out that the LED flashes of the electricity meters in the buildings were significantly shorter than the LED flashes of the electricity meter in the lab. The sensor module for pulse detection (electric pulses or light pulses) used a debouncing IC (MAX6816). The LED flashes from the electricity meters in the lab were long enough to be detected after the debouncing. The LED flashes from the electricity meters in the buildings were shorter and were ignored by the debouncing IC. The issue was solved by removing the debouncing IC for detection of light pulses. In hindsight, this is an obvious and straightforward issue.

    The municipalities also provide gas. However, in the region, where the case study took place, all meters were analog, and there were no plans to replace them anytime soon. However, in other places digital gas meters with a pulsing LED as an indicator can be found (e.g., Zurich).

  • Deployment 1 – Case Study 1

    Mario Frei03/06/2019 at 16:32 0 comments

    The current version of the sensor network was deployed in eight single-family buildings in Switzerland. The deployment started by the end of January 2017 and was ended in May 2017. Ideally, we would have started at the beginning of the heating season. One sensor kit was placed in each house. A sensor kit consisted of 18 sensor nodes, 5 router nodes, and 1 gateway. Just in these eight buildings, we have encountered a large variety of heating system setups: the energy source for heating, the energy source for domestic hot water, the metering infrastructure, the heat emission systems, and the heat storage. Sometimes we would only learn about the circumstances when being in the actual buildings.

    The case study participants were all buildings owners, who were customers of building energy assessor. We cooperated with the assessor, who asked his customers if they were interested in participating in a case study. The assessor provided us with his assessment of the buildings, which included building plans. We used the information to propose the placement of the sensors. After arrival on the side, I would sit down with the case study participants and explain the reasons for the case study and the course of action. During this talk, I would also discuss a data privacy statement, which they had to sign. Then, the building owners would show me the building, and during this tour, I made suggestions about where to place the sensors. If the building owner agreed, I would put the sensor on the floor for later installation. If the building owner disagreed, we would find an alternative solution. After the house tour with the owner, I would install all sensors properly, clean up and check whether all sensors appeared online. By the end, I would again make a tour throughout the building with the owner, indicate the sensors and asked whether he/she was content with the installation. Then I would say good-bye. The whole deployment including introduction, house tours, questionnaire took on average 2.5 hours.

    The oil flow meter for oil-based heating systems was installed by a third party after the initial sensor deployment. (Pro tip: measure the diameter of the oil line during the first visit, or you have to visit again). After the oil meters were installed, I would go back to the building for a check on all the sensors (check whether they still stick where I stuck them or whether they fell off). The sensors held up quite well. However, a few fell off (e.g., heat flux sensors or reed switches) but nothing major. The check of the sensor network took about one hour per building. 

  • Sensor Network History 3 – Third Iteration (current)

    Mario Frei09/20/2018 at 17:54 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 will trigger an 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 consist 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 a 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:

    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 a 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 nodes have too 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 follows:

    • 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:

    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 into 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 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 be 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 the 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, 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:

    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 downside 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


  • 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 outdated / 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 to 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

    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 into two effects: the prebound effect and the rebound effect. The prebound effect occurs with old buildings that are in need of a refurbishment. There, the energy consumption is usually overestimated, i.e., the actual buildings consume 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 a 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 8 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

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