Description

FieldKit is an open-source software and hardware platform that allows individuals and organizations to collect and share field-based research data, and to tell stories through interactive visualizations. Designed to be easy to deploy customizable, FieldKit can be adapted to meet the needs of diverse research teams, from biology and ecology to marine and environmental sciences, from post-doc researchers to elementary school students. FieldKit offers a simple platform for enabling live data expeditions, and for the creation and deployment of environmental sensor networks or in situ monitoring.

Project Logs

When there's WiFi in the Amazon

Pretty much every sensor deployment we've done has been to remote areas with little or no connectivity. It can take days to reach some locations, either off roading through unforgiving terrain, boating in over crocodile infested waters, or hiking over rocks, ice, and snow. Sometimes we've been able to get status over satellite, but the bandwidth and power budget usually mean that the truly useful status and diagnostic information is left sitting idly on disk until the station can be visited again physically. It's stressful setting up a station and then leaving the poor thing behind, hoping that nothing was forgotten and that enough testing was done.

Over the last few months our efforts have largely revolved around some work we're doing with WCS and FIU in the Amazon jungle. Most of the stations there have been of the breed we're used to, left on their own to fend for themselves. Lately we got word that a future site would have WiFi, which for us is a pretty unique opportunity for a few reasons. First, we'll be able to get higher fidelity diagnostic information and data from these stations. In addition, given the right preparation, we'll be able to service the firmware on these stations remotely.

Being able to remotely upgrade firmware is a feature I've been wanting for a while. Given the state of the FieldKit project we've never really had a reason to expend the effort for the feature, though. This recent news was a great opportunity to justify that initial groundwork work.

Now that the feature is implemented and being tested, I wanted to write up a post going over what the feature took. So, get ready, this is a software heavy post.

Overview

At a high level, the basic premise is that the station would periodically check with our servers to see if there is new firmware available. If there is, the firmware is downloaded and then stored in the Serial Flash chip. Once completed and verified, the MCU sets a flag in memory indicating the self-flash should be done and then restarts itself. At startup our custom bootloader checks for this flag, and if set will reprogram the MCU's flash memory from the binary in the external flash chip.

When remotely upgrading module firmware the process is very similar. The Core module (the one with the WiFi) will check to see if any of the attached module's firmware is outdated, downloading the binaries if necessary. Then that binary is transferred to the module over I2C, verified, and the module restarts itself in a similar fashion.

This is one area where us deciding to include serial flash memory as a standard "Module" feature was a good idea. This process would have been more awkward, otherwise.

It's important to us that all of the work we do fit comfortably within the OSS/OSH ecosystem that's evolved from Arduino and similar platforms. This work represents the largest deviation from that work, so far. Though it's possible to use our code/hardware with standard bootloaders and simply forgo that functionality in your own projects.

Digging into Bootloaders

Most "maker" focused development boards in the Arduino ecosystem come pre-installed with a bootloader of some kind. This is a small program, usually less than 8k or so, then runs before application code and provides friendlier ways of programming the MCU. For example:

Presenting the MCU as a USB storage device so you can simply copy new firmware files over.

Checking for "double taps" of a physical button that places the MCU in a "ready to program" state.

Now would be a good time to mention that all of our boards use the ATSAMD21G18 chip, the same one from the Arduino Zero boards and the Feather M0 line. So most of what's here applies to them and another Cortex M* chips....

Botswana's Okavango Delta is one of the most incredible places on this planet. Named a UNESCO World Heritage site for it's biological diversity, the Delta is a pristine habitat for all the charismatic megafauna that subsaharan Africa is known for: elephants, hippos, lions, giraffes, and more. It is one of the most incredible places that I have ever been and the need to monitor and protect it has never been more necessary. It was in this magical place where FieldKit was born, with support by the National Geographic Society.

FieldKit was inspired by a collaboration between National Geographic Explorers Shah Selbe, Steve Boyes, and Jer Thorp. Steve was conducting biodiversity surveys of the delta from canoes year-after-year in the same old ways that scientists have done for decades (if not longer). While working in the field in Botswana, Angola and Namibia, the team realized that there were few good open source hardware and software tools that met the specific needs of field research. Not only in sensor technology but also ways to organize and visualize the data. Responding to this need, Shah and Jer began to prototype software and hardware solutions and field-tested these approaches from 2014 to 2017.

We wanted to share the science and the story behind the expedition real-time, so anyone could join and provide insight or support. By turning Into The Okavango (ITO) into a live-data expedition, we have been able to bring thousands of people along with us on expeditions in the Okavango Delta (including an astronaut that was following along from the International Space Station). We collected, stored, and shared 40 million open data points and continuously measured ‘the heartbeat’ of this crucial ecosystem through large-scale open source sensor systems.

