Three lessons to consider while field testing IoT hardware: Learnings from the Upande grant

December 14, 2017 | Mobile for Development Utilities | Sub-Saharan Africa | Kenya | Ilana Cohen

This blog was written by Charu Chadha, formerly a Senior Market Engagement Manager, Mobile for Development (M4D) Utilities.

In 2013, we launched the M4D Utilities Innovation Fund to trial and scale the use of mobile to improve or increase access to energy, water and sanitation services. To date, we have awarded Seed and Market Validation grants to 34 organisations in 21 countries. We are publishing a series of blogs and case studies containing the final learnings from the 21 grants in the second phase of our Innovation Fund. Our objective is to develop an evidence-base across mobile-enabled utility solutions that can inform ecosystem players and accelerate the growth of the sector.

This blog shares key lessons from the Upande grant, related to the hardware development that should be considered during field testing.

Upande was awarded a M4D Utilities seed grant in May, 2015 to develop GSM-enabled remote monitoring hardware (sensors and communication module) as well as a geographic information system (GIS) based tool, the Water Sanitation Hygiene Management Information System (WaSHMIS). These tools were intended to measure the flow rate of water to generate alerts related to leaks and bursts and align the boundaries of the District Metering Areas (DMA) with the master meters to calculate losses that lead to non-revenue water (NRW). The WaSHMIS platform represents this analysis of technical data in an easy to understand graphic form to assist decision making by the utility management teams. Upande also developed a mobile-based application to help water utilities implement customer surveys (to collect account information such as water consumption, ownership, GIS location, state of the meter etc.), to reconcile field data with billing and track corrective actions through a bespoke JobCard app.

Upande began developing the platform, for analysing water flow data recorded through sensors, using data reported from Ellitrack data loggers starting in 2012. There were however, several limitations of the Ellitrack hardware and platform:

  • The high cost of the data logger ($350) and batteries ($35);
  • Unavailability of both the data logger, batteries and spares locally;
  • Ellitrack could not be directly integrated with the new WaSHMIS platform; but
  • Instead, data had to be downloaded from Ellitrack’s proprietary backend platform. Upande’s ability to analyse and use this data was only possible after building an API.


Figure 1 – PicoBRCK connected to the Cyble senor installed on a master meter

These factors made it difficult to use Ellitrack for scale-up. Therefore, this grant enabled Upande to partner with BRCK, a Kenyan company developing locally relevant connectivity solutions, to develop picoBRCK. This is a GSM-enabled connectivity device that would report data collected by the cyble sensor (used to measure water flow) and thus replacing the Ellitrack. Since the picoBRCK was being locally produced its price was expected to be lower and BRCK would be able to provide troubleshooting support. Additionally, the WaSHMIS platform could receive data directly through an open source platform and API integration.

Fifty picoBRCKS, with cyble sensors to measure flow, were installed at Kericho Water and Sanitation Company (KEWASCO) on key locations such as master meters, pump houses, treatment plant, etc.

The process of generating insights from data reported by sensors is not strictly linear. But to generate data-based insights, it was important to get the monitoring hardware to consistently report accurate data. This would be followed by analysis using algorithms and manually defining limits to generate alerts or any of these insights. During the grant term Upande developed the analytics platform based on the available data. However, hardware development was limited to a prototype-refinement loop (Figure 2), limiting Upande’s ability to extract insights on NRW.

Development journey for IoT hardware

GSMA’s report on IoT development journey for utility enterprises in emerging markets highlights the importance of field testing IoT hardware pre-pilot. Field testing is not a linear process but rather, as the report explains, a feedback loop. Results from field testing are used to refine the device and develop new features in the lab that again need to be field tested. This cycle may have to be repeated several times before the desired functionality and reliability are achieved.

Upande’s journey during the grant mimics the flow suggested in the GSMA’s report. During most of the grant term, with support from BRCK, they were using results from field tests to refine the hardware. During April, 2015 to March, 2017 they repeated the cycle, build-measure-learn, more than four times.

Figure 2 – Upande’s hardware development journey

Key lessons: Field testing hardware is the best way to test reliability

BRCK and Upande faced several challenges while developing hardware in-country. On several occasions the required components were not locally available (as expected) or the quality was not sufficient for the task. These challenges highlight the need to develop the in-country ecosystem to promote local development and innovation in hardware. Irrespective of these issues there were interesting learnings related to the field testing phase that may be relevant to other innovators.

1. Weather damage: water will find its way inside hardware

It is critical to understand the impact of prolonged exposure to natural elements, such as water and the sun, on the performance of the hardware. As Upande and BRCK realised even after conducting water immersion tests in the lab, during field testing hardware was damaged and stopped reporting due to water seepage.

The first version that was field tested was not sufficiently insulated, resulting in water damage. Based on this result, the second time, picoBRCK was enclosed in an IP66 rated case and sealed with silicon. However, moisture ingress was observed even with IP66 rated cases. This could have been due to thermal cycling pulling humid air into the case despite the seal. To remedy this situation conformal coating was used to protect the circuit boards and GoreTex venting technology to allow pressure equalisation. This solution appeared to be more resilient to seepage.

2. GSM network: Coverage and behaviour will vary across locations

2G coverage is quite ubiquitous in Kenya. While lab testing in Nairobi the devices performed predictably using GSM networks. However, once the devices were deployed in the field it was difficult to understand if they were not reporting due to unavailability of GSM network, i.e. tower downtime, network overload etc., or any other reason such as damage to the hardware, insufficient battery charge, and so on. This delayed the testing process considerably. Finally when BRCK was able to connect the issue of non-reporting to unavailability of the GSM network, they tried to resolve this issue by creating a robust code that accounted for exceptional cases. To prevent data loss due to unavailability of network, sufficient storage capacity was provided on the device through an SD card. Staggering the reporting time for different devices by few seconds (so that all of them don’t try to reach the server at the same time) which also improved reliability of reporting.

3. Security issues: Vandalism and theft

Installing the picoBRCK and cyble sensor on the piped network was a complicated task. More often than not the master meters were located underground where the water pipe network was and the picoBRCK required exposure to sun for charging. To ensure the safety of the devices, Upande, with consultation from KEWASCO, deployed the picoBRCK in secure premises such as shops and homes and connected them to the cyble using a cable. However, this was not a flawless solution as a few devices were stolen or damaged. Upande is working on developing more durable mounting hardware to prevent theft and damage.

Conclusions and recommendations

It is important that issues affecting IoT hardware reliability are resolved before volume roll-out that may include several hundred units. Field testing can be a time consuming process but is beneficial in the long-run. As IoT hardware is often deployed in places with low accessibility, where it can be time and resource intensive to troubleshoot.

Upande and BRCK, respectively developed WASHMIS and picoBRCK further. BRCK has been exploring alternate uses for the picoBRCK, working with other start-ups. Upande has introduced several utilities to their solution with over ten utilities trialling various components of the service.

Tell us about your experience of testing IoT hardware at

This initiative is currently funded by the UK Department for International Development (DFID), and supported by the GSMA and its members.

Leave a Reply

Your email address will not be published. Required fields are marked *