Posts in Uncategorized

We’re looking for a Community Manager!

May 27, 2020 Posted by Careers, Uncategorized 0 thoughts on “We’re looking for a Community Manager!”

From the outset of the project, we’ve imagined FieldKit as being three things at the same time. First, it’s sensing hardware, open-source and modular and custom-built to be easy to use and durable. Second, it’s a software platform for managing, analyzing and the data that the stations collect. Finally, FieldKit is a place for people who are curious (professionally or otherwise) about the world around them to come together to share, learn, question, and contribute. It’s a community of environmental care.

We’re looking for someone to join our team and help to build this community, to work with scientists, teachers, activists and developers to get the most out of FieldKit. We want the FieldKit community to be built on a shared interest in environmental advocacy, but also on generosity and kindness.

Our mission is to empower everyone to monitor and advocate for the world around them. We know that online communities have historically been unwelcoming places for marginalized groups, and we know there is real work to be done to make FieldKit truly inclusive. We’re inspired by communities like p5.js, Glitch, Adafruit and Hackaday, who have made meaningful openness a priority.

If you’re excited about the opportunity to build the bright and wild future of FieldKit’s community, we’d love to hear from you: Send us a few paragraphs about why you’re interested, and a link where we can learn a bit more about you. We’re particularly interested in hearing from people in the aforementioned marginalized groups, and from people with experience working with communities outside of North America & Europe.

In the meantime, here are some things that make working with FieldKit team special:

Comprehensive health care

Medical and dental insurance for you and your qualified dependents covering 100% of your employee costs, and will also cover 30% of any dependent costs.

Work hours that you can live with

Most of the company gets in around 9am and leaves around 5:30pm, but some of us come in early and/or stay later. We prioritize letting people live their lives and have their downtime.

As community manager, there will be times when you’ll need to be able to take calls or respond to emails in the evenings or during weekends. We try our best to avoid this, but we prioritize being responsive to our community. Part of this job involves planning and running community events, which might happen outside of typical work hours.

Meaningful work

We’re making FieldKit because we care. About the environment, about the climate crisis, about giving people and communities tools for activism and advocacy. We believe this thing we’re making will have a measurable positive effect on people’s lives and on the world around them.

A connection to nature

FieldKit was born in the wilderness, and every year we venture into the field to help scientists, to test our products, and to engage with communities. Working with us means an opportunity to go to incredible places, meet amazing people, and get some mud on your boots.

#FieldKit50: Earth Day Giveaway

April 21, 2020 Posted by Announcements, Uncategorized 0 thoughts on “#FieldKit50: Earth Day Giveaway”

To mark the 50th anniversary of Earth Day we’re giving away 50 FieldKits to scientists, students, teachers, activists and community leaders around the world. *

On April 22nd, 1970, twenty million Americans took to the streets. In parks and in public squares, in front of city halls and state legislatures, they arrived to demonstrate against the impacts of more than a century of unbounded industrial growth. The brainchild of Senator Gaylord Nelson, a junior senator from Wisconsin, the first Earth Day was an unlikely bipartisan success. “The movement,” recalls Robin Wall Kimmerer, “was supported by disparate constituencies: rural and urban, left and right, rich and poor. The earth beneath our feet formed our political common ground.”

In the first Earth Day’s wake came a wave of government-led policy change, which would over three years see the formation of the E.P.A, and the passing of the National Environmental Education Act, the Clean Air Act, the Clean Water Act and the Endangered Species Act. For the one in ten Americans who marched, that spring day in 1970 must have seemed the beginning of a a new era of environmental responsibility.

Five decades later we find ourselves at a crossroads. Industrial activity has, for the most part, continued unabated. Pollution and extinction threaten life in every corner of the globe. Climate change sits before us as perhaps the greatest challenge that our species has faced.

