Introductory musings

“Fish in the fog. Fish in the clouds. How do people ever get bored? How did boredom even get invented?” – 11^th Doctor

There’s currently three aquaria in the house: a big community tank with blood parrot cichlids, a planted one full of catfish, and a small quarantine for new arrivals or sick inhabitants. This all adds up to a surprising amount of electrical equipment – 5 filters, 4 lights, 3 UVs, 3 heaters, 2 air pumps. Some of this is intentional redundancy but it all need to be functioning for the tanks to maintain healthy conditions. Most aquatic equipment is reasonably reliable but apparently random failures still occur more often than you would like. Sometimes this is obvious and non-dangerous (e.g. lights not coming on, air pump diaphragm splits) but other failures will put the livestock at risk. We’ve had several heaters get stuck ‘on’ rather than correctly thermostating and filter pumps jam or break entirely. No serious loses fortunately but the fish forums have quite a collection of horror stories from those who’ve been less lucky.

Not all failures are immediately obvious and obsessive equipment checking rapidly gets tiresome so we don’t we get some tireless machine to do it for us? Maybe some sort of robot? Something suitably clever could message a mobile if a filter cloged up or post the tank temperatures hour-by-hour on Facebook. That would be nifty! (ok maybe not the Facebook thing, RSS then).

So, what do we want?

Some sort of magic aquarium-monitoring device able to track tank physical parameters (e.g. flow rates, temperature) via various sensors. This data needs to be stored somewhere and be available for display off site. The system needs to support various types of alarm (visual, audible, virtual) in response to dangerous states (filter has stopped, temperature is too high/low) and the parameters for these alarms need also be adjustable remotely.

Since there’s the real risk that the monitoring system itself becomes just another point of failure or annoyance, there are other requirements:

• fail-safe – so a broken aquarium monitor can not kill the fish!
• robust hardware and simple code – reducing the risk of bugs or crashes, easier to add features and functions
• appropriate responses – considering the seriousness of the problem and appropriate choice of alarm type
• auto recovery – from power loss or reset, including updating with modified settings if needed

We keep tropical planted tanks so we’re less concerned about water chemistry than (for example) a marine fish keeper. Similarly, while we could control the lights or CO₂ injection via this device, there are already commercial appliances available that would do a better job. There’s little out there to monitor equipment though, so we’ll focus on physical parameter sensing to address this.

Another set of concerns have nothing to do with equipment or fish and everything to do with people. As researchers, we’re interested in learning new things and teaching them on. This leads to ‘transferable knowledge’, information allowing someone else to build this device – always assuming anyone is mad enough to want to! We also care about having fun, so new approaches and techniques have an implicit value simply by evoking new learning. Novelty need to be balanced with robustness however – a filter flow sensor built entirely from origami would be fun but perhaps not entirely functional.

Finally, the physical stuff. The sensors and the ‘device’ needs to be compact enough to fit in/behind an aquarium cabinet. They need to have a reasonable aesthetic and be rugged enough to survive a high humidity environment. The costs can’t be too excessive (we’re not rich and neither are the catfish, with the big families to feed and all). Minimal energy usage would also be nice as the tanks sink quite enough watts as it is.

Platform 9¾

Our house network consists of several file/web servers, workstations, laptops, excessively-clever phones, xboxen etc. all linked via WiFi or wired to an ADSL line. The easiest option is thus to hook up sensors to one of these devices and either process the data locally or squirt it off elsewhere for processing. However, while such a network is clearly a modern necessity (!) it’s sadly uncommon and we can’t expect all users to have a suitable PC nearby or wish to leave them on permanently.

Consider an architecture that combines stand-alone sensor hubs communicating via Ethernet to a data logging, control and user-interface server. There are significant advantages. It’s flexible, so the sensor node can be almost anywhere as can the server. It can also be ‘many-to-one’ with a single server handling lots of sensor hubs. For the hub hardware, multi-purpose microprocessor controlled prototyping boards are getting increasingly popular. While low in processing capability and memory, they’re relatively cheap, compact and energy efficient. The server that the hubs report to could be piggy-backed on an existing web host, or could use a cloud service like Pachube – effectively being free. Once the data is ‘in the cloud’, what you do with it mostly limited by imagination and coding ability: post it to Twitter, build an RSS feed, SMS message it, write an iPhone/Android app, pipe it to an IRC bot etc.

