22 min readMay 4, 2016

(The report that follows can also be downloaded here in PDF format.)

Introducing new technology in international development is hard. Yet all too often, the key details of what actually happened in a project are hidden. This is especially true when the project doesn’t quite go as planned, which is what happened during the MakeSense project.

Between 2014–2016, the MakeSense pilot was supported by Feedback Labs to develop a citizen-led environmental monitoring project in Brazil. What follows is the story of what took place and what was learned. It is the full text of our actual final project evaluation. We hope that detailed storytelling and openness about the sometimes imperfect trajectory of technology and development projects can help others working with similar projects, and can inspire greater transparency in the field as a whole.

Introduction

The MakeSense project began in early 2014 with a proposal to the Feedback Labs experiment fund, seeking to test this hypothesis: Citizen-led sensor monitoring of environmental factors will strengthen feedback loops by providing structured, accurate and reliable data to compare against government measurements and news stories in the Amazon basin.

The funding amount of $60,000 was initially meant to support the following proposal activities:

GroundTruth Initiative, InfoAmazonia and Internews to work with communities and researchers to determine pollutants to measure
Internews to build several low-cost sensors with its academic partners
SIMLab to build the technical back end in FrontlineCloud to interpret incoming data, and create APIs useful for InfoAmazonia
InfoAmazonia to provide support to GroundTruth and to connect its platform to FrontlineCloud
Formalizing the standing informal partnership between GroundTruth Initiative, InfoAmazonia, Internews, and Social Impact Lab

The initial concept, drafted by FrontlineSMS (later SIMLab, its nonprofit institutional home), was meant to lay the groundwork for a further estimated $500,000 consortium project to build and expand on this sensor pilot. So, this small pilot was also envisioned as the beginning of a fundraising campaign and preparation for donor engagement that would grow substantially.

The project, over the next 1.5 years, made several detours from the initial plan which explain its current dormant status — while at the same time making headway in certain key areas. This site reviews this trajectory, and draws several lessons learned.

It is our hope that this open evaluation will be useful to others as they deploy similar projects, and fulfills our commitment to be as transparent as possible in our work.

The report was written by Erica Hagen of GroundTruth Initiative, and is based on her knowledge of the project as a participant as well as interviews with each consortium member and reviews of project documents.

Timeline

February 2014: Initial conversations occur between FrontlineSMS and Internews around the possibilities of the project
April 2014: Funding is approved by Feedback Labs for the Making Sense project
July 2014: Decision is made to reduce geographic scope to São Paulo
August 2014: MoUs signed among each member with SIMLab, to create an official consortium
March 2015: SEEED Studio agreement is signed to distribute the sensor prototype (known as DustDuino)
April 2015: Sensors are shipped to Brazil
May 2015: The website DustDuino.org is up and running
June 2015: Consignment agreement is signed
June 2015: The website OpenDustMap goes live
August 2015: Air Quality Meetup, Sensor-Building Party
January 2016: Video about the project is completed

Theory of Change

Under the initial theory of change, community members and groups in the Brazilian Amazon basin, who were highly impacted by environmental degradations, would operate simple sensors whose data would then be used by Brazilian members of the Earth Journalism Network (EJN) to report on key issues. By comparing readings to official sources they would be able to counter incorrect, unknown or ignored information, increasing accountability. InfoAmazonia (based in São Paulo) would provide the required networks and contacts in these communities and serve as local base, while Internews would supply the technical know-how for the devices. FrontlineSMS would develop a pipeline to transmit the sensor data via SMS through its platform. GroundTruth Initiative would design and test the engagement with local communities who would manage the sensors.

The MakeSense project’s conceptual framework built upon research and case studies in the nascent field of sensor journalism. Emerging sensor technologies could be used by citizens themselves to provide missing environmental monitoring in order to help hold governments and the private sector accountable, especially in cases where official measurements were not available, fully trusted or reliable. It was envisioned that environmental journalists could help mediate this process.

Inception:

A meeting between FrontlineSMS and Internews was held in Washington, DC to discuss deployment of a GSM-based sensor network as a continuation of prototype development by the Internews Center for Innovation and Learning. GroundTruth Initiative was brought on to help design and test a citizen engagement process around the sensors. InfoAmazonia, an organization based in São Paulo, Brazil, provided the local context and capacity for piloting (Internews and its Earth Journalism Network (EJN) were already working closely with InfoAmazonia).

