Experiences and Lessons Learned From Making IoT Sensing Platforms for Large-Scale Deployments

This paper shares experiences and lessons learned from designing and developing the bespoke Internet of Things (IoT) sensing platforms of a sensor platform for healthcare in a residential environment (SPHERE). These IoT platforms, which include a wrist-worn wearable sensor, a room-level environmental sensor, and a dual-radio gateway, constitute integral parts of the SPHERE system that is currently getting deployed in up to 100 houses of volunteers for up to 12 months. This paper is focused on sharing several years’ worth of insight and experiences from making IoT sensing platforms for large-scale academic deployments, providing information that can accelerate the development and deployment of prototypes and enable timely research in the space of IoT.


SPHERE (a Sensor Platform for Healthcare in a Residential
Environment) is a multipurpose, multi-modal platform of non-medical home sensors that envisions to be an enabling technology for healthcare provision in a residential environment [1].Amongst other modalities, the SPHERE system incorporates low-power environmental and wearable sensors, as well as a backbone data collection infrastructure that is based on IoT (Internet of Things) wireless technology.This functionality is materialised using bespoke IoT platforms, shown in Fig 1, namely the SPHERE Wearable Sensor [2], the SPHERE Environmental Sensor [3] and the SPHERE Gateway.Hundreds of SPHERE Wearable Sensors, SPHERE Environmental Sensors and SPHERE Gateways are currently being deployed in the homes of up to 100 participants in the Bristol area for up to 12 months, as part of SPHERE's 100 homes study [1].Furthermore, SPHERE Wearable Sensors are given to patients recovering from heart surgery enabling clinical research on heart disease [4].Following the completion of these studies, the SPHERE sensing platforms are planned to be used in additional clinical research studies, focusing on patients recovering from hip or knee replacement surgery, and on identifying early signs of dementia.
Since 2013 and until they reached a readiness level that is sufficiently high for deployment in the wild, the SPHERE sensing platforms have gone through a number of designing stages and revisions.This article documents the experiences and lessons learned from making the IoT sensing platforms of SPHERE.Indeed, the goal of this article is knowledge exchange, as it aims to share SPHERE's several years' worth of insight to researchers who plan to design and develop similar sensing platforms for large-scale deployments.It is the authors' hope that this article is a source of valuable information that can accelerate the development of prototypes and, thus, facilitate timely research in the space of IoT.
It is highlighted that the focus of this paper is on developing IoT sensing platforms in an academic context.Indeed, there are significant differences in terms of requirements, resources and constraints, compared to developing sensing platforms in an industrial context.For instance, academic research is typically non-for-profit, the developed IoT sensing platforms are typically not commercialised and they are manufactured in relatively low quantities 1 .Moreover, requirements for certifications (e.g.CE marking), and protection of the intellectual property are typically more relaxed in an academic environment.In addition, academic projects do not typically have the resources for dedicated full-time engineers that specialise in different aspects of the platform (e.g.electronics designers, enclosure designers, embedded software engineers, testers, etc.); on the contrary, these tasks are conducted by researchers amongst several other academic duties.Academic research projects are typically limited by such constraints.
This article is structured as follows.Section II briefly summarises works of similar nature.Section III provides the requirements of the SPHERE deployments, as well as the particular requirements of the IoT sensing platforms.Section IV presents the bespoke IoT sensing platforms of SPHERE (namely, the SPHERE Wearable Sensor, the SPHERE Environmental Sensor, and the SPHERE Gateway), as well as experiences from deploying them and using them in the wild.This is followed by Section V that provides tips and discusses lessons learned.Section VI concludes the paper.

