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

Matt Barney

Forum Replies Created

Viewing 10 posts - 51 through 60 (of 171 total)
  • Author
    Posts
  • in reply to: MMW not receiving data #15517
    Matt Barney
    Participant

      Thanks @aufdenkampe – really appreciate that update, and all of the hard work by you and the team to fix and document these issues!

      Note that the lost data appears to extend beyond May 7th, with very large data gaps each day from the 8th through 12th. The images attached below show these data gaps for 3 of our sites, with the UTC timestamp when datapoints resumed and the duration of each outage. I’m assuming these data are lost too.(?)

      Matt

      in reply to: MMW not receiving data #15512
      Matt Barney
      Participant

        We are also seeing the data gaps that I believe @thomas-schanandore and @movingplaid have reported above across all 3 of the stations that I’ve checked.

        In particular, there are large gaps (9- to 24-hours) every day since at least May 5th, followed by data resuming at 12:30UTC across every station. This suggests that something is failing on the server and that an intervention is being done to fix/restart it every day sometime shortly before 12:30UTC.

        I’m attaching a screenshot that shows the UTC timestamps marking the end of each data gap since May 1st for 3 of our stations, where the data gap is of duration greater than 1 hour.

        Matt

        Attachments:
        in reply to: MMW not receiving data #15492
        Matt Barney
        Participant

          Hi All,

          Just checking in to see if there is any news about the status of MMW. I haven’t been able to find relevant issues in the ODM2 Github site, so thought I’d share here what we’re seeing on MMW:

          • The big Download Sensor Data button returns a Server Error (500).
          • No sparkline plots are displayed.
          • The 3 buttons for each variable are disabled: Open in TSA, Download, and View Table.
          • Site Alerts are being sent out by MMW for all our sites, though the data is apparently getting uploaded.
          • TSA won’t display charts beyond the morning of 5/1 UTC (e.g. Bear Creek).

          Thanks,

          Matt

          Trout Unlimited

          in reply to: Hydros-21 Depth Temp Compensation #15383
          Matt Barney
          Participant

            Hi Dan,

            I’m curious whether it’s possible to identify Gen 1 vs Gen 2 Hydros21; are they labeled? I’m wondering what I’ve got.

            Thanks,

            Matt

            in reply to: Meter Hydros 21 address #15363
            Matt Barney
            Participant

              Ok, I see. Thanks so much for taking the time to provide all these details – very helpful!

              Best,
              Matt

              Trout Unlimited

              in reply to: Meter Hydros 21 address #15360
              Matt Barney
              Participant

                Thank you both for those details!

                So to be clear: if I have only 1 SDI-12 sensor on the bus, and it’s at address 0, it should work properly with ModularSensors, even if I’m averaging 6 readings and collecting conductivity, temp, and depth each time. Is that correct?

                in reply to: Meter Hydros 21 address #15357
                Matt Barney
                Participant

                  Thanks Anthony. That warning is pretty clear. But I wonder why that’s a constraint.

                  It looks like “0” is a valid address according to the SDI-12 spec, and Meter supports it. Perhaps there’s something in ModularSensors that doesn’t like it. Scanning through the code, I don’t see anything right off.

                  Matt

                  in reply to: Testing power consumption #15345
                  Matt Barney
                  Participant

                    @srgdamiano
                    Hi Sara, any advice on the question above, about powerUp/powerDown vs. wake/sleep?

                    Matt

                    in reply to: Testing power consumption #15304
                    Matt Barney
                    Participant

                      Thanks to both of you for your responses! I think I had just figured out the cause of my problem right about the time you were posting them, but needed to continue refining and testing my code before replying.

                      What’s working now is:

                      1. In the sensor’s setup() function, set trigger pin to an output
                      2. at powerUp(), set pin HIGH
                      3. at wake(), run the wiper (set pin LOW, wait 50ms, set pin HIGH)
                      4. at powerDown(), set pin LOW

                      The wiper cycles as expected and sleep current is <0.7mA. The only exception seems to be that when the Mayfly wakes up at the first measurement cycle (not at startup), the wiper doesn’t run as expected. At all subsequent measurement cycles that I’ve watched, the wiper cycles properly.


                      @srgdamiano
                      Sara, which of the following functions would you recommend as a best practice for where to change the pin value described above, at powerUp and powerDown, or at wake and sleep?


                      @neilh20
                      That’s funny on the FTDI cable (well, funny in hindsight) – ouch! 🙂

                      Best,
                      Matt

                      in reply to: Testing power consumption #15294
                      Matt Barney
                      Participant

                        Trying to track down and eliminate my my Mayfly’s excessive power draw during sleep, I rebuilt my circuit to use the Mayfly’s onboard ADS1115 via voltage dividers, but got the same results; my sleep current is still around 6 mA. However, I discovered that if I disconnect the Turner’s wiper trigger wire from D10, sleep current drops to around 0.5mA.

                        To initiate the Turner’s wiper cycle, you pulse its trigger line low for 50 milliseconds. My TurnerTurbidityPlus class (code below) derives from Sensor, and its setup() method sets the D10 pin high; then when it’s time for a measurement, its wake() function sets D10 low, delays 50 milliseconds, and sets it back to high. Is this code causing the current drain, and how can I eliminate it?

                        -Matt

                         

                      Viewing 10 posts - 51 through 60 (of 171 total)