Following the submission and acceptance of a brief proposal to Feedback Labs, the consortium convened its first meeting for project start up in April 2014. The purpose of early meetings was to reach a common understanding of prioritization and execution of the project.

During these early discussions it became clear that Internews already had a strong preference for working with air quality sensors as a result of prior research and development of 10 prototypes, called DustDuinos, that were tested with journalists in 2013. The gap in data quality for low-cost dust sensors was shrinking, and deploying low-cost sensors as a complement to high-cost monitors had real potential to expand monitoring networks and increase opportunities for citizen contributions. Other types of environmental sensors, such as water quality sensors, were still comparatively difficult to develop.

Previously, the DustDuino sensors — designed by Matthew Schroyer, an Instructional Technologist at Oklahoma City Community College — had been set up individually, with parts coming from several different manufacturers. A GSM version had not yet been tested.

It may not have been clear at this point to all partners or to Feedback Labs that production of mass-produced sensor hardware device is in itself a highly challenging and time-consuming process — or, the extent to which the mass-produced version of the device and its data systems were still in a very early stage of development. The initial hypothesis had assumed that there was a working prototype, or that one could be easily produced.

Background: Air Quality and Sensors

The health effects attributed to outdoor ﬁne particulate matter (PM2.5) rank it among the risk factors with the highest health impacts in the world, accounting for over 5.5 million premature deaths annually. In October 2013, the World Health Organization announced that they consider particulate matter, a major component of indoor and outdoor air pollution, as a Group 1 carcinogen along with tobacco smoke and asbestos. More than 85 percent of the global population lives in areas where the World Health Organization Air Quality Guideline is exceeded.
DustDuino was initially prototyped to help individuals with limited resources monitor PM10 and PM2.5 concentrations, indoors or outdoors. It contains a Shinyei PPD42NS, a $15 optical sensor that uses an LED and lens to determine the concentration of dust in a partially closed chamber that draws in air from its surroundings. The sensor data can be received by an Arduino development board and transmitted over WiFi. (While some air quality sensors for the general public were already in existence, they either measured other types of air components or could not transmit data over wifi.) For more detailed device information please see Public Labs DustDuino page.

Changing Hardware Parameters, New Partners

The budget allotted to the pilot turned out to be not nearly enough to cover the objectives of the team. Discussion centered around what constituted a minimal viable product, and there was some disagreement on project direction. Should the pilot set the stage for further fundraising based on a limited product and research, or should time be spent actually developing and field testing more thoroughly — which would ultimately leave less partner time for outreach and business development?

There were several cost considerations. First of all, sensor components themselves are priced based on their quantity. A cost analysis conducted in June 2014 projected the following costs per unit (organized by connectivity type) without mass production:

GSM: $174.22 per unit
Wi-Fi: $97.95
Xbee Mesh Network: $206.69

If sensor components could be mass-produced, it would lower the cost per unit and reduce the logistical complexity needed to acquire parts from multiple sources. However, reducing per-unit costs required increasing the quantity of sensors ordered beyond the needs of this pilot. Internews offered to provide co-financing for the cost of additional units to be used in their broader sensor work.

But, that also meant possibly reducing orders of GSM sensors, since they were more costly and therefore of lesser interest to Internews for other work. In addition to procurement costs, each individual SMS incurred charges unless donated by mobile network providers. For example, 30 devices sending 24 messages a day (hourly) for 90 days at $0.05 cents per message would cost $3,240.

Another emerging consideration was that the number of sensors required for accurate measurement needed to be large enough to function as a “network.” A reprioritization toward a more scientifically valid proof of concept would mean deploying a larger number of sensors than first envisioned. GSM sensors would additionally require substantial budget allocation to cellular charges if the network of sensors was fairly large.

Two issues that were previously not well-considered arose at this point, which would redirect the course and alter the goals of the project:

Internews’ suggestion that a fairly large number of sensors would be required in order to attempt to create reliable data worthy of comparison with official sources.
Related interest in mass production meant ordering sensors that could be used beyond the scope of this pilot, and therefore GSM-based sensors would not be mass produced at this stage.

At the same time, after breaking down the travel costs both within and to Brazil, it became clear that this travel would potentially be cost prohibitive. InfoAmazonia is based in São Paulo, and the locations proposed for deployment were in the Amazon basin, requiring local travel expenditure. GroundTruth was originally meant to assist with deployment and community engagement planning with the selected civil society organizations, which also required international travel.