II. RELATED WORK
Since the early days of wireless sensor networks, the academic community has shown particular interest in deploying sensing platforms in the wild.Lessons learned from these practical experiences have been documented and shared with the academic community in a series of influential papers.
Beaudin et al. [5] published one of the first papers of this kind, sharing their experiences and lessons learned from deploying a prototype sensing kit in real homes.The paper is specifically focused on the relationship of the researchers with the participants and the challenges of deploying sensors in someone's private space.
Langendoen et al. [6] published their highly-influential paper "Murphy Loves Potatoes" in 2006.This paper is presenting the experiences of the authors from a pilot sensor network deployment in a potato field in the Netherlands.The authors present a history of failed deployment attempts, highlighting what went wrong and the lessons learned.
Two years later, Barrenetxea et al. [7] published "The Hitchhiker's Guide to Successful Wireless Sensor Network Deployments".The authors share experiences from six outdoor sensor deployments in Switzerland and present lessons learned in the form of an elaborate deployment guide.The guide covers several steps of the process, including software and hardware development, testing and preparation, sensor deployment, and monitoring.The authors conclude with a summary of their most important advice.
Inspired by [7], Hnat et al. [8] published "The Hitchhiker's Guide to Successful Residential Sensing Deployments", focusing on indoor sensor deployments instead.Indeed, the authors share experiences from deploying more than 1200 sensors in over 20 real homes and present advice and lessons learned as a series of myths and facts, i.e. common misconceptions and wishful thinking contrasted by hands-on experience and evident facts.The paper deals with resource availability within a house, user participation, and other technical issues.
In recent years, the literature is becoming more specialised.Elsts et al. [9] share their experiences with designing a bespoke sensing platform for precision agriculture.Their work highlights the advantages of designing bespoke sensing platforms as opposed to using commercial off-the-shelf sensing platforms.Aloulou et al. [10] share their experiences and lessons learned from deploying assistive technology in a nursing home in Singapore.Their work focuses on the particular challenges of working with dementia patients and their carers.Cheng et al. [11] share their experiences and lessons learned from building a big data platform and integrating it with Santander's smart city testbed [12].Dehwah et al. [13] share their lessons learned from deploying a solar-powered wireless sensor network in a desert environment.
In SPHERE [1], we are conducting a large-scale deploy-ment of sensing platforms in the homes of volunteers in the Bristol area.In our previous work [14], we have shared our experiences and lessons learned from this effort, focusing on software development and low-power IoT networking.This paper compliments our previous work, presenting our experiences and lessons learned from designing and making SPHERE's bespoke IoT sensing platforms.

III. REQUIREMENTS
SPHERE is a project on healthcare technologies, which combines interdisciplinary expertise in various fields of computer science and electrical engineering, as well as expertise in medical and social sciences.Its key objective is to conduct a large-scale deployment of state-of-the-art sensors in up to 100 houses in the city of Bristol, UK, for a period of up to 12 months (also known as the 100 homes study2 ).The purpose of this deployment is twofold.Primarily, the collection of long-term data from healthy individuals is planned to be used for developing and training multi-modal machine learning algorithms for behavioural analytics in a home environment.
The secondary purpose of the SPHERE deployment is to demonstrate that the SPHERE IoT infrastructure can scale up to large numbers of residential environments in a timely and cost-effective manner, demonstrating that the SPHERE system can effectively support clinical studies composed of potentially hundreds of individuals.For a successful long-term large-scale deployment in the wild, the SPHERE technology requires to be at a relatively high Technology Readiness Level (TRL), i.e.TRL 5-6: technology validated and demonstrated in relevant environment [15].More specifically, the SPHERE system has the following requirements.First and foremost, the SPHERE system needs to be easy to deploy and maintain by a small group of technicians that are not experts in the deployed technology.To this end, the deployed embedded devices and networks need to be robust and operate reliably for long periods of times, so that the number of visits to the participants' houses are kept to the absolute minimum.Secondly, the deployed technology needs to comfortable and acceptable to the participants.This is important not only for recruitment, but also for ensuring long-term compliance.Thirdly, the overall cost of each deployment (i.e.cost of equipment, cost of visits, cost of remote monitoring, etc.) needs to adhere to a tight budget.Last but not least, the study has gone through ethics approval and the platform needs to meet certain ethical requirements; for example, all sensor data must be encrypted when transmitted over the air or stored in hard drives.
As integral parts of the deployed system, the bespoke IoT sensing platforms of SPHERE need to meet the aforementioned requirements.In addition to that, SPHERE researchers use these platforms as research tools for laboratory experiments.To this end, SPHERE's IoT sensing platforms also need to be flexible and versatile to support a wide range of experiments and interdisciplinary research.

