# A Cost-Effective, Scalable, and Portable IoT Data Infrastructure for Indoor
Environment Sensing

Sheik Murad Hassan Anik  Xinghua Gao  Na Meng  Philip R Agee  Andrew P McCoy
Department of Computer Science, Virginia Polytechnic Institute and State
University, Blacksburg, VA 24061, USA  Myers-Lawson School of Construction,
Virginia Polytechnic Institute and State University, Blacksburg, VA 24061, USA

###### Abstract

The vast number of facility management systems, home automation systems, and
the ever-increasing number of Internet of Things (IoT) devices are in constant
need of environmental monitoring. Indoor environment data can be utilized to
improve indoor facilities and better occupants’ working and living experience,
however, such data are scarce because many existing facility monitoring
technologies are expensive and proprietary for certain building systems, such
as building automation systems, energy management systems, and maintenance
systems. In this work, the authors designed and prototyped a cost-effective,
distributed, scalable, and portable indoor environmental data collection
system, Building Data Lite (BDL). BDL is based on Raspberry Pi computers and
multiple changeable arrays of sensors, such as sensors of temperature,
humidity, light, motion, sound, vibration, and multiple types of gases. The
system includes a distributed sensing network and a centralized server. The
server provides a web-based graphical user interface that enables users to
access the collected data over the Internet. To evaluate the BDL system’s
functionality, cost-effectiveness, scalability, and portability, the research
team conducted a case study in an affordable housing community where the
system prototype is deployed to 12 households. The case study results indicate
that the system is functioning as designed, costs about $3500 to sense 48
building zones (about $73 per zone) and provides 12 types of indoor
environment data, is easy to scale up, and is fully portable.

###### keywords:

Internet of Things, Sensing Network, Facilities Management, Indoor Environment
Sensing, Raspberry Pi

††journal:

##  1 Introduction

Buildings are one of the most important aspects of human life, and people
spend 87% of their time inside buildings [1]. Buildings have both direct and
indirect impacts on human health, comfort, and productivity [1, 2, 3, 4].
Maintaining optimal conditions for a better experience is critical for built
environments. New techniques and methods are becoming available for this
purpose with the developments of the Internet of Things (IoT) technologies [5,
6]. For example, an air quality monitoring system can benefit occupants in
many ways from detecting harmful gases to monitoring oxygen levels. There are
systems, such as the ones presented in Zakaria et al. [7] and Marques et al.
[8], that provide indoor air quality monitoring. However, these systems are
dedicated for air quality monitoring only without the capability of extension
to other features such as temperature or humidity monitoring. Another
important application of indoor environment sensing system is to support the
optimization of building energy consumption. Buildings consume about 40% of
total consumed energy, and half of that goes to Heating, ventilation, and air
conditioning (HVAC) systems [9]. A significant portion of this consumed energy
is wasted [10], and using a proper monitoring and control system can reduce
this waste significantly [9].

Even though many building systems already incorporate proprietary networks of
sophisticated sensors and devices, they normally have very limited
inter‐system connectivity or exposure to the larger networks of IoT devices,
which hinders the establishment of a comprehensive IoT data infrastructure for
building automation and management.

There are four major challenges in establishing a comprehensive IoT data
infrastructure for buildings. First, the high cost of the sensing devices is a
major reason why building owners and managers are normally reluctant to
install a data system in the first place. For example, the average cost per
square foot to outfit a facility with a building automation System (BAS) is
$2.30, in 2017, which means it will cost about $230,000 on BAS alone for a
typical 100,000 square foot building [11]. Moreover, building systems such as
BAS will not last for the entire life cycle of a building, and there will be
upgrade fees for about every ten years or less. Second, the installation of
building systems can be a challenge for existing buildings. The best time to
install a building system, with numerous wires and devices, is during
construction. After a building starts to operate, installing additional
systems or changing the existing ones are usually disruptive to occupants.

The third challenge is that most of the data generated by commercial building
systems are self-proprietary because most of the existing building systems are
lacking interoperability. Typically, there is a lack of means to use the data
collected in one system for another system’s functions. Different systems need
to generate the indoor environment data they need, and the data are not in a
format that can be used for other purposes, which significantly limits the
potential of smart building innovations. Scalability is the fourth challenge.
For many building systems, after the initial installation during construction,
it is usually difficult to modify the system by adding or removing features,
or increasing the coverage to other building spaces. The system’s functions
and scale, including what kind of indoor environment data to generate, are
usually settled by the time of initial installation. Scaling up the system may
cost more than installing a brand new system that can cover the required
functions and spaces. In addition, current building systems are lacking
portability. Usually, after a system is installed in a building, it normally
cannot be ported to a different location later on. It is very challenging to
take out the system from the installed location and place it in another
location without extensive engineering and re-construction.

In this paper, we present a cost-effective, scalable, portable, and
distributed indoor environment sensing system, Building Data Lite (BDL), to
address the building data availability challenges, and thus, to provide a
means for establishing the IoT data infrastructure of a smart building. To
collect indoor environment data, the system has three types of components:
sensing nodes, central nodes, and inter-node connections. The sensing nodes
are an array of digital and analogue sensors to collect data from the
surroundings. Each sensing node has its local database. A central node is a
web-based central server that integrates data from all local databases and
visualizes data on a website. The inter-node connections link sensing nodes
with the central node. The system is scalable such that each sensing node’s
function (what data to generate) is customizable, and it is easy to add
sensing nodes to or remove nodes from an established system. The system also
includes a web-based Graphical User Interface (GUI) for users to extract,
view, and analyze the generated data. Industry $4.0$ [12] introduced a system
that enables appliances such as refrigerators or air-conditioners to capture
relevant data and pass it to a cloud storage. The BDL system, on the contrary,
uses dedicated sensing nodes to capture targeted data through connected
sensors. This research proposes an innovative means of establishing cost-
effective, scalable, and portable IoT infrastructure for indoor environment
data generation, integration, processing, and presentation. The research team
developed a prototype of the BDL system to demonstrate how it overcomes the
limitations of existing building systems regarding indoor environment sensing
in the following manners:

a) Cost: The BDL system is built with mini computer Raspberry Pi and
compatible sensor modules. The cost of each sensing node is limited to $40 to
$60, depending on the sensing requirements. Typically, each sensing node can
cover one building zone, and therefore, for a building with 100 zones, the
entire system only costs about $5,000. The BDL system is fairly affordable for
indoor environment sensing requirements by smart building research and
innovations.

b) Installation: The distributed sensing nodes (Raspberry Pi computers) of the
BDL system are connected with a centralized server via wireless communication.
Each node can capture multiple indoor environment values of a particular
building space. The installation of the sensing nodes requires only power
supply and Internet/WiFi connection.

c) Comprehensiveness: The BDL system uses multiple sensors to collect
different environment data simultaneously, and establish a comprehensive
database that can be used for developing multiple smart building applications.
The developed prototype can capture data related to temperature, humidity,
light, sound, motion, vibration, flame, and three types of gas.

d) Scalability: The BDL system is customizable, and the users have the option
to add or remove devices (Raspberry Pis), sensor modules, and functions.

e) Portability: The nodes of BDL system are connected to the central server
via local WiFi or the Internet, which makes them portable to any location with
power supply and under the coverage of wireless network. The sensing nodes can
be removed from one location and then deployed in another location without any
engineering on the building.

f) Open-source: The source code of BDL has been published by the authors via
GitHub [13]. The BDL also provides an open-source, integrated database system
that makes it easier for other systems to utilize the generated data.

This paper is structured as follows: Section 2 reviews relevant studies
conducted in the indoor environment sensing field. Section 3 presents the BDL
system’s overall design. Section 4 demonstrates the prototype development.
Section 5 presents the case study in which the BDL system is deployed in 12
households. Section 6 discusses the challenges encountered and corresponding
solutions, potential use cases of the BDL system, and the current limitations
and future research directions. Section 7 concludes the research.

##  2 Literature Review

The first step to make a building “smart” is to establish the data
infrastructure. Data collection has always been a challenge in the smart
building research domain [14]. Wireless sensor network technologies have been
implemented as solutions to this challenge. However, there is still a lack of
cost-effective means to generate, collect, and process the ubiquitous indoor
environment data in existing buildings. In this section, related works in the
domain of indoor environmental sensing system are discussed. The innovation of
the proposed BDL system lies in comprehensively achieving cost-effectiveness,
portability, scalability, and generalizability. Therefore, the related works
are discussed regarding these properties.

Ferdoush et al. [15] presented a wireless sensor network system using open-
source hardware platforms, Arduino, Raspberry Pi, and XBee module. The system
is low-cost and scalable both in terms of the type of sensors and the number
of sensor nodes. It is suited for a wide variety of applications related to
environmental monitoring. Each sensing node centers around an Arduino board,
which incorporates multiple sensors. Ferdoush et al. [15] demonstrated their
prototype by collecting only temperature and humidity data. The Arduino board
incorporates a XBee module to communicate with the base station. The base
station is based on a Raspberry Pi which is connected to the Internet via a
router. The XBee module on the base station works as a coordinator device
which has a limitation of supporting maximum 10 sensing nodes. The system is
portable in the sense of placing the sensing nodes with the approximation of
the base station.

Gross et al. [16] conducted a study on the usage and condition of the
emergency room at Soroka Hospital Center. The experiment had a fixed system
setup in terms of the portability and scalability. The study has found that
the adult respiratory conditions are likely to occur on days with high total
particulates (TSP) and “respirable” particulates (RSP). A significant
difference was found in RSP for adults (not in TSP), when the mean values were
compared for asthma and shortness of breath days against normal days. Natural
dust is the more likely cause of this association. The authors conclude that
emergency room monitoring should be useful in locations with high levels of
man-made pollutants. Truong et al. [17] proposed an IoT system that can
capture environmental data of rural crop fields, and store the data in the
cloud. The authors applied machine learning on the collected data to analyze
environmental conditions for harmful fungal diseases in local crop fields. The
study focused on providing environmental data in rural crop fields for the
detection and management of fungal diseases. This study is more of an
application of a IoT based sensing network.

