[Sara Damiano]

Oh. Oops, apparently I didn’t refresh and see Beth’s latest response. She has much better detail than me. If you use the default “src” directory, you don’t need the src_dir = in your platformio.ini file. But you can only have a single ino in that folder, so if you want multiple programs for testing, you’ll need to specify the directories.

The two serial libraries are listed separately in the platformio.ini file because ModularSensors actually *doesn’t* require them, but most of the examples do. If you’re working with RS485 sensors and you’re also using some sort of remote communication, you’re almost certainly going to want to be using AltSoftSerial for the Serial communication with the sensors. AltSoftSerial is the best non-hardware serial port I’ve found. The SoftwareSerial_externalInts is pretty awful at best. NeoSWSerial is another workable alternative. There’s more detail in the ReadMe for ModularSensors about the serial port problems: https://github.com/EnviroDIY/ModularSensors#notes-on-arduino-streams-and-software-serial

[Sara Damiano]

I’m sorry for not chiming in earlier.

PlatformIO is definitely a much, much better system for programming than the Arduino IDE. It’s much more powerful and the library manager is very good. I’m running it on Atom (instead of VSCode) but it’s the same beast underneath.

The ModularSensors library is designed to be able to communicate with a whole bunch of sensors and to get the data from them onto an SD card and up to the network. I’ve spent a lot of time optimizing the timing of the variables in the arrays to make it very flexible while minimizing power and data consumption. I decided when I started building the library to create it so that the library itself would not need to be modified by users (ie, no library config file) but that unfortunately does mean that you must have the sub-libraries for every supported sensor installed on your computer in order to compile the library.

The example programs are gigantic and scary because they contain the code for every single sensor that’s supported and a lot of extra notes about each one. You’d never want to really run the examples as they stand.

Ok, so to get going in VSCode/PlatformIO:

– Open VSCode, wait for it to load up. Make sure PlatformIO is installed.
– Click on the little house on the left in the bottom blue bar (open PlatformIO home)
– In the PlatformIO home window, click “New Project”
– A window should pop up – give your project a name, select “EnviroDIY Mayfly” as your board, “Arduino” as your framework, and put it wherever you want on your PC, preferably in a brand new folder all of its own.
– Be patient while the new project is set up.
– Now, look at the new folders that were created (using windows explorer or VSCode). Find the folder named “src”. It will have a file “main.cpp” in it. Delete “main.cpp” (HINT: By right clicking on a file in VSCode and picking “Reveal in Explorer” you can get right to the folder.)
– Download the example you want from the modular sensors library by navigating to it and then clicking “raw” and saving the page as a ino file. Put that ino file in the “src” directory where main.cpp used to be.
– Now, in the folder above the src file, a platformio.ini file should have been created. Open that platformio.ini in VSCode.
– Go back to GitHub and find the platformio.ini from the example and open it up.
– Copy the section under the heading [env:mayfly] from the platformio.ini file on GitHub into the one on your computer. Save the file.
– Gears should start turning as soon as you save the platformio.ini. A .piolibdeps folder should appear and more libraries should appear inside of it. If this doesn’t happen within a minute or so, force it by clicking on the “clean” button that looks like a trash can on the bottom left blue bar. (The clean functionality both removes any pre-compiled library files (these are usually hidden) and downloads any new libraries and their dependencies as listed in the platformio.ini file.
– Go to your ino program. Scroll through it and delete the chunks for sensors that don’t apply to you. Change the sensor addresses and pins to what you really have. Save.
– Click on the check mark in the bottom blue bar. This does “platformio run” – ie, it compiles everything but does not upload. Look for any compiler errors. Hopefully you don’t have any. If you do.. first check for missing semi-colons that you accidentally deleted when customizing your pins. Dig deeper from there.
– To upload to your board, attach it to the computer and click on the arrow button between the check mark and the cloud. If you only have one serial device connected, the upload will automatically try to go to that. If you have more than one connected, you can make sure it goes to the right one by adding the line “upload_port = COM##” in the [env:mayfly] section of your platformio.ini file.
– Check that everything is running smoothly by watching from a serial monitor. You can access the one built in with VSCode/PlatformIO by clicking the button that looks like a power cord in the blue bar. I think all of the examples have the serial port running at 115200 baud.

That’s kind-of whirl wind and not very detailed, but I hope that gets you going, if you haven’t gotten farther than that already on your own!

~Sara

[Sara Damiano]

Huh.. I don’t know why the XBee would entirely stop responding. Does it still respond on XCTU? Could you have accidentally put it to sleep?

So far I have not managed to get my LTE-M XBee to connect to the internet with Hologram’s sims. I get denied service every time; sometimes quickly, sometimes after hanging at “22” (searching) for a long time. I’m having the same issue whether it’s on a Mayfly, connected to a PC and talking to XCTU, or connected to a PC and using a terminal with the USB direct access pins at AT commands.

The same hologram sim works fine in a 3G XBee and my LTE-M XBee can connect to the network just fine when I put in my AT&T sim from my cell phone. But I cannot get the hologram sim to allow connection with my LTE XBee.

[Sara Damiano]

What was the bug you found?

[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?

[Author]

Posts