IV. THE DEVICES
The first bespoke SPHERE sensing platform was the SPHERE wearable sensor.It's first version, named SPW-1, is shown in Fig. 2 (left).SPW-1 is a wrist-worn accelerometerbased activity tracker [16] that is based on Bluetooth Low Energy (BLE) for wireless communication [17], based on the nRF51822 System-on-Chip which incorporates a Cortex M0 processor, 32KB of RAM, 256KB of non-volatile flash memory.SPW-1 is powered from a coin-cell battery and employs two ADXL362 acceleration sensors.The ADXL362 is a micro-power triaxial digital accelerometer that has 12bit resolution, a maximum sampling frequency of 400 Hz, and supports measurement ranges of ±2g, ±4g, ±8g [18].The physical dimensions of the board are 24 × 39 × 3.8 mm.The incorporation of two accelerometers, at a distance of 30 mm, provides an energy-efficient alternative to a gyroscope.Indeed, the angular acceleration can be derived from differential measurements from multiple accelerometers [19] [20].SPW-1 has been extensively used in SPHERE's pilot studies, in which participants lived in a prototype SPHERE house for a time period of up to two weeks.Data collected from these studies was used in a machine learning competition on activity recognition with multi-modal sensor data [21].
In parallel, the SPHERE wearable sensor was also provided to members of the ALSPAC cohort study.ALSPAC (Avon Longitudinal Study of Parents and Children), also known as the Children of the 90s, is a cohort study of children born in the county of Avon in England.During the first stage of the study, in the early 90s, thousands of pregnant women and their children were recruited and monitored.In present day, the study continues, monitoring the next generation, namely the Children of the Children of the 90s [22].Unlike SPHERE that is targeting residential environments, ALSPAC requires outdoor data collection as well.Indeed, SPW-1 was designed to operate within a smart home context.Hence, it has no sufficient non-volatile memory that would allow raw data collection when the user is far from their house.As a result, a bespoke variant of the SPHERE wearable sensor was designed for ALSPAC, named SPW-90s.SPW-90s, shown in Fig. 2 (middle), incorporates an SD card for long-term raw data collection.
Up until then, the wearable and environmental sensing modalities of SPHERE were two completely independent subsystems [23].However, the unsatisfactory performance of the commercial off-the-shelf platform that was used for en-vironmental sensing led to the development of the SPHERE Environmental Sensor and the integration of the wearable and environmental sensing modalities into one subsystem.This was materialised using the CC2650 System-on-Chip that was (at the time) the only chip that supported both BLE and IEEE 802.15.4 [24], two of the most commonly used low power wireless standards.
The second version of the SPHERE wearable sensor, named SPW-2, is shown in Fig. 1 (top) and Fig. 2 (right).SPW-2 is based on the CC2650 System-on-Chip which incorporates a Cortex M3 processor, 30KB of RAM and 128KB of non-volatile flash memory.The CC2650 offers more energy-efficient wireless connectivity, making SPW-2 more energy-efficient than SPW-1 [2].In addition, SPW-2 offers acceleration data of higher quality due to better voltage regulation and has similar wireless performance to SPW-1 despite its much smaller form factor [2]. SPW-2 also offers additional functionality which include: (i) an external flash memory of 8 MB; (ii) wireless inductive charging based on the Qi standard [25]; and (iii) an optional gyroscope.The physical dimensions of the board are 20 × 41 × 3 mm.SPW-2 is the wearable sensor that is currently being deployed in the homes of the participants of SPHERE's 100 homes study [1].SPW-2 is also given to patients recovering from heart surgery, as part of the deployment of EurValve, a research project that focuses on heart disease [4].It is worth mentioning that the requirements of the EurValve and SPHERE deployments are slightly different.EurValve has more relaxed requirements for long battery lifetime, instead it requires more non-volatile storage for outdoor data collection.As a result, the wearable sensors that are used for the EurValve deployment employ a different flash memory chip (256 MB).
The SPHERE Environmental Sensor (SPES-2) [3], shown in Fig. 1 (middle), is also based on the CC2650 System-on-Chip.SPES-2 incorporates a series of sensors for monitoring the residential environment, including a temperature and humidity sensor (HDC1000); a light sensor (OPT3001); a barometer (BMP280); and a passive infrared (PIR) motion sensor (EKMB1101).Moreover, SPES-2 exposes an interface for connecting external sensors.SPES-2 operates on a 3.6V AA battery and has 8 MB of non-volatile storage.The physical dimensions of the board are 75 × 75 × 1.6 mm, enclosed in an off-the-shelf casing (dimensions 85 × 85 × 25 mm).
The data generated from the wearable and environmental sensors are collected through a backbone 6LoWPAN home network of USB-powered nodes, named SPHERE Gateways (SPG-2).The SPG-2, shown in Fig. 1 (bottom), is equipped with two CC2650 Systems-on-Chip: one of them operating in BLE mode (collecting the data from the wearable sensors) and one operating in IEEE 802.15.4 mode.Effectively, each SPG-2 operates as a gateway from the BLE to the 6LoW-PAN network.It is worth mentioning that the environmental sensors are directly connected to the 6LoWPAN network; yet, they do not relay any traffic on behalf of other nodes to save energy.The reception of the wearable data from multiple SPHERE Gateways, combined with PIR data, is leveraged for room-level localisation of the house residents.Each SPG-2 is equipped with a temperature and humidity sensor (HDC1000) and a barometer (BMP280); thus, they also constitute additional data points for environmental sensing.The root SPG-2 is responsible for delivering all the data to a central server within the SPHERE house.
To summarise, each SPHERE deployment incorporates 6 to 10 SPHERE Environmental Sensors (SPES-2) and 4 to 6 SPHERE Gateways (SPG-2) depending on the size of the property, as well as 1 to 5 SPHERE Wearable Sensors (SPW-2) depending on the number of residents.In other words, the SPHERE 100 homes study is a deployment of more than a thousand of custom IoT sensing platforms in the wild.