To lower energy consumption, Alva et al. [18] used video-based human occupancy
sensing to optimize the lighting strategy. This study involves the development
of a human occupancy sensing system in MATLAB and the hardware for lighting
controls. Video cameras in this system can be placed in a portable fashion but
the system remains purpose-specific, and the cameras significantly increase
the system’s cost.

Kumar et al. [19] proposed a low-cost Smart Living System, which uses an
Android-based user interface for control of home appliances. This model
integrates temperature and humidity sensor, DHT11, sound sensor, LM393, and
gas sensor, MQ135, with Raspberry Pi 3B microcontroller board. The authors
used an external GPRS module to connect their system with the internet. The
paper presents an experiment on monitoring the air quality, sound,
temperature, and humidity detection. The system uploads the collected data to
a cloud server, which decides whether the pollution level has crossed a
certain threshold.

Zakaria et al. [7] developed an air quality sensing system by utilizing MQ-135
gas sensor, coupled with the temperature and humidity sensor DHT-22. The
system can detect gaseous components such as NH3, NOx, alcohol, and benzene,
along with sensing temperature and humidity. Coleman et al. [20] developed a
low-cost indoor air quality sensing system capable of measuring volatile
organic compounds (VOCs) and other gaseous concentrations while monitoring
temperature and humidity. They identified the Indoor Air Quality (IAQ) matrix
as composed of CO2, VOC, CO, PM, HCHO and NO2. Sahal et al. [21] proposed a
Raspberry Pi v3 based model to capture and monitor gas and sound properties
from the environment. It uses a LM393 sound sensor, MQ135 gas sensor, DHT11
temperature and humidity sensor, and a GPRS module. The objective of this
research is monitoring the air quality and measuring noise intensity to
mitigate sound pollution. Marques et al. [8] provided an IoT based real-time
indoor air quality monitoring system named iAir. It features an ESP8266 with
ATMega168PA MCU as communication and processing unit. The system utilizes
MICS6814 sensor to detect gases such as Carbon Mono-oxide, Nitrogen Dioxide,
Ethanol, Methane, and, Propane. It uses WiFi connectivity and smartphone
application to provide data access and real-time notification.

The website [22] provides an online platform to make IoT projects featuring
both Arduino and Raspberry Pi with just drag and drop. A list of sensors is
provided in the system for users to use. Custom codes can also be injected if
desired. It also provides the user a dashboard to access and monitor the data
collected by the sensors connected in their system. The system helps
individuals to create custom projects with user specific requirements.

The systems proposed in [7, 8, 20, 21] are focused on specific task of air
quality monitoring with a set of fixed sensors, lacking the feature of
scalability. The system in [18] is also task-specific but significantly more
expensive than the other works mentioned here. The systems proposed in [15,
19, 22] offer the property of cost-effectiveness, portability, and scalability
to some extent. The BDL system proposed in our work aims in attaining cost
effectiveness, code-free scalability, portability, while keeping the usability
of the system more generic and task independent. BDL’s architecture is similar
to the one presented by Aheleroff et al. [23], which describes the system of
mirroring digital representatives of physical assets with two-way dynamic
mapping. In respect to [22], BDL provides a complete code-free sensing network
with both local and central database whereas [22] can be used to create
functional sensing nodes. The general concept of code-free sensing network
system can help research work across researchers of different backgrounds
because data regarding building environments can be useful in multiple
academic areas, in which not all researchers have a background of programming.

##  3 The System Design of BDL

Unlike previous studies that develop a sensing system for a particular use
case, this research is focusing on how to develop a more generic-purpose,
cost-efficient, scalable, portable, and distributed indoor environment data
sensing system that can be used to establish the data infrastructure for smart
building innovations. This section demonstrates the system design of BDL by
describing the system architecture, central server, sensing node, database
configuration and data transmission, network configuration, data integration,
and graphic user interface.

###  3.1 System Architecture

The BDL system, as shown in Figure 1, consists of a central server and
multiple individual sensing nodes, which are built around Raspberry Pis. The
sensors in each sensing node capture real-time data from the environment and
transfer the data to the connected Raspberry Pi, which has its own local
database. After a certain interval, the Raspberry Pi communicates with the
central server and upload the newly generated data to the central database.
The GUI communicates with the central database to visualize data, and provides
functions such as downloading (selected) data, downloading the error log,
modifying the system by adding or removing sensing modules or sensing nodes.

Figure 2 illustrates an example of the BDL system deployment. The green
portions represent the locations where individual sensing nodes collect
environment data. The blue area denotes the area covered by the wireless
network. The central server is also connected to this network either locally
or through a live server. The sensing nodes are modular, and each node can
have different sensors. They are portable and can be deployed anywhere with
power and network connection.

Figure 1: The BDL system architecture. Figure 2: An example of BDL deployment.

All software used in the system is open sourced, and both the database systems
used, MariaDB and MySQL, are free. The system software including both server
and sensing node has been made publicly available and can be found in the
GitHub repository [13]. The server is currently available for open access to
help researchers and industry practitioners with the need of indoor
environment sensing.

###  3.2 Central Server

The central server of BDL is designed as a web-based system. The prototype
uses PHP v7 as the server language. The front-end was written in HTML, CSS,
and JavaScript. The system is designed to use Asynchronous JavaScript and XML
(AJAX) to create a fast and dynamic GUI. JQuery and Chart.js libraries are
used for data visualization. The GUI fetches data from the central database.
The server is live and being hosted in a third party hosting sites with the
domain: building-data-lite.com. Figure 3 shows the entity relationship diagram
of the central database, and it is a general overview of the database schema.
Here the rectangular shapes denote the entities, the circular shapes denote
the attributes of the entities and the rhombus shapes denote the relation
between each entities.

Figure 3: Entity relationship diagram of the central database.

Each sensing node has its local database system to store offline data. This is
essential because there can be disruptions of communication between the
sensing node and the central server. The sensing nodes use MariaDB for the
local database. To keep data consistency, a temporary data file is being
created every hour consisting of new records that have not been sent to the
central server. The central server provides the information (for example, the
timestamp of last synchronization) to make sure the data in this file are not
redundant. In each synchronization, the file is transferred to the central
server, and then, replaced by a new one to reduce space wastage. Approximately
60 records are present in each hourly generated file, but this number will be
doubled for each occurrence of communication disruption. The central server
performs a synchronization check of the received data before storing it into
the central database. Figure 4 illustrates the data flow in the BDL system.

Figure 4: Data flow in the BDL system.

###  3.3 Sensing Node

In each sensing node, the Raspberry Pi connects with multiple sensor modules
to collect data from the surroundings. Figure 5 shows the prototype of a
sensing node. The sensors are connected via the GPIO ports of the Raspberry
Pi, with a GPIO extension breadboard for easier deployment. The Raspberry Pi
can take digital inputs only, which is a problem in incorporating analogue
sensors, such as the light sensor and the gas sensors. To resolve this issue,
the authors use an analogue-to-digital converter, MCP3008 [24], to capture
readings from the analogue sensors. The MCP3008 has 8 channels, which means it
can connect up to 8 analogue sensors with the Raspberry Pi. The rest of the
GPIO pins on-board will be able to connect one digital sensor each. The
sensors have been categorized in three types depending on their implementation
with the Raspberry Pi. Type 1 is the direct input sensors, for example, the
light dependent resistance sensor (LDR) [25]. These sensors connect to the
GPIO pins and Raspberry Pi can be directly read data from these pins. Type 2
refers to the sensors that provide a feedback signal to the connected pin when
an event occurs, for example, the sound sensor [21, 26] or the motion sensor
[27]. The third type of sensors do not share a common implementation pattern
and needs to have a specific implementation code. The repository will be
continuously updated with new sensors of this type for users to just select
and use. Advanced users can add their custom code in the system for this type
of sensors. The code repository [13] includes a section to add custom codes
for this sensor type.

The range of each sensor is different and some sensors include a potentiometer
to tune the amplitude of readings or range of the sensor. As the system is
designed to be of generic purpose, the range of a sensing node will depend on
the sensors used in the particular node. For example, the default radius of a
PIR motion sensor is 6 meters with 120 degree angle while a temperature sensor
should capture the temperature of the air surrounding the sensor. The sensing
node captures environment data through the connected sensor modules and stores
them in its local database, which is designed based on the connected sensing
modules. It captures one value from each sensor at every given time frame, for
example, 60 seconds. The Raspberry Pi must have an operating system installed
and include the required packages to run python scripts of the sensing
program. The packages required to run the program is listed in a note with
more instructions on the code repository [13].

Figure 5: Sensing node prototype version 1.

There are multiple options for the core of the sensing node design, such as
ESP8266, ESP32, Nodemcu, Arduino, Pycom, and our selected board of Raspberry
Pi. While the other boards are slightly cheaper than Raspberry Pi (model 4B),
they are mostly microcontrollers and/with WiFi connectivity modules. These
boards provide easier connectivity with low-level sensors but Raspberry Pi
boards provide the functionalities of a complete computer system with
operating system, memory, database, built-in WiFi module, HDMI, and USB
extension ports. It is easier to program, collect and store data in a
Raspberry Pi than the other boards, especially for a non-technical individual.

###  3.4 Database Configuration and Data Transmission

There are two separate database designs in the BDL system. One is used in the
sensing nodes (shown in Figure 6) and another in the central server (shown in
Figure 3). The database share some common entities such as “error_logs” and
“sensors”. The “data_storage” table of the local database represents a
specific Raspberry Pi table in the central database with the name “rpi_n”
where n represents the raspberry pi identification number.

Figure 6: Local database design.

