Reply To: Using two MB7389s via Grove

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.