Maxbotix sonar 0 mm readings between "good" readings, other delays

[fisherba]

Using the sketch "mayfly_10_sonar.ino", the serial monitor gives several "0 mm" (and sometimes 9999 mm) readings between the correct distance readings. I tried to change the delay in the sketch (from 700 to 1400), and I hoped that would solve the issue for me, but I am still experiencing as many as 3-24 "0 mm" readings while the sketch runs.

I am using Mayfly v0.3, and I wonder if the constant power for the D4-5 port could be part of the issue?

Also, it seems to take ~20-30 seconds to recognize a change in measured distance, meanwhile the old distance continues to output to the serial monitor (along with the 0 mm readings). Is this an expected behavior?

[SRGDamia1]

I'm working on this right now over in the modular library (https://github.com/EnviroDIY/ModularSensors) but, in short, it's triply finickey.

1 - The sonar itself gives noisy readings, frequently spitting out 300 or 500 (around the blanking distances), and is just not terribly stable. We're pretty sure this is just a fault of the sensor. It also (by design) sends out 9999 or 4999 (depending on the model) when it cannot see a proper reflection because there's nothing close enough or there's too much noise in the reflections.

2 - On the Mayfly, you're reading the serial data from the sonar over a "software" serial port. Faking a serial port with software is not nearly as solid and stable as a real hardware serial connection because it's all about baud and timing, etc. So the software serial port implementation sometimes just misses or mangles the response from the sonar. The sonar sends out several header lines and then the readings as "R####\r". The code in the example is looking for that "R" character and then keeps the next 4 characters as numbers. But it often gets confused because there are several R's in the header lines and the less-than-perfect serial connection frequently either misses or double-reads characters. All of those responses get translated to 0. I'm working on this part right now, but I don't have a good solution yet. I put in some extra print statements to track it for debugging and had it working perfectly, but the very slight change in timing just from removing those print statements made it crash.

3 - Although the sonic has a very low power draw, according to @s-hicks2 when it starts up it somehow causes a glitch in the power on the board. So if you're alternately turning on and cutting the power to the sonar with the D22 switched power pin, it can sometimes cause the whole board to reset or do weird things. Because it does take such little power, you can power it with any of the other 3.3V or 5V digital pins on the board (ie, if you read off of 5 you can power with 4) and that isolates it from the shared power and reduces all the glitching. If you're not turning the power on and off, though, this shouldn't be a problem.

[fisherba]

Hi @SRGDamia1, the sketch at ModularSensors is working perfectly for me. That sketch is clearly turning the sensor on and off for readings (indicated by lights on board), but the workshop sketch doesn't do this. It seems to be constantly reading, which I understand is then recording all of the ill-timed information as "0 mm". I think updating the workshop sketch with the code from the modular set will be in our future. Thanks for the speedy reply.

[SRGDamia1]

I've updated the MaxBotix part of the library (again). I'm finally mostly satisfied with it now.

Just FYI, the red power LED only shows if the power is on to the "V" pins (controlled by #22). If you have the sonar set so it's pulling power from another digital pin, there won't be any indicator whether it's on or off. I've written the update functions for all of the sensors, though, so they first check that the sensor has power before trying to take a reading. If you try to take a reading from a sensor using the modular library and you didn't power the sensor, it will automatically power the sensor, wait one second, take the reading, and then turn the power back off. I'd still suggest separately turning the power on and off, though, if you're using more than one sensor so you can loop through the sensors a little faster and aren't flickering the power as much.

[sgfulton]

To take a single serial reading, you need to power down or ground the trigger pin (4th pin from the right next to the signal pin). To take a single reading, set the trigger pin HIGH for a delay of 1 millisecond, and then set LOW again. The system will send an R####<13> (/R or carriage return). To read the serial input buffer, strip out the R and the /R and convert to integer or float. That reading is in mm.

We have found that taking one second readings for 30 seconds, then averaging the resulting 30-sec median value over 5 minutes gives results that vary about 0.5 cm.

This is only true if a filter is added to the sensor. For our sensor (MaxBotix MB7383 Outdoor Ultrasonic Sensor), we soldered a 100 uF electrolitic capacitor between the ground and Vin pin on the MaxBotix, and then a 10 ohm resistor to the + side of the electrolitic capacitor. The 22 gauge 4-wire shielded cable was attached to these leads.

The system worked equally well with hardware serial on an Arduino Mega and software serial.

[SRGDamia1]

@s-hicks2, what do you think? I like @sgfulton 's way of interfacing with the sensor, but we'd need to re-solder the grove connections.

[s-hicks2]

Sara, the Grove connector on the ultrasonic sensor you're using was only intended for use during the constanly-powered workshop example sketch.
For actual real-world deployments, I put a screw terminal block on the ultrasonic sensor so that the end-user can easily connect wires to whatever pins they want.

I use the sensors in the free-running mode by letting the trigger pin float. I experimented with external capacitor filters awhile back but didn't see much improvement, and after discussions with the techs at Maxbotix, we determined that it wasn't necessary.

For our deployments, there usually isn't any variation between readings that are made in quick succession. I can take 1 reading or 20 in a row, and might only see 1 or 2 mm of variation. So I don't average the readings for very long in order to minimize the time that the logger is awake. Where we see the greater problem in the range readings is cause by temperature variations between subsequent sample periods. If the sensor housing or air has even moderate temperature changes, that will be evident in a change in distance reading on the order of several millimeters. We use the an external temperature sensor connected to pin 1 of the ultrasonic sensor (and mounted to an external, shaded location) to provide a more accurate compensation for the offset problems caused by the air/sensor housing temperature change.

Sara Damiano wrote:

@s-hicks2 https://github.com/s-hicks2, what do you think? I like @sgfulton https://github.com/sgfulton 's way of interfacing with the sensor, but we'd need to re-solder the grove connections.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/9#issuecomment-282401069, or mute the thread https://github.com/notifications/unsubscribe-auth/AFBvGjaIWhT3nzr0no-CW_Y0lmAqpY6mks5rf0KsgaJpZM4MLVBL.

--

---

Shannon Hicks Research Engineer Stroud Water Research Center 970 Spencer Road, Avondale, PA 19311 Tel: 610-268-2153 ext. 267 Fax 610-268-0490 shicks@stroudcenter.org