Specific implementation of the system will vary according to what sensor
modules are used by each customized sensor nodes. The “placements” table
records Raspberry Pi nodes presents in the system. It has a column “updated”
which refers to changes made in the Raspberry Pi. It will be 1 if a sensor has
been added in the system or removed from the system and 0 otherwise. The
entity “rpi_1…n” represents sensing nodes based on Raspberry Pi boards. A new
table marked with an increasing identification number is created every time a
new node is inserted in the system. Every node can have different set of
sensors connected to it. The dynamic set of sensors makes changes of sensor
columns “sensor1_1…n” in the corresponding Raspberry Pi table. The sensor
information of each sensing node is also recorded in the “sensors” table which
contain implementation specific information, such as sensor type and
connecting pin number. Each record in the “rpi” table is denoted by a unique
id generated from the combination of date_time and rpi_id. The date_time and
rpi_id (Raspberry Pi ID) are string data and are present in separate columns
to enable faster queries. The rest of the columns represent different
information record related to the sensors, such as light presence,
temperature, sound, etc. The central database contains additional tables to
keep track of the sensing node placements and sensor modules. The “error_logs”
table contains exception message logs. The local database system used in each
sensing module is MariaDB, which is usual for Raspberry Pi systems. The
central database is created using MySQL. MariaDB and MySQL are similar in many
aspects, and to keep concurrency between them does not take much effort.

Data transmission in the system is done through post methods in Hypertext
Transfer Protocol Secure (HTTPS) which is secure. Relaying on the security of
HTTPS, external encryption and decryption mechanisms have not yet introduced
in the current BDL system but there are plans to introduce those in future.
The frequency of requests in the system will depend on the number of sensing
nodes in the system and not the number of sensors in each node. This is
because the a sensing node will send chunk of data collected from all its
connected sensors in a preset interval which can be an hour or a day or a
month. This practically eliminates the limit of server request bottleneck
because it is very unlikely that multiple sensing nodes will hit the server at
the exact same time. Even if such scenario occurs, the HTTPS server can handle
at least 200 requests a minute.

###  3.5 Network Configuration

The BDL system is designed to run in both local and global connectivity. For
the global setup, the server needs to be running in a live domain. Many live
domain hosting providers are capable of running PHP server. It is one of the
most common server languages and easy to implement. After the server project
folder has been uploaded to the server’s public HTML folder, the server can
start running at the domain address. The domain address needs to be set in all
sensing nodes, by the change of a single line of code. Each sensing connects
to a wireless network. If a server is deployed in local mode (on one of the
Raspberry Pis rather than on an independent computer), then all sensing nodes
and the server needs to be connected to the same network. If working in the
global mode, then each node and the server need to be connected to the
Internet.

The DBL system prototype 1 adopts the Raspberry Pi model 4B, and the prototype
2 and 3 adopts the Raspberry Pi Zero W because they all have built-in WiFi
modules for wireless network connections. Data are transferred from the
sensing nodes to the central server via the network, which can be WiFi or
wireless Internet (4G, 5G, etc.). If the network connection is broken for some
reason, the sensing nodes will keep working in offline mode, in which they
will keep generating data and storing them in their local databases. The data
will be synced whenever the connection is resumed.

###  3.6 Data Integration

In each sensing node, the sensors output data to the connect Raspberry Pi
either directly or through an analogue to digital converter (ADC), and the
Raspberry Pi receives the data through the GPIO ports. The sensing node is
programmed to run in an infinite loop to collect data continuously. In the
prototypes, there is a 60 seconds interval between the readings, and it can be
changed according to demand. The data record interval does not need to be
manually adjusted and the user can view the data in different intervals on the
GUI regardless of the input interval. The viewing interval however can be
either equal or greater than the recorded interval, for example, if data is
recorded every minute then the records cannot be viewed per 30 seconds but
they can be viewed as per minute or as per 10 minutes. The Raspberry Pi
collects all sensor readings each minute and merge them together to make a
record. The record is then stored in the local database with a timestamp and
other necessary information, such as location and the identifiers of sensor
modules. If any of the sensor faults in providing data, a system exception is
thrown. The sensing node records the exception details with the timestamp in a
separate table in the local database. The data is stored in numeric format.
Each sensor is different in regards to its readings, for example, the
temperature sensor (DHT11) provides readings in degree centigrade while the
humidity reading is in percentage. Figure 7 illustrates some data format
sample from the sensors connected in the designed prototype. Here, each column
from ‘temperature’ to ‘lpg’ refers to a sensor name and the records show the
different type of values each sensor generates.

Figure 7: Sample data format

In the prototype system, the sensing node is programmed to communicate with
the central server once every hour (which can be changed). Each sensing node
sends its identification string to the central server, and the server returns
the ID of the latest stored data from the corresponding sensing node. After
receiving that ID, the sensing node queries the local database for all the
records inserted after that given ID. The local database then returns the
newly inserted records to the sensing node. These are the records that are
present in the sensing node but not yet inserted in the central database. The
sensing node then creates a CSV file with these records and sends the
generated file to the server. The central server receives the data and
performs another synchronization check before inserting them to the central
database.

###  3.7 Graphical User Interface

The BDL system’s GUI has five functions, which are 1) data visualization, 2)
data download, 3) error log download, 4) add or remove sensing nodes
(Raspberry Pis), 5) modify sensor modules on each sensing node. Figure 8(a)
illustrates the home page, which updates dynamically on the value change of
the control fields. To visualize the data, the user can specify sensing
node(s), the time range, time interval, and sensor module(s). The data is
generated by the sensors connected to the sensing nodes. The data is
represented in a graph chart with the date-time in x-axis and sensor reading
in the y-axis. The user can also download the numeric data in a CSV file
through the data download page shown in Figure 8(c). The user has the option
to select the sensing node and sensors from the list of connected sensors. The
system’s error log collects error information from all the sensing nodes and
it can be downloaded for each sensing node and specified time span, similar to
data download page as shown in Figure 8(c).

Figure 8: BDL system’s Graphical User Interface

The BDL system architecture is designed in a way that it is capable of
including or removing sensing nodes and sensors of each node as per the need.
The user has to connect and disconnect the hardware manually, and the BDL
system will adjust the code based on the user inputs from GUI. The GUI has the
option to add/remove sensing nodes and sensors, which can be done by clicking
the button. The user does not need to write any code to add or remove a
sensing node or a sensor. After the operations on hardware, which are set up
the Raspeberry Pi, and connecting or disconnecting sensor modules to it, the
user can use the GUI to finish the system configuration, as shown in Figure
8(b) and Figure 8(d).

The sensors are categorized in three types as described in section 3.3. The
GUI offers a dropdown list for the user to select the sensor type when adding
a new sensor. The user needs to specify the sensor name, type, and, connected
pin in the GUI as shown in figure 8(d). As mentioned in section 3.3, the
sensors of type-3 require specific implementation code, to minimize the effort
on the user, the GUI of BDL offers a list of supported sensors which the user
can directly choose from. This list will be kept up to date to support latest
sensors. The advanced users also have the option to write and add their custom
code in the system for this type of sensors. The code repository[13] includes
a section to add custom codes for this sensor type.

##  4 Prototype Deployment

In the BDL system, each sensing node is centered around its own Raspberry Pi,
which is connected with a set of analogue and digital sensor modules. Any
sensor that is capable of communicating through the General-Purpose Input
Output (GPIO) ports of the Raspberry Pi system can be connected in this
system. The first two prototypes of the BDL system were developed using the
following sensors: DHT11 (temperature and humidity) sensor, light sensor,
sound sensor, vibration sensor, motion sensor, MQ2 (smoke, natural gas and
carbon mono-oxide) sensor. The third prototype version includes a sensor array
named Enviro Plus [28], which includes light, proximity, gas, and sound
sensor. Each sensing node is connected to the central server via either a WiFi
network or a wireless Internet connection. The prototype 1 and 2 use the
central server in local connectivity mode, in which the server and the sensing
nodes need to be connected in the same wireless network to communicate. The
prototype 3 uses the global mode, in which the server is implemented in a live
server in the cloud, eliminating the need for being in the same wireless
network with the sensing nodes. In this mode, each sensing node needs to be
connected to the Internet via either wired or wireless connection. The
Raspberry Pi model 4B used in the first prototype features both types of
connections while the other two prototypes use Raspberry Pi Zero which uses
the wireless communication.

Figure 9: Sensing node prototype version 2 (left) and version 3 (right).

The sensing nodes of the BDL system are customizable and can be implemented in
different ways. To demonstrate the different implementations, three separate
variations of the sensing node were created and tested. While the server side
remained the same, the physical hardware setup of the sensing nodes varied.
Figure 5 shows the bread-board setup which is completely scalable with plug-in
sensors (prototype version 1). Figure 9 (left) shows the Printed Circuit Board
(PCB) version of the bread-board variant using a Raspberry Pi Zero, which is
prototype version 2, and the third version of the prototype, which uses a
Raspberry Pi Zero connected to an Enviro Plus sensor module, is shown in
Figure 9 (right).

Figure 10 shows the structure of one of the prototype sensing node (v1 & v2).
It contains seven sensors and provide 10 type of readings. On the figure, the
solid lines represent the digital data and the dashed lines represent the
analogue data. Prototype v3 has similar design with different set of sensors.

Figure 10: Structure of the prototype’s sensing node.

The sensors used in the prototype v1 & v2 are listed as follows:

Figure 11: Sensors used in sensing node prototype.

  * 1.

Temperature and Humidity sensor (DHT11) : This sensor provides readings for
temperature and humidity[29, 30, 31]. The system uses degree centigrade as the
unit of temperature and percentage for the unit of humidity. It uses a
capacitive humidity sensor and a thermistor to measure the surrounding air,
and can generate new data every 2 seconds.

  * 2.

Light sensor (GL5528): The light sensor is one of the digital sensors. It uses
photo-detector GL5528 to detect light intensity of the surrounding
environment. The resistance of the sensor varies depending on the amount of
light it is exposed to which changes the output voltage. It provides 0 when it
detects light and 1 if it does not detect any light. The sensor has a tuning
potentiometer (POT) for adjusting the reading threshold [25].

  * 3.

Microphone Sound sensor: The sound sensor is also a digital sensor. When
module in the intensity of the sound environment does not reach a threshold
(set through the included variable resistance), the sensor will output a high
signal. Otherwise, it will output a low signal. The sensor detects a change in
sound amplitude and provides a reading [21, 26]. This reading can be called a
beat. The designed sensing node counts the number of beats in a time interval
for the data record.

  * 4.

