Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Reply To: Geographically Scaling Modular Sensors

Home Forums Mayfly Data Logger Geographically Scaling Modular Sensors Reply To: Geographically Scaling Modular Sensors

#14098
Matt Barney
Participant

Hi Neil,

Thanks for opening up this important topic, and for sharing your work!

This idea of scaling up one’s Mayfly installations is really coming to the fore at my organization, Trout Unlimited (TU). My colleague Jake (@jlemontu-org) has been working with Stroud for a couple of years now to deploy Mayflys with volunteer groups in Michigan, Pennsylvania, and elsewhere. Last fall I joined forces with Jake to begin making customizations to the code and building our internal capacity to assemble our own monitoring stations and conduct trainings without imposing additional load upon the time and resources of our partners at Stroud.

Once we refined our monitoring needs and began to deploy our code to multiple stations, we quickly realized that 90%+ of our stations will have the same configuration of sensors; the only differences between the stations’ firmware are the UUIDs, Station ID, etc. Using some kind of config file on the SD card would alleviate the need to rebuild the code for each new station. And if we had that capability, we would avoid the risk of inadvertently introducing changes to the binary (due to library updates and dependency changes on whichever PC the code was rebuilt).

Second, it’s not feasible for us to train a number of our folks, who are dispersed nationwide, to be proficient with the development stack (VSCode, PlatformIO, and ModularSensors). It’s not hard, per se, but there is a learning curve. So it makes a lot more sense for me to centrally manage our source code (and to document when it changes), and to build and distribute a binary (.HEX file) for installation by a local staffer or trained volunteer. That process (using avrdude to install the .hex) is a much easier lift than setting up a development environment and building from source code, for a majority of folks.

As we work to expand the use of this awesome platform among our volunteer chapters, as well as our scientists and stream restoration staff, these kinds of scalability features are critical, and I’d like to see us — the EnviroDIY community — bring them into the mainstream of the Mayfly ecosystem.

Looking forward to more discussion and idea-generation here!

Cheers all,
Matt Barney,
Trout Unlimited