Testing for Wild Hardware
One of the most important parts of the FieldKit project is thoroughly testing the hardware out in the field. The phrase “in the field” can mean many very different things to different projects. Often times, it means a production environment or out in the “real world” where it can interface with users and other systems. On some projects, this can be as easy as flipping a switch or taking a few steps out of an office. However for FieldKit, we quite literally mean the field.
By design, our hardware is going to places that are not electronics-friendly. These are places that we have to worry about things like flooding, rats, biofouling, freezing temperatures, insect infestations, stolen solar panels, and anything else you can imagine could happen when you put unaccompanied electronics in the wild. On an earlier FieldKit iteration, we literally had a hyena chew up one of our sensor enclosures. We’ve had partners request that our sensors are built to be “elephant-proof” (a feat that, if you’ve ever seen an angry elephant, is nearly undoable). Anything is possible with enough money, but some things do not make sense for a product that is aiming to be low cost.
The more reasonable considerations have made their way into our design and we spend a lot of time prototyping and testing to make sure we can meet the needs of the users. Over the last year we have been testing prototypes in the Amazon Rainforest with the Tropical Rivers Lab at Florida International University. These have been absolutely instrumental at finding design issues, identifying bugs, and providing input into the UI of the app and website. Our partners here have been absolutely essential team members. All of those test units will be replaced by the production version of FieldKit in the next few months.
The types of problems or UI/UX frustrations that come up when you are out in the middle of a field deployment are the things that you would never find during testing in the lab. There is a clear and undeniable benefit that comes from these experiences that makes them incredibly valuable. Over the next few months, we have a number of testing deployments planned to thoroughly vet FieldKit before its commercial release in the second quarter of 2020. Some of those will be local tests using the team at Conservify, including the deployment of some stations on the roof of the lab and in our respective backyards. Some of those will be with partners in other parts of the United States, including California, Montana, and Florida. Some of those will be across the globe, as we send production versions to some of the early adopters and advisors of FieldKit. All of the feedback and issues will come back into our issue tracking process at Conservify. We will incorporate the lessons learned into Jira to track any bugs or design flaws. This helps us prioritize the work moving forward.
The whole FieldKit team was recently in town for a design review. We decided it would be helpful to have everyone in the team do a test deployment of the FieldKit weather station. This included building up the station, using the app for deployment, letting it run for a bit, download the data off the hardware, and then disassemble the station. We arranged the teams so that the those doing software development and design, the folks who knew the app the best, would go last.
The feedback from the team was everything we hoped to gain from an experience like that. We found software bugs within the app and how it interfaced with the hardware. We had improvements to the app UI and deployment process. We identified tweaks to the hardware to improve integration, the connector experience, and mounting. It allowed us to have a good evaluation of the effort required in the push to get us to that point. Even working to the dates of this field test allowed us to prioritize and push in areas to get us to a testable product.