Nelson believed that meaningful change would come through the cultivation of a “concern for the environment so large that it would shake the political establishment out of its lethargy.” We built FieldKit because, like the late Senator, we believe there is tremendous power in collective action. It’s our goal to get thousands of FieldKits deployed across the planet, to empower people everywhere to monitor the world around them. This #FieldKit50 giveaway is out first step toward that goal.

If you’re someone who cares deeply about the environment, and who is actively pushing for change in the field or in your classroom or in your community, we’d love to give you one of 50 FieldKits.

To enter, fill out the form before May 22nd. Tell us who you are and how you’d use your FieldKit; we’ll pick the winners by June 19th.

*Please note that applications are now closed, but we always want to hear from people who are keen to put our FieldKits to work.

A FieldKit LoRa gateway is installed high in a tree in Cameroon

FieldKit goes arboreal in Cameroon’s Dja Reserve

January 12, 2020 Posted by Uncategorized 0 thoughts on “FieldKit goes arboreal in Cameroon’s Dja Reserve”

FieldKit’s Jacob Lewallen installs a LoRa gateway high in a tree on the Bouamir inselberg in Cameroon’s Dja Faunal Reserve (Photo: Peter Houlihan)

Working with the Congo Basin Institute and Peter Houlihan, the FieldKit team is deploying a series of stations in the Dja Faunal Reserve, one of the largest and best-protected rainforests in Africa. The stations, along with a tree-mounted LoRa radio system, will allow researchers to better study the reserve’s unique ecosystem, and will provide much needed infrastructures for Cameroonian scientists and for local communities.

The Place

Dja Faunal Reserve, Cameroon (ancestral Baka territory)

The Tech

The Story

Nighttime at Bouamir camp. (Photo: Peter Houlihan)

If you’re looking for peace and quiet, don’t go to the Congo. Even at night, there is the constant drone of cicadas, the trill of frogs, the chirp of crickets. The escalating screams of the hyrax, the strange bird-like calls of moustache monkeys, the weird electronic beeps of fruit bats. The low hoots of owls, the looping whistle of pigeons, the woop woop woop of a coucal, the kok kok kok kok kok of the Great Blue Turaco. I spent the first nights in my tent awake, listening, parsing, cataloguing

If I’d been able to somehow tune my hearing, to expand its range, the raucous audio landscape of the forest would have filled up even more. Down in the subaudible range I’d hear the rumbles of the forest elephants, low pitched conversations between giants, stretching over tens of miles. Up in the ultrasonic would be the social chatter of cane rats, the quiet courtship songs of moths and, and the radar ping of hunting bats. Somewhere around forty-five thousand times the upward frequency limit of human ears, three thousand times higher than the highest known range of animal hearing (the greater wax moth), I’d find a quite new addition to the jungle soundscape: the chirp chirp chirp of data.

These signals are coming from FieldKit weather stations, installed on two of the Dja Faunal Reserve’s peculiar inselbergs– rocky islands that rise above the dense rainforest. The stations are measuring data about the inselbergs’ unique microclimates, and are sending the information to radio gateways we installed high up in the branches of nearby trees. By later this year, there will be four LoRa gateways in the reserve, which will allow local researchers to easily instrument the forest, tracking its wildlife and learning more about the ecosystem in general.

The FieldKit team makes their way to the top of the Bouamir inselberg. The grasslands on these remarkable rocky outcroppings are home to small herds of buffalo.

Radio has deep roots in conservation technology. In 1894, Alexander Stepanovich Popov demonstrated a device that could detect lightning from more than thirty kilometres away by picking up the radio waves generated by the strike. Recorded on paper rolls, the data points about lightning activity could be used to help the forest service investigate potential fires. As early as the 1950s, scientists began attaching radio transmitters to animals, with the intent of tracking their movement. These radio ‘tags’ emit brief pulses, which are then picked up by Radio Direction Finding (RDF) receivers, which triangulate the location of the signal.

A circuit diagram for Popov’s lightning detector