Flame sensor: This sensor detects the presence of flame nearby. It is
sensitive to flame wavelengths between 760nm to 1100nm in infrared. It is a
binary sensor and provides 1 for the presence of flame and 0 for otherwise.
There is a tuning potentiometer to adjust the reading threshold of the sensor
[32].

  * 5.

Vibration sensor (SW420): The vibration sensor can detect nearby vibration
beyond a threshold defined by a potentiometer and provide a binary reading
[33]. The beat counting mechanism has been used to present the readings of
this sensor (how many beats per minute).

  * 6.

Passive Infrared Motion sensor (HC-SR501): Passive Infrared motion sensor,
also known as PIR sensor, records the intensity of motion detected nearby
[27]. It comes with two tuning potentiometers to adjust sensitivity and
reading delay. The output goes high when objects enter the sensing range, and
automatically returns to low when object leaves.

  * 7.

Gas Sensor (MQ2): This is an analogue gas sensor that requires an additional
analogue to digital converter circuit to incorporate this sensor with the
Raspberry Pi. It can provide continuous readings of smoke, carbon monoxide
(CO), and liquefied petroleum gas (LPG) [34].

Prototype v3 uses a sensor array, Enviro Plus [28], which packs light,
proximity, temperature, humidity, gas, and sound sensors. The prototype’s
source code is shared through an open-source project published on by the
authors [13]. The wiring settings of each sensor is written in comments of the
source codes. A GPIO extension for the Raspberry Pi has been used in the
prototype development for the ease of implementation in a breadboard setup
(v1). The digital sensors are directly connected to the GPIO pins of the
Raspberry Pi. The analogue sensors are connected to the MCP3008 analogue-to-
digital converter, which forwards a digital output to the Raspberry Pi for the
respective analogue sensor connected. Figure 11 shows the different sensors
used in the sensing node prototype. From the left, DHT11, light sensor, sound
sensor, flame sensor, vibration sensor, motion sensor, and, MQ2 gas sensor.
The version 2 uses the same setup in a printed circuit board setup, which
makes the setup more compact.

To demonstrate the flexibility and stability of the sensing nodes, a total of
30 nodes including all three variants have been developed and deployed which
are continuously collecting data for over 4 months.

##  5 A Case Study

To evaluate and demonstrate the capabilities of the BDL system, the research
team has been conducting a case study. A total of 48 sensing nodes are being
deployed and collecting data continuously in 12 households (four sensing nodes
each, distributed in different rooms) of a affordable community in Richmond,
VA. The data collected by the sensing nodes of BDL prototype 3 system are
being transferred to a live cloud server.

The typical sensing node deployment is illustrated in Figure 2, in which one
of the houses’ floor plan and the locations of the devices are shown. Figure
12 shows a set of images about the deployed devices, and Figure 13 shows an
image of a house in the case study.

Figure 12: Image a deployed sensing node. Figure 13: A photo of a house in the
case study.

The research team use BDL prototype version 3 for the case study because it is
more compact and, with the 3D-printed cases, it is more acceptable for the
house occupants participating in this study. BDL v3 uses Raspberry Pi Zero
with built-in WiFi module, connecting with the Enviro or Enviro Plus sensor
bundles. The Enviro Plus bundle includes proximity, humidity, pressure, light,
sound, and gas sensors. It is the advanced version of Enviro bundle, which
includes all these sensors except for the gas sensor. The research team has to
use some of the Enviro bundle because the global chip shortage is impacting
the availability of the Enviro Plus bundle. The server side code is slightly
modified so that both types of the sensor bundles can be installed in the
system with just a single click.

The deployed system’s central server operates in global mode on an Apache
server [35] of the Xampp module [36]. The server is established in a laptop
with Microsoft Windows 10 as the operational system. The central database is
built with MySQL [37]. Local WiFi networks are used to connect each house’s
sensing nodes to the cloud-based central server. The sensing nodes’ local
databases are built with MariaDB [38]. If the server becomes unavailable in
situations such as lost Internet connection, the data transfer will be
cancelled. Instead of making a second communication attempt immediately, the
sensing node will keep collecting more data and then repeats the data transfer
process after another hour. In this process, the data may pile up in the
sensing node, and the generated file size will keep increasing every hour but
60 records per hour will not make the file size larger than the transfer
capability of the current network systems.

The web-based GUI displays graphs of the data collected from the 12 houses and
stored in the central server. With the proper selection of the control options
(shown in Figure 8a), the graph representation of the collected data can be
presented on the website (building-data-lite.com). The system can show data
graphs for all sensors of a sensing node on a single page, as Figure 14 shows,
or the data graph of a particular sensor with additional detailed information
such as minimum, maximum and average, as Figure 15 shows.

Figure 14: Visualization of collected data from all sensors of a deployed
sensing node. Figure 15: Visualization of collected data of a single sensor.

Figure 14 illustrates a truncated view of 6 sensor readings of a sensing node.
The graph presents the collected data of this sensing node from 1st August
2021 to 31 August 2021. On the top row, the data of the proximity sensor and
the humidity sensor are shown, and followed by the data of the pressure sensor
and the light sensor on the second row, and then, the data of oxidised gases
and reduced gases on the third row. The Figure 15 shows the temperature data
captured by the sensor node Raspberry Pi #10 (rpi_10). The minimum, maximum,
and the average values are 27.7, 26.3 and, 26.98 centigrade degree,
respectively. In all graphs, x-axis represents the date-time of data and the
y-axis represents the reading of a particular sensor.

The Enviro and Enviro Plus sensor board also include a LCD display. The BDL v3
sensing nodes utilize this display to provide the house occupants with a
reading of the most recent data.

The deployed devices in this case study are planned to collect data for at
least one year. The data will be collected with full respect to the privacy of
the tenants. These indoor environment data will be used for research studies
related to low-income households, the performance of manufactured houses, and
other related topics.

##  6 Discussion

###  6.1 Challenges and Solutions

This section discusses the technical challenges encountered by the authors and
provides corresponding solutions.

_Analog signal_. The Raspberry Pi, as the center of each sensing node, can
only receive digital signals, but some of the sensor provide only analog
signals (e.g. the gas sensor MQ2). This issue is solved by using an additional
analogue-to-digital converter circuit.

_Binary sensors_. Some of the sensors provide only yes-no data. For example,
the sound sensor gives a reading when detect a sound, but it cannot provide
any measurement of the amplitude of the noise. The authors implemented a beat
counting system to count the frequency of sounds during a time interval to
achieve an understandable reading from the sensor.

_Sudden crashes_. There were some sudden run-time crashes during the data
collection phase. The problems were caused by faults in sensor readings, bad
connection, overloaded access, and unavailability of server. Python’s run-time
exception handling feature was used to tackle these issues. Two types of
exceptions were caught during this phase. The first one occurred due to a
problem in sensor reading or sensor connection and the second one occurred due
to server unavailability, longer wait time, or bad network connectivity. These
exceptions were caught and logged in local database and later the log is
transferred to the central database.

_Data synchronization_. Synchronization is important for the data continuity
and integrity between each sensing module and the central server. The authors
solved this issue using a two-fold solution combined together. First, a
routine update mechanism between sensing node and central server was designed.
Instead of transferring data records, we transferred files consisting of
multiple records. Second, a record checking system was implemented in the
sensing node to keep data consistency. The databases in both sensing nodes and
the central server were restructured to reduce the number of entries (the
database designs for the sensing node and the central server are shown by
Figure 3 and Figure 6, respectively).

_File size limit_. The sensing nodes transmit the newly added records to the
central database through a data file. If the transmission is not complete for
some reason, such as the server being unavailable, the sensing node will wait
another hour for the next transmission attempt. The file size increases as the
number of unsent records piles up. The problem occurs when the file size
exceeds 2 Megabytes, which is the default limit of file transfer in the local
PHP server. The authors addressed this issue by manually overwriting the
maximum transferable file size limit in the “php.ini” file.

###  6.2 Potential Use Cases

The proposed BDL system is an innovative method to create the data
infrastructure for existing buildings. It is also one step towards many
potential smart building applications. Several example use cases are listed as
follows:

_Space utilization analysis_. The BDL system can be used to collect historical
data of building space usage. These data can be used for space utilization
analysis to deduce whether the space is being used properly or not; is it
underused or is it overused; what is the indoor environment when the space is
used, etc.

_Building control system_. The BDL system can provide data to, or be merged
with a building control system to enable automated building control. With
sufficient data and analysis (such as machine learning on occupant behavior),
the system can automatically control the indoor environment, such as light,
temperature, humidity, ventilation, etc.

_Emergency management system_. The BDL system can be modified to become an
emergency warning system. It can warn the building owner if it detects any
abnormal characteristics in the indoor environment. The user can set a
threshold for a particular reading to be marked as abnormal, or machine
learning models can be developed to detect anomalies.

_Activity monitoring_. The BDL system can be used as a monitoring system for
detecting unusual activities. It can provide data to, or be merged with a
building security system that can warn the building owner that there is an
unusual activity, such as burglary, in a particular building space.

###  6.3 Limitations and Future Research

Although the proposed BDL system’s first prototype has been finished and
experimented with, the system is still under development, and there are some
limitations, which will be resolved or mitigated in the future.

Some of the sensors require fine-tuning and calibration to provide a more
accurate reading. The prototype has been calibrated, but for more accurate
results, the system needs to be calibrated in different environmental
conditions. The authors have plans to create more sensing nodes and deploy
them in different locations. It will help us in tuning and calibrating the
sensors for improved accuracy.

The BDL system is capable of running in both local connection mode and global
connection mode via local WiFi or Internet connection, respectively. The
current prototype has only been tested in the local mode because of the lack
of a live server. In the future, the system will be designed in a way that it
will be able to switch between local mode and global mode.

##  7 Conclusion

