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

Sleep code not working with Maxbotix 7389

Home Forums Mayfly Data Logger Sleep code not working with Maxbotix 7389

Viewing 9 reply threads
  • Author
    Posts
    • #13444
      Marion
      Participant

      We have a project which requires only reading a Maxbotix 7389 and using the result to trigger taking a water sample.

      With cold weather we have started getting bad (300 mm) data values sometimes. We were using pin 18 to supply the Maxbotix power and pin 19 to read. Sleep code worked fine. But, we would like to test supplying power to sensor continuously from an external power pack. This resulted in the sleep code not working. The sensor just takes data one point after another and does not sleep. Have installed the new EnviroDIY_SoftwareSerial_PCINT12 and EnviroDIY_Sodaq_PCINT0 libraries (removed old libraries) but whenever the sensor is supplied continuous power, the board still will not execute sleep code). Any suggestions?

    • #13448
      Shannon Hicks
      Participant

      Sara is probably the best one to comment on the code aspect of your question, but hardware-wise, you might want to try a different pair of pins for connecting the sensor. D19 is used as the status pin of the Xbee socket, and is used in all of the code examples we use for radio, wifi, and cellular telemetry. D18 is kind of reserved for being used as either the card detect pin of the microSD card socket (if you enable SJ10), or you can use it for reading a trigger from the RTC via SJ6. So picking a pair of pins that’s totally free would be good in case you want to add telemetry or other features to your board. D4, D5, D6, D7, D10, and D11 are free, which is why I put them on the Grove sockets. The other digital pins that are available on the 20-pin header are bought out for compatibility with things you might put on a protoshield, but aren’t necessarily free for any sort of output or input from a sensor or other device.

    • #13451
      Sara Damiano
      Moderator

      Can you post your code? I can’t help much with the sleeping issue without seeing your code.

      The issue with getting those 300mm values back from the sonar is an issue with the sensor/installation itself not the code. The sonar will report its blanking distance (300 or 500 depending on the model) anytime something is too close to it to get a real reading. Usually the thing too close to the sonar is condensation on the sonar itself. You’re probably seeing it a lot more in the winter because of the difference in temperature between the sonar/Mayfly box and the outside air. Having the sonar in a pipe over the water might make it even worse. It’s also possible that the sensor is just dirty, but if it’s alternating between blanking distance and good values, it’s probably condensation. In most of our newer code I re-read the sonar up to 25 times if it’s reporting 300/500, but if there’s really too much condensation on the sensor there’s nothing any code can do to change it. I’m pretty sure the “self-cleaning” feature available on some of the MaxBotix models is a heater to prevent condensation.

      I also strongly recommend switching from the Arduino IDE to PlatformIO. Library management is much easier in PlatformIO – you can keep set up different groups of libraries for each program and not worry about an old sketch breaking because you updated the libraries to use in a different sketch. I know VSCode and PlatformIO can seem a lot scarier up-front, but I promise it’s easier to use in the long run!

    • #13452
      Marion
      Participant

      Sensor works much better in open air suspended over water on a boom. We are now testing taking 10 separate reads at each time interval- for trouble shooting information. Although occasional intervals give 300 for all 10 reads, most of the time bad data occurs in only the first 2 or 3 reads at any interval. We are seeing intervals with some bad data values at a frequency of maybe once per day. We will test going up to 25 reads to see if that solves the problem.

      The code used for testing is in the attached file. This works as desired (sleep code works) when sonar power is on D18 and signal read is on D19. Alternatively works on D10 (power) and D11 (signal). However, the sleep code does not work if sonar power is provided continuously from the 3.3 V rail. We wanted to test effect of leaving power applied to the sonar all the time to see the effect (might clear off condensation from the face?).

    • #13453
      Marion
      Participant
    • #13454
      Sara Damiano
      Moderator

      I put your code into a “code snippet” to make it easier to read.

      You’re listening to the sonar via SoftwareSerial. SoftwareSerial works by means of pin change interrupts. Pin change interrupts wake the board up. While the sonar is powered, it will continuously send out data. So if your sonar is continuously powered and continuously sending out data and you don’t explicitly stop listening and turn off those interrupts, your board will be immediately woken up by the sonar. I’m sorry. If I’d just thought a little harder I could have figured that out without seeing any code. Anyway, if you want to use your code mostly as-is and keep the sonar on all the time, remove the sonarSerial.begin(9600); from your setup and make it the first line of your readSonar() function. Then add sonarSerial.end(); just before the return of that same function. Doing that should prevent the interrupts from keeping the board awake any time except within that function.

      I don’t think leaving the sonar continuously powered like that will help it to stay fog-free unless it actually is a “self-cleaning” module. The 7389 isn’t. Have you actually seen it make any difference? I don’t think we’ve ever even tried.

      You’re not using ModularSensors, but for anyone who might be and notices the keep-awake issue with a MaxBotix, I created an issue for it here: https://github.com/EnviroDIY/ModularSensors/issues/303

    • #13455
      Sara Damiano
      Moderator

      Well, actually, I forgot about the internal data filter. Leaving the sensor always powered will give time for that to come into play. I don’t know if it will help any, though.

      Some thing else I thought about in your code: Even though you’re delaying for a second between calls to the SonarRead() function, you were actually parsing and keeping the first 10 readings the sensor took after power on (about 166ms apart) and just processing them 1 second apart. That’s because as long as the sonar is sending data (which is continuously while it is powered) and you’re listening to it with SoftwareSerial, the characters are being stored in the buffer. Once the buffer is full, they just get thrown away. Nothing comes out of the buffer until you read() it. When you do read it, you’re reading out in the order they were placed into the buffer, even if they were placed there a while ago. The fix I suggested for the sleep will also fix this because the end() will dump the buffer and it will be re-created empty at the begin().

      I doubt going up to 25 attempts will make much of a difference.

    • #13488
      Sara Damiano
      Moderator

      Did the modification I suggested get your board to go back to sleep and stay asleep?

    • #13536
      maxbotixinc
      Participant

      Thanks for your use of the MaxBotix Sensors. As such, Sara Damiano’s response regarding the 300mm reported value is correct. This is often caused by object defections or condensation. We offer a self-cleaning version of sensor that provides a more robust condensation solution. Link (https://www.maxbotix.com/product-category/all-environments/scxl-maxsonar-wr-products)

      Should you have any further sensor questions, please let me know and I will be happy to help. The best way to contact us is at the following link ( https://www.maxbotix.com/contact.htm)

      Scott Wielenberg
      MaxBotix Inc.
      techsupport@maxbotix.com

    • #13553
      Marion
      Participant

      We just finished the last of a series of tests of the Maxbotix. With the changes which Sara suggested (close the serial port after each log interval and restart it for each new consectutive interval), the sleep code does work if the sensor is continuously powered.

      Setup: Maxbotix 7389 sensor with the target either stream water or a fixed/flat metal plate approx 1/2 meter on a side. Before all testing (with 2 sensors), the sensor faces were coated with a very thin coating of fluoropolymer grease (very hydrophobic) to help shed any condensation.

      Results:
      1. Sensor mounted over a standpipe in water. Ambient temperature near 20 C. Frequent bad data (300) with normal serial read using code originally supplied by Shannon Hicks. Sensor powered by Mayfly digital pin only when logging.

      2. We suspected that there might be some interaction between the sensor and logger. Tried reading in the serial data with 50 milliseconds delay between each digit. This very slow read out of the data- have never seen this in the literature, gave a partial solution. This eliminated the bad data until fall when temperatures dropped down to about 10 C at night. Then bad data again occurred.

      3. Sensor tested with a boom mount over the water or metal plate with intermittent power, but no standpipe. Results still showed some bad data points, even with traps to reread up to 20 times in the event of bad data. The bad data occurred at random times, when the temps were well above freezing and below freezing. The conclusion is that condensation on the sensor face is not the issue.

      4. The final test was a 10 day test, 5 minute intervals, with sensor continuously powered independently by a separate battery power pack. During that time, the angle of the sensor from perpendicular to the target was varied from 0 degrees up to 5 degrees (to help shed potential condensation if any occurred). During that time, the temperatures ranged from as high as 15 C and as low as -5 C. Absolutely no bad data points were measured during the entire test.

      Conclusions:
      a. We saw no evidence that the sensor had any issue related to condensation during the tests given that there was a hydrophobic coating on the sensor face and that the bad data occurred at random temperatures as opposed to only when the temperatures were low.

      b. Reading out the serial data with a pause between digits rather than at normal speed seemed to help eliminate bad data when the weather was warm. But, this did not solve the problem when cooler weather arrived in the fall.

      c. There was no bad data during the testing of the sensor with continuously power independent of the Mayfly, including at temperatures well below freezing.

      Recommendation: If the Maxbotix 7389 sensor is used and a criterion is to log absolutely no bad data (such as when the data is used to control a pump sampler as we intend), it is recommended that sensor power be supplied continuously by an independent power pack.

      I will be happy to forward or post data files if anyone wants to see the raw data.

      • #13559
        Sara Damiano
        Moderator

        a. We saw no evidence that the sensor had any issue related to condensation during the tests given that there was a hydrophobic coating on the sensor face and that the bad data occurred at random temperatures as opposed to only when the temperatures were low.

        That’s good to know. What was the fluoropolymer grease you used?

        b. Reading out the serial data with a pause between digits rather than at normal speed seemed to help eliminate bad data when the weather was warm. But, this did not solve the problem when cooler weather arrived in the fall.

        I’m not quite sure what your code looked like, but this doesn’t make sense, so of course it doesn’t make a difference. The Maxbotix talks to your Mayfly at 9600baud sending an R####\r every cycle (150ms-ish). That is exactly the rate that the Mayfly listens and records the data in. That’s not a changeable setting. Any “pause” you add in your code is just a pause in reading out from the buffer that whatever underlying serial library you’re using already stored the characters in. No matter the rate you read your data out from the buffer at, the input rate doesn’t change. The only caveat to that is that SoftwareSerial is just pretending to be a serial port and so it’s possible to throw off the character accuracy if the processor is doing too much when the characters come in. The result of the SoftwareSerial errors would be total garbage though (as in not even printable characters), not readings like “R0300\r”.

        c. There was no bad data during the testing of the sensor with continuously power independent of the Mayfly, including at temperatures well below freezing.

        Good to know it works. Good to know. Assuming you’re not manually triggering the sonar every time, that’s the internal range filtering doing its job. I’d guess you could get similar results by powering up the sonar just 5-10 seconds before taking a reading. Based on the spec sheet, it takes 5 readings for the filtering to take effect. It doesn’t specify the maximum number of readings the filtering considers, but the sonar “boots” up in ~160ms and, as long as pin 4 is left floating, completes a reading every ~148ms. So if you power up the Maxbotix for even 10s before you accept readings (10s before opening your serial port that is) it will have already had a chance to take over 60 readings which is probably plenty for good filtering.

Viewing 9 reply threads
  • You must be logged in to reply to this topic.