[Sara Damiano]

Hm. I doubt the mid-character times are the problem, but it is possible that the break or marking times are causing problems. You can try tweaking them a bit on the very top of the SDI12.cpp file.

Instead of timing, it’s possible there’s a voltage problem. Do you have the sdi-12 data pin going directly to the Mayfly? Then the power and ground to another battery? The sdi-12 specification actually requires that the voltage of the “spacing” be over 3.5V. The Mayfly is only powered at 3.3V, so it’s not actually ever getting the voltage high enough to meet sdi-12 specs. The decagon and zebra tech sensors I’ve worked with have seemed to be fine with that but the Campbell might not be. Can you try putting a level shifter on the data pin to boost the voltage? I think a standard Uno runs at 5V so you could also try the basic communication on an Uno if you have one handy to see if it works.

[Sara Damiano]

Most of your code looks familiar, though very mish-mash. I’m glad it works.

As far as getting the data into a website or MySql database… Doing that is all going to be the responsibility of your web receiver, that is, whatever website the internet connected radio receiver visits. You have to use your php or whatever set up for that.

Have you looked at the Wiki Watershed/EnviroDIY data portal? http://data.envirodiy.org/ If you are able/willing to have your data publicly viewable, you can take advantage of the structure already in place there to store/view/graph your data. We’ve also created a library to simplify sending data there from many different kinds of sensors, including the Maxbotix sonar sensors. https://github.com/EnviroDIY/ModularSensors. The communication with the data portal in this library is assumed to be via direct internet connection (cell/wifi) but you could also use most of the functionality and set it to another radio instead.

[Sara Damiano]

In short, no. There’s currently no way to send “testing” data to any site and delete those points later. You can create a site that you call testing, test uploads to it, and then delete that site and create a new “real” site, but the new site will have completely new GUIDs and tokens.

[Sara Damiano]

Hm. I’ve done some pretty extensive rewriting of the sdi-12 library in the last month or so. Do you know which version of the library you are using? Can you try updating to the most recent version (1.3.1) if you’re not already using it? Can you post the full serial output your getting from both the address change example (b) and the data logging example (d).

[Sara Damiano]

I’m glad it worked!

[Sara Damiano]

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.

[Sara Damiano]

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.

[Sara Damiano]

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

[Sara Damiano]

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:

C++

// Lines in this block are commented out // because PCINT0, PCINT1, and PCINT3 // are not used by SoftwareSerial for this // project. //#if defined(PCINT0_vect) //ISR(PCINT0_vect) //{ // SoftwareSerial::handle_interrupt(); //} //#endif //#if defined(PCINT1_vect) //ISR(PCINT1_vect) //{ // SoftwareSerial::handle_interrupt(); //} //#endif #if defined(PCINT2_vect) ISR(PCINT2_vect) { SoftwareSerial::handle_interrupt(); } #endif //#if defined(PCINT3_vect) //ISR(PCINT3_vect) //{ // SoftwareSerial::handle_interrupt(); //} //#endif

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

// Lines in this block are commented out // because PCINT0, PCINT1, and PCINT3 // are not used by SoftwareSerial for this // project. //#if defined(PCINT0_vect) //ISR(PCINT0_vect) //{ //  SoftwareSerial::handle_interrupt(); //} //#endif   //#if defined(PCINT1_vect) //ISR(PCINT1_vect) //{ //  SoftwareSerial::handle_interrupt(); //} //#endif   #if defined(PCINT2_vect) ISR(PCINT2_vect) {   SoftwareSerial::handle_interrupt(); } #endif   //#if defined(PCINT3_vect) //ISR(PCINT3_vect) //{ //  SoftwareSerial::handle_interrupt(); //} //#endif

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.

[Sara Damiano]

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.

[Author]

Posts