V. LESSONS LEARNED
Designing and fabricating IoT sensing platforms for largescale deployments in the wild is a process full of pitfalls.Some of these pitfalls may appear apparent; yet, without proper attention, they can be overlooked.SPHERE is no exception.During the experiences summarised in the previous section, we have succumbed to some pitfalls and near-missed others.This section summarises lessons that we have learned while making the IoT sensing platforms of SPHERE.

A. IT TAKES TIME
From conception to deployment, an IoT platform goes through various stages and this process may require a considerable amount of time.Realistic estimations of the time required for making an IoT platform is particularly important for research projects that operate under strict deadlines.
The first stage is design and includes the design of the schematic and the PCB layout.There are several things that can be done to accelerate the process, some of which will be discussed further in this section, yet the time required for the design of the IoT platform fundamentally depends on the incremental functionality added on previously made platforms.Prototyping particularly risky parts of the platform may slow down the design stage; yet, it may save time in the long term, by mitigating potential design faults and, thus, the number of required revisions.It is, therefore, highly recommended for high-risk parts of the platform, such as custom antennas that, almost certainly, require some fine-Fabrication and assembly is the second stage.In the case of SPHERE, this stage is outsourced and it usually requires 6 to 8 weeks including delivery (see Table 1).It should be noted that the process has an additional overhead of 1 to 2 weeks for quoting and preparing the purchasing order.In large orders in particular, factory lead times require particular attention.Indeed, the above lead times refer to the case that all the required components are available for purchase.There was indeed a particular order of environmental sensors (SPES-2) which was delayed by 7 additional weeks due to shortage of the PIR sensors.The third stage is testing for the identification and correction of potential design faults.Design faults can be patched manually until they are eventually addressed with a revision of the PCB.The potential need for PCB revisions should be accounted both financially and in terms of time planning.It is noted that the SPHERE boards required 1 to 2 revisions to be deployable without the need of manual patches, as detailed in Table 1.
For critical deployments that cannot tolerate delays (e.g.participants that have undergone surgery), it is recommended to consider at least 1 year for the development of the IoT sensing platform, to account for at least two revisions, sufficient time for testing and debugging, and unexpected factory lead times.