Technically, there’s loads of ways you could do all this but our chosen approach is to combine the new Arudino Uno with a (Wiznet W5100) ethernet shield. This can either be plugged directly into a cable/ADSL router or air gapped with a cheap Ethernet-Wifi bridge or Powerline modules or whatever. The control/display server could be written in almost any web-able language, but we’ve developing an ‘old style’ PHP/MySQL platform and a ‘new style’ Javascript/CouchDB one. REST style data interfaces are being used as they make it easy for lots of different devices to chat to the server.

Alternative methods of communication

Using Ethernet keeps things simple, most home networking gear will work and it’s all reasonably cheap. There are alternatives though, ranging from simple and cheap (bare radio links) to most definitely neither (XBee). They’re well suited for building mesh networks of inexpensive sensors or when you have multiple hubs all talking to a local control PC. Unfortunately they’re less well suited to the stand-alone approach we want to use here. For example, a XBee/ZigBee network for two (physically separate) aquaria would probably consist of 3x XBees, 3x XBee shields, 3x Arduino, 1x Ethernet shield (or 2x shields and Arduinos, 1x XBee USB interface and a PC). That’s a tad expensive and overkill if you only want to monitor one aquarium. Going direct to an all-in-one WiFi-enabled Arduinos or a WiFi shield would cut out a step, but these tend to be expensive or difficult to get hold of.

The Uno should cost about £21, or you could go cheaper with a Duemilanove clone – just make sure it’s a ATmega328 core. The Ethershield (we like the D-Robotics clone) and the Wifi-bridge are also about £22-25 each.

Limitations of Ethernet

So, we’re sticking with boring old Ethernet – what could go wrong? That depends on your broadband set-up (if you’re stuck on a modem, um, sorry) but assuming something not too outrageously unusual:

• NAT/firewalls – most ISP-supplied routers are locked down, so it’s not possible to define a NAT channel to allow access to the Arduino from the outside world. The easiest solution is to make all communication initiate from the Arudino, with messages being passed back from the server via its responses. Since the Arduino will be regularly broadcasting data anyway this isn’t a problem but it does mean that the server can’t ‘push’ commands to the Arduino
• fixed local IP – DHCP is possible on the Ethernet shield but the libraries reportedly don’t work with modern builds of the development environment. If you can, defining a DHCP rule for the Ethershield MAC address (just pick one) should avoid problems but also just using a free local IP should work
• no DNS – As with DHCP, this is doable but expensive in terms of system resources. Easier to point at a server with a fixed IP
• RAM limits – The Uno processor (ATmega328) has 2KB of memory, which isn’t very much. A 500 byte buffer is sufficient for a short message plus headers but the choice data encoding needs to balance succinctness with clarity. XML would be great but JSON is more compact and using REST reduces the need for communication via GET/POST parameters (if that made no sense to you, don’t worry about it!)
• latency/data usage – Latency delays need to be hard coded into the firmware, so may need tweaking depending on the network conditions. Data pings of 0.5KB every 20s works out at about 60Mb/month – shouldn’t be a problem unless you’re using lots of Arduinos or a mobile link ($!)

What can we see?

There’s lots of stuff we could measure but doing everything would get expensive (and the Arduino would hates us) so what are appropriate sensors for this project? They needs to be reasonably cheap, suitable for the environment (damp!), appropriate for continuous measurement, and able to respond with either a digital signal or an analogue voltage. It would be advantageous to run off the 5v or 3.3v lines available on the Arduino. We have 6 analogue input lines (0 to 1024 resolution) and between 4 and 6 digital lines depending on usage for LEDs, alarms etc. We also need to pick sensors that actually detect something that’s useful!

What’s the key equipment we trying to monitor?

Filters

The activity and flow rates of aquarium filters is not something that’s commonly monitored, presumably because it requires specialist hardware and/or is difficult to calibrate. After much consideration, we’ve chosen two approaches.