One of the main challenges in using these technologies for conservation has been a fundamental limit of radio: the relationship between range and power. One of the inherent properties of radio signals is that signal strength is proportional to the inverse square of distance. Moving a receiver twice the distance from a transmitter reduces the signal strength by 1/4th. Moving it ten times farther from the transmitter reduces the signal strength by 1/100th. Put more simply, broadcasting a signal across a wide geographic range requires a lot of power. This relationship will be familiar to anyone who has tried to tune into a community radio station: unlike big corporate stations with high-powered broadcasters, smaller stations typically use less expensive, lower power set-ups, which means their signals are broadcast across smaller areas. When I was growing up outside of Vancouver, I could pick up the college radio station (CITR)… only if I parked my car at the edge of a north-facing bluff.

The radio gateways that we hoisted up into trees in the Dja, and the FieldKit Weather stations on the inselbergs take advantage of a clever innovation in radio that allows for something that seems to go against the rules I just told you: they can transmit over long distances with very little power. LoRa (Long Range) radio manages this trick by compressing information into short frequency modulated sinusoidal chirps (yes, that’s actually the technical term) that can be reliably picked up by receivers up about 10km away. Both the FieldKit weather stations and the LoRa gateways we deployed in the Dja are solar-powered; thanks to to small amount of energy needed to send messages they can keep up their data chatter happily without needing extra power.

Spectrogram of a LoRa chirp

LoRa works best when there is a clean line of sight between the transmitter and the receiver, so knew we wanted to get our gateways as high up in the air as possible. In an urban area this would mean putting hardware on top of tall buildings; in the jungle it meant getting up into the trees. The Congo rainforest is home to some very tall trees, some exceeding sixty meters (about two hundred feet). We had an extra advantage in the Dja because of the inselbergs, which rise above the forest as high as thirty extra meters.

Getting a radio gateway with batteries and a solar panel up into a tree is a delicate task, one that requires careful engineering, a careful eye on safety, and more than a little sweat. Luckily for us, we’re partnering on the Dja project with Peter Houlihan, a conservation scientist and lepidopterist whose area of specialty– the rainforest canopy– sees him spending a good chunk of his life off the ground. With Peter’s help, we were able to get gateways up into a tree on the Mussfelli inselberg and one at the central research camp; on our return trip in April we’ll install two more on the Bouamir and TK inselbergs. Over the coming years we hope to expand LoRa radio coverage to include the entire Dja reserve.

The Congo Basin Institute’s clearest and most urgent goal is to create research infrastructure in Southern Cameroon. In the short term, these technologies will work to attract outside researchers working on conservation, biodiversity, health, and other environmental projects. In the long term, it will support Cameroonian scientists to train with cutting edge technologies, and to plan and lead their own projects in the reserve. Another fundamental objective is to engage the local indigenous community – the Baka People – with the work being done in the reserve. Local knowledge is critical to the success of the Dja project, and during our next visit to the reserve, we’ll be training Baka guides to use the FieldKit stations, and exploring meaningful ways to give people ownership over the project’s long-term future.

Person holding FieldKit product

Welcome to the new FieldKit

January 11, 2020 Posted by Uncategorized 0 thoughts on “Welcome to the new FieldKit”

The FieldKit team is excited to announce the release of in the lead up to our official product launch (coming in Spring of 2020).

Building FieldKit into something that can make a difference in environmental sensing has been a deep passion of ours for years. The team has been singularly focused over the last year to develop hardware and software that fills some of the gaps in the current market and creates a tool that is accessible to all. We have thought deeply about access, modularity, user experience, scientific robustness, and the best ways to create something that can meet the needs of diverse users.

Everything about FieldKit is open source, including the circuit designs, firmware, data visualization tools, and so much more. We deeply believe in the importance of that approach in creating better and more meaningful products. The funding that we received from organizations like the Gordon and Betty Moore Foundation and the National Geographic Society and through winning the 2019 Hackaday Prize is structured to keep this all open forever. We want FieldKit to be yours as much as it is ours.