This paper presents the research study that aims to establish a distributed
wireless sensing network for collecting indoor environment data in existing
buildings. This research contributes to the body of knowledge by proposing an
innovative way for establishing a cost-effective, scalable, and portable IoT
data infrastructure for indoor environment sensing. The authors first proposed
the BDL system’s overall design, and then developed three prototypes and
conducted a case study with one of them to collect indoor environment data of
12 households of an affordable community. The data can be generated by the
prototypes involve temperature, humidity, light, sound, flame, vibration,
motion, smoke, carbon monoxide (CO), and liquefied petroleum gas (LPG).

The system’s hardware is built around the mini computer Raspberry Pi and
compatible sensor modules, and its software running on each Raspberry Pi is
written in Python. The system includes a graphical user interface that enables
the user to access, visualize, and download the data, and modify the sensing
nodes and sensor modules as needed. The experiment has shown that the proposed
system is functional, portable, and scalable. The system is also affordable
with each sensing node costs only $40 to $60, and the software programs used
are free. The authors have published the system prototype’s source code on
GitHub [13].

This paper also discusses the challenges during the system development,
corresponding solutions, potential use cases, and limitations of the current
BDL system. The system has the capabilities to provide indoor environment data
for research and applications in areas such as smart building, facility
management, digital twin, and internet of things (in the built environment).
Although the proposed BDL system’s first three prototypes have been developed
and experimented with, the system is still under development and require more
adjustments and modifications to perform better. The authors plan to keep
working on the system and conduct more studies with it in the future.

## Funding

This research was funded by NSF-1845446 and NSF-1929701 grants.

## Acknowledgements

We thank Zack Miller, Marion Cake, and Madeline Petrie at project:HOMES for
supporting the case study. We thank National Science Foundation, Virginia
Housing Development Authority, and Virginia Center for Housing Research for
the research funding support.

## References

  * [1] I. Mujan, A. S. Anđelković, V. Munćan, M. Kljajić, D. Ružić, Influence of indoor environmental quality on human health and productivity-a review, Journal of cleaner production 217 (2019) 646–657.
  * [2] B. Berglund, B. Brunekreef, H. Knöppe, T. Lindvall, M. Maroni, L. Mølhave, P. Skov, Effects of indoor air pollution on human health, Indoor air 2 (1) (1992) 2–25.
  * [3] H. Tang, Y. Ding, B. Singer, Interactions and comprehensive effect of indoor environmental quality factors on occupant satisfaction, Building and Environment 167 (2020) 106462.
  * [4] K. W. Tham, Indoor air quality and its effects on humans—a review of challenges and developments in the last 30 years, Energy and Buildings 130 (2016) 637–650.
  * [5] T. K. Hui, R. S. Sherratt, D. D. Sánchez, Major requirements for building smart homes in smart cities based on internet of things technologies, Future Generation Computer Systems 76 (2017) 358–369.
  * [6] D. Minoli, K. Sohraby, B. Occhiogrosso, Iot considerations, requirements, and architectures for smart buildings—energy optimization and next-generation building management systems, IEEE Internet of Things Journal 4 (1) (2017) 269–283.
  * [7] N. A. Zakaria, Z. Z. Abidin, N. Harum, L. C. Hau, N. S. Ali, F. A. Jafar, Wireless internet of things-based air quality device for smart pollution monitoring, Int. J. Adv. Comput. Sci. Appl 9 (2018) 65–69.
  * [8] G. Marques, R. Pitarma, A cost-effective air quality supervision solution for enhanced living environments through the internet of things, Electronics 8 (2) (2019) 170.
  * [9] T. Ekwevugbe, N. Brown, V. Pakka, D. Fan, Real-time building occupancy sensing using neural-network based sensor network, in: 2013 7th IEEE international conference on digital ecosystems and technologies (DEST), IEEE, 2013, pp. 114–119.
  * [10] R. J. Meyers, E. D. Williams, H. S. Matthews, Scoping the potential of monitoring and control technologies to reduce energy use in homes, Energy and Buildings 42 (5) (2010) 563–569.
  * [11] ReadyOne, Building automation system cost per square foot (2017).
URL https://ready.one/building-automation-per-square-foot/

  * [12] S. Aheleroff, X. Xu, Y. Lu, M. Aristizabal, J. Pablo Velásquez, B. Joa, Y. Valencia, Iot-enabled smart appliances under industry 4.0: A case study, Advanced Engineering Informatics 43 (2020) 101043.  doi:https://doi.org/10.1016/j.aei.2020.101043.
URL https://www.sciencedirect.com/science/article/pii/S1474034620300124

  * [13] S. M. H. Anik, BDL Project Repository (accessed October 1, 2021).
URL https://github.com/anik801/data_collection

  * [14] L. Linder, D. Vionnet, J.-P. Bacher, J. Hennebert, Big building data-a big data platform for smart buildings, Energy Procedia 122 (2017) 589–594.
  * [15] S. Ferdoush, X. Li, Wireless sensor network system design using raspberry pi and arduino for environmental monitoring applications, Procedia Computer Science 34 (2014) 103–110.
  * [16] J. Gross, J. Goldsmith, L. Zangwill, S. Lerman, Monitoring of hospital emergency room visits as a method for detecting health effects of environmental exposures, Science of the total environment 32 (3) (1984) 289–302.
  * [17] T. Truong, A. Dinh, K. Wahid, An iot environmental data collection system for fungal detection in crop fields, in: 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE), IEEE, 2017, pp. 1–4.
  * [18] A. Alva, K. Shailesh, S. Tanuja, Design and implementation of video based occupancy sensing for adaptive lighting applications, in: 2012 International Conference on Emerging Trends in Electrical Engineering and Energy Management (ICETEEEM), IEEE, 2012, pp. 478–482.
  * [19] S. Kumar, S. R. Lee, Android based smart home system with control via bluetooth and internet connectivity, in: The 18th IEEE International Symposium on Consumer Electronics (ISCE 2014), IEEE, 2014, pp. 1–2.
  * [20] J. Coleman, E. Teitelbaum, H. Guo, J. Read, F. Meggers, Examining architectural air and temperature with novel sensing techniques, Energy Procedia 122 (2017) 1135–1140.
  * [21] A. K. Saha, S. Sircar, P. Chatterjee, S. Dutta, A. Mitra, A. Chatterjee, S. P. Chattopadhyay, H. N. Saha, A raspberry pi controlled cloud based air and sound pollution monitoring system with temperature and humidity sensing, in: 2018 IEEE 8th Annual Computing and Communication Workshop and Conference (CCWC), IEEE, 2018, pp. 607–611.
  * [22] myDevices Inc., Cayenne - The worldś first drag-and-drop IoT project builder (accessed October 1, 2021).
URL https://developers.mydevices.com/cayenne/features/

  * [23] S. Aheleroff, X. Xu, R. Y. Zhong, Y. Lu, Digital twin as a service (dtaas) in industry 4.0: An architecture reference model, Advanced Engineering Informatics 47 (2021) 101225.
  * [24] M. A. Mahmud, K. Bates, T. Wood, A. Abdelgawad, K. Yelamarthi, A complete internet of things (iot) platform for structural health monitoring (shm), in: 2018 IEEE 4th World Forum on Internet of Things (WF-IoT), IEEE, 2018, pp. 275–279.
  * [25] K. Krishnamurthi, S. Thapa, L. Kothari, A. Prakash, Arduino based weather monitoring system, International Journal of Engineering Research and General Science 3 (2) (2015) 452–458.
  * [26] A. F. Symon, N. Hassan, H. Rashid, I. U. Ahmed, S. T. Reza, Design and development of a smart baby monitoring system based on raspberry pi and pi camera, in: 2017 4th International Conference on Advances in Electrical Engineering (ICAEE), IEEE, 2017, pp. 117–122.
  * [27] H. T. Sukmana, M. G. Farisi, D. Khairani, Prototype utilization of pir motion sensor for real time surveillance system and web-enabled lamp automation, in: 2015 IEEE Asia Pacific Conference on Wireless and Mobile (APWiMob), IEEE, 2015, pp. 183–187.
  * [28] Pimoroni, Enviro for Raspberry Pi (accessed October 1, 2021).
URL https://www.pi-shop.ch/enviro-for-raspberry-pi

  * [29] D. Robotics, Dht11 humidity & temperature sensor, DHT11 Datasheet (2010).
  * [30] D. Uk, Humidity & temperature sensor, DHT11 Datasheet (2010) 9.
  * [31] AOSONG, Temperature and Humidity Module, DHT11, Datasheet (2010).  arXiv:arXiv:1011.1669v3, doi:10.1093/acprof:oso/9780195179477.003.0005.
  * [32] I. A. Taha, H. M. Marhoon, Implementation of controlled robot for fire detection and extinguish to closed areas based on arduino, Telkomnika 16 (2) (2018) 654–664.
  * [33] S. Biansoongnern, B. Plungkang, S. Susuk, Development of low cost vibration sensor network for early warning system of landslides, Energy Procedia 89 (2016) 417–420.
  * [34] B. B. L. Heyasa, R. G. Van Ryan Kristopher, Initial development and testing of microcontroller-mq2 gas sensorfor university air quality monitoring, IOSR Journal of Electrical and Electronics Engineering (IOSR-JEEE) 12 (3) (2017) 47–53.
  * [35] A. Mockus, R. T. Fielding, J. Herbsleb, A case study of open source software development: the apache server, in: Proceedings of the 22nd international conference on Software engineering, 2000, pp. 263–272.
  * [36] D. D. Dvorski, Installing, configuring, and developing with xampp, Skills Canada (2007).
  * [37] C. Shah, A Hands-On Introduction to Data Science, Cambridge University Press, 2020\.
  * [38] E. Kenler, F. Razzoli, MariaDB Essentials, Packt Publishing Ltd, 2015.


# A Sensitive Test of Non-Gaussianity in Gravitational-wave Detector Data

Ronaldas Macas<EMAIL_ADDRESS>Andrew Lundgren
<EMAIL_ADDRESS>Institute of Cosmology and Gravitation
University of Portsmouth, Portsmouth, UK

###### Abstract