This experience we had with ITO was transformative, and it made us realize that we should bring these same capabilities to anyone anywhere in the world by giving them a publicly available, fully featured ITO of their own. The lessons learned and understanding that came from years of continuous field use allowed us to architect FieldKit in way that can be scaled and expanded across various users regardless of how much they know about engineering and computer science. Scientists have already been embracing social media and blogs to share their expeditions with the world visually, but there wasn't a good tool out there for them to do that same sharing scientifically. @Jacob Lewallen has been helping with the hardware and software development on a volunteer basis since the beginning, and stepped in as FieldKit's Principal Engineer at Conservify in 2017.

We already have additional working partnerships with scientists to use FieldKit in their efforts, which include:

Deployment of a FieldKit camera module, as a request from the Wildlands Conservancy and U.S. Fish and Wildlife Service to monitor the first California Condor to return to the Wind Wolves Preserve. This will also stream the video live to a "condor cam" that will serve as a public outreach and conservation communication tool.

In our previous post, Shah outlined our most recent project with the Tropical Rivers Lab at Florida International University and gave a high level overview of the work we've started with them. I wanted to take some time to talk about how valuable the real world work is in providing feedback on FieldKit ecosystem.

It's inevitable in field work that you'll find yourself working with conditions or constraints that you didn't anticipate, even more so when you're the one who has designed the hardware you're using. Ever since my first field experience I've tried my best to keep meticulous notes on the issues I encounter, their solutions, and ways they could be avoided and mitigated in the future. These notes are incredibly valuable compared to in-lab testing of hardware and physical enclosures by virtue of many important facts:

They are often taken outside of the lab, without access to the tools and parts that are available during development.

They include insight from volunteers or partners that aren't present during the day to day in lab testing.

Not every field installation is identical and always brings some unique challenge to bear on the hardware.

There tends to be a difference in scale that has an impact on my mindset. For example, assembling 10 stations is very different than assembling 1 for an in-lab test, making bottlenecks and physical improvements more obvious.

I'm going to quickly go over some of the changes we've made recently, directly due to the efforts of preparing these stations for the field.

Physical/Hardware Changes

Size

Connectors

Oh connectors. Connectors have been one of the largest frustrations I've had. We've recently begun incorporating Molex connectors on our boards to link modules to the Core board. The connector is a 5 position one, carrying I2C, power, and Vbus (unused for now) This went so well that one change I wanted to make was use them for even more things, not just the Core/Module connection. We decided to increase our use of these connectors in these ways:

These stations were the first to incorporate an external user switch, which was exposed via an awkward through-hole header. This became a 2 position Molex.

Weather stations have two PCBs, one main weather module and a board we call the sensor board that's housed in a Stevenson screen. One end was already Molex and for some reason the other end was not. These things happen. The learning experience here though, was that the Molex on the sensor board should be on the bottom of the PCB for easier mounting.

Our water quality module had a 4-position "sensor" connection already. We carried this pattern across all our module boards because it's become common to attach secondary sensors to various modules.

We added second Core connectors to all modules so they could be daisy chained in the future.

Vertical Entry vs Side Entry

So far used we've been using side-entry USB and JST connectors exclusively. Somewhere around the third board I realized that vertical entry USB would be way more useful in situations where the enclosure is an off the shelf box. Side entry, especially on the ends of boards, requires internal space to be be able to use the connector. Otherwise, you've got to lift the board from inside the enclosure to insert a USB cable when flashing or charging, etc.. The same goes for the JST connectors we used for batteries, though to a lesser extent because they tend to be more maneuverable than USB cables. Right now we're testing hybrid USB and JST footprints that allow either part to be soldered on. We'll be reporting back on how successful this is, especially with regard to the frankenprint we're using for the USB.

FieldKit is designed to work with many different scientific applications, across various deployment scenarios and geographic locations. That requirement came from the type of work we do at Conservify, which can vary from partner to partner. One goal for this Residency at the Supplyframe DesignLab is to get us into a product line focus instead of the constant one-off projects that we have been doing time-after-time. We want to build something useful for the scientific community, that allows for anyone with any scientific level of knowledge or goal can go out and start learning about the world. We wanted to standardize the tools so we could start to focus on the projects in the field and getting the critical data that was necessary for the scientists and conservationists.

Five (5) FieldKit Water Quality buoys measuring pH, water temperature, conductivity, dissolved oxygen, and water depth (using a pressure sensor at the end of 8 meters of cable - which was a requirement since the change in water level between the wet and dry seasons can remarkably be up to 8 meters of flooding).

