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

Seeeduino Stalker v3.0 discussion

Home Forums Other Data Loggers Seeeduino Stalker v3.0 discussion

Viewing 13 reply threads
  • Author
    • #1120
      Sam Atkins

        Hi all,

        I am new to the wireless sensor world, and I had a question regarding the Seeeduino Stalker. I noticed while reading the blog posts that Ms Hicks was staying away from the most recent iteration, v3.0, of the Stalker, and favored the previous version, v2.3, instead.
        As someone with a desk full of jumbled v3 stalker boards, sensor bits, and wifi chips, I’m curious if it will be worth my time to continue attempting to build sensors on this platform, or if they will be rendered un-usable in the near future.
        I remember reading a comment on seeeduino’s site mentioning that the v3 stalker uses more power in sleep mode than the v2.3, but I was wondering how much that would really impact sensor and wireless network performance. Thanks in advance for sharing thoughts and/or experiences.

      • #1127
        Shannon Hicks

          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.

        • #1268

            I was inspired by this site to build 27 distance sensors based on Stalker v3 kit.
            The bad things I noticed are:

            the kit contains cylindrical encolsure – no way to attach connectors etc.;

            included solar panel is much weaker than v2.3, it starts charging the lipo battery only under direct sunlight. V2.3 starts to charge much earlier.

            The temperature readings show some strange values even if you copypaste the code from the Seeeduino wiki tutorial. For example, i got readings of -127 degrees. Same code produces correct results with v2.3. Does anyone has suggestion for fix in code? The problem is probably lined to changed RTC chip.

            I need those temp readings to correct distance readings, daily fluctuations during fixed testing were within 2 cm. The correlation with temperature was linear enough and corrections therefore easy to implement if I have the temperature readings.

            In the good side it seems to consume littebit less power than v2.3.

          • #1384
            Steve Roberts

              If you are referring to internal temperature from the rtc chip, there is none on the v3; value of -127 means there is effectively no sensor.

            • #1611

                Hi guys. I was really impressed with your early Seeduino Stalker ultrasonic water level sensor and I have tried to build one of my own.
                I was not fast enough to get hold of your Mayfly so have used a Seeduino Stalker V3 and I have been struggling to get my code to work.
                I have used a maxbotix 7360 sensor and want to try to record the Serial output as I am trying to achieve 1 mm accuracy.
                Any chance you could share the code you used with your Stalker versions of your project?
                I’m Happy to share what I have so far but as I am not really sure whats wrong with it I don’t really know how to fix it.
                It will only print one sample to the Serial output and to the SD card then goes into a coma.
                Also do you think there will be another run of the mayfly anytime soon?
                Any help you could give would be really appreciated.

              • #1614
                Shannon Hicks

                  I’m not sure why your code didn’t post correctly. Maybe because you attached it as a .ino file. Try just pasting it into the “code snippet” box when you’re typing a reply. Just hit the “Add Code Snippet” button in the row of buttons right above the text box, past your code into the window that pops up and choose “Arduino” from the Language drop-down menu so it formats the code properly.

                  Here’s some code that I used a long time ago when using the Maxbotix sensors with a Seeeduino Stalker. In the example, I connected the data line of the sensor to pin D7, then just connect the sensor to ground and its power to 3v3. Communicating with the Maxbotix sensor only uses pin 5, 6, and 7 on the sensor. The sensor outputs a digital string every second when it’s powered continuously. If you only want to take readings periodically, you can power the sensor momentarily with any of the free digital pins on the Stalker since the sensor only uses a few milliamps so the Arduino digital pins can source that. In the following example, it’s powered all the time.

                • #1617

                    Thanks for the help, I really appreciate the well commented code as I really have no idea whats going on without it.
                    I tried your code and perhaps I was having data issues because Of something I did or because of a different sensor but I was getting quite a few out of sync readings that would throw a spanner in the works for using the data later.
                    I have had really good data coming from the code attached here, hopefully between the two options someone may get some benefit out of these options.

                  • #1619

                      Ok so I have the sensor reading well with the code above and I have a sample of the seeduino datalogger that also seems to work but I cant seem to embed one code to the other and have it keep working. it just seems to put the poor little arduino into a coma after taking and writing one sample to the SD card.
                      Ill attach the datalogger code and hopefully some clever person out there can help.
                      this code works well on its own.

                      • #1624
                        Shannon Hicks

                          Did you put a solder blob across the pads of P3 on the back of the board? You’re using INT0 in the code, so you need to close the pads that connect the RTC interrupt signal to pin D2, and according to the Stalker 3.0 wiki, that is accomplished by shorting out P3. I have not used a Stalker 3.0, but I know on the Stalker 2.3, the board would go to sleep after one reading and never wake up again if I forgot to short that RTC INT0-D2 solder jumper.

                      • #1626

                          I have just double checked the jumpers I soldered across P2 and P3 as you say to make sure it was not some sort of dry joint problem and all seems well.
                          The problem I am having it seems is that the software serial is not playing ball after the first sleep, wake up cycle. I have just tried the re allocating sonar onto pin 8 instead of pin 11 and got totally different behavior so will try some more things and give an update. All of the info I can find pointed to pin 11 being free as was pin 8 so I wonder if I am Missing something.

                        • #1627
                          Shannon Hicks

                            Pins 10, 11, 12, and 13 on the Stalker are used by the SPIbus, so if you’re want to use the microSD card socket, you can’t use those digital pins for anything else. It’s been awhile since I looked at the specs of the Stalker, but I think there are very few free pins. That’s one of the reasons we stopped using it and created the Mayfly. And the Mayfly’s secondary hardware serial port makes it easier since you can sometime avoid using the SoftwareSerial functions if you just have one serial device to interface with.

                            The Mayfly boards should be available again on Amazon by this weekend.

                          • #1628

                              Awesome, I will be one of the first to buy one once they are back in stock.
                              The 10 11 pin issue is what seems to have made things screwy all along, Now to go find some free pins, using pin 8 seems to make it cycle through the sleep awake about 4 times before getting another sample. It may still be broken but at least it’s different broken 😉

                            • #14449


                                I’m sorry to dig up this old post but it seems the right place to post. Tell me if it’s better to create a new post.
                                So here’s my problem :

                                I plugged the MB7363 Sonar sensor from Maxbotix to the Seeeduino Stalker v3.1 . I used the analog pin of the sonar (pin 3) and I connected it to the analog A1 input of the Seeeduino Stalker, Vpin to the 3,3v and GndPin to the GND pin, as you can see in the following picture :

                                I also added a 4LED display to show the value of the sonar from the analog input, again, as shown on the picture.

                                Everything work fine this way, but when I want to remove the LED display, the value of the analog input coming from the sonar drops to 0. If I reconnect the LED display, correct value from the sonar start being read again. Thing is that I use the LED display as debug and I need to remove it at the end to put this setting (Seeeduino Stalker connected to a battery) in a closed box. Leaving the LED display will use too much power.
                                So, is there anyone here that have any idea about what is going on here and how can I make it work without the LED display ?
                                Why is my readings on 0 when I have only my Maxbotix Sonar connected ? I tested the same code with the same setup on Arduino Mega and it works fine (with or without the 4LED display)..

                                Here’s the code I used :


                              • #14461
                                Shannon Hicks

                                  Not sure why it’s not working based on what’s visible in the sketch you posted. But I’m guessing there’s something happening in the TM1637Display library that is looking for return data or confirmation from the display in order for the sketch to continue, so without the display plugged into your Stalker, the sketch hangs and stops, rather than ignoring the lost display and moving on.

                                  I’d recommend something like this display: https://shop.switchdoc.com/products/grove-128×64-i2c-oled-board-for-arduino-and-raspberry-pi

                                  It uses much lower power, you can remove it at any time from the board while the sketch is running and it won’t interrupt things. It has a Grove jack on it, so you can just connect it to one of the Grove ports on your Stalker (or our Mayfly) with a basic Grove cable (they come in various lengths).

                                • #14467

                                    Thanks for taking the time to answer me.

                                    I did some others tests, and this became much weirder. So, I removed all the code about the LED display, and still not working (value stay on 0). So I tried connecting the LED display to see how it react, despite the fact there was no code about it. When I plugged the power and ground wire on their respective pin on the Stalker, and one of the two (CLK or DIO, doesn’t matter which) on DIGITAL PIN 9, sonar reads corrects values again… The 4LED does not show any value (of course, no code was written about, and wires are not all connected), but the sonar works..

                                    So I tried something else. I removed the 4LED module, and wired the 5vcc Stalker pin directly to the DIGITALPIN 9. Sonar works and read correct value. Thing is, I don’t know why it works that way. I tried on other digital pins, and it doesn’t work. It’s only on digital pin 9. Is it possible that some trash code is left somewhere on the Stalker and it somehow wait to get signal on DPin 9, or do I have a Stalker that is messed up ?

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