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

Upgrading boards at existing locations

Home Forums Mayfly Data Logger Upgrading boards at existing locations

Viewing 2 reply threads
  • Author
    • #17988

        I am going to be changing out a Mayfly datalogger board at an existing location and was trying to figure out the best approach in regard to data consistency. Since the location of the logger and sensors are the same, I will be using the existing UUIDs of the current site on MMW. I want to test out the board before deploying to see if the programming of the sensors and cellular board is correct; because of the testing it will upload data that doesn’t pertain to the site. Can I delete this data from MMW or what is the best approach for this? Thanks.

      • #17991

          @nick IHMO there are few maintenance and ease of use concepts  built into   github.com/EnviroDIY/ModularSensors    & MMW.

          To  make it easier, it takes what Computer Science people call “Use Cases” for how equipment is used in the field. There are international standards for managing equipment maintenance states – however they  take more software infrastructure work!

          I haven’t found any way of being able to set a MWM node to a “test state”, show the test data separately until its determined that its ready for real data gathering. But maybe it will happen some day.

          What you can do is test the parts separately with out POSTs to the “Production” MMW site – that is test with a “dummy test” UUIDs to a test MMW site, and then switch the UUIDs in some form – possibly as a compile option in a ms_cfg.h file. If it compiles and you have eyeballed the data flow, it probably will work.

          I’m a great fan of ModularSensors, and its great strength is interfacing to sensors.  I have extended the software for real world equipment management.

          I put the UUIDs on the uSD as an .ini file and they are read at initialization. I also build a set of .hex programs for my release, and then I can program all the Mayflys with the same features from this one .hex – and the uSD customizes each hardware unit. Data driven design. I discuss it here. https://www.envirodiy.org/geographical-scaling-modularsensors/

          For my replacement board, I test with a “dummy test” of UUIds on the uSD to verify that the board works to MMW.  However it doesn’t upload to the “production” MMW.

          In the field they will disconnect the solar panel, battery, and RS485 shield from the Mayfly. Unscrew/remove the Mayfly from the enclosure. Then they will take out the uSD, which has the personalization UUIDs on it, and plug it in the new Mayfly. Then put the board back together – since this is often in the humid riparian zone, take care to keep sweet out your eyes, off the board – and make sure all the pins of these small devices locate properly!!!  Be interested to hear how you make it work!


        • #17994

            @neilh20 Thank you for all of the info! It makes sense to create a dummy site on MMW so I can test without interfering with the production site. I will let you know how it turns out.

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