The photos above were of a few of the systems in their final integration, before we left them in Miami for the trip to Ecuador. Later project logs will cover the construction of these and some of the changes that we will undertake from the lessons learned over the last few weeks.

The plan was to take this hardware out to Quito (Ecuador) for the 2018 AQUATROP conference, where the team behind the Amazonia project had a large scientific representation. There was a showcase where the FieldKit sensors were deployed and many additional implementations were discussed with future partners.

Our partners for this first deployment (seen in the photo above) is the Tropical Rivers Lab at Florida International University. Every Conservify project partners with scientists (either at a university, government, NGO, or even citizen scientists) to handle the specific scientific questions around the technology we develop. This can be things like where to deploy, what to measure, and the specific requirements around the data we need. Getting the scientific question correct is fundamental to the technology development pathway.

Over the course of this project, we will outline some of the other work we are doing with other FieldKit partners and the expeditions that we go on during the development and deployment.

We sent out for the panels for the handheld version to a New Zealand-based PCB supplier that Dan had worked with in the past. This is both for the main MCU and sensor board. They are separated (as Jacob mentioned in an earlier post) so we can mount the sensor board close to the enclosure for more accurate readings. Those sensors measure temperature, humidity, ambient sound, and ambient light.

Jacob has been pulling together the component orders for the pick-and-place machine, which has been an interesting exercise. We have only hand-built PCBs before so our quantities were much lower. Once you start looking into reels and trays of components, the numbers can really add up. Fortunately the common providers like Mouser and Digikey have smaller sub-reels that would be perfect for the runs we plan to do here at the DesignLab. We are still finding the right balance on quantities since we are not in full production yet.

For all the other sensor boards (water quality, weather, etc), we are still ordering the trusty purple boards from out friends at OSH Park. They have been fantastic supporters of FieldKit since the Open Hardware Summit last year.

Product Design Ideation

I have been working a lot on what the look and feel of FieldKit should be as we get into the enclosure design. Jacob and I both come from engineering backgrounds, so some of these industrial/product design stuff is new to us and we were really excited about those opportunities that would come out of the DesignLab residency. I already had a fantastic chat with Majenta and Giovanni about best practices around designing a product like that. The plan is to start on the handheld version (what we frequently call the "Naturalist") and design some solid 3D prints of potential enclosure designs that we can touch and feel. Using those, I will ask for feedback and we can discuss which one meets the feel that we are seeking for FieldKit in general. As these are to be used out in the field, we want them to have an outdoorsy vibe (much like the stuff that Best Made does so well):

We also want the product to follow the branding that we have built for Conservify and started to develop alongside FieldKit partners Office for Creative Research (which, tragically, is no longer around) and the National Geographic Society. For those who haven't been following along for long, FieldKit came out of work we had done with OCR since 2014 as part of the Okavango Wilderness Project. That project came out of a collaboration between a few National Geographic Explorers to bring live data from the field during a biodiversity survey expedition in Botswana's Okavango Delta (more here and here). The branding and color schemes (as currently stands) looks like this:

Finally, there are some functional characteristics that we want for this handheld version. These are:

It needs two buttons (one to reset the device and another to start the wifi hotspot). We have also been exploring some options on simplifying that to one button and way the devices responds to actuation.

There needs to be external access to the SD card (to replace/remove) and micro USB plug (for charging and programming)

The device needs to be designed for outdoor use and appropriately ruggedized

There might be some potential for interesting mounting options, like a tripod mounting point or loops/slots that allow you to attach the device for in situ measurements.

The design should influence the user to hold the device in correct orientation for best sensor readings

Some level (TBD) of waterproof or weather resistant protection should be included

Happy Monday everybody, hope you’re ready for another update! Things were fairly quiet this week as Shah was in Washington DC for the National Geographic Society Explorer festival. My focus was on the preparation for scaling up the manufacture of our FieldKit Naturalist boards.

We have two goals on this front. The first is the assembly of a panel of boards using the pick and place machine at the DesignLab and the second is having the capability of sending away for assembled boards from a 3rd party. In order to be ready to send away for a panel of PCBs, a quick design review was necessary.

Design Review

Before:

After:

This was fairly straight forward as we have some working prototypes that I hand assembled in our lab and so we have pretty high confidence in our current board design. We did make some changes, though:

Drop the break-off sensor PCB feature in favor of two separate boards. We had originally intended the break-off design to be useful for STEM settings. Given the relative infrequency of that application when compared to the pre-assembled scenario we opted to just commit to two separate boards.