The Spring of 2020 launch will include:

  • An online store to pre-order pre-built FieldKit hardware
  • Open sensor library, outlining extensive documentation about environmental sensing in general
  • Hardware documentation, designs, and technical specifications

We would love to hear from you. Please let us know what you think and reach out if you’re interested in working with us.

Open for a Reason

November 18, 2019 Posted by Uncategorized 0 thoughts on “Open for a Reason”

Hey everybody! We’re really humbled and gratified to have won the Hackaday Prize, and we’re seeing a lot of interest on this project page! If you’re thinking about hardware you might want to develop in the FieldKit ecosystem, especially sensors, I want to hear from you! We’re not quite at the Arduino level of easy shield specifications and library support yet, but we’re working on it, and we’re keen to help out in the meantime. Drop us a line –

Making Lots

September 30, 2019 Posted by Uncategorized 0 thoughts on “Making Lots”

Outsourcing, Insourcing, and Open Sourcing.

Our manufacturing philosophy is a little unorthodox, but in the interest of helping others who may have similar needs, I thought we’d talk about it a little.

In the VC funded hardware startup world, there’s a certain script, like the Hollywood three-act structure. You’re meant to work your way through prototypes until you have a production-ready article,  and then send that off to China to have a gazillion made for cheap, and then presumably sell them to your gazillion customers and profit. This consumer electronics model is typically taken as gospel. People emulate it because that’s just what the “big kids” do. 

But as the old saying goes, it ain’t necessarily so. When I came to Conservify, my prior two EE related positions had involved not just design but profitably assembling all their own products in-house. This was a real education.

When Conservify bought a pick and place, there was some slack-jawed bafflement and dismay on Twitter. Weren’t we going to use contract manufacture? Well, of course we are, but not for everything, and not all the time. 

When you have a simple product that gets sold to everybody in the same configuration, and you can reasonably anticipate the size of demand, and you have a lot of cash gently warming your pocket, outsourcing assembly can be the right call, but consider :

FieldKit isn’t a single board or product, it’s an ecosystem. It is built from many different pieces that are meant to be put together in such a way as to fill a specific need. At the time of this writing, we have ten different boards working in the ecosystem, we have a list of desirable future modules and other additions which is that long again or longer.

Conservify isn’t a startup. We are a not-for-profit conservation laboratory. If we were to adopt a model where the only things we could make are things which would quickly pay back a production run of thousands, that would prevent us from solving important problems simply because the demand would not be great enough.

Forecasting the future is difficult, but I suspect some of the most important and impactful projects we undertake will involve production quantities of hundreds or even dozens. Not every important problem carries iPhone level demand.

In the Open Source hardware world,  the high unit low margin products are also the ones most likely to be cloned by the unscrupulous.

So I decided that we should be able to assemble everything we make in-house, without losing money. Even if not every product would generate eye-watering profits that way. This guarantees our freedom to explore new projects without enormous financial risks, or huge infusions of cash. It also means if we predict demand wrong, or a contract manufacturer screws up on delivery or quality, we can still fill our orders without losing our shirts. 

So how does this influence the hardware design?

No through-hole. In mass-manufacture, selective solder machines have made throwing a few through-hole components on a board easy. But in artisanal production, the soldering iron is where productivity goes to die. In the whole of the Fieldkit ecosystem of PCBs, there is only one through-hole component, and believe me, I’m still trying to figure out a way to bring that number to zero.

No itty-bitty passives. We use 0603 throughout. Our pick and place could probably allow us to go a bit smaller, but yields would suffer, and rework is the enemy.

One Side Only, Please. No big deal in mass manufacture to put SMD components on both sides of a board, but you pay heavy time penalties when you do it in-house. Doubling the number of passes through the production line has never yet proved worth it. All our boards are populated on just one side.

Modest Panel Sizes. In-House assembly has a certain rhythm; you feed boards to the PnP, attend to any placements the machine can’t deal with (tall stuff, in the case of our machine) and then into the reflow. If your panels are huge, you become the bottleneck, and the machines sit idle waiting to be fed. Ideally, the pick and place, hand work, and reflow processes should all be the same duration, more or less. Adjust your panel size until this is true.

