This article describes a real life use case of ubiworx™ in the environmental monitoring area: construction noise and vibration remote monitoring.

Some of the challenges we had to face were:

• Remote data gathering of industrial grade sensors.
• Provide a solution that dramatically saves costs.
• Do heavy computational work on the edge to minimise network (3G/4G) utilisation.
• Design of an off-the-grid solution.
• Design of a solution that can withstand all weather conditions.
• Provide real-time alerts and notifications.
• Provide 24/7 monitoring time.

In the following sections we will present a detailed solution that we have designed and implemented.

Typical scenario

An old-fashioned scenario without using ubiworx™ environmental monitoring site would require physical access to the site and instruments on a periodic basis. The most commonly used data collector instruments would gather data and store it on SD cards which would have to be collected manually. They would include no remote management or network access capabilities.

We wanted to come up with a solution that would allow us to re-use these existent instruments but in a more intelligent way. The most important features would be to collect the data and store it directly on the cloud so it would become available straight away as well as remotely managing and checking the status of the instruments.

Once the data is stored on the cloud we could apply different algorithms to manipulate it the way we needed to and generate meaningful reports in real-time.

Typically, the reports would mostly include these types of information:

• Vibration levels over frequency.
• Vibration levels over time.
• Maximum vibration levels detected.
• Statistical noise levels: Lmin, L90, Leq, L10 and Lmax.
• Historical graphs of these values over the last day, week and month.

Our solution

As any other ubiworx™ deployment, our proposed solution can be divided into two large components: the edge device side and the cloud infrastructure.

On the edge side our solution comprises of a mix of hardware and software components that we are very familiar with. On the hardware side we chose to use the UP board a foundation because of its' reliability and low power consumption. On the software side, the chosen OS is ubilinux™ - a Debian Jessie Linux distribution developed and maintained by Emutex which is specifically designed to work on the UP board. On top of it, we have ubiworx™, our IoT Gateway Framework.

ubiworx™ already features most of the requirements we initially needed so the development and integration process was drastically reduced.

To properly read data from a standard vibration sensor we had to sample the device at a higher than normal sample rate, around 100 - 200 Hz. However, this was tackled with no issue by ubiworx's soft-real-time execution engine.

Making use of our "local logic" feature we are able to analyse all samples just after they are read from the sensors and act upon following user-defined rules, in this case to generate alarms and notifications whenever high levels of noise were detected.

The versatility of the UP board was much appreciated when it came down to extend its I/O with off-the-shelf HATs. One of the vibration sensor we used has three analogue outputs that need to be read simultaneously. Since the UP board has only one single ADC input pin we decided to use a 3rd party HAT. Extending the board capabilities through HATs is probably one of its coolest features. In this case we used an ADC HAT to read the three analogue inputs from the vibration sensor.

The 3G/4G network access was achieved with an USB 4G dongle. All the other components were simply off-the-shelf.

The boxes have to be able to operate with no connection to any source of main power since they would mostly be placed on sites with no access to the main grid. In order to solve this problem we used a solar panel, a car battery and a charging controller.

In terms of isolation from the outside world, the UP board was put inside a plastic enclosure along with all the sensitive connections. A bigger Rital box was used to place all the other components - including the UP board. These industrial graded type of boxes are constantly used for several applications because of their durability under harsh environmental conditions.

The cloud infrastructure is also provided by ubiworx™ so no new development was needed. The edge devices report to the ubiworx™ broker and the data becomes immediately available through our REST API. Other features like "store and forward" - a TCP-like way of synchronising data between client and server assures us that no data is lost even if the network is down.

The following image describes the initial architecture:

While the process is fully automated and "much more real-time" than the original and manual methodology, we plan to bring it to a new level. In future phases of the project we are planning to move all the post analysis down to the edge device. The UP board features a very powerful CPU and we have already proven that running CPU intensive tasks is not a problem for it. ubiworx™ on the edge will not only gather the raw data from both vibration sensor and microphone but it will also process the data and report ready-to-plot information. The future architecture will look like the following:

The following sections will give a better insight into the implementation of some of the main components.

Noise Level

