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

Shannon Hicks

Forum Replies Created

Viewing 6 posts - 521 through 526 (of 526 total)
  • Author
    Posts
  • in reply to: Mayfly USB Connection Problems #1530
    Shannon Hicks
    Moderator

      The power switch on the Mayfly is a DPDT switch that has 2 functions. One pole switches the power input line to the main processor power rail, and the other other pole switches the power supplied to the FT232RL USB chip. So if there’s a defect in the switch mechanism on only one of the poles, it’s possible that the Mayfly will still power up and perform normally but the power for the USB converter could be intermittent. If you’re continuing to have problems with the switch, I’ll send you an email about how to resolve this.

      in reply to: Mayfly USB Connection Problems #1514
      Shannon Hicks
      Moderator

        I’m not aware of any other issues with the power switch or USB connectivity. What operating system are you using? And did you buy the Starter Kit that comes with it’s own microUSB cable, or are you using your own cable? I’ve had connection issues with microUSB jack/cable combinations on other devices, so maybe try a different cable and see if that helps. Do you have an FTDI cable or adapter board that you could use to power and program the Mayfly to see if touching the power switch has the same effect?

        Another thing to troubleshoot whether it’s communication or power related would be to put a sketch on the board that lights both LEDs constantly, then disconnect the USB or FTDI cable, and plug in a battery to the LiPo jack. Then you can turn the switch on and keep an eye on the LEDs while touching the switch to see if perhaps there’s a loose connection in the switch.

        in reply to: Datalogger build #1286
        Shannon Hicks
        Moderator

          FWIW, in the past I’ve had a few times where the DS1307 clock on the Adafruit shield would reset to some random time in the past or sometimes even in the future. If I remember right, I think it usually happened whenever I was trying something new with the hardware, so I just assumed it was sensitive to shorts or other weird electrical gremlins. It has only happened a few rare times with the DS3231 on the Stalker in the past couple years. I stopped using the Adafruit shield for deployments where timing really mattered because the DS13007 is so inaccurate at either high or low temperatures that our timestamps would get horribly fast or slow during the either the winters or summers. But if you’ve got a GPRS unit on the logger, you could just grab the time from a time server occasionally and resync your clock every few weeks.

          in reply to: Ultrasonic Stream Depth Sensors #1137
          Shannon Hicks
          Moderator

            I will be assembling a couple of Ultrasonic loggers with a colleague in a few weeks and we will document the process and post it on this site. However, we’ll be using the Seeeduino Stalker v2.3 board, so you’d have to modify the plans if you use a different board, or if you’re lucky you might be able to find a spare v2.3 board somewhere online.

            in reply to: Seeeduino Stalker v3.0 discussion #1127
            Shannon Hicks
            Moderator

              The Seeeduino Stalker boards are handy because they are one of the few options on the market that have everything you need for a standalone, radio-reporting, solar-powered datalogger. I have been using them for about 4 years now, starting with a dozen of the v2.0 boards in 2011. They were okay, but there were issues with the supercapacitors used to keep the RTC alive, so I had to remove the caps and replace them with small lithium batteries. They also used an obscure RTC chip that didn’t have much library support or documentation. But one of the best features of the board was that the microSD memory card socket was mounted on the edge of the board, making it very easy to access the card, even when a shield was used on top of the Stalker. I still have some of these boards that are still deployed and working fine. Then Seeed released v2.1 and 2.2 the following year to fix a few of the problems, however there were various problems with both of those versions, but they finally got most of it right with v2.3 in early 2012.

              One of the best features of the v2.3 boards is that they used the DS3231 RTC chip, which you might recognize is the same part used in the semi-famous Chronodot. That’s one of the best options for datalogger timekeeping because it is temperature-compensated. Standard RTC chips like the DS1307 (used on the Adafruit datalogger board) and DS1337 will gain or lose time if the temperature varies much. In the case of the 1307, I’ve had outdoor loggers with the Adafruit board get up to 30 minutes behind during the winter. They also lose time in the summer if the logger heats up. So overall, the DS3231 is a big improvement over the DS1307 and 1337 chips, and I think it’s essential that you have accurate timekeeping in an outdoor logger. Unfortunately, the Stalker V3.0 is using the DS1337 chips (it’s like the 1307, it just has some alarms), so anyone using the v3.0 boards outside is going to have problems keeping the correct time on the logger.

              Another criticism of the board from multiple users, that Seeed said last year they would fix but apparently did not, is that the microSD card holder on the Stalkers is very hard to use. They occasionally break off, sometimes the cards don’t get seated properly in the socket, and if you’re using a shield, you have to remove it to access the card. Supposedly they switched to this design a few years ago because it was hard to access the cards when used in their weather-proof enclosures (the ones that the stalker shape was designed to fit inside), but now they’ve changed the shape of the Stalker so it won’t fit in those enclosures, and the card is still hard to access. And apparently no one has found a good enclosure for the new 3.0 boards.

              And then there are some other little annoyances, like their supplied libraries don’t work right, there are a few errors in the board that are complicated to work around, the documentation is spotty and sometimes incorrect. There are at least a dozen things I could think of that should have been addressed with the new version, but either weren’t addressed or were made worse. And some users are reporting that the new boards use 5 times more power in sleep mode than the previous boards, which would be a major problem for the standalone, sleeping loggers I deploy. And as I’m programming more and more options and functionality into my loggers, I’m running out of flash and RAM, so the limited capacity of the processor is another headache.

              So in general, I think the Seeeduino Stalker v3.0 changed or removed several of the features I liked about the old model, they introduced some new problems, and they failed to address a few of the outstanding user requests. There aren’t many other options out there for similar boards, but it really depends on your requirements. Do you need solar power battery charging? Do you need an Xbee socket? Do you need an SD card? How important is accurate time keeping? You can buy all these things separately, (Chronodot, SD card breakout, Xbee adapter), and connect them to something like a Sparkfun ArduinoPro (Uno’s use too much power, even when sleeping and should never be used for a logger). But if you have the time and patience to work through the kinks of the new Stalker v3.0 board, then it may turn out to be okay for you.

              in reply to: Ultrasonic Stream Depth Sensors #1125
              Shannon Hicks
              Moderator

                Tom, I checked out that new sensor, the I2C interface from Maxbotix is a new feature, it might be handy, but I think the serial output is just as easy to use. My main concern is that the 7040 model is kind of a general purpose rangefinder used for object detection, usually indoors. In the datasheet, it warns that different target sizes will result in different range measurements, even if they are at the same distance. Basically, there is no filtering or target size compensation. The MB7389 model that I use is specifically designed to measure water level, so it has a special filter that returns the largest signal (the water surface), so all other sources of noise and reflections are ignored.

                And most importantly, the MB7389 has internal temperature compensation that is applied at each power-up. Without this, the varying temperature of an outdoor environment will make a non-compensated sensor rather inaccurate. And my recent tests have shown that we need to also use the maxbotix external temperature compensation sensor (only $5) in order to eliminate all of the effects of temperature variations.

                I’ve had many communications with the technicians at Maxbotix in the past year, and they assured me that the MB7389 is the best model for water level measurements with TTL-level serial output, so I would recommend that you try that one.

                The rest of your post on your blog sounds interesting. That’s the kind of content we’d like to have here on this site as well, so you should post it here on a blog post so users here can comment easily on it.

              Viewing 6 posts - 521 through 526 (of 526 total)