Helpfully, many of these disciplines in design also make boards cheaper to outsource, as well. 

If, like us, you’re developing an ecosystem of boards, try to consolidate your most-used core feature sets onto a very few of them. In our case,  every FieldKit is definitely going to have an Upper and a Radio. Most will have a Backplane. These will doubtless be contract manufactured.

One more thing, if you’re considering insourcing as an interim step before mass production, and especially if you’re considering it as a standard way to do business, you must have a really good testing and programming game.

Break out the important signals for testing in such a way that you can connect an entire panel to a testing and programming jig with ease. Plug it in, Push a button, get a report. Don’t be tempted to skip this, it will chew up vastly more time than you imagine. 

If you sell to customers who put the product out in the middle of nowhere and do not see it again for weeks, as we do, consider performing burn-in testing. Most component failures occur in the first dozen or so hours of operation. Burn-in testing large quantities can really eat up space, but in some applications, it’s worth it.

I hope some of this is useful. Go make good things!

The Journey to Make FieldKit Viable

September 30, 2019 Posted by Uncategorized 0 thoughts on “The Journey to Make FieldKit Viable”

The origin story for FieldKit is similar to the origin story of many projects. A few of us had an idea to do something better than was currently being done so we hacked something together. The first hardware was built on my dining room table, using a combination of Arduinos/Raspberry Pis, development boards, and easily obtainable sensors. The code was quickly taken over by Jacob, on a volunteer basis, to support some of those early tests in Botswana. Jer, and his team in NYC, worked on ways to visualize the data and make sense of it through storytelling. We were all helping a colleague, an ambitious scientist who was interested in trying a new way to do his work.

Over the years the support and funding for FieldKit ebbed and flowed, mostly as a result of the field we work in. Conservation is not a discipline that traditionally accepted the benefits of technology development. Many of the tools that were in use came from repurposed technologies or ecology doctorate projects that spun off into companies. My initial research into conservation technology was part of a small body of work that has spent the better part of a decade trying to change that previous paradigm. It is how my relationship with the National Geographic Society first came to fruition, which ultimately (through folks that I met) resulted in the FieldKit project becoming an idea.

I started Conservify as a mechanism to move that work forward. It is a technology development lab, not unlike others you see in places like Silicon Valley, but we are a nonprofit. All of the work produced at Conservify is completely open source. We also only work in the realm of wildlife conservation and environmental protection. This is important because that means the funding avenues we had for FieldKit are very different than other commercial products that you might see. The lab is funded by philanthropic funding and research grants. That model makes product development very difficult to do, as most of that funding is tied to projects with a defined scope. 

We interface with the open science hardware community (specifically GOSH – the Gathering of Open Science Hardware) and the researchers, companies, and nonprofits that frequent those circles. They face many of the same challenges we face in funding and building something sustainable (both financially and environmentally). But the mission behind open science is so fundamentally important, particularly when working with scientists in the global south. Science is underfunded in just about every country in this world, so the work to create better tools is critically important.

Given that we are a nonprofit, our business model is different than a typical IoT company. We don’t (or more specifically, can’t) charge the same margins on our hardware that commercial entities do. We want people to use FieldKit regardless of whether they are using our hardware or not. Our aim is to engineer lower cost tools and create some easier mechanisms to increase the global capacity at scientifically relevant environmental monitoring. Sometimes that means that we are selling the devices and sometimes that means we are supporting the community in building off our work into something of their own. Given all of these considerations, our team has worked hard to develop FieldKit in the same way that an effective startup would develop their technology. We put the same considerations into user experience, design, and aesthetics that any commercial company would. Just because it is open source and nonprofit does not mean that it has to suck.

