Ultrasonic sensors for ATO?

[Bob2bob]

Thinking about making an ATO and was wondering if anyone has used an ultrasonic sensor to measure water level in their sump. Mostly because I already have one lying around but also from what I've read sounds like they are pretty accurate within a cm which is more than fine for my purposes. I'll probably combine it with a float as an emergency shutoff as well.

They're quite cheap: https://www.sparkfun.com/products/13959 so I can probably have all of my electronics for ~$20 and then get a cheap pump as well for a relatively inexpensive ATO.

Just wondering if anyone has done this before or can think of any gotcha's. Off the top of my head before testing, I'm concerned that ultrasonic pings make noise that the fish can hear and that probably is not fun for them. Also, I'm concerned that the sensor will trigger accidentally when I'm doing maintenance. Both of these issues can be offset if I only run the sensor every 30 minutes or so.

 

[Ranjib]

I have not seen one being used. I have personally used e-tape, float switches and optical sensors. I dont know any real risk, as long as you have a second layer of safetynet. Give it a shot and let us know how it went,

 

[Bob2bob]

@Ranjib etape looks really cool and something i was thinking of using but i read that salt creep gets in the way. is there a breakdown of the different sensors you've used on reef-pi with pros/cons anywhere?

 

[Ranjib]

My idea around the etape sensor was to use it in the ato reservoir and use it along with humidity sensor to understand the water evaporation rate and make a self learning ato .

I didn’t write down my experience with different sensors in reef-pi . There are tonnes if experiment I did (and still doing) , and this was just one of them.

 

[TaylorPilot]

It doesn't look too saltwater safe! LOL But it says up to 400 cm distance and 3mm accuracy. You could literally mount it to the bottom of the stand out of the way. As long as nothing gets in its way, it could be a great solution. I know they are really accurate on solid surfaces like walls. I wonder how well they work against water. Especially if there is any surface agitation. Try it and let us know. Like you said, it could be fun and cheap to play around with.

 

[Bob2bob]

Ok, so have a very basic rig set up and so far the early results are promising enough that it warrants a further exploration.

What I've done so far is hook up the ultrasonic sensor to a particle photon and do the bare minimum amount of code to log distance in cms. I then jerry-rigged a little setup on some cardboard to see if the distance it read off the water level was accurate. It seems on what is very early testing that it is accurately reading the level.

It doesn't look too saltwater safe! LOL But it says up to 400 cm distance and 3mm accuracy. You could literally mount it to the bottom of the stand out of the way. As long as nothing gets in its way, it could be a great solution. I know they are really accurate on solid surfaces like walls. I wonder how well they work against water. Especially if there is any surface agitation. Try it and let us know. Like you said, it could be fun and cheap to play around with.

Yeah, I made a fairly tall stand and have a good amount of space between my 40b sump and stand so I'd be mounting it up here if it works. It does present a problem with getting an eventual emergency float wired up that much distance but not really.

 

[tiggs]

The upcoming eKoral controller uses ultrasonic sensors for their ATO, so it's definitely possible

 

[TaylorPilot]