Rural testing may still have been achievable within the initial budget, but now there was a growing concern among some team members that a user interface for configuring the sensor and an attractive front-end site for displaying the data were missing from the project plans.

The initial idea was that InfoAmazonia.org would be the hub where the sensor data would appear and be mapped. InfoAmazonia already had a geographic component and a network of environmental journalists. The data would be sent to Xively to be captured and managed, but this too ran into cost barriers — there was concern over being locked into the Xively fee-based platform indefinitely. Feedback from the initial Internews pilot also indicated that simplifying the process for connecting the device to an online database was important.

A diagram of the data flows and storage in the project.

So, a decision was made to create Open Dust Map to contain and display the data, and for individuals to connect their sensor easily to the web. Development Seed would come in as a new partner. They would house the incoming data from the sensors in a simple database on their servers and display it geographically on the site, instead of on InfoAmazonia’s (which anyway lacked the ability to display streaming data without significant investment).

In order to save money and reallocate some to the new partner, as well as to establish a longer term manufacturing and distribution partnership for the devices with SEEED Studios, a China-based manufacturer, Internews proposed that the team rely on mass-produced sensors and pay for 35 sensors out of a bulk order of 100 (the rest of the 100 would be paid for by Internews for their own use).

The majority of these sensors would be wifi-based, without the GSM shield. The wifi-enabled sensor was priced at approximately $50.80 USD per unit in the bulk order (a GSM-enabled sensor from SEEED would have cost approximately $110.70 per unit).

So, the decision was made to produce the wifi sensor in bulk, and to separately purchase a set of GSM shields that could be tested on a few of the devices.

From Community Engagement to Civic Spaces

A DustDuino being installed in an apartment window in São Paulo.

Aside from the cost savings potential in removing transportation to rural Brazil, the project now had to make the wifi sensors work — which meant limiting much of the project to urban centers. The team therefore decided to reevaluate the location of the sensor project deployment. They considered first whether measuring air quality during the World Cup, taking place in June 2014 in Rio, was feasible within the time frame. But this would require very rapid production of the sensors. While some sensors already existed, they weren’t in Brazil and would need to be sent or carried there in time. The time was too short for this idea to succeed.

Alternatively, InfoAmazonia proposed testing sensors within São Paulo itself in public spaces. Air quality could be measured in micro-environments such as individual bus stops on the streets of the city. Individuals could borrow a sensor from InfoAmazonia and test their homes, schools, and other places where there may be concern about air quality. This was the final model of deployment that was selected. GroundTruth Initiative was reassigned to work with InfoAmazonia on the plan for deployment and engagement around a variety of São Paulo communities, with both wifi and GSM sensors.

Shifting Project Goals and Allocations

This set of interrelated decisions — ordering a higher quantity of the Wi-Fi sensor than GSM, designing a new user interface with a new partner (Development Seed), and mass producing the sensors — effectively reallocated the budget from the initial plan.

This plan had relied heavily on GroundTruth Initiative and InfoAmazonia working closely with local organizations. Emphasis shifted from pre-deployment research around sensor data demand and citizen engagement, to setting up technical systems and working on hardware, data pipelines and web design.

This decision acknowledged on the one hand the sheer difficulty of setting up a working new piece of hardware in bulk, and the failure to build in appropriate funding and timelines in the initial proposal for this development. It seems the assumption was made that hardware development was already covered by Internews and InfoAmazonia for other projects, so it would not need to be figured into the planning as extensively as it turned out was needed. Many of the challenges and time delays that arose later came out of the manufacturing and data pipeline processes.

However, it also indicated a move towards spending on development time over determining field needs and demand in-person, relying instead on an individualistic “Maker” model. By this model, community access comes only after a device is developed and validated within a hacker/technologist setting. Or, journalists and other data literate individuals to exclusively work with technology and mediate the information to the general public.

This can allow for all the bugs to be worked out before devices are introduced to less technical groups and communities, but it may risk failure to develop for the needs of such communities without their participation, leaving them with hardware and software that has already been built to suit a particular social subset (usually wealthier, more urban, and highly technically skilled groups). In some ways this goes against the “Maker” ethos itself, which might prioritize tinkering in-situ whether in the Amazon basin or an urban hackerspace. Ultimately, environmental sensors will need to reach locations that are more remote and challenging.

