Posts in Uncategorized

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/10th. 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 FieldKit.org 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 – bradley@conservify.org

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 FieldKit.org 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 FieldKit.org 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?

Power

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.

SPI Bus

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.

The FieldKit Portal

September 25, 2019 Posted by Uncategorized 0 thoughts on “The FieldKit Portal”

Most of the development effort for FieldKit has been focused on the hardware, its firmware, and the app. There’s another component in the platform that hasn’t gotten much attention, because in the grand scheme of human undertakings it’s Just Another Website. It’s what we internally call the Portal.

The portal is where users register and manage their accounts. It’s got tools for administrative tasks and listing, monitoring and cataloging their FieldKit stations. It’s reactive, but primarily meant to be consumed on a desktop because of the data visualization tools the portal provides for exploring the data streaming in from actively running FieldKit stations.

Approaching the development of the portal was done like most of the other efforts. Even though it’s the lowest priority, it’s grown as we’ve needed functionality to support the most important user stories being developed in the mobile app and the firmware. Things like authentication, accepting data from the app and WiFi enabled stations, querying of that data and basic visualization support to allow the team to monitor the data coming from the early hardware. Regardless, we started wire-framing the portal early on, as you can see in these images. Once the User Experience is dialed in and mostly settled, our talented designer(s) start to add color and apply our style guide.

From a technical perspective, the portal looks like any other modern site you’re likely to see:

  • React/Vue. Work on the portal began several years ago and in the interim as our team as grown we’ve come to prefer VueJs for a number of reasons. Some political and some technical. Most of the administrative areas are React and will stay that way as long as their stable, but as new features and feedback from users comes in they’ll be rewritten and brought up to date with the more modern sections.
  • Golang. Arguably an odd choice. Go is a great language though and while certainly prone to some verbosity it’s very fast (and getting faster) and extremely readable and accessible. We have a lot of internal tooling that’s also written in Go and having the easy ability to cross compile has been absolutely fantastic. For example we have several builds that produce binaries for darwin-amd64, linux-amd64 and linux-arm and being able to share tooling code with code that runs on the backend is very convenient.
  • PostgreSQL. An easy choice. PostgreSQL has been a favorite database of many team members for years and continues to get better. Plus, with access to several time series and PostGIS extensions this was the clear winner. It’s also supported on RDS which, while more expensive, gives us some support we don’t need to stress about as much day to day.
  • AWS. Probably one of the most controversial choices on the team. During our discussions about the company values we’ve talked at length about finding an alternative cloud provider that is more green and environmentally friendly. Unfortunately, our institutional knowledge and our use of Terraform for scripting the infrastructure meant we could be far more productive sticking with AWS in the near term.

One technical note that some readers may find interesting is that architecturally there’s actually two separate backend services. The first is monolithic and embodies what most people imagine as the backend. It implements the API, acting as the arbiter of state and business logic. The other, which we call the ingester, is extremely small and rarely modified. It’s job is to accept data from stations and apps in the field and store them on S3. 

One of the main reasons the portal is a lower priority is that it’s the component with the fastest turnaround on development. Hardware has the longest cycle, followed by firmware and then the mobile app. Even though the mobile app is a hybrid and built on similar technology to modern websites, there’s still the process of running on phones and testing on multiple devices and platforms. Today’s web, thankfully, is a much more cohesive platform.

User Testing Insights: How User-friendly is the Design?

September 24, 2019 Posted by Uncategorized 0 thoughts on “User Testing Insights: How User-friendly is the Design?”

An important and critical step in the UX Design process is User Testing. Before we moved too far in the design process, we conducted a usability test to determine if the app was an intuitive, valuable, and engaging user experience. 

We recruited and tested with participants that were both non-technical “amateurs” and technically-minded “professionals” in environmental data collection. During the session, we gave participants tasks to complete using the mobile app prototype and hardware prototype. We measured the user testing with the following metrics:

  • Successful task completion: The percentage of task the participant completes
  • Errors: The number of errors that occur while completing the task
  • Time to complete task: The amount of time it takes the user to complete a task
  • Task satisfaction: How the participant felt about the experience completing a task

Key insights we learned from the user testing:

  • The FieldKit experience is a new paradigm for people who don’t have experience collecting environmental sensor data. The FieldKit experience and terms like “deployment”, “configuration” and “calibration” are not intuitive. The app needed more education and guidance for first time users
  • It was confusing to take the user to the station page before completing the setup process. The hardware setup needed a clearer onboarding experience that concluded with a visible state change upon completion of setup to clearly show that the station was ready to deploy.
  • There was some confusion with the concept of “recording” at the completion of the deployment. We needed a clearer way to introduce the concept of recording data as part of the deployment process, and indicate clearly when the station was not recording versus recording

Key UX Enhancements

  • New app onboarding experience took the user through a more detailed setup showing images and on how to assemble and connect station
  • We created a set by step calibration guide for each module
  • A new design for the station page introducing the concept of recording data as part of the deployment process, and indicating clearly when the station was not recording versus recording