Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, an initiative of Stroud Water Research Center designed to help people 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

Tagged: , , ,

Viewing 10 reply threads
  • Author
    Posts
    • 2020-04-23 at 11:09 PM #14092
      neilh20
      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/

      • 2020-04-24 at 10:43 AM #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.

        • 2020-04-24 at 12:31 PM #14096
          neilh20
          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.

          • 2020-04-24 at 12:48 PM #14097
            Jim Moore
            Participant

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

            • 2020-04-24 at 6:27 PM #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

              • 2020-04-27 at 1:37 PM #14100
                neilh20
                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
                  (edit oops its changed)
                  github.com/neilh10/ModularSensors/tree/release1/examples/tu_xx01

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

                   

                • 2020-05-26 at 1:00 PM #14174
                  neilh20
                  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/1a-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. ?

                  • 2022-09-15 at 2:03 PM #17336
                    neilh20
                    Participant

                      @rogers1313 great to hear of your project from the technical questions thread.
                      This thread on scaling may be of interest.
                      I just posted a lot of links for scaling systems, and I forgot that enviroDIY doesn’t allow too many links in messages. (spam protection I guess).
                      I’m scaling some systems for Tu N California, soley stage gauges at present. If you would like some pointers I’m happy to post some links
                      https://www.envirodiy.org/members/neilh20/profile/

                    • 2022-09-15 at 2:08 PM #17337
                      neilh20
                      Participant

                        @rogers1313 Some other links .. I’m trying four links to see if it passes the spam filter ..
                        https://github.com/neilh10/ModularSensors/wiki

                        https://github.com/neilh10/ms_releases/wiki
                        https://github.com/neilh10/ms_releases

                        https://github.com/neilh10/ms_hardware

                        • 2022-09-15 at 2:41 PM #17338
                          Heather Brooks
                          Keymaster

                            Hi Neil! Jumping in here as site admin to explain about link limits. You’re correct: a common characteristic of comment spam is a large number of hyperlinks. That said, you should be able to post up to 15 links before your post is held for moderation. If you’re finding that’s not the case, please email webmaster@stroudcenter.org so that I can investigate. Thanks!

                        • 2022-09-15 at 5:31 PM #17335
                          neilh20
                          Participant

                            (edit : thanks Heather this is post had got stuck) @rogers1313 great to hear your project (from your posts in the https://www.envirodiy.org/topic/mayfly-v1-1-technical-questions-forum-thread/#post-17333)

                            – thanks for filing your profile https://www.envirodiy.org/members/rogers1313/profile/

                            I’m similar EE/and FirmWare – https://www.envirodiy.org/members/neilh20/profile/ – youre welcome to email me dreictly, but this is also a good place for discussing how to deploy.
                            Matt is also deploying for TU https://www.envirodiy.org/members/mbarney/profile/
                            This thread may be of interest – I’m targeting my fork for easy deployment and reliable delivery of readings .

                            I’m scaling some systems for Tu N California, and documenting some of it through this (but an open source wip).
                            https://github.com/neilh10/ModularSensors/wiki

                            https://github.com/neilh10/ms_releases
                            https://github.com/neilh10/ms_releases/wiki
                            https://github.com/neilh10/ms_hardware

                            For low cell phone service I’m using an android app “Phone Signal” https://inpocketsoftware.com/phone-signal-cell-strength-overview/ for doing a survey.
                            A note, IMHO the core https://github.com/EnviroDIY/ModularSensors works for where there is reliable phone service – excluding some 90% of potential coverage range where the cell signal may be marginal.

                          • 2022-10-04 at 8:49 AM #17366
                            Erik G
                            Participant

                              This is very interesting @neilh20 ! I learnt something new reading up on HEX- and INI-files and it would be of great help with a method like this.

                              I will try your examples and see if I can be of any help.

                          • Author
                            Posts
                          Viewing 10 reply threads
                          • You must be logged in to reply to this topic.