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

Sara Damiano

Forum Replies Created

Viewing 10 posts - 431 through 440 (of 460 total)
1 2 3 … 43 44 45 46
  • Author
    Posts
  • 2018-03-02 at 4:22 PM in reply to: SDI12/Software Serial library conflicts: Arduino-based data logger #9365
    Sara Damiano
    Moderator

      I’m sorry, you can’t just update the library, you have to actually open and change the cpp files from both SoftwareSerial and the SDI-12 libraries if you want to use them together. All updating did was remove the warning about ‘util/parity’ (which is now gone from even your verbose log).

      That being said, yes, unless you have a very good reason not to use hardware serial, the hardware serial port on the Mega should do a better job of communicating with the Mini than any software port on the Mega would do. (Always, always, always use hardware serial unless you have no other choice!) If you do that, then you can simply not include SoftwareSerial in your sketch at all and you won’t have any compile errors. The only problem would be if you want the Mini to talk to both SDI-12 instruments and the Mega because the Mini Pro doesn’t have an extra hardware serial port. To get the Mini running with both libraries, you have to open and change the cpp’s.

      You can’t upload your sketch as an attachment without first changing it to a txt file, but you can use the “Add Code Snippet” button and paste the contents of your sketch in there and it will appear in your post as code.

      2018-03-02 at 10:50 AM in reply to: SDI12/Software Serial library conflicts: Arduino-based data logger #9290
      Sara Damiano
      Moderator

        Oh, also, the warning “#warning “This file has been moved to <util/parity.h>.” might be because you have an older version of the SDI-12 library. Try updating it and see if that goes away.

        2018-03-02 at 10:43 AM in reply to: SDI12/Software Serial library conflicts: Arduino-based data logger #9277
        Sara Damiano
        Moderator

          If you want to understand the problem better, there’s a good explanation of interrupts here: http://www.engblaze.com/we-interrupt-this-program-to-bring-you-a-tutorial-on-arduino-interrupts/

          The wiki attached to the EnableInterrupt library also has a lot of helpful information about interrupts and which pins are attached to which interrupt vectors for a number of different Arduino boards: https://github.com/GreyGnome/EnableInterrupt/wiki

          2018-03-02 at 10:37 AM in reply to: SDI12/Software Serial library conflicts: Arduino-based data logger #9276
          Sara Damiano
          Moderator

            Yes, the SDI-12 library will conflict with SoftwareSerial, EnableInterrupt, and every single other library that defines and uses pin change interrupt vectors. This is a known issue. There are notes about it here: https://github.com/EnviroDIY/Arduino-SDI-12/issues/8. There are also lots of places around the web where you’ll find lots of suggestions for dealing with SoftwareSerial conflicts.

            Because you’re using a Mega, by far the easiest way to get around that is to not use SoftwareSerial. The Mega has 4 hardware serial ports. [Serial: 0 (RX) and 1 (TX); Serial 1: 19 (RX) and 18 (TX); Serial 2: 17 (RX) and 16 (TX); Serial 3: 15 (RX) and 14 (TX).] Unless there’s a real necessity to use software to emulate a serial port, you should always, always, always use a hardware serial port. It will be more stable, more accurate in sending and receiving data, has more bit/parity options, and won’t conflict with other libraries. This is true on *all* Arduino boards, no matter what you’re trying to communicate with. Hardware serial is better. I’ve found several instruments that just cannot handle the instability with software port emulation but will work fine on a hardware serial port. (Looking at you S::CAN…)

            If you’re already using all of the hardware serial ports on the Mega, or you’re trying to do everything on an Uno, which has only one hardware serial port (already dedicated to USB programming), the second best thing is to use another library called “AltSoftSerial.” That library is based on timer interrupts instead of pin change interrupts so it’s more stable/accurate than SoftwareSerial and will not conflict with SDI-12 or others. Unfortunately, it only works on very specific pins on each board, so you have to make sure those pins are free.

            If you still really want to use SoftwareSerial, you have to use versions of both the SoftwareSerial and SDI-12 libraries that have been modified so as not to hog the interrupt vectors. Exactly how you modify them depends on which pin you want to use for SDI-12 and for SoftwareSerial. If you’re set on pins 62/A8 and 63/A9 for software serial on the Mega, those are both on port K/PCINT2_vect. So you probably want to tell the SoftwareSerial library that it’s only allowed to control that one vector. Do do this, open the file SoftwareSerial.cpp and find and modify the section defining interrupts like this:

            Then you have to figure out which interrupt whatever pin you want to use for SDI-12 is on, and then find the same section of code in SDI-12.cpp and comment out all the interrupt vectors except whichever one controls the pin that you’re using for SDI-12. If you’re already claiming PCINT2_vect for SoftwareSerial, you will not be able to use pins A8-A15 for SDI-12 because those pins are all on PCINT2_vect. If you make those modifications, you should be able compile the libraries together.

            Just another note:

            The errors saying “Multiple libraries were found for “SD.h”” and “Multiple libraries were found for “Adafruit_Sensor.h”” have nothing to do with SoftwareSerial or SDI-12. Go thorough your library folder and delete those duplicate libraries or you might get some unexpected errors or oddly behaving code. If you’re shopping for an SD card library, I prefer SDFat.

            2018-02-19 at 5:37 PM in reply to: Problems compiling Logging_to_EnviroDIY example in ModularSensors #6280
            Sara Damiano
            Moderator

              Oops, delete the “@>=0.6.7” after ModularSensors. That’s the version that I’m working on and it hasn’t been released yet so PlatformIO won’t find it.

              2018-02-19 at 5:33 PM in reply to: Problems compiling Logging_to_EnviroDIY example in ModularSensors #6279
              Sara Damiano
              Moderator

                Great that you’re using PlatformIO; it really is a big improvement over the Arduino IDE!

                Do you mind sharing your platformio.ini file? It should look very much like this:

                The “lib_ignore = RTCZero” is needed for AVR boards (like the EnviroDIY Mayfly). That library is for SAMD boards (like a Sodaq Autonomo or Arduino Zero) that have a clock in the processor. If you don’t tell PlatformIO to ignore the library it will try to build it and you’ll end up with errors like you’re seeing. Also the “lib_ldf_mode = deep” might be needed because sometimes it misses dependencies otherwise.

                2018-02-12 at 3:17 PM in reply to: enviroDIY server not responding to POST #3769
                Sara Damiano
                Moderator

                  Ok, I hate to admit this, but I’m baffled as to why that example is failing. It really should be working. You do need to change the server IP address (DL) on your XBee to 129.123.41.212 because the server’s IP address has changed. Other than that, everything looks great to me… but the server isn’t responding to the request.

                  So, in the meantime, don’t use that example to try to send data to the EnviroDIY portal. Instead, use the EnviroDIY logger library in the ModularSensors library. There are a lot of sensors that the library already supports and we’d love your contributions if you want to add more.

                  To use ModularSensors, you’ll need a whole bunch of other libraries installed. You can get them all here: https://github.com/EnviroDIY/Libraries.

                  The coding structure has changed enough that you cannot just paste the “code snippet” for your site into the example, but it sounds like you’ve already figured out how to get the GUID’s you need, so you shouldn’t have trouble placing them where they need to go.

                  Please let me know if that doesn’t work for you! If you want to try making the post requests by hand, I’d recommend the ‘Postman’ app for google chrome. Make sure you add in the request body; it looks like that’s why your other test to the server failed.

                  2018-02-12 at 10:48 AM in reply to: enviroDIY server not responding to POST #3707
                  Sara Damiano
                  Moderator

                    I haven’t tried running that particular example in a long time, but I don’t think the POST request format has changed since it was first developed. The server definitely *is* accepting data right now; my online loggers have up-to-date data. I’ll go back to that example and see what happens for me.

                    2018-01-11 at 10:42 AM in reply to: Modify SW5V boost to 12V #2476
                    Sara Damiano
                    Moderator

                      I’m sorry I’ve missed this thread until now.

                      I agree that when interfacing with a 12V powered device through the RS485 adapter, there shouldn’t be much risk of frying the Mayfly. I would still go with a separate power boost instead of stripping the resistors on the Mayfly, though.

                      I would *NOT* recommend any RS485-to-TTL adapters based on the MAX485/MAX3485 chip. Getting the timing right for the enables is *really* tricky and I haven’t been able to get it to work successfully at all. I have bought a couple of boards with automatic flow control (looking similar to the one Calvin pictured) and all of them have worked.

                      WRT Modbus communication, I have not tried to interface with In-situ probes yet, but in working with other sensors I found the ModbusMaster library to be really confusing. I ended up writing my own library to handle modbus interfacing with sensors. It’s specifically written with someone who knows very little about modbus in mind. That library is on GitHub if you’re interested: https://github.com/EnviroDIY/SensorModbusMaster

                      2017-10-06 at 12:42 PM in reply to: Wiring Ultrasonic sensor w/ temp compensator #2357
                      Sara Damiano
                      Moderator

                        I’m sorry, I’ll have to look into why you’re getting some values that are too high.

                      • Author
                        Posts
                      Viewing 10 posts - 431 through 440 (of 460 total)
                      1 2 3 … 43 44 45 46