Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Using two MB7389s via Grove

Home Forums Mayfly Data Logger Using two MB7389s via Grove

This topic contains 4 replies, has 2 voices, and was last updated by  CECL 3 weeks, 5 days ago.

  • Author
    Posts
  • #12354

    CECL
    Participant

    I’m attempting to use two MB7389 sonars on one Mayfly. My code works if I connect one sonar via grove to D10/11 and the other to D18/19 on the digital 20-pin header (see code below, derived mostly from the example sonar sketch). However, I would like to attach both sonars to the Mayfly via grove cables (e.g. D10/11 and D6/7) but the board crashes and loops the set-up endlessly if I change the numbers at lines 24 and 26 to 6 and 7. I’d greatly appreciate any help getting two grove connections working.

  • #12355

    Sara Damiano
    Participant

    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.

  • #12357

    CECL
    Participant

    Thanks for the response. I have looked over the ReadMe but am very new to this all. Do you have any recommendations for which serial input library to use or how to modify to allow two grove connections?

    Alternatively, I could continue using 10/11 and 18/19 – is there a suitable and easy way to securely attach (for remote deployment) to 18/19 you could suggest?

  • #12358

    Sara Damiano
    Participant

    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.

  • #12360

    CECL
    Participant

    Thank you very much for the suggestions. I’ve decided to go with 10/6 for one sensor and 11/7 for the other – a very easy solution! I’ve also switched to using the parseInt stream function. Thanks again.

You must be logged in to reply to this topic.