A clear tension between the desire to have statistically valid data and systems, and to have input from the potential user community in a high-need field context arose due to the limited budget.

The goal was always to get a working prototype of the technology and research the needs of the remote community. But, as the technical/logistical challenges grew and the timeline slipped, the ambitions of the project were forced to contract. Without a working prototype to show, raising follow-on funding also became more difficult.

In technology and development projects, there is often a question to be answered about exactly how and when to integrate user feedback directly — a question of what happens when, and how often during the overall design process.

In the case of this project, there may have been different, shifting, or poorly communicated understandings within the team of who the most critical “users” were for this pilot (and whose feedback was necessary at each juncture): the initial proposed target of the Amazon basin communities, or the urban “hackers” who were already familiar with Arduino boards and could easily manage the devices.

Each Dust-Duino kit arrived with parts needed to put together a sensor. They were not preassembled for both shipping and cost reasons. However, this made them less user-friendly for novice technologists.

Sensors Arrive

By the end of 2014, five sensors with GSM shields had been sent to Brazil and assembled by the project team. FrontlineSMS developed the API to channel their SMS messages to the website in development by Development Seed. However, there was another problem: the code on the devices themselves wasn’t working correctly to allow the GSM shield to operate. The team would have to re-code the devices to even begin to transmit any data. Since this was also not budgeted for, a Brazilian developer had to commit volunteer time to get them working. This was not completed until March of 2015, and bugs in the code plagued the project throughout.

Three of these GSM sensors were then set up for testing: one at a bus stop, one at a local “hackerspace”, and one at the InfoAmazonia office. They did begin sending text messages to FrontlineSMS (these messages were paid for by the project); however there was an issue between the Frontline API and OpenDustMap so they did not yet display on the map. They were taken down until this could be resolved.

The Bus Stop:

In part to address the potential disconnect for the information with the general public, even in São Paulo, the InfoAmazonia team decided to deploy a sensor at a news kiosk at a large public bus station, with an LED sign color-coded to alert the public to high dust levels. They also put up posters to help people understand the LED and issues around air quality.
A developer working with InfoAmazonia hooked the LED sign up to the Arduino processor for the bus stop sensor. Here it is shown with a green light indicating safe levels of dust.
Meanwhile, the full shipment of sensors had been delayed while Internews developed the manufacturing agreements and documentation with SEEED studios, the manufacturer. It also turned out that customs expenses to Brazil were going to fully triple the cost of each sensor, an unforeseen budgetary challenge. For 35 sensors, the costs to import came to nearly $2,900 USD. Internews covered that expense.

Finally in April of 2015, the full sensor shipment arrived in São Paulo. In August, an event was held to start to share the devices within the hacker community for testing, and an online form was developed and shared to invite residents to “adopt” a sensor, or take one home or to their office on loan. Five devices were adopted by attendees during the hacker event.

A screenshot of locations streaming sensor data to OpenDustMap.com

In September 2015, the bus stop GSM sensor was redeployed and began sending signals via SMS to Frontline, and from Frontline to OpenDustMap successfully. (Due to a miscommunication, the sensor was first programmed to update readings every minute instead of every hour — which not only incurred excessive SMS charges, but also went over the limit on the free account with Frontline Cloud. This was later corrected.)

However, other technical issues became apparent immediately. The sensors were getting incorrect readings. Some appeared to have actually negative numbers. Others were clearly too high. It turned out that the casing was the wrong size for the sensors and was obstructing the airflow; meanwhile the wifi component’s power demands were also impacting the readings. The casing was resized locally but funding for reordering all the cases from SEEED Studio was not available.

Overall, several bugs were reported in the wifi sensors in late 2015 — complex combinations of hardware and software with multiple points of failure, meaning that troubleshooting them was time-consuming, and not budgeted for. Some of these additional issues were not resolved when the casing was fixed.

By November, so few sensors had been deployed that information was very patchy. Once a sensor went offline, its historic data remained with no way to remove or mark it as old. Again, funds to permit even this relatively small fix were not available.

So, in November the consortium decided to archive the site for the time being and turn it into a record of the pilot’s learning, foregrounding this report and resources that might allow others to take forward this work. GroundTruth committed to document this learning and evaluate the project.

Conclusion

Ultimately, this project has not sufficiently demonstrated proof of concept or fully tested its hypothesis.