Methods for parameter estimation of gravitational-wave data assume that
detector noise is stationary and Gaussian. Real data deviates from these
assumptions, which causes bias in the inferred parameters and incorrect
estimates of the errors. We develop a sensitive test of non-Gaussianity for
real gravitational-wave data which measures meaningful parameters that can be
used to characterize these effects. As a test case, we investigate the quality
of data cleaning performed by the LIGO-Virgo-KAGRA collaboration around
GW200129, a binary black hole signal which overlapped with the noise produced
by the radio frequency modulation. We demonstrate that a significant portion
of the non-Gaussian noise is removed below 50 Hz, yet some of the noise still
remains after the cleaning; at frequencies above $\sim 85$ Hz, there is no
excess noise removed. We also show that this method can quantify the amount of
non-Gaussian noise in continuous data, which is useful for general detector
noise investigations. To do that, we estimate the difference in non-Gaussian
noise in the presence and absence of light scattering noise.

††preprint: APS/123-QED

##  I Intro

Gravitational-wave (GW) data are often non-Gaussian meaning it contains
outliers. This excess noise is broadly divided into two categories: short and
well-defined noise (also called ‘glitches’), and longer-duration broadband
excess noise. Both types of excess noise can overlap with real GW signals in
time and frequency, therefore affecting GW searches, and source parameter
estimation, including the sky localisation which is used for electromagnetic
follow-up efforts [1, 2, 3, 4, 5].

In some cases, the excess noise is recorded by the detector’s witness
channels. For example, throughout the second LIGO-Virgo observing run multiple
noise couplings were recorded: mains power lines, detector calibration lines,
as well as the laser beam jitter noise present in LIGO Hanford [6, 7].

In principle, recording the noise with witness channels allows us to estimate
the noise coupling to the gravitational-wave strain channel and thus remove
the noise [8]. With this in mind, the linear noise subtraction method
gwsubtract was developed [9]. The method assumes that noise is Gaussian and
stationary, and that the noise couples linearly. About $30$% increase in LIGO
Hanford sensitivity was achieved during the second LIGO-Virgo observing run
with gwsubtract [9]. There was no noticeable improvement for LIGO Livingston
because the ‘jitter’ noise was not present at the detector.

During the third LIGO-Virgo-KAGRA observing run, binary black hole signal
GW200129 coincided with the noise caused by the 45 MHz electro-optic modulator
driver system at LIGO Livingston [10]. This noise was recorded by multiple
radio frequency (RF) channels, one of which was used to clean the data around
GW200129 using the previously mentioned linear subtraction method [11]. After
the re-analysis of LIGO-Virgo-KAGRA results, Hannam et al. (2022) found
GW200129 to be a highly precessing event; in fact, the measured orbital
precession is 10 orders of magnitude higher than any previous weak-field
observation [12].

Payne et al. (2022) questioned whether this event is indeed highly precessing
or whether the observed precession is just an artefact of the left-over noise
after the data cleaning [13]. While there were various checks performed by the
LIGO-Virgo-KAGRA collaboration to make sure that the linear noise subtraction
mitigated the noise [10], there was no statistical estimate of how much RF
noise was removed.

In this paper, we present a sensitive statistical test for measuring non-
Gaussian noise in GW data. In §II, we derive the normalised Q-transform which
allows us to make assumptions about Gaussian data. We also describe how
Bayesian statistical modelling can be used to estimate the amount of non-
Gaussian noise in GW data. In §III, we apply our method to the data around
GW200129 and evaluate the effectiveness of the linear noise subtraction. In
addition, we also show that our method can be used as an informative real-time
noise measurement. Finally, the discussion and conclusions are given in §IV
and §V, respectively.

##  II Methods

###  II.1 Normalised Q-transform

GW data containing outliers can be represented by the sum of Gaussian and non-
Gaussian time series. In our model, we assume that the Gaussian data follows a
Gaussian distribution with a standard deviation of $1$, while the non-Gaussian
noise is made out of short bursts of transient noise whose amplitudes are
drawn from a distribution.

To identify Gaussian and non-Gaussian parts of the time series data, we start
with the Q-transform defined as

$X(\tau,f,Q)=\int_{-\infty}^{+\infty}x(t)w(t-\tau,f,Q)e^{-i2\pi ft}dt,$ (1)

where $w(t-\tau,f,Q)$ is a window centered on time $\tau$ with the width of
the window proportional to the quality factor $Q$

$Q=\frac{f_{0}}{\Delta f},$ (2)

where $f_{0}$ is central frequency and $\Delta f$ is the frequency bandwidth
[14].

Using Eq. (1), we transform the time-series data into time-frequency tiles for
certain $Q$ and $f_{0}$ values. Contrary to Ref. [15] which uses a variable
$Q$, we chose to use a specific window width for two reasons.

First, we focus only on frequencies where there is non-Gaussianity which means
that our statistical measurement of noise is more precise. Furthermore, by
specifying $Q$ and $f_{0}$ we normalise the Q-tiles in such a way that the
average power for Gaussian data in each tile $k$ is 1, i.e.

$\frac{1}{N}\sum_{k=1}^{k=N}\bigg{[}\Re^{2}\big{(}A_{k}(t)\big{)}+\Im^{2}\big{(}A_{k}(t)\big{)}\bigg{]}=1,$
(3)

where $A(t)$ is the amplitude of time series data.

Normalising the Q-transform enables us to make an assumption about the
distribution of Q-tile powers for Gaussian data. As shown in Eq. (3), our
Q-tiles have two degrees of freedom: real and imaginary parts of the time-
frequency data. As a consequence, we expect that Gaussian data should follow a
$\chi^{2}$(2) distribution [16] which is simply an exponential distribution
with a rate $\lambda=1/2$ (Figure 1).

This lets us define a simple statistical test to estimate the Gaussianity of
the data: for the number of tiles $N$, the total Q-tiles power for Gaussian
data is N and the standard deviation is $\sqrt{4N}$ (assuming $N\gg 1$).

Figure 1: Q-tile power for $Q=8$ and $f_{0}=40$ Hz for 366 s simulated
Gaussian data (blue) and 366 s data with excess noise (orange). The
distribution of powers for Gaussian data closely follows the expected
exponential distribution with a rate $\lambda=1/2$. Noisy data, however,
contains excess noise and therefore does not follow the exponential
distribution associated with the Gaussian data.

###  II.2 Distribution fitting with Bayesian statistical modelling

For a more informative test of non-Gaussianity, we model the non-Gaussian part
of the data. GW data with excess power has two contributions: Gaussian data
modelled by $\chi^{2}(2)$ and a non-Gaussian part represented by an unknown
distribution. Data with excess power has much higher energies and a longer
tail in contrast with the Gaussian-only data (Figure 1).

To estimate the amount of non-Gaussianity, we need to fit a mixture of two
distributions. We achieve this by using a marginalized mixture model
likelihood [17].

The likelihood of a data point $z_{k}$ belonging to either Gaussian data or
non-Gaussian data distribution can be written as

$p(z_{k}|q_{k},\alpha)=\Pi_{k=1}^{K}\big{[}q_{k}p_{1}(z_{k}|\alpha_{1})\\\
+(1-q_{k})p_{2}(z_{k}|\alpha_{2})\big{]},$ (4)

where $k$ is the tile number, $q_{k}$ is a binary flag and
$p_{1}(z_{k}|\alpha_{1})$, $p_{2}(z_{k}|\alpha_{2})$ represents the
probability that a point corresponds to the Gaussian noise distribution or a
non-Gaussian distribution, respectively.

Prior on $q_{k}$ is defined as

$p({q_{k}})=\begin{cases}F&\text{if $q_{k}$ = 0}\\\ 1-F&\text{if $q_{k}$ =
1}\end{cases}$ (5)

where fraction $F\in[0,1]$.

Eq. (5) allows us to marginalize the likelihood from Eq.(4) giving

$p(z_{k},\alpha)=\Pi_{k=1}^{K}\big{[}(1-F)\,p_{1}(z_{k}|\alpha_{1},q_{k}=1)\\\
+F\,p_{2}(z_{k}|\alpha_{2},q_{k}=0)\big{]}.$ (6)

To estimate the marginalized likelihood, we use a Bayesian statistical
modelling package PyMC with Hamiltonian Monte Carlo “No-U-Turn” sampler (NUTS)
[18, 19]. Rather than relying on classical Markov Chain Monte Carlo that does
not consider the geometry of parameter space, PyMC with NUTS allows us to
recover distribution parameters faster and with fewer samples. It achieves
this by specifying a probabilistic model in PyMC, compiling it into a
computational graph, providing initial values for parameters, configuring the
NUTS sampler, and then running the sampling process. NUTS explores the
posterior distribution by proposing and accepting/rejecting parameter values,
allowing for efficient and scalable Bayesian inference.

After recovering parameters for each distribution, we estimate the total power
in each distribution, i.e. the area under the curve. The ratio of non-Gaussian
power to the total power (which we refer to as fractional power) lets us
statistically measure non-Gaussianity in GW detector data.

##  III Demonstration on real data

###  III.1 Radio frequency noise around GW200129

GW200129 coincided with the $45$ MHz radio frequency noise caused by the
electro-optic modulator driver system at LIGO Livingston. Luckily, this noise
was also recorded by multiple witness channels, thus enabling to clean the
data around GW200129 using the linear subtraction tool gwsubtract [10, 20,
21].

To estimate the effectiveness of linear subtraction, we compared the data from
the original (i.e. not cleaned) LIGO Livingston data frame and the frame that
has the excess noise removed using gwsubtract.

First, we identified when RF noise was present in the data around GW200129
using Z-score. Out of $4096$ s, we selected in total $366$ s considered to
contain radio frequency noise. After that, the data subset was Q-tiled for
various $Q$ and $f_{0}$ values.