B. SIMPLICITY IS YOUR FRIEND
The KISS design principle is very relevant.It is, indeed, important to keep the platform design simple and avoid unnecessary complexity.Battery-powered IoT platforms, such as wearable sensors, are severely resource-constrained devices.Energy-efficiency and space-efficiency are particularly important design objectives.In addition, the cost of production is always a consideration.
Simplicity is, effectively, beneficial for all these performance metrics.A simpler design is a design with fewer components and, therefore, has a smaller form factor.A simpler design is also a more energy-efficient design, as each additional component contributes to the total idle power consumption of the board.Moreover, a simpler design is a cheaper design; not only because of the bill of materials, but also because it requires fewer person-months in prototyping and development.Furthermore, a simple design without unnecessary complexity has fewer parts that can go wrong.It, therefore, requires on average fewer revisions and practically enables timely research, as it shortens the time from conception to a prototype ready for experiments.
In addition to avoiding unnecessary functionality, an effective way of simplifying the design is transferring part of the necessary functionality from the IoT platform to the infrastructure.For example, consider the SD card of the SPW-90s variant of the SPHERE Wearable Sensor.In retrospect, it is clear that it would have been significantly more timeefficient and cost-efficient if the necessary functionality (i.e.raw data collection outdoors) was implemented by streaming the data to a smart phone instead of saving them locally in an SD card.Indeed, this approach would not require the design of a new variant of the wearable sensor, nor the implementation of new firmware for the wearable and drivers for the SD card.Another example is the requirement for timestamping the wearable data in SPHERE's 100 homes study.Instead of implementing this functionality on the severely energy-constrained wearable sensor, the wearable data are time-stamped at the mains-powered SPHERE Gateways (at the cost of decreasing the accuracy of the timestamps by the delay of one hop).
The benefits of simplicity are straightforward.Yet simplicity can also be challenging.This is because it implicitly assumes that what constitutes required functionality is known in advance -not necessarily the case for academic research that is exploratory by nature.It can be, indeed, very temping to add nice-to-have functionality to the design or attempt to make the design sufficiently versatile to be used in multiple deployments with different goals.

C. THERE IS AN EFFICIENCY-VERSATILITY TRADE-OFF
Due to the relatively high cost of designing and manufacturing a new IoT sensing platform, it is natural to expect that it is cost-efficient to use this platform in as many research projects as possible.To that end, an IoT sensing platform needs to be versatile.Versatility, however, comes with a cost.Indeed, versatility not only compromises the efficiency of the design, but it can also increase the overall cost it certain cases.The SPHERE Wearable Sensor demonstrates this efficiencyversatility trade-off well.
Despite the fact that the primary goal of SPHERE is the deployment of the SPHERE system in the houses of volunteers, not all outputs of SPHERE research reached the deployment stage.The SPHERE Wearable Sensor is not an exception.The SPHERE Wearable Sensor is primarily designed to satisfy the requirements of the SPHERE deployments in the wild (TRL5-6); yet, it is also designed to be a sufficiently versatile research tool that can support a series of experiments in the laboratory (TRL4).Indeed, the SPHERE Wearable Sensor has been used to validate a heart rate sensor [26], an inductive energy harvester [27], a privacy preservation algorithm [28], and gyro-free motion analysis with two accelerometers [20].The high-TRL experiments, i.e. the SPHERE deployments, require a wearable sensor that primarily satisfies the following requirements: (i) high robustness and high energy-efficiency for long-term operation with minimum maintenance; (ii) very small form factor to be comfortably worn by the participants for several months; and (iii) low cost to be within the tight deployment budget.Yet, none of these requirements are critical for the aforementioned research works that were evaluated in a laboratory environment (TRL4).Instead, the TRL4 experiments require a wearable sensor that is extendable and sufficiently versatile to support a wide range of experiments.This versatility is is achieved by making the wearable sensor compatible and easily extendable to various sensors and other peripherals via employing connectors, external interfaces, jumpers, and solder-bridges.Indeed, the SPHERE Wearable Sensor attempts to simultaneous satisfy the requirements of high-TRL experiments in the wild and low-TRL experiments in the laboratory.From the perspective of the low-TRL experiments, this approach introduces unnecessary delays.From the perspective of the deployments, this approach has an impact in efficiency.Indeed, the SPHERE Wearable Sensor that is currently being deployed, SPW-2, incorporates a series of components that are not used in the 100 homes study.These include the second acceleration sensor, the gyroscope, the non-volatile flash memory, the LED and the button.Should this unnecessary functionality had been avoided, the deployed SPHERE wearable would have been smaller, more energy-efficient, more cost-efficient, and less complex (see Section V-B).In retrospect, it would have been more cost-efficient for SPHERE to maintain two branches of the SPHERE Wearable Sensor, one for the deployments and one for laboratory experiments.