As a result, we have documented our costs pretty well. It is important for us to understand the fundraising ahead, so we can get sufficient grant funding to help and cover it. Above you see a small snapshot of our larger cost analysis, identifying the cost of goods sold for a part of FieldKit. Having “low cost” as a key differentiator means that our users are sensitive to the final unit price, and we must make decisions to optimize that. We also have to be aware that our nonprofit doesn’t have the same purchasing power or funding to buy massive quantities of things. It is a delicate balance for us since much of the traditional grant funding we can get isn’t structured in a way that allows us to pay for that sort of stuff. It also means we have an urgent incentive to get FieldKit operating on revenue as much as possible. Not all of that would be necessarily from selling hardware (we are planning to offer other services – such as custom sensor module design and deployment expedition support) but we are still experimenting with what those will be. 

The specific open source licenses that FieldKit will use are also somewhat in flux. Anyone who has developed a product (particularly one that includes hardware, software, and data), knows that this landscape is somewhat convoluted. Despite sitting on the board of OSHWA, I still struggle with wrapping my head around what is best for us. We plan to certify the hardware as open source through the OSHWA certification process but the specific license for that is still being decided. The content of and our Open Sensor Library (a wiki we haven’t discussed too deeply here) wil be published under a Creative Commons Attribution Non-Commercial License. FieldKit data belongs, first and foremost, to the user. But anything that is pushed to will be published under a CC0 designation. The software will likely be published under BSD

But, as I said, we are still evaluating all of this stuff. The plan is to have it decided before the end of the year, well in advance of our public release. If anyone has any comments or ideas about this, I would love to hear them. Please feel free to reach out.

Testing for Wild Hardware

September 29, 2019 Posted by Uncategorized 0 thoughts on “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.

Building a Better Box

September 28, 2019 Posted by Uncategorized 0 thoughts on “Building a Better Box”

As with many electronics products, we started thinking about enclosures later than we probably should have. We had spent a lot of time thinking deeply about the design and style of the electronics, app, and website. Unfortunately, when it came to the case, we just made use of what was easiest. For much of its prototyping lifetime, FieldKit has made use of these commercially available ABS project enclosures that we would modify to incorporate things like buttons and cable glands.    

There are plenty of benefits to using this COTS approach:

  • Inexpensive unit cost and no upfront tooling or manufacturing budget impact
  • Easy to find online, even with next day shipping through Amazon
  • Modifiable if done carefully and correctly
  • Discrete and boring looking, which helps when installing electronics in places where you would rather not have people mess with them

But this approach also leaves a huge amount to be desired. When compared to the amount of thinking that went into the design of the other parts of FieldKit, the act of putting the electronics in a box that looked like the one above felt uninspired. We had constant issues with the modifying of these boxes when adding cable glands, buttons, or adaptor plates. The worst part was the variability in the boxes, even when buying from a single supplier. They were different in color, consistency, hole patterns, and the plastic of the lid (transparent or opaque). They are fragile and crack easily. Finally, in my opinion, they are depressingly ugly and unimpressive. 

Over the years, we have used a number of different off-the-shelf enclosures for our FieldKit (and other conservation technology) deployments. Some of the best to work with are the polypropylene copolymer protective cases like Pelican. They provide protection from impact, water, and allow for forgiving modification for cables and buttons. But they are expensive. So we started to take inspiration from those to think about what a custom-designed FieldKit enclosure would look like.

We wanted FieldKit to feel like it was at home in the wilderness, where much of this hardware was going, and like it was supposed to be a part of it. It needed to be rugged, deliberate, and inspire confidence in the user. We wanted it to be designed thoughtfully, both from an aesthetic feel (to go with the brand ideals we had with FieldKit) and a usability features perspective. We also wanted it to feel somewhat friendly, not intimidating, and not look like it was tactical hardware. There was a lot we were thinking about when developing the model. 

So we started with the same mounting points as our previous COTS enclosure (both for standardization and to provide users options with what seemed to be somewhat standard in the junction box enclosure world) and build out some of the features we wanted. Our first prototype we had printed at Shapeways on an SLS printer to make sure we had the right tolerances and feel to the enclosure.