For the first test of non-Gaussianity, we simply estimate what is the average
tile power for both the original and the gwsubstract data. To do that, we
Q-tile the data for various Q and $f_{0}$ values which give us the total
number of tiles and the power in each tile. Since we use the normalised
Q-tiles, the average tile power for Gaussian data is 1. Figure 2(a) shows the
corresponding average tile power for quality factor $Q=8$. We chose the
Q-value of 8 in this and the following figures because low Q-value tiles fit
the short duration glitches such as RF noise better.

As a more advanced test, we want to measure the amount of non-Gaussianity. In
order to do that, we model the data with an exponential distribution with a
rate $\lambda=1/2$ and a half Student’s T distribution [22] with probability
density function given by:

$f(x|\sigma,\nu)=\frac{2\Gamma(\frac{\nu+1}{2})}{\Gamma(\frac{\nu}{2})\sqrt{\nu\pi\sigma^{2}}}\bigg{(}1+\frac{1}{\nu}\frac{x^{2}}{\sigma^{2}}\bigg{)}^{-\frac{\nu+1}{2}}$
(7)

where $\nu$ is degrees of freedom, $\sigma$ is normality parameter and
$\Gamma$ is the gamma function. We chose half Student’s T distribution because
it has a long tail which closely matches the non-Gaussian data (see, for
example, Fig. 1).

After recovering distribution parameters, we estimate the fractional power
which is the ratio of non-Gaussian power to the total power. Figure 2(b) shows
the fractional power for GW200129.

(a) Average tile power for data around GW200129 with quality factor $Q=8$.

(b) Fractional power for data around GW200129 with quality factor $Q=8$.

Figure 2: Average tile power (above) and fractional power (below) for data
around GW200129 with quality factor $Q=8$. Linear subtraction gwsubtract
removes a significant portion of the non-Gaussian noise below 50 Hz, yet some
of the noise still remains after the cleaning. At frequencies above $\sim 85$
Hz, there is no excess noise removed.

###  III.2 Light scattering noise

We also apply both tests to measure the excess noise in the time-series data
that is continuous. For this example, we selected 10 minutes of data with a
relatively low amount of light scattering noise and 10 minutes of scattering-
heavy data recorded by LIGO Livingston on January 6th, 2020. Light scattering
glitches are caused by stray light reflection in the beamtube, which can
happen due to excessive ground motion [23, 24, 25]. As a result, such noise
transients can last up to minutes with a typical frequency range of
$20\text{--}50$ Hz.

We use the same procedure as in the previous example of GW200129. Firstly, we
calculate the Q-tile power for specific $Q$ and $f_{0}$ values giving us the
average tile power. Then, we fit the Q-tile power with $\chi^{2}(2)$ and half
Student’s T distributions to estimate the fractional power which is the ratio
of non-Gaussian power to the total power. Figure 3 shows the average tile
power and the fractional power for both low noise and scattering-heavy time
series using quality factor $Q=8$.

(a) Average tile power for data with quality factor $Q=8$ in the presence and
absence of light scattering artefacts.

(b) Fractional power for data with quality factor $Q=8$ in the presence and
absence of light scattering artefacts.

Figure 3: Average tile power (above) and fractional power (below) for data
with quality factor $Q=8$. Time series data in blue has excess power at the
15–50 Hz range caused by the light scattering artefacts, whereas the time
series data in orange with no light scattering artefacts have a relatively
small amount of non-Gaussian noise across all frequencies.

##  IV Discussion

In this paper, we present a method to estimate the amount of non-Gaussian
noise in the data based on the normalised Q-transform. This method has
multiple advantages over other statistical tests. While comparing power
spectral density (PSD) between the cleaned and original data provides a
quantitative measurement of the removed power, it does not discriminate
whether the removed power is non-Gaussian, i.e. the excess noise, or Gaussian
[7]. Furthermore, the PSD estimation is usually performed over a long
duration, e.g. 512 s, meaning that such a test becomes less sensitive to
removing short-duration noise bursts like in the data around GW200129.

Contrary to the PSD comparison, our test discriminates between the Gaussian
and non-Gaussian noise; we also analyze only the times when the RF noise is
present which makes our test much more sensitive than the PSD comparison.

Another commonly used method to estimate how well the data is cleaned relies
on the visual inspection of spectrograms [7]. However, this becomes
problematic when the excess noise is weak and is comparable to Gaussian noise.
This issue becomes even more precarious when the excess noise overlaps a GW
signal, as in the case of GW200129. Conversely, our method provides a
quantitative measurement of the excess noise.

By using normalised Q-tiles, we put a constraint that Gaussian data has an
average tile power of 1, whereas the data with excess noise is expected to
have more power on average. Furthermore, we found that the Gaussian data must
follow a $\chi^{2}(2)$ distribution after we normalise the Q-tiles. As a
result, the data containing Gaussian and non-Gaussian noise can be decomposed
into two distributions, one of which is $\chi^{2}(2)$.

To estimate the amount of non-Gaussian noise in GW data, we fit the normalised
Q-transform power using Bayesian statistical modelling with Hamiltonian Monte
Carlo. By doing this, we reconstruct the parameters of both Gaussian and non-
Gaussian distributions.

As the first application of this method, we investigate if (and how much)
gwsubtract cleaned the data around GW200129. As shown in Figure 2, RF noise is
mostly affecting the data in $30\text{--}50$ Hz range where the non-Gaussian
power is at least 55% of the total data power, i.e. the frequencies where
precession effects are especially important for GW200129 [13]. Linear
subtraction gwsubtract removes up to 30% of the fractional power in this
frequency range indicating that it does remove the RF noise, albeit not
entirely.

At higher frequencies, there is less RF noise in the data which could explain
why gwsubtract is less efficient at these frequencies compared to the
$30\text{--}50$ Hz range. Above $\sim 85$ Hz, gwsubtract does not remove any
noise which is reasonable given that the witness channel used to clean the
data does not have any information above this frequency.

Our simpler test showing the average tile power agrees well with the
fractional power results (Figure 2). Both frames, Original and gwsubtract,
have more power per tile than the Gaussian data. However, the original data
has considerably more power in the $30\text{--}50$ Hz range (up to 70% more).

We also tested if our method can be applied as a live monitoring tool of
excess noise in GW detector data. For that, we compared 10 minutes of
relatively quiet data with 10 minutes of data containing many scattering
glitches at LIGO Livingston on January 6th, 2020.

We found that the fractional power is much higher for data with many
scattering glitches than for the quiet data (Figure 3(b)). The excess noise is
concentrated within $10\text{--}50$ Hz and peaks at $20$ Hz, where the non-
Gaussian noise power is 0.96 of the total power. The frequency of light
scattering noise ($20\text{--}50$ Hz) is similar to the excess noise at
$15\text{--}50$ Hz, indicating that our test correctly identified the presence
of excess noise. For 10 minutes of relatively low noise, the fractional power
is much lower and stays relatively constant across all frequencies.

Similarly, our average tile power test indicates that the data with scattering
glitches contains up to $\sim 7$ times more power than the Gaussian data
(Figure 3(a), blue). Data with no scattering glitches (Figure 3(a), orange)
stays relatively constant across all frequencies and has an average tile power
close to Gaussian data, i.e. 1.

##  V Conclusions

Gravitational-wave data contains many noise transients which can affect GW
searches and estimation of source parameters such as the precession of a
binary black hole. It is possible to mitigate excess noise from GW data in
some cases, for example by correlating information from noise witness
channels. However, the lack of meaningful and sensitive statistical tests
prevents estimating the effectiveness of such noise mitigation tools.

In this paper, we propose a novel method to statistically measure the non-
Gaussian noise in GW detector data. By using normalised Q-transform, we
constrain how Gaussian data should be distributed, which allows us to
determine the amount of non-Gaussian noise in the data.

Our method provides two statistical tests to measure the non-Gaussianity. The
first one measures the average tile power which, for Gaussian data, must be
equal to 1. The second test estimates the relative power of non-Gaussian data
compared to the total power, which we define as fractional power. Both our
tests are sensitive to excess noise changes in frequency, which allows for a
more precise noise measurement than averaging across all frequencies.

In order to show the effectiveness of our statistical tests, we explore two
scenarios. First, we investigate how well gwsubtract, a linear subtraction
tool, removes the noise around the binary black hole event GW200129. We find
that gwsubtract removes a significant portion of the non-Gaussian noise at
lower frequencies (30–70 Hz), yet it fails to remove the non-Gaussian noise
completely. There is also no noise removed above $\sim 85$ Hz.

In the second scenario, we test if our method can be applied as a live
monitoring tool of excess noise in GW detector data. We show that for data
that has many light scattering noise artefacts, our method correctly
identifies the excess noise within the light scattering noise frequency range
(20–50 Hz).

###### Acknowledgements.

