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

Geographically Scaling Modular Sensors

Home Forums Mayfly Data Logger Geographically Scaling Modular Sensors

Viewing 6 reply threads
  • Author
    Posts
    • #14092
      neilh
      Participant

      Just wondering how other people are deploying multiple Mayflys with the same Modular Sensors and interfaces. I’ve written a blog on how I’m planning on it, so this is a space for responses (I think that is the way it works for the forums).

      https://www.envirodiy.org/geographical-scaling-modularsensors/

    • #14094
      Jim Moore
      Participant

      I am currently working on setting up an array of Low Cost EC sensor Stations in Great Marsh, N. Chester County to monitor UNTs flowing into this large wetland.  My current issues are compensating the raw sensor data to µS and ºC.  See my forum thread.

      I currently have six stations and will probably add more all using the the same operating code.  If I understand what you are proposing is that the UUIDs for each station would be in a file on the SD card which would configure the station code with the UUID for that Station 0nce it is registered on MonMW.  My stations are currently registered as GMI_*

      Do you have any plans for uploading UUIDs via the cellular network?  This would be useful if one wanted to move sensor stations to different locations where a new station would be registered on MonMW so as to create a separate dataset for that location.

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

      8

    • #14096
      neilh
      Participant

      Hi Jim. Thanks for the description.

      What the ‘ini’ reader does is read a file on the  Mayfly microSD card called ms_cfg.ini – in that file is all the configuration information that is specific to a particular node “station” as when the MMW sensor UUIDs are created.

      What this does is allow your .ino file to be compiled once to a .HEX, with no custom UUIDs. All the node specific MMW UUIDs  are then put in the individual  “Stations”  Mayfly microSD files.

      The Mayfly’s mega1284 is a small 8bit microprocessor, and there is very limited networking capability – not like a linux system that has a lot of generic networking. So no there is no capability to push a UUID back onto the  Mayfly.

      On MMW I couldn’t find a way of searching for Sites GMI_*  it needs the Organization to be first specified.

    • #14097
      Jim Moore
      Participant

      Sorry forgot to add the links: GMI_test and GMI_EC1.  The other sites GMI_ECx are currently manual upload.

    • #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

    • #14100
      neilh
      Participant

      Hi Jake

      Good to hear about it. I’d be happy to do a PR on it.

      One of the other areas I believe for scaling for a group is quality testing. For every commercial company I’ve been with, being a able to test and characterize the functionality – that is how well it works – is a big value add to the end defined release. For anybody who works with embedded software for very long, repeatable builds and testing is a really challenging.   So  I’ve also defined a release that can be built simply and downloaded. I’ve put it in “examples”, but I think there should be in a “tested” directory or maybe there is a better name for it.

      ModularSensors/examples/tu_id01  and is at https://github.com/neilh10/ModularSensors/tree/release1/examples/tu_id01

      I’m still not clear on how to manage the repeatable builds with the distributed code environment, but working on it.

       

    • #14174
      neilh
      Participant

      I’m added a new capability for the Mayfly to program its internal EEPROM with geographical specific pieces of information.
      When a site is visited, this will allow the retrieved uSD card to be replaced with a blank uSD card.
      https://github.com/neilh10/ModularSensors/wiki/Feature-notes

      For multiples sites that don’t have modems, and the readings are retrieved on a site visit by replacing the uSD card, I’m seeing the workflow is that the uSD cards are retrieved and stored together.

      The remote site visit workflow would be to keep the the retrieved uSD cards separate from the blank uSD’s.  Back in the office, the retrieved uSD cards are read, and each .csv file has unique geographical and node information on it. The site visit could be performed by one person, and then the person reading the uSD and analyzing the data, would have good traceability that uSD readings came from a specific  Mayfly/geography.

      Just wondering if I’ve covered all information that needs to be stored on a uSD to make it uniquely identifiable. ?

Viewing 6 reply threads
  • You must be logged in to reply to this topic.