The project has made some progress toward creating a reliable DustDuino air quality sensor prototype; ironing out mass-production, software and hardware issues; and building FrontlineSMS integration, API, and a back-end user integration and front-end data display on Open Dust Map. The project has also made headway toward getting reliable and accurate structured data from the sensors, and produced extensive documentation that will allow for further experimentation.

In the end, however, the consortium was not able to successfully test the potential of sensor technology for monitoring by people and communities most affected by environmental degradation.

This is where the project stands as of this review. Internews does plan to carry forward efforts to increase data quality through new casing and other improvements, and to continue to develop DustDuino in 2016 in combination with several other related projects — such as OpenAQ, a site monitoring official government air quality data. The formal consortium established for this pilot does not have plans to move forward.

Lessons for Future Projects

Explaining the DustDuino readings to a bus stop vendor in São Paulo

Technical Challenges

Technical Difficulties are to be expected

Setting up a new hardware is not like setting up software: when something goes wrong, the entire device may have to go back to the drawing board. Delays are common and costly. This should be expected and understood, and even built into the project design, with adequate developer time to work out bugs in the software as well as hardware. At the same time, software problems also require attention and resources to work out which became an issue for this project as well, which often relied upon volunteer backup technical assistance.

Simplify Technical Know-how Required for Your Device

The project demonstrated that it is important to aim for the everyday potential user as soon as possible. The prototype, while mass-produced, still required assembly and a slight learning curve for those not familiar with its components, and also needed some systems maintenance in each location. Internews plans for the DustDuino’s next stage to be more “Plug-and-play” — most people don’t have the ability to build or troubleshoot a device themselves.

Consider Data Systems in Depth

This project suffered from a less well-thought-out data and pipeline system, which required much more investment than initially considered. For instance, the sensor was intended to send signals over either Wi-Fi or GSM, but the required code for the device itself, and the destination of the data shifted throughout the project. Having a working data pipeline and display online consumed a great deal of project budget and ultimately stalled.

Prioritize Data Quality

The production of reliable data, and scientifically valid data, also needs to be well planned for. This pilot showed how challenging it can be to get enough data, and to correct issues in hardware that may interfere with readings. Without this very strong data, it is nearly impossible to successfully promote the prototype, much less provide journalists and the general public with a tool for accountability.

Implementation

It is important to be intentional about technical vs programmatic allocation, and not underestimate the need for implementation funding. It is often the case that software and hardware development use up the majority of a grant budget, while programmatic and implementation or field-based design “with” processes get short shrift in the inception phase. Decision making about whether to front-load the technology development or to develop quick but rough in order to get prototypes to the field quickly, as referenced in the narrative, should be made intentionally and consciously. Non-technical partners or team members should be aware of the incentives present for technical team members to emphasize technical development over often equally critical local engagement and field testing processes.

Funding Paralysis

The anticipation of a need for future funding dominated early conversations, highlighting a typical bind: funding available tends to skew to piloting with no follow-up opportunities for successful pilots. This means that before the pilot even produces its results, organizations must begin to source other funds. So, they must allocate time to business development as well, which can be difficult if not impossible, and face pressure to create marketing materials and other public relations pieces. This can also in some cases (although not with this pilot) lead to very premature claims of success and a lack of transparency. During this project, there was some disagreement among team members about how much to use this pilot fund to support the search for further investment — almost as a proposal development fund — and how much to spend on the actual proof of concept through hardware/software development and field testing.

This is a lesson for donors especially: when looking for innovative and experimental work, include opportunities for scale-up and growth funding or have a plan in mind for supporting your most successful pilots.

Teamwork

A consortium project is never easy. A great deal of time is required simply to bring everyone to the same basic understanding of the project. This time should be adequately budgeted for from the start. Managing such a team is a challenge, and experienced and very highly organized leadership helps the process. FrontlineSMS (which received and managed the funding from Feedback Labs) specifically indicated they did not sufficiently anticipate this extensive requirement. Also, implementing a flat structure to decision making was a huge challenge for this team. Though it was in the collective interest to achieve major goals, like follow-on funding, community engagement, and a working prototype, there were no resources devoted to coordinating the consortium nor any special authority to make decisions, sometimes leading to members operating at cross purposes. Consistent leadership was lacking, while decision-making and operational coordination were very hard given quite divergent expectations for the project and kinds of skills and experience. This is not to say that consortium projects are a poor model or teams should not use a flat structure, but that leading or guiding such a team is a specialty role which should be well considered and resourced.

