Matthew C Good : Musician, Software Engineer, Hobbyist.

FishApp – Water Change Detection

The other day, I went to the mall with Kristin.  I usually finish up quicker than her, and this time being in possession of a shiny tiny netbook, I was able to code and tweak the water change detection algorithm for the FishApp while sitting on a bench outside of Macy’s.  I had a couple rather confused onlookers.  I may or may not be on a “do-not-fly” list now.

To refresh your memory, the FishApp keeps track of water changes, and gives you a graph showing weighted-age values for the water in your fish tank.  This requires you to pay attention while you’re doing the water change, and to log in to the website and report how much water you changed when.  Well, I want to have the FishApp sense, measure, and publish water changes for me.  To those ends, I designed a system that can measure the water level in the tank over time, report it to a computer, figure out when and how much water was changed, and report that back to the main fishapp web application.  The measurement is done using a Ping))) ultrasonic rangefinder, and data from that (and other sensors) is fed into a computer.

But just how is the computer supposed to figure out when a water change happened?  It’s input is just a string of numbers, and it’s gotta be smart enough to filter out random noise from tank cleanings, frisky fish, the water filter starting and stopping for one reason or another, or any of a hundred other situations.  What to do?

If you’ve read the last post about the FishApp, you know where to start – smooth out the data.  To recap, I have the sensor set to read the water level every half-second, and report it to the computer.  The raw data is pretty noisy:

but if we make new data points from the median of  every 20 samples, things smooth out pretty quickly:

The system should be able to handle this muuuch easier.

The algorithm works by keeping a queue of recent (smoothed) samples.  By comparing the oldest sample with the newest sample, you can get a “slope” value.   On the graph above, for example, it doesn’t take very many samples until the oldest will be just over 600 but the most recent will be around 800 or so, and you’ll have a large positive slope.  Once the algorithm sees this large positive slope (above a certain trigger value), it knows that a water change is beginning, and notes the water level beforehand.  At some point in the process of a water change, I start filing the tank up again, and we see a large negative slope (around 55-60 on the graph above).  The algorithm notes the capitulation and the minimum water level.  If the absolute value of the slope stays low enough for long enough, the algorithm detects a steady state, and calls it the end of the water change.  The “steps” you see on the graph are because I do my water changes bucket-by-bucket, but because the algorithm is using a slope from a queue maybe 10 samples long, it already does a pretty good job of smoothing these steps out, and not getting too confused.

After running the algorithm against the data above, it worked flawlessly.  Take a look at this graph:

The gray lines are where the important steps in the process were detected.  For example, the first gray line @ x=10 is where the algorithm first noticed we were emptying water out of the tank.  It looks late – and it is, but that’s merely a consequence of using a queue of 10 samples to generate the slope.  The actual “before” water level value it uses is not the one at the gray line, but the minimum one in the queue – which is correct (enough for rock and roll).  Then, at x=54, the algorithm detected a large negative slope and decided that we were filling the tank up again.  It started looking for the start of a steady state, which it found at x=121, and it stayed steady long enough that at x=150, the algorithm wrapped up and decided that we’ve done a water change.  NIFTY!

If you think about what is going on here, it’s really calculus, under the covers.  The slope value is the derivative of the function, and we look for the points that derivative changes sign.  But the function we’re using isn’t perfect, and isn’t continuous, and so we’ve got to build in a little extra wonkitude-resistance.  The algorithm has inputs for the size of the queue, the trigger value for large positive/negative slopes, a tolerance value to ignore noise during steady states, and the number of samples to go during a steady state before deciding we’re really done with the water change – so in theory, this algorithm could be adapted and tuned for a wide range of input sources with little-to-no modification.

Right now, the algorithm is coded in python, but I think it might even be possible to do the crunching on the Arduino.  If I did that and wired the Arduino up to an ethernet shield, I could ALMOST eliminate the computer altogether.  I still need the computer to run the webcam, however, so there’s no point in trying to run this code on the chip or anything like that.  But I think it would be possible in theory, if you don’t want the cam server running.

Tags: , , , , , ,

2 Responses

  1. Angela says:

    Hey Matthew, I’m totally digging your projects. Especially the guitar pedal/circuit building. I built a Landgraff Overdrive clone but learned the skills on the fly so I would like to learn more about what I’m building, not just copying a schematic. i.e. I would like to learn how the components actually lend to certain sounds and how to tweak said sounds to make “new” project pedals. I don’t know if you have tried anything outside of building clones, but I was wondering if you would be willing to share some links, knowledge or other info that you use for reference materials. My email is _____@yahoo.com, any advice or information is greatly appreciated. Thanks

    (edited by matt to remove email address. don’t want my readers getting spam!)

  2. matt says:

    Hey Angela, thanks for commenting! I’m going to send you an email on this too, but I wanted to put my comments out here for anyone else who may be lurking.

    To tell you the truth, the Mastodon Dave I’m building is my first pedal. I’m kindof in the same spot as you as far as not really knowing how stuff works. I have a couple pieces of advice though. It would be a good idea just to learn about electronics in general. What a diode does, what a transistor does, how to do some simple circuits. I’ve heard that Getting Started in Electronics By Forrest Mims is really good for that sort of thing. I haven’t read it myself (it’s on my Christmas list), but I do have one of Mims’ other books and it’s AWESOME.

    I emailed my other pedalbuilding buddy Ian, because he’s done a lot more research into it than I have. He’s also spent a lot of time looking at schematics and forums and definitely has a better handle on where to start and what resources are out there than I do. Here’s what he recommended as far as getting started:

    * Sign up for the forums at http://www.freestompboxes.com and http://www.diystompboxes.com/smfforum/. Between those two you can find probably anything you’re looking for. You’ll have a better chance at finding more boutique pedals at freestompboxes since they have an “anything goes” mentality and diystompboxes has a list of pedals that they will not post information on. For a third website I would recommend http://www.beavisaudio.com or http://www.buildyourownclone.com/board/. Beavis has less tech information, but a lot of awesome projects (you have to really search his site to find them though, kind of annoying) and the other is another message board (i hardly go there). For buying parts, http://www.smallbearelec.com is pretty good.

    I’m taking the approach of trying to learn electronics more generally and then how it applies to building pedals more specifically. That way I can use what I learned on Arduino projects and stuff like that.

    It would also be useful to have a basic idea about how sound is represented as voltage in electronics, and some basic acoustics stuff. That way, if you know that a diode only allows current in one direction through it, and you know that a sine wave is passing through it, you should be able to think “okay that’s going to get chopped, so you’ll have peaks only (no valleys), and that will probably sound a little more like a square wave. Buzzy.” Another thing that pedals do a lot is slightly overload transistors, op amps, or power supplies (i think they do the last one, anyway. I could be wrong). Each component is going to respond slightly differently when used outside of it’s normal operating range, and that usually means distortion (higher-order harmonics being added to the signal).

    There you have it. That’s pretty much the entire extent of my pedal-building electronics knowledge. You may have known all that already! Hope it helps. Post a link to your projects if you have them online anywhere. I’m about to start work on my Mastodon again (I was waiting to get it painted but the artist wife is swamped), so expect to see a post or two here on that.

Leave a Reply