This design had a few design elements that we were very excited about. It included a replaceable bottom plate that could be custom configured for the necessary cable glands, antennas, or bulkhead connectors for a specific sensor module configuration. This means there is no custom drilling or modifications needed, just laser cut a plate that suits your needs and screw it in place. We had beefy mounting flanges that could accommodate a number of different attachment methods. The lid had a locking mechanism to keep away prying hands.

After considerable testing, we realized that there were things that we needed to change. The gasket channels were not quite right. The clasps could be updated to accommodate more finger types and allow for better experience in opening and closing. We wanted to add a battery holder for commonly found 18650 battery packs, which had implications for the backplane board. We wanted more texture on the lid to differentiate it from just another a generic case. We also wanted it to be easily 3D printable. We are going the injection molding route with this case, but we wanted to provide the designs to anyone who wanted to print their own. 

The next version was much more beautiful and functional:

Module Mayhem

September 26, 2019 Posted by Uncategorized 0 thoughts on “Module Mayhem”

So back in “Origin of Species” I talked about the big-picture hardware architecture of Darwin. Let’s talk a little bit more about the architecture of modules, and why we made them the way we did.

So what don’t we want in FieldKit Modules?

We don’t want to have to manually configure each module.

Please, no jumpers, dip switches, or solder blobs to give them each a special address so as not to collide with another one.

We don’t want to have to tell Fieldkit everything.

Like that a module has been inserted, or in what slot, or what kind of module it is.

We don’t (typically) want to connect modules with cables.

They’re bulky, fiddly in tight spaces, and don’t provide physical support for the systems’ hard-knock life.

We don’t want the module to be powered all the time.

Batteries and Solar Panels are the most common way of powering FieldKit stations out in the world, so power consumption is always a concern. A module should come online at the selected interval,  take a measurement, and shut off. We can’t rely on every future IC or sensor having effective power management on-board.

This is a perfectly lovely set of aspirations, but several of them seem to be incompatible with using i2C, which is ubiquitous. Enter Our Hero : Texas Instruments’ TCA9548 – an i2C Multiplexer. This solves a lot of problems:

Address Collisions.

If each module is an address-space to itself, multiple identical modules can be connected and not collide. Cute, right?

Module Identification.

Since i2C address collision is no longer a thing, each one can have an EEPROM on a known address which contains information about itself, so Fieldkit can identify them in a slick and automatic way. Modules needing calibration can also carry calibration data on that EEPROM, which is nice if somebody, say, moves it from one slot to another, or from one station to another.

Module Detection.

Each ‘client’ side of the i2C multiplexer requires pullup resistors, like any other bus. If you put the pullups on the module, only slots with modules plugged into them will have a high SCL line with the bus at rest, which makes detecting the presence of modules easy.

So what does our final bus look like?


Modules are expected to do their own regulation and obey their Enable pins, so unregulated power and ground are provided. A regulated 3.3V line is also provided for the odd cases where some piece has to stay running even when the rest of the module is asleep. And Enable line is provided to turn the module on and off as required.

EEPROM Protection

A few modules require an onboard microcontroller. In these instances, the easiest way to pass data between modules and FieldKit is to stash it in the EEPROM we also use for module identification. This requires a negotiation line so you can prevent them from trampling all over each other.

i2C Bus

Necessary and ubiquitous.


This is mostly provided as a safety measure. We don’t presently have any modules which require it, but it doesn’t pay to assume we never will.

Mechanical Considerations

Modules have cables connected to them which might be heavy, and we don’t want the leverage tearing headers off the boards, so while we use bog-standard 12-pin male box headers on the FieldKit side for their ubiquity and strength, we use a somewhat less common female header where the pins pass through the PCB via holes underneath the connector. This lowers the center of gravity and available leverage on the pins significantly.

For belt-and-suspenders levels of resilience, we also have threaded standoffs on the backplane, with matching holes in the modules so they can be firmly secured in place. This seems excessive until the first time you drop one from a ladder.