Part of the challenge in this case was that the lead grantee role in the consortium actually shifted in 2015 from FrontlineSMS to SIMLab, its parent company, when the FrontlineSMS team were spun out with their software at the end of 2014. The consortium members were largely autonomous, without regular meetings and coordination until July 2015, when SIMLab instituted monthly meetings and more consistent use of Basecamp.

Communications

Set up clear communications frameworks in advance, including bug reporting mechanisms as well as correction responsibilities. Delays in reporting bugs with Development Seed and FrontlineSMS APIs contributed significantly to the instability of the sensors in the field. Strong information flow about problems, and speedy remote decision-making, was never really achieved. At the same time, efficiency in such consortia is paramount, so that time isn’t taken from operational matters with coordination meetings — so a balance must be struck. This project eventually incorporated the use of BaseCamp.

Implications for Innovation Funding

While it might have been too ambitious to try for a hardware prototype with two types of connectivity, a documenting website, actual community engagement AND business development, all for $60k, not to mention the coordination required, it is also true that typical funds available for innovation lend themselves to this kind of overreach. Indeed, a more realistic proposal would have merely stated that the team would work out software and hardware bugs and establish key relationships and processes, clearly only a first step — though a critical one — toward a “feedback loop”. However, such a proposal would not be as exciting to donors.

At the same time, for projects which have already come this far — which have a viable product and need to take the next several implementation and development steps — funding is not as easily available. Instead, funders may support a different team to start over from scratch with a similar concept rather than support the crucial yet less “exciting” growth phase of a project. If they do support a growth phase, they may expect the project to generate revenue prematurely.

Consortium projects are another trend that require more consideration. Rather than simply expect a new team to know how to work well together, in spite of differences ranging from subject area expertise, geographical base, to business models to even basic assumptions about development, funders should instead consider direct support (financial and/or capacity) to consortium leadership alongside or as part of project funding. Our analysis of this project highlights the key role played by communication and teamwork, yet hardly ever does a funder request management plans or demonstrated experience in consortium leadership, nor give special attention and resources to support the collaborative process. The more partners are included, the more difficult the process becomes to the point where there may be a lack of buy-in and ownership of the project overall.

Good practice would be to support innovators throughout the process, including (reasonable) investment in team process (while still requiring real-life testing and results), and opportunities for further fundraising based on “lessons” and redesign from a first phase. As well, an expectation that the team be reconfigured, perhaps losing some members and gaining others between stages, plus defining a clear leadership process. Supportive and intensive incubation, with honest assessment built in through funding for evaluations such as this one would go a long way toward better innovation results.

Funders should also require transparency and honest evaluation throughout. If a sponsored project or product cannot find any problems or obstacles to share about publicly, they’re simply not being honest. Funders could go a long way toward making this kind of transparency the norm instead of the exception. In spite of an apparent “Fail Fair”-influenced acculturation toward embracing failure and learning, the vast majority of projects still do not subject themselves to any public discussion that goes beyond salesmanship, in fear of causing donors to abandon the project. Instead, perhaps donors could find ways to reward such honest self-evaluation and agile redirection.

Inputs

Codigo Urbano organized local deployments and coding, Organized meet-ups at São Paulo hackerspaces, Led GSM hardware development, Led local sensor assembly and configuration

Development Seed led the software development and design initiatives, Produced opendustmap.com and api.opendustmap.com

DustDuino lead developer Matthew Schroyer, Led engineering of the DustDuino board, Led wifi code development, Provided materials for product documentation

Feedback Labs: provided financial support for the pilot 60,000 USD

FrontlineSMS (later SIMLab), produced the proposal and led development of the GSM data pipeline, Coordinated project schedule and task management. Development of SMS pipeline to OpenDustMap via FrontlineCloud API

GroundTruth Initiative contributed research and learning components of the project, Advised InfoAmazonia on deployment strategy, Produced the learning report

InfoAmazonia led the production of local media and deployment of Coordinated local deployment of sensors Produced video and poster materials

Internews Earth Journalism Network: led hardware development and documentation Research and development of sensor technology Coordinated development and iterative testing of sensor technology Formalized manufacturing relationship and managedlogistics, Led production of users tutorials and documentation