We increased the separation between the Micro USB and the SD card. The gap between the two was fairly narrow and we were worried about having thin areas on the enclosure.

The USB connector was nudged further out so that the board didn’t need to seat right up against the wall of the enclosure.

Adding fiducials for the pick and place machine. Dan suggested three of them, and that they be as far from other circular features as possible to avoid confusing the CV of the machine.

One of our sensors, the SPH0645 MEMS Microphone, has a very strange footprint. The microphone port itself is on the bottom of the chip and so the PCB needs a drill to expose the port. In addition, the chip’s GND is a ring around the port, as you can see to the right. I was worried about solder paste being applied over the top of that drill and potentially sealing off the port. We decided to change the footprint to be more “stencil friendly” by placing some rectangular SMD pads in a way that overlaps the GND ring.

Ensure we have as few through hole components as possible. These greatly increase the cost of assembly. Thankfully this board doesn’t have any of those.

I asked Dan about the possibility of moving to a 4-layer board and he insisted we stay with 2-layer as long as possible due to the extra cost of more layers.

Another optimization he suggested, specifically for future boards, is using resistor arrays when possible.

BOM Preparation

In ramping up for the pick and place we need to begin ordering pick and place friendly parts - reels and trays. We try and keep all of our BOM information in our schematic files. This means that going into this process each part already had a supplier name and supplier part number, typically from Mouser. Because many assemblers have their own preferred supplier for basic parts like passives, Dan suggested we keep manufacturer details in the schematic as well.

One of the things I love most about Kicad is how scriptable things are. It was easy to export a CSV of the parts and then fill in MFN (Manufacturer Name) and MFP (Manufacturer Part) there and then update the fields in Kicad from that. We also have scripts that go over all of our boards and their parts and look for parts with out-of-sync manufacturer and supplier information. We want the authority to be the schematic, but with several boards keeping the details consistent can be time consuming. Scripts help with that.

Soon, I hope to write a project log about our “grouped spread and place” script. This is...

Last week, the Conservify team started their tenure at the SupplyFrame DesignLab Residency! This opportunity is something we've been looking forward to for several weeks and we're very excited. This first post is going to outline the current state of FieldKit and give a brief rundown of the goals we have for our time at the DesignLab. A kind of "state of the project" to set the stage for future updates.

State of the Hardware

FieldKit’s evolution began where many present day electronics projects do, as a series of glued together prototype boards from Adafruit and the internet at large. After a couple years bouncing between various MCUs in the Arduino space for various one off projects we eventually settled on the Adafruit Feather line, specifically those containing the ATSAMD21G chip (their M0 boards). We liked the variety they offered, the compatibility with Arduino tools and libraries, and the trade off the chip made between power and capabilities. It was nice having all the peripherals as well as the memory when compared to other Arduino boards. They became a natural choice as we began prototyping the various FieldKit modules. This post assumes you’re slightly familiar with our project so please read the summary if you haven’t.

This may be a good time to point out that Arduino compatibility is important to us as a feature for two reasons. First, we are hoping to provide a platform people are comfortable hacking on and modifying for themselves and Arduino provides that framework. The second is related, and that is that it's important to us that we have something approachable for STEM related applications.

So, going into the residency we have early versions of the following modules designed and being tested:

Core

Our core module is our most complicated board and was the first one we began designing last year. This board is pretty densely packed for our standards and includes GPS, SD, Serial Flash, WiFi (WINC1500), LoRa, LiPo Fuel gauge and charging, and some other smaller systems.

Atlas

Water quality based on the Atlas Scientific line of sensors. This board has room for five Atlas modules of any kind. We’ve been designing the board to be populated with ORP, DO, pH, Temp, and EC. In the next few weeks we'll also be adding a pressure sensor to this module for depth readings.

Weather

This module is designed to work with the relatively cheap rain/wind weather meters available at a few online retailers. It also has a separate PCB that holds a few environmental sensors like temperature, pressure, humidity and ambient light.

Sonar

A very basic module for attaching to a sonar sensor for water depth readings. This board also has a LoRa module and charging abilities because of certain slim municipal deployments we're anticipating.

Naturalist

This board is effectively a Core board and a Weather smashed together with two other sensors thrown in, specifically an SPH0645 MEMS microphone and a BNO055 IMU. This was originally developed to be a separate module but was merged into a single board to save space and simplify the project. It will also be one of our early focal points at the DL residency as we experiment with enclosure fabrication.

Naturalist is also special because when we designed the integrated single-PCB version we did so anticipating using that as a basis for a new version of our Core board. Core had gone through enough revisions that we felt things could benefit from a redesign.