D. TRYING TO BE FUTURE-PROOF IS FUTILE
Trying to make the IoT sensing platforms future-proof is only natural, yet our experience suggests that is is futile for two reasons.Firstly, embedded systems are very specialised by nature and it is very hard to predict what are the exact requirements of future deployments.It is interesting to observe that the SPHERE Wearable Sensor has been used in four different deployments (i.e. the SPHERE House experiments [21], the SPHERE 100 homes study [1], the ALSPAC study, and the EurValve deployment [4]), yet each one of these deployments uses a different variant of the SPHERE Wearable Sensor.Indeed, in practice, none of these platforms managed to be future-proof and meet the requirements of future deployments.
The second reason is that the electronics market progresses at a very high pace.The manufacturers of integrated circuits continuously make new generations of their products, offering new functionality and better performance.This constitutes an important limiting factor for the lifetime of an IoT sensing platform.It can be difficult for an academic project to keep up with this pace, especially without the resources to employ full-time electronics designers and software engineers.In that case, it is preferable to design the IoT sensing platform based on the current requirements using the most appropriate components that are currently available.

E. DATASHEETS AND PRESS RELEASES ARE NOT ALWAYS TRUSTWORTHY
It is also important to remember that the manufacturers of integrated circuits are sellers who are perfectly aware of the fact that once a customer commits to a particular integrated circuit, it is significantly costly for them to switch to a competitor.This is particularly relevant for integrated circuits that are associated with software development.
A particularly common practice is the advertisement of functionality before it gets implemented.Without proper attention an IoT sensing platform designer may select a particular component for its functionality, only to realise that they have to wait for months until the desired functionality is released.Another common practice is the announcement of new chips in press releases long before these components are available to purchase.Occasionally, these components never get released.Lastly, the datasheets of integrated circuits are not always trustworthy.It should be said that this happened only once during the development of SPHERE's IoT sensing platforms; yet, there was a particular occasion where the performance figures of a particular integrated circuit were exaggerated by one order of magnitude.
It is highlighted that adopting brand new chips is a doubleedged sword.One one hand, these chips may offer outstanding performance characteristics and, hence, may constitute unique selling points for the sensing platform.On the other hand, the availability of third-party experience and resources is very limited.As a result, these components require additional development time and are inherently risky, as they may hide unpleasant surprises.As a concrete example for this outside SPHERE, the support for msp430x extended 20bit memory did not exist in the msp430 port of the GCC compiler for several years after first msp430x microcontroller units (MCU) were available.Thus the extra memory was effectively unusable for many software developers.Another example for the risks inherent in insufficiently field-validated chips is the MSP430F1611 MCU, used in the popular Tmote Sky platform.Tmote Sky was created in 2004, and was widely advertised as supporting 8 MHz operation [29].However, only few years ago, Texas Instruments published errata3 that reports faulty MCU behaviour when its clock rate is above 6 MHz.

F. DO NOT REINVENT THE WHEEL
With the ubiquity of hobby electronics, there are numerous open hardware platforms available.Moreover, the manufacturers of integrated circuits often release open development boards to promote the use of their products.These open platforms can be of particular value when making IoT sensing platforms for academic research.Indeed, adopting parts of widely-used open hardware designs mitigates the risk of design faults.Consequently, it lowers the number of revisions, reducing the overall manufacturing cost and development time.
In addition, platform design choices can indirectly affect the time required for software development.Therefore, the development process can be significantly accelerated by adopting components that have open source drivers and are supported by open source operating systems.Within SPHERE, the designs of the SPHERE Environmental Sensor and the SPHERE Gateway take advantage of the open source software that is distributed with the Contiki OS [14].As a

G. DO NOT OVEROPTIMISE ONE PART OF YOUR SYSTEM
Research is typically highly specialised and very focused.It is naturally tempting for a researcher to provide highly optimised solutions for the elements of the system that are closer to their research interests.Yet, it is important to remember that an IoT sensing platform is an integrated system that is only as efficient as its least efficient component.Unless all the components of the system are designed to the same level of efficiency, the weakest element would be the performance limiting factor.For example, the energy-efficiency of the IoT sensing platform as a whole is determined by the joint efficiency of several sub-systems within the same platform (e.g.sensing, communication and networking, signal processing, voltage regulation and power management -all different of research).Therefore, it makes little sense, for example, to optimise the energy consumption rate of radio communication to micro-watt levels, when the board employs sensors that require milliwatts in sleep mode.The same principle applies to cost-efficiency and space-efficiency.
A noteworthy practical example can be found in the activity recognition literature.The drive to maximise the recognition accuracy has led researchers to use wearable sensors with redundantly high sampling frequencies.Unnecessarily high sampling frequencies may not be a problem in laboratory studies; yet, in a context of long-term deployments, they can be the cause of unmanageable maintenance burdens.