Who says you have to use a float switch? Why not two of these sensors. You can have them cross check. You could also set them so that if the level rises too fast (more than an 1" a minute or so) or rises above a certain level, the computer will know that it likely has something blocking its beam. That way it can be all mounted to the roof of you stand and out of the way. Can even have it send a signal or set off an alarm if it rises about that level you preset.

 

[Bob2bob]

hmmm that's a good idea. Was thinking I wanted a redundant sensor type but now might add a redundant ultrasonic sensor as well

 

[Bob2bob]

After work today I took @TaylorPilot suggestion and added a second HC-SR04 ultrasonic sensor, cleaned up the code and then jerry rigged it to the top of my stand look down at my return section in the sump. I have it set up with IFTTT to log to a google sheet where I'm just tracking the data for now. Going away for a few weeks while it will gather data.

The way it currently works (and I'm super open to suggestions and improvements here since I just kind of did this on the fly) is that every ten minutes each sensor takes 10 readings which are then sorted in order. I take the 4 median readings of each sensor and avg them out. Eventually, I'll use that data to determine whether to turn on a pump or not but for now, I'm just logging the data while I test the sensors out.

I've attached all 80 lines of heavily commented code in a textfile if anyone is interested in doing this test as well. I'm not a firmware or C dev by any means so be nice

Will report back in a few day with preliminary data results.

Here I added the second sensor. Really should get some different color wires and add a few resistors but I'm not an EE either.


Then I "waterproofed" it


and attached it to my stand


now we wait for results.

 

[TaylorPilot]

That waterproofing is epic...lol

 

[Ranjib]

Neat. How the readings distribution looks like? do they vary a lot in between readings? Means are prone to outliers, medians are sometime better. But really depends on the data. Exciting none the less . Keep us posted

 

[Bob2bob]

Neat. How the readings distribution looks like? do they vary a lot in between readings? Means are prone to outliers, medians are sometime better. But really depends on the data. Exciting none the less . Keep us posted

So far the data is a bit bizarre and inconsistent. I've had periods of time where both sensors are seemingly reporting accurate data and times when just 1 sensor is and times when neither are. I'm not quite sure why that is -- could be a hardware issue as i'm not sure I wired this up appropriately with resistors and also could be noise that the sensors are giving each other or something else entirely.

I noticed when setting it up if I didn't add a delay between asking the two sensors to make a reading that the second sensor errored out. I'm going to play around with increasing that delay for now and see what happens. Can't mess with the hardware since I'm away on work as of today but can do OTA updates with Particle which is nice.

EDIT: I did just find a bug where I wasn't necessarily delaying between the second sensor reading and the first sensor doing all of it's re reads so fixed that and will see what happens.

In terms of the data and outliers I'm doing the mean of median readings so I think that should be safe from outliers but let me know if you would do it differently. This is certainly not my field of expertise -- I mostly do front-end work and am SUPER open to ideas here. I just threw something up relatively quickly. I'm currently grabbing 10 readings on each sensor and then sorting them and doing an average of the middle four readings (median 4)

 

[Ranjib]

So far the data is a bit bizarre and inconsistent. I've had periods of time where both sensors are seemingly reporting accurate data and times when just 1 sensor is and times when neither are. I'm not quite sure why that is -- could be a hardware issue as i'm not sure I wired this up appropriately with resistors and also could be noise that the sensors are giving each other or something else entirely.

I noticed when setting it up if I didn't add a delay between asking the two sensors to make a reading that the second sensor errored out. I'm going to play around with increasing that delay for now and see what happens. Can't mess with the hardware since I'm away on work as of today but can do OTA updates with Particle which is nice.

EDIT: I did just find a bug where I wasn't necessarily delaying between the second sensor reading and the first sensor doing all of it's re reads so fixed that and will see what happens.

In terms of the data and outliers I'm doing the mean of median readings so I think that should be safe from outliers but let me know if you would do it differently. This is certainly not my field of expertise -- I mostly do front-end work and am SUPER open to ideas here. I just threw something up relatively quickly. I'm currently grabbing 10 readings on each sensor and then sorting them and doing an average of the middle four readings (median 4)

I think your methodology is preety good. I would expect the the readings fluctuate a bit. Various sensors are prone to various anomalies resulting from environmental or usage influences . How frequently you are polling the sensors ? Mean of medians is a sound strategy , moving average will be even better, and also filter data based on an acceptable window before computing the moving average is a good strategy . For the time being it’s best to take the raw reading and plot them to get an idea of the distribution, that should be help you deciding what’s the best way to compute the final metric

Keep hacking, and thank you for sharing your findings

 

[Bob2bob]

Thanks @Ranjib I really appreciate the input and the motivation. I'm going to do what you suggest and take a step back and just plot the readings to a google sheet for now. Will just curl the data instead of using IFTTT with Particle since that integration seems to not accurately be recording the time.

 

[Ranjib]

Thanks @Ranjib I really appreciate the input and the motivation. I'm going to do what you suggest and take a step back and just plot the readings to a google sheet for now. Will just curl the data instead of using IFTTT with Particle since that integration seems to not accurately be recording the time.

Way to go

particle/photon has adafruit.io integration? there are things like freeboard.io also which provides direct submission of data (aka datalogging) and you can plot/dashboard it there. They also have API to download the data and then you can use R or spreadsheets to do any custom analysis... these are some things i had tried in the early days of reef-pi development

 

[User]

Hi there

This is an awesome little project. Any chance you have a more detailed write-up? I came looking for an ultrasonic sensor to use on my water mixing barrels and this looks like it’ll work great.

Thanks!

 

[Bob2bob]

Been meaning to get back to this but had to put it down for a bit due to work picking up. Maybe after MACNA i will have some time again. I do remember I was getting two different readings between my two ultrasonic sensors though which could have been due to low quality sensors or something else.

 

[Sisterlimonpot]

There was a group of guys that were experimenting with those sensors for ATO purposes back in circa 2012 in the DIY forum of reefcentral. It's been so long but as I recall they proved to be unreliable because of the turbulence of the water surface.

Curious what your findings were.. I'll be tagging along.

 

[Ryan115]

Great project!
I have had one of these laying around for years, and have not gotten around to doing anything with it yet.
One thing to watch out for, these sensors have a 15deg angle. It will be worth checking the math to see how large of a footprint they will have at the height you have them mounted. Anything other than the surface of the water that falls within that cone will give you erroneous results. If you are 24" up, the measurement area will be ~6" diameter.
Also how turbulent is the water surface you are measuring? If it is pretty laminar, you should be ok. Either way your testing across multiple samples should help to negate that as well.