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

Mayfly not writing to SD card = possibly a libraries issue?

Home Forums Mayfly Data Logger Mayfly not writing to SD card = possibly a libraries issue?

Viewing 6 reply threads
  • Author
    Posts
    • #15902
      David Lutz
      Participant

        Dear Mayfly community,

        Recently we’ve expanded our terrestrial Mayfly network to include 7 new stations in a research forest in Vermont. We installed 2 stations in the fall and data was logged just fine.

        We set everything up identically, using the same code and the same libraries. Set the RTC, addressed all the sensors. No problem. Checked the data through the serial monitor – great. But for whatever reason, the boards do not log data to the SD card.

        The code is identical, and the libraries on the laptop used to upload the code is identical. The set up is nearly identical. We even took the Mayflys back to the lab and tested everything, and they wrote to the SD card just fine. So, we brought them back out and – nothing was written.

        At this point – we’re stuck. We tried formatting the SD card differently (which is the only thing that we think could possibly be the difference) and that didn’t work. For some reason, when the Mayfly is allowed to run code, sleep, and awaken and collect data, it is not writing into a text file anymore.

        I’m not sure if this could possibly be a conflicting library issue – since the libraries are updated from time to time. What else could be the root of a failure to write to the SD card from a board perspective? We bought these mayflys as part of a kit, so there is the capacity to use the vertical SD card, but we are not using that. Otherwise, we are quite stumped and any help would be appreciated!

         

        Dave

      • #15903
        BrianJastram
        Participant

          If they wrote to the SD card in the lab but not the field could it be a power supply issue?

          • #15904
            David Lutz
            Participant

              That’s a good thought – the only thing is that we have the identical setup nearby that we installed in November with the exact same battery and solar panel, and those function with no problem. We don’t believe there is a difference in the physical infrastructure that we can tell – so the only difference could be what libraries we installed?

          • #15905
            neilh20
            Participant

              An idea, equipment failure isolation.  (assuming you’ve got the board in a lab location) Possible combinations of the three variable 1) switch uSD and 2) switch Mayfly  3) add separate USB power supply via USB cable.  Does the Mayfly always fail writing to the uSD, even with known working uSD.   That could be that the uSD slot has a failure (effectively Mayfly bad).  I  get a white/red SD card so that I give each SD card a number on the white portion so I can track them.

            • #15933
              David Lutz
              Participant

                A small update for everyone:

                We were able to allow the Mayfly to operate by updating the libraries in our code. We are using some core IDE libraries as well as some EnviroDIY libraries. My sense is that there might be a conflict between the recent update to the SD library, and perhaps a pin interrupt library from EnviroDIY, but I’m not sure.

                One particular clue is that for the mayflys that are not operating when connected to the battery, their RTC clock is also not operational. So, when we pull the SD card, not only is there no file written, but when we check what is written to the serial, the RTC is still set to the date we initially set it in August.

                I’m not sure if Shannon or Sara have any insights into possible issues with library updates and SD card functionality. It writes to the serial when connected to a computer, but just won’t initialize the txt file to write to the external file on the SD.

                Dave

              • #15935
                Shannon Hicks
                Moderator

                  I haven’t had any issues with any loggers not recording data recently or clocks not running, including boards I just programmed this week.  But I use stable libraries from several months ago and haven’t updated them recently.  Are you using all the libraries that are available in our suggested .zip file, found here: https://github.com/EnviroDIY/Libraries  and are you using one of our sample logger sketches, or one that you’re written or modified?

                   

                  • #16046
                    David Lutz
                    Participant

                      Shannon,

                      We had been using the EnviroDIY Libraries as well as libraries contained within the IDE itself. Our code uses sections of the sample logger sketch, but have been built out a bit to combine possible analog sensors as well as communicate with Xbee.

                      I’d be happy to share with you – it’s not super long and you’ll see that it is pretty simple.

                      Another thought I had dealt with power supplies. I know the Mayfly has a 12V step-down in it. We have each of our stations connected to a charge controller linked to a solar panel and a deep-cycle marine battery so that our stations can operate even in the winter time. I wonder if power is entering at a voltage higher than 12V (low 14s) if this might cause an issue.

                      A clue really does seem to be the RTC. When it is not operational and doesn’t retain the date/time, the Mayfly will not write. But we have brand new batteries in the RTC so that’s why we thought it could be a conflict in the libraries somehow?

                      Dave

                  • #15936
                    neilh20
                    Participant

                      Sara captures all the libs specified as part of the release procedure https://github.com/EnviroDIY/ModularSensors/releases/tag/v0.30.0 look for ModularSensors_Dependencies_v0.30.0.zip

                      I’ve not had any issue with 0.30.0.. The tests are heavily utilizing the SD for reliable web delivery, storing them to uSD, before a POST.
                      I do a build from scratch including pulling all the libs when I do a release.
                      https://github.com/neilh10/ModularSensors/releases/tag/v0.30.0.release1_210831

                      Building 210831_1234
                      Dependency Graph

                      |– <EnviroDIY_ModularSensors> 0.30.0+sha.bc3dd0e
                      | |– <EnableInterrupt> 1.1.0
                      | |– <SdFat> 2.0.7
                      | | |– <SPI> 1.0
                      | |– <TinyGSM> 0.11.4

                    • #16092
                      dan@wachusett
                      Participant

                        I am experiencing a similar issue that may be related, although without the RTC issue…

                        • Built with Modular sensors v0.30.0
                        • Data is saved to SD card when connected to computer via cable. RTC time is correct (or close enough)
                        • If I disconnect the board from the computer it fails to wake up or log any data to the SD card
                        • Battery voltage is sufficient (3.88 V, tested with multimeter)
                        • One of my boards was operating fine using a previous sketch and prior version of modular sensor dependencies, so I don’t think its a hardware issue. I am experiencing the exact same problem on 6 boards.

                        I’ve included my sketch below (UUIDs and Tokens have been scrubbed). I have seen sketch examples (DRWI_LTE.ino) where the wake pin is set to 31, whereas I have it set to A7. Perhaps this is the issue? If anyone has any thoughts or suggestions for troubleshooting please let me know.

                        Thanks,

                        Dan

                         

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