H. USER ACCEPTANCE IS MORE IMPORTANT THAN YOU THINK
User comfort, acceptance, and the aesthetics of the deployed devices are paramount for a successful deployment.This is particularly relevant for platforms that are worn by the users, but it is also important for environmental sensors that are deployed in private spaces.Researchers that have a background in performance-driven disciplines should be particularly careful not to underestimate the importance of these aspects of the design.Research in low power networking, for example, is primarily focused on improving performance metrics, such as energy-efficiency and reliability.User acceptance is not less important than these performance metrics.A wearable sensor that is not worn by the user is as valuable as a wearable sensor with a depleted battery or a wearable sensor that delivers 0% of its packets.
A group of members of the public, named the SPHERE public advisory group, was a particularly useful source of feedback during the development of the SPHERE technology.For wearable sensors, as expected, a small form factor is crucial for user compliance.It is interesting to observe how the SPHERE Wearable Sensor gets smaller from generation to generation, as we take the users' feedback into consideration (see Fig. 2).It is also worth noting that the capacity of the battery of SPW-2 is half of its predecessor.Effectively, we opted for decreasing the battery lifetime in half, in an attempt to increase user acceptance.In addition, we opted for making the process of battery recharging more convenient for the user with inductive wireless charging.With regards to the enclosure, a detachable strap is highly recommended, as different users may have different preferences or sensitivities to particular materials, such as nylon and leather.Lastly, it is useful to offer to the users a variety of colours for the casing and the strap.This not only helps with aligning with the users' preferences and aesthetics, but also decreases the probability of one participant wearing the wearable sensor of another.For the environmental sensor, we have observed that devices of the size of a smoke alarm are generally considered acceptable.Lastly, it is important that there are no lights emitting from devices that are deployed in bedrooms, as they may disturb the users' sleep.

I. ENCLOSURES ARE COSTLY
Every IoT sensing platform that gets to be deployed in the wild needs to be enclosed in a casing that is appropriate for the respective environmental conditions.The challenges of making enclosures for IoT sensing platforms can be very easily overlooked, especially within research groups that do not aim to innovate in this space.The first generation of the SPHERE Wearable Sensor was designed without a particular enclosure in mind.A suitable off-the-shelf enclosure was later identified.Yet, this enclosure was bulky and uncomfortable.Indeed, designing the board without a particular enclosure in mind significantly limits the available options for enclosures.For the SPHERE Environmental Sensor and the SPHERE Gateway, we followed the opposite strategy.We first identified a suitable off-the-shelf enclosure and then we designed the boards to fit this enclosure with minor modifications.More specifically, SPES-2 requires a front opening for the PIR sensor and SPG-2 requires side openings for the external antennae and the USB cable.This service was provided by the manufacturer of the enclosure at a reasonable cost, yet with lead times of up to 16 weeks.The design of the enclosure for SPW-2, Fig. 1 (top), was outsourced.Designing a bespoke casing, no matter how simple, is significantly more expensive than modifying an off-the-shelf casing.

J. ORDER MORE UNITS THAN YOU NEED
It is also advised to maintain stock of more units than the deployment needs.Indeed, IoT sensing platforms can be lost or damaged.For example, forgetting to remove a jumper on the programming board was the cause of permanent damage in some wearable sensors.In addition, we have damaged some environmental sensors by accidentally connecting them with an incompatible UART-to-USB cable.Moreover, the deployment requirements may unexpectedly change.For instance, an additional resident moved in the house during the 12-month experiment and required an additional wearable sensor.Furthermore, some obscure design imperfections may cause problems to a small subset of the produced units.Placing two components too close to each other was the cause of improper soldering in approximately 10% of a batch of wearable sensors.Fundamentally, planning for the worstcase scenario is costly, whereas planning for the averagecase scenario is risky.The best way to manage this trade-off depends on the particular resources and requirements of each deployment.

