[Sara Damiano]

Which ADS1115 library are you using? Make sure you’re using the soligen2010 fork at https://github.com/soligen2010/Adafruit_ADS1X15/ – Don’t use the Adafruit original.

[Sara Damiano]

Also posted to GitHub, but so it’s here:

Pins D4, D5, (Timer 1 – 16 bit) D6, D7, (Timer 2 – 8 bit) D11, D12, (Timer 0 – 8 bit) D14, D15 (Timer 3, 16 bit).

[Sara Damiano]

How (physically) are you connecting to the Maxbotix? Are you using a grove-to-male connector into screw terminals on the sensors? Are the sensors being positioned (in the field) in a way that their sonar beams could interfere with each other?

If you want to use the libraries you have and leave your code as is, you could twist your cables up such that the two serial inputs are 10 and 11 and the two excites are any two other pins together on a grove (4/5, 6/7, etc). Just setting the pin mode or pin level high/low does not interfere with the pin change interrupts. In that case bed might be 10 data/6 excite and water 11 data/7 excite. There’s certainly no rule that the pins have to be next to each other.

If the sonars are positioned in the world such that the won’t interfere with each other, you could also completely disconnect the excite pin and just let them free range with the data going to pins 10 and 11. You would need to make sure you clear your serial buffer before each reading, though, or your buffer will fill up and you’ll only be reading out older data instead of the newest point.

Since it looks like you’re also using the PCInt library that’s cropped to just vector 0, if you really want to use a single grove for each Maxbotix, you could instead differently modify SoftwareSerial so that it can control 1, 2, and 3 instead of just 1 and 2. That would allow you to use any pin from 0-23 on software serial. You cannot use the unmodified PCInt and SoftwareSerial libraries together. Or you can drop both the Sodaq PCInt and SoftwareSerial and switch to GreyGnomes EnableInterrupt as your pin change master and then use NeoSWSerial with the interrupts handled by EnableInterrupt instead of by NeoSWSerial directly. (You have to un-comment the appropriate line in the NeoSWSerial library to allow that.) But if what I’m saying doesn’t make much sense, or you don’t feel confident modifying libraries, I’d suggest you go with twisting the wires.

Some other notes on your code:

Using the timer library is unnecessary. You’re setting the board to go to sleep and then wake up when there’s an interrupt. Then you’re setting the clock to create that interrupt every minute. When the clock wakes the board up on the even minute, it will immediately start at the beginning of your loop. It will run through the loop until it gets to the sleep function and then will go to sleep until the next interrupt. You also do a check just in case to make sure that no other interrupt (except the timer minute) sets off any of the interesting code in the loop. So, if you want to rewrite, ditch the timer. Having the timer shouldn’t hurt anything, though.

Also, that code looking for the “R” and then reading the next four bytes looks like code that was at one point on the Maxbotix site, but I think using the “parseInt” stream function is simpler and works better.

[Sara Damiano]

Short answer: you just can’t use on 7 for the Maxbotix using the libraries and sketch as you have it written.

Long answer: It’s a pin change interrupt conflict problem. The software serial library version you’re using is a modified version that only has access to vectors 1 and 2. Pin 7 is on vector 3. The ReadMe for ModularSensors has more details about how to deal with this type of conflict in serial input libraries. I might be able to give more details later if you need it, but that’s the ghist of it.

[Sara Damiano]

The modular sensors library that Beth references depends on TinyGSM for the majority of the cellular connection process. You may want to look at the code and examples in that library for help communicating with the GPRSBee (which is a SIM800 chip).

Unfortunately, I think if you’re successfully querying for csq and only being a response of 0, that probably means you just don’t have any signal. Having amazing 3G or 4G doesn’t mean there’s any 2G at all. Beth has found some quirks to the sequence of connecting the GPRSBee to that could also cause it to falsely report 0 signal. From the ReadMe for modular sensors:

Note for GPRSBee modems: To start the modem you will need to power the logger board off, connect the battery to the logger board, and finally attach the modem to the logger board. Then you may power the board and run your sketch. We have found that attaching a GPRSBee modem to power in a different sequence results in the modem reporting zero signal strength. Note, the Mayfly connected to a computer via USB does not supply sufficient power to the GPRSBee. If the community finds this true for other modems, please let us know.

[Sara Damiano]

I’m sorry, I just looked back at your link from the first page and they mentioned they were using a Mega, which should be 5V. I don’t know. I don’t have any other guesses. Do you have an oscilloscope you can put on the line to watch the communication between the sensor and CR1000? If so, can you share the results of sending a single command to the sensor via the CR1000 and the same command between the Mayfly and sensor?

[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).

[Author]

Posts