Firstly measuring the flow induced pressure drop due to the Venturi effect, normally used to inject air bubbles into water streams. A constricted T-piece is added to the outflow pipe and the side channel connected via a tube to a solid state barometric sensor. The higher the flow rate, the lower the pressure in the air column against ambient and the higher the value on the sensor. Using a chip sensor gives good sensitivity at a reasonable price and a suitable model is the Freescale MPX5010DP (pressure range 0-10kPa [1.4psi]; max 200kPa; differential, temperature compensated sensor; supply voltage 4.75-5.25v; supply current 7-10mA; minimum signal 0.2v; maximum signal 4.7v; sensitivity 450mv/kPa; response time 1ms) and cost about £12 each. The Venturi effect requires the addition of a specialist T-piece which is often built in for internal filters or can be bought for Juwel filters (£8). The less sensitive MPX5050DP model would be appropriate for more powerful filters or power-heads. In either case, signals are measured on an analogue line and can be easily scaled to an approximate kPa reading.

Since these sensors are not waterproof we should consider how to protect them from condensation (or floods due to blow back!) A non-return valve will work but may also disrupt the sensor, particularly if the Venturi pressure is low. We’ve used valves on the more powerful pumps but left the weaker ones with just a plastic coupling piece between two bits of air tube. That provides a weak point which should pop open if the main flow is blocked, rather than squirting water all the way back to the sensor.

Unfortunately, it’s not clear how to build/fit a Venturi to an external filter with a spray bar. Splicing into the output water line is feasible but carries a significant leak risk. Instead we’ve chosen to use Hall effect sensors, which detect changes in local magnetic fields. Simple chip-based ones can be very cheap (e.g A1301EUA-T is £1.50) and easily detect the rotating field generated by magnetic pump impellers. The sensor needs to be placed somewhere suitable on the filter casing (takes some experimentation, and perhaps waterproofing) and the analogue resulting signals are quite small. They also oscillate at about 100Hz, presumably due to a combination of the main frequency and the number of magnet poles on the impeller. Measuring the analogue in voltage at 5ms intervals for a 100 or so values and recording the difference between the highest and lowest values gives a steady value that relates to the impeller spin rate. This value isn’t that suitable for rating water flow (since the impeller speed doesn’t change much until the filter is badly clogged and we’re probably only seeing the driving fields anyway) but easily detect if the pump has failed to power up.

Air pump

This is most easily done using the MPX5050DP barometric sensor described above. The more sensitive 5010 might be a better option if you were using a smaller air pump (an Eheim 200 with 3 bubblers, gives about a 25% total signal with a 5050, a 5010 would be overloaded with this). Attachment is via a T-piece in the air line or a manifold, and you should already have a non valve in the air line before it enter the water.

Temperature

The classic approach for this is to use a calibrated thermistor but that’s old tech and this is the 21st Century, so lets use something cleverer. There are well developed libraries that support the Dallas/Maxim DS18B20 temperature chip, which can be bought in either a 3-pin transistor-like package or as a sealed stainless steel probe (see Ebay, sourced from Hong Kong, shipping may be very sloooow). These chip only needs 2 wires (signal/+ve and a ground) for a digital communication bus. That means you can connect any number of temperature sensors to one digital pin and access the temperature of each one individually (they all have a unique ID, a bit like a MAC address). They should also be more accurate (0.01^oC) and reliable than thermistors, showing little drift as they age – although they are probably less sensitive with a measurement time of about 0.5s). They also cost more but at £1.50 each that doesn’t matter unless you want to use dozens of them.

Light

A simple photoresistor (light sensitive resistor) bridge works well here. These are cheap £1 (see Ebay with properties: dark resistance: 1 MOhm; resistance @ 10 Lux: 10-20 kOhm; resistance @ 100 Lux: 2-4 kOhm. A 5v supply (automatically switched to save power) to this and a suitable balance resister (e.g. 50 kOhm) then gives a variable voltage when tapped between them. This is fed into an analogue-in and calibrated as needed in software.

Sir Not-Appearing-in-this-Film

So what parameters are we not monitoring (this time round…)?

Conductivity is important in marine keeping since it relates to salinity, however for freshies it’s likely to just give a combination of water hardness and nitrate level. The later would be very useful if we could measure it specifically or with a sensor stable enough to detect an increase by delta, but continuous conductivity sensors are expensive and require regular calibration. pH and ORP sensors would be easily to include but given that we don’t use CO₂ injection, they don’t supply particularly useful information. Current usage measurement of the heaters and lights would be useful but requires splitting the live or neutral line of the mains cable away from the others. Maybe something to consider for a future Mk 2 – especially if we decide to implement Arduino controlled mains so you could turn the lights on or off remotely.

What’s next? On to the hardware!