K. KEEP THE COST OF ELECTRONIC COMPONENTS IN PERSPECTIVE
The bill of materials is a common concern of electronics designers.Yet, it is important to keep it in perspective and consider the implications of your design decisions beyond the cost of the electronic components.A good example is the PIR sensor of the SPHERE Environmental Sensors.This single component contributes to more than 30% of the total bill of materials.A much cheaper variant of this PIR sensor was also available; yet, this alternative needed two orders of magnitude more energy to operate.Looking at the bigger picture, the expensive PIR sensor was a much more cost-efficient design choice.With such higher energy consumption, the SPHERE Environmental Sensor would not have been able to yield a 12-month battery lifetime.Indeed, the premium of using a very expensive electronic component for the environmental sensor is negligible when compared to the cost of scheduling periodic maintenance visits in 100 properties for replacing batteries.Another aspect that needs to be considered is the scale of the production.The benefit of reducing the bill of materials is proportional to the scale of the production.Indeed, the benefit of reducing the cost per unit by a dollar in a smallscale production of 100 units is small, and perhaps unworthy of the time of the designer.In contrast, consider the benefit of reducing the cost per unit by a dollar in a large-scale production of 1000000 units.

L. THERE IS A SIGNIFICANT ADMINISTRATIVE OVERHEAD
It is stressed that the process of making IoT sensing platforms has a significant administrative overhead that should be taken into account when planning and budgeting the research project.Examples of time-consuming administrative tasks include: (i) browsing the specifications and availability of electronics components; (ii) preparing bills of materials, requests for quotes, and purchasing orders; (iii) liaising with various PCB and enclosure manufacturers; (iv) packing and shipping electronic components; (v) storing and organising components and devices; (vi) procuring off-the-shelf parts (e.g. the strap and the charging pad of the wearable); and (vii) phone-calls, meetings and teleconferences.

M. READ THE LITERATURE AND CONSIDER THE EXPERIENCES OF OTHERS
From making the sensing platforms to developing their firmware and from collecting the data to remote monitoring, deploying sensors networks outside of the laboratory is a process with many pitfalls that can be easily overlooked.Before attempting a large-scale deployment in the wild, the authors highly recommend the reader to read about the experiences, the mistakes, and the lessons shared by other teams, and carefully consider their advice.The existing literature, which is briefly summarised in Section II, is a very insightful source of information that can substantially accelerate the deployment of sensors in the wild.

VI. CONCLUSION
SPHERE is in the process of deploying hundreds of its custom-made IoT sensing platforms in the houses of volunteers in the Bristol area.Making IoT sensing platforms for deployments outside of the laboratory is a complex process full of pitfalls.This paper shares experiences and lessons that we have learned from designing and developing embedded sensing devices for large-scale deployments in the wild, such as the SPHERE 100 homes study.It is our hope that this paper will prevent others from repeating our mistakes, and that the recommendations that we provide will significantly accelerate future research experiments of similar scale.

FIGURE 1 :
FIGURE 1: The bespoke SPHERE platforms that are being deployed in the houses of participants as part of SPHERE's 100 homes study: the SPHERE Wearable Sensor, SPW-2 (top); the SPHERE Environmental Sensor, SPES-2 (middle); the SPHERE Gateway, SPG-2 (bottom).
This work is licensed under a Creative Commons Attribution 3.0 License.For more information, see http://creativecommons.org/licenses/by/3.0/.This article has been accepted for publication in a future issue of this journal, but has not been fully edited.Content may change prior to final publication.Citation information: DOI 10.1109/ACCESS.2017.2787418,IEEE Access Fafoutis et al.: Experiences and Lessons Learned from Making IoT Sensing Platforms for Large-Scale Deployments This work is licensed under a Creative Commons Attribution 3.0 License.For more information, see http://creativecommons.org/licenses/by/3.0/.This article has been accepted for publication in a future issue of this journal, but has not been fully edited.Content may change prior to final publication.Citation information: DOI 10.1109/ACCESS.2017.2787418,IEEE Access Fafoutis et al.: Experiences and Lessons Learned from Making IoT Sensing Platforms for Large-Scale Deployments

Fafoutis
et al.: Experiences and Lessons Learned from Making IoT Sensing Platforms for Large-Scale Deployments result, the Contiki drivers of the CC2650 SoC and several of the peripherals were compatible, accelerating the software development process.
This work is licensed under a Creative Commons Attribution 3.0 License.For more information, see http://creativecommons.org/licenses/by/3.0/.This article has been accepted for publication in a future issue of this journal, but has not been fully edited.Content may change prior to final publication.Citation information: DOI 10.1109/ACCESS.2017.2787418,IEEE Access Fafoutis et al.: Experiences and Lessons Learned from Making IoT Sensing Platforms for Large-Scale Deployments

TABLE 1 :
History of SPHERE PCB Orders