We thank Marissa Walker and members of the LIGO Detector Characterization
group for their valuable input during the preparation of this manuscript. We
also thank the anonymous referee for valuable comments which improved the
manuscript during the review. RM is supported by STFC grants ST/S000550/1,
ST/T000325/1, ST/V005715/1 and ST/X002225/1. The authors are grateful for
computational resources provided by the LIGO Laboratory and supported by
National Science Foundation Grants PHY-0757058 and PHY-0823459. This research
has made use of data, software and/or web tools obtained from the
Gravitational Wave Open Science Center (https://www.gw-openscience.org), a
service of LIGO Laboratory, the LIGO Scientific Collaboration, the Virgo
Collaboration, and KAGRA. This material is based upon work supported by NSF’s
LIGO Laboratory which is a major facility fully funded by the National Science
Foundation. LIGO Laboratory and Advanced LIGO are funded by the United States
National Science Foundation (NSF) as well as the Science and Technology
Facilities Council (STFC) of the United Kingdom, the Max-Planck-Society (MPS),
and the State of Niedersachsen/Germany for support of the construction of
Advanced LIGO and construction and operation of the GEO600 detector.
Additional support for Advanced LIGO was provided by the Australian Research
Council. Virgo is funded, through the European Gravitational Observatory
(EGO), by the French Centre National de Recherche Scientifique (CNRS), the
Italian Istituto Nazionale di Fisica Nucleare (INFN) and the Dutch Nikhef,
with contributions by institutions from Belgium, Germany, Greece, Hungary,
Ireland, Japan, Monaco, Poland, Portugal, Spain. KAGRA is supported by
Ministry of Education, Culture, Sports, Science and Technology (MEXT), Japan
Society for the Promotion of Science (JSPS) in Japan; National Research
Foundation (NRF) and Ministry of Science and ICT (MSIT) in Korea; Academia
Sinica (AS) and National Science and Technology Council (NSTC) in Taiwan.
Various parts of the analysis used GWpy [26], PyCBC [27, 28] PyMC [18], NumPy
[29], SciPy [30], IPython [31], Jupyter notebook [32], pandas [33], Matplotlib
[34], arviz [35] and corner [36]. This document has been assigned LIGO
Laboratory document number P2300172. For the purpose of open access, the
author has applied a Creative Commons Attribution (CC BY) licence to any
Author Accepted Manuscript version arising.

## References

  * Canton  _et al._ [2013] T. D. Canton, S. Bhagwat, S. V. Dhurandhar, and A. Lundgren, Effect of sine-gaussian glitches on searches for binary coalescence, Classical and Quantum Gravity 31, 015016 (2013).
  * B. P. Abbott et al. [2018] B. P. Abbott et al. (LIGO Scientific Collaboration and Virgo Collaboration), Effects of data quality vetoes on a search for compact binary coalescences in Advanced LIGO’s first observing run, Classical and Quantum Gravity 35, 065010 (2018).
  * B. P. Abbott et al. [2020] B. P. Abbott et al. (LIGO Scientific Collaboration and Virgo Collaboration), A guide to LIGO–Virgo detector noise and extraction of transient gravitational-wave signals, Classical and Quantum Gravity 37, 055002 (2020).
  * Pankow  _et al._ [2018] C. Pankow, K. Chatziioannou, E. A. Chase, T. B. Littenberg, M. Evans, J. McIver, N. J. Cornish, C.-J. Haster, J. Kanner, V. Raymond, and et al., Mitigation of the instrumental noise transient in gravitational-wave data surrounding GW170817, Physical Review D 98, 10.1103/physrevd.98.084016 (2018).
  * Macas  _et al._ [2022] R. Macas, J. Pooley, L. K. Nuttall, D. Davis, M. J. Dyer, Y. Lecoeuche, J. D. Lyman, J. McIver, and K. Rink, Impact of noise transients on low latency gravitational-wave event localization, Physical Review D 105, 10.1103/physrevd.105.103021 (2022).
  * R. Abbott et al. [2019] R. Abbott et al. (LIGO Scientific Collaboration and Virgo Collaboration), GWTC-1: A gravitational-wave transient catalog of compact binary mergers observed by LIGO and virgo during the first and second observing runs, Physical Review X 9, 10.1103/physrevx.9.031040 (2019).
  * Derek Davis et al. [2021] Derek Davis et al., LIGO detector characterization in the second and third observing runs, Classical and Quantum Gravity 10.1088/1361-6382/abfd85 (2021).
  * Nguyen et al. [2021] Nguyen et al., Environmental noise in advanced ligo detectors, Classical and Quantum Gravity 38, 145001 (2021).
  * Davis  _et al._ [2019] D. Davis, T. Massinger, A. Lundgren, J. C. Driggers, A. L. Urban, and L. Nuttall, Improving the sensitivity of advanced LIGO using noise subtraction, Classical and Quantum Gravity 36, 055011 (2019).
  * R. Abbott et al. [2021] R. Abbott et al. (The LIGO Scientific Collaboration and the Virgo Collaboration and the KAGRA Collaboration), GWTC-3: Compact Binary Coalescences Observed by LIGO and Virgo During the Second Part of the Third Observing Run (2021), arXiv:2111.03606 [gr-qc] .
  * Davis  _et al._ [2022] D. Davis, T. B. Littenberg, I. M. Romero-Shaw, M. Millhouse, J. McIver, F. D. Renzo, and G. Ashton, Subtracting glitches from gravitational-wave detector data during the third LIGO-virgo observing run, Classical and Quantum Gravity 39, 245013 (2022).
  * Hannam  _et al._ [2022] M. Hannam, C. Hoy, J. E. Thompson, S. Fairhurst, V. Raymond, M. Colleoni, D. Davis, H. Estellés, C.-J. Haster, A. Helmling-Cornell, S. Husa, D. Keitel, T. J. Massinger, A. Menéndez-Vázquez, K. Mogushi, S. Ossokine, E. Payne, G. Pratten, I. Romero-Shaw, J. Sadiq, P. Schmidt, R. Tenorio, R. Udall, J. Veitch, D. Williams, A. B. Yelikar, and A. Zimmerman, General-relativistic precession in a black-hole binary, Nature 610, 652 (2022).
  * Payne  _et al._ [2022] E. Payne, S. Hourihane, J. Golomb, R. Udall, D. Davis, and K. Chatziioannou, Curious case of GW200129: Interplay between spin-precession inference and data-quality issues, Physical Review D 106, 10.1103/physrevd.106.104017 (2022).
  * Chatterji [2006] S. Chatterji, The search for gravitational wave bursts in data from the second ligo science run, , 109 (2006).
  * Vazsonyi and Davis [2023] L. Vazsonyi and D. Davis, Identifying glitches near gravitational-wave signals from compact binary coalescences using the q-transform, Classical and Quantum Gravity 40, 035008 (2023).
  * Cochran [1952] W. G. Cochran, The $\chi^{2}$ Test of Goodness of Fit, The Annals of Mathematical Statistics 23, 315 (1952).
  * Foreman-Mackey [2014] D. Foreman-Mackey, Blog post: Mixture models 10.5281/ZENODO.15856 (2014).
  * Salvatier  _et al._ [2016] J. Salvatier, T. V. Wiecki, and C. Fonnesbeck, Probabilistic programming in python using PyMC3, PeerJ Computer Science 2, e55 (2016).
  * Hoffman and Gelman [2011] M. D. Hoffman and A. Gelman, The no-u-turn sampler: Adaptively setting path lengths in hamiltonian monte carlo, (2011), arXiv:1111.4246 [stat.CO] .
  * Davis et al. [2021] Davis et al., Data quality vetoes applied to the analysis of ligo data from the third observing run (2021).
  * Lundgren [2019] A. Lundgren, aLIGO LLO Logbook, 47707 (2019).
  * Sutradhar [1986] B. C. Sutradhar, On the characteristic function of multivariate student t-distribution, The Canadian Journal of Statistics / La Revue Canadienne de Statistique 14, 329 (1986).
  * Soni et al. [2020] Soni et al., Reducing scattered light in LIGO’s third observing run, Classical and Quantum Gravity 38, 025016 (2020).
  * Accadia et al. [2010] Accadia et al., Noise from scattered light in Virgo's second science run data, Classical and Quantum Gravity 27, 194011 (2010).
  * Arthur E Tolley and Gareth S Cabourn Davies and Ian W Harry and Andrew P Lundgren [2023] Arthur E Tolley and Gareth S Cabourn Davies and Ian W Harry and Andrew P Lundgren, ArchEnemy: removing scattered-light glitches from gravitational wave data, Classical and Quantum Gravity 40, 165005 (2023).
  * Macleod  _et al._ [2020] D. Macleod _et al._ , gwpy/gwpy: 2.0.1 (2020).
  * Davies  _et al._ [2020] G. S. Davies, T. Dent, M. Tápai, I. Harry, C. McIsaac, and A. H. Nitz, Extending the pycbc search for gravitational waves from compact binary mergers to a global network, Phys. Rev. D 102, 022004 (2020).
  * Canton  _et al._ [2021] T. D. Canton, A. H. Nitz, B. Gadre, G. S. Davies, V. Villa-Ortega, T. Dent, I. Harry, and L. Xiao, Realtime search for compact binary mergers in advanced ligo and virgo’s third observing run using pycbc live (2021), arXiv:2008.07494 [astro-ph.HE] .
  * Harris  _et al._ [2020] C. R. Harris, K. J. Millman, S. J. van der Walt, R. Gommers, P. Virtanen, D. Cournapeau, E. Wieser, J. Taylor, S. Berg, N. J. Smith, and et al., Array programming with numpy, Nature 585, 357–362 (2020).
  * Virtanen  _et al._ [2020] P. Virtanen, R. Gommers, T. E. Oliphant, M. Haberland, T. Reddy, D. Cournapeau, E. Burovski, P. Peterson, W. Weckesser, J. Bright, and et al., Scipy 1.0: fundamental algorithms for scientific computing in python, Nature Methods 17, 261–272 (2020).
  * Perez and Granger [2007] F. Perez and B. E. Granger, Ipython: A system for interactive scientific computing, Comput. Sci. Eng. 9, 21 (2007).
  * Kluyver  _et al._ [2016] T. Kluyver, B. Ragan-Kelley, F. Pérez, B. Granger, M. Bussonnier, J. Frederic, K. Kelley, J. Hamrick, J. Grout, S. Corlay, P. Ivanov, D. Avila, S. Abdalla, and C. Willing, Jupyter notebooks – a publishing format for reproducible computational workflows, in  _Positioning and Power in Academic Publishing: Players, Agents and Agendas_ , edited by F. Loizides and B. Schmidt (IOS Press, 2016) pp. 87 – 90.
  * McKinney  _et al._ [2010] W. McKinney _et al._ , Data structures for statistical computing in python, in  _Proceedings of the 9th Python in Science Conference_ , Vol. 445 (Austin, TX, 2010) pp. 51–56.
  * Hunter [2007] J. D. Hunter, Matplotlib: A 2d graphics environment, Comput. Sci. Eng. 9, 90 (2007).
  * Kumar  _et al._ [2019] R. Kumar, C. Carroll, A. Hartikainen, and O. Martin, Arviz a unified library for exploratory analysis of bayesian models in python, Journal of Open Source Software 4, 1143 (2019).
  * Foreman-Mackey [2016] D. Foreman-Mackey, corner.py: Scatterplot matrices in python, The Journal of Open Source Software 1, 24 (2016).