Background noise level measurement was the first challenge we had to face. The background noise level calculation is not trivial, from an implementation point of view. The audio captured from the microphone has to be put through a series of filters in order to obtain a response similar to the one the human hearing would get. The industry standard way of doing it is by using an A-weight filter. This filter was designed to mimic the response of the human hearing system. That is, the frequency attenuation of the A-weighting filter corresponds to an empirical average obtained across a broad sample of perceptual experiments.

Applying these kinds of filters is not trivial from a computational point of view since they require complex number manipulation and FFT calculations. As mentioned before though, the UP board is well capable of performing these types of tasks with minimal CPU usage.

We used an industrial standard CLASS 1 microphone that features an SMB connector. Given the lack of analogue audio input on the UP board, we decided to use a Sound Blaster X-FI GO! PRO USB sound card made by Creative.

In order to connect the SMB microphone to the sound card's Mini Jack a special connector had to be created. We simply used an SMB coaxial cable and a mountable stereo Mini Jack male connector.

The raw audio is captured from the sound card in 60 second chunks. We used the well known open-source ALSA library to do the heavy lifting for us. Every minute a raw mono PCM encoded, a piece of audio would be ready to be analysed. Before that though, the audio is split up into smaller pieces. The dB(A) values (A-weighted dB) are calculated from these individual smaller chunks. The algorithm we used is described in this document from MIT.

The noise level statistics are obtained from these series of individual dB(A) values. Following the industry standards we calculate:

• Lmin: minimum noise level detected in a given interval of time.
• L90: noise level that is exceeded 90% of the time. It's normally considered as background noise.
• Leq: also known as equivalent continuous noise level, it's the preferred method to describe sound levels that vary over time, resulting in a single decibel value which takes into account the total sound energy over the period of time.
• L10: Noise level that is exceeded 10% of the time.
• Lmax: maximum noise level detected in a given interval of time.

These five values are then time-stamped and sent up to the cloud as a single sample. These are ready-to-plot values. We have historical graphs of daily, weekly and monthly levels. This is real noise level data captured by one of the systems:

The raw audio is also stored locally for possible future usage but it's currently not being sent to the cloud.

Vibration intensity

The vibration sensor we used is another well known industrial standard geophone. As mentioned in previous sections, it features three analogue outputs that have to be read simultaneously. We connected these to an ADC HAT featuring two Microchip MCP3424 A/D converters. These chips are able to sample data at 240 samples per second with 11 bits of resolution. While this sampling rate/resolution is not high compared to other A/D converters, it is more than enough to cover our 100/200 sample per second needs.

From the software point of view, the integration was straight forward. ubiworx™ is designed to be very extensible, so adding code to support new types of sensors is very clean and easy. Some small logic was needed to convert the raw voltage values read from the analogue inputs into vibration intensity values (or peak particle velocity) measured in mm/s.

After converting the raw voltage into vibration intensity on the three axis (longitudinal, vertical and transverse), these three values are composed together as a single time-stamped sample before being sent up to the cloud. In order to minimise network usage, only samples that exceed a given threshold are considered - the other ones are simply discarded since they don't show enough vibration to be considered.

The post-analysis is an on-demand process that has also been automated. The data is retrieved from the ubiworx™ cloud in a JSON format. A series of mathematical functions (Fast Fourier Transformations) are applied to them in order to determine the frequency of the vibration.

Another useful way of reporting the vibration data is by plotting the vibration intensity over time. The images below show the vibration intensity broken down by axis:

Power management

In this section we wanted to explain the process we went through regarding the design of an off-the-grid solution. Starting from the power management optimisations done to the UP board, to the type of solar panel, the charging controller and batteries we chose to use.

Given the importance of this topic and the amount of cool things we learned along the way, we decided to spin-off a separate article for it.

Conclusions

With this project we brought ubiworx™ to a new area, the area of environmental monitoring. The goal was to design an off-the-grid system that could be easily deployed, scalable in terms of deployable systems and in the number and type of sensors that each one can support.

All our expectations have been exceeded with the results. The lessons learned along the way are invaluable and will be applied in future projects. We now count with a scalable solution that solves our original problem in a very cost-effective way re-using the existing hardware components.

For more information about ubiworx™ please visit www.ubiworx.com