Here are the evapotrons in action at Burning Man. We eliminated over 1500 lbs of grey water. Oh yea!

The evapotron on the truck at Coffee, Tea and Me

Close up of evapotron at Coffee, Tea, and Me

View of evapotron at Above the Limit

The weight sensor was an interesting little beast. I’ll write a long post at some point about how hard it is to figure out with a sensor how much water is in a bucket. I tried the eTape liquid sensor, various electrical sensors in the water, ultrasonic measurement of the height, and finally a weight sensor. The final one was the only one that worked at all — and it didn’t work all that well. More on that later.

However, it did sort-of work, and that can be seen here in the data between 12:45pm and about 3pm on Sunday 26 Aug. The cycling from low level to a high level shows the pump’s action. When the pump is running, most of the water is up on the evaporation tower, not in the reservoir bucket, and so the weight is low. The pump shuts off, the water drains back into the bucket, and the weight goes up.

Not *all* the water drains back. In the graph above, starting at about 13:30, imagine a straight line through the tops of the line’s plateaus. That line is tracking the loss of water due to evaporation off the tower.

There are tons of complicating factors: water is added to the system, as shown in the previous post; the measured weight is noisy because the truck (on which the whole tower sits) is jostled by wind, as people move stuff around inside, and when they climb onto the truck; and occasionally the sensor reports completely nonsensical readings. I’m working on an analysis that will control all these effects to get at evaporation rates.

Figuring out how much grey water went through this machine was pretty complicated. We kept a logbook, but I worried that it would be honored “more in the breach than in the observance,” as my friend Cheddar said. He was right. 

This graph shows the cumulative number of pulses recorded by a flow sensor attached to the filter bucket. All the grey water put into the evapotron went through this sensor. One key finding from this graph is that there are many, many more upward steps in the graph than records in the logbook. People put grey water into the system frequently without recording it. Cheddar worried about this on the last day (when a LOT of grey water went in, starting just after midnight on Sunday 2 Sep: what were people doing putting grey water into the evapotron a couple of hours after the Burn?). However, it seems that people put the odd one or two gallons in throughout the week.

In tests before I built the evapotron, I found that the flow sensor is extremely imprecise. Although it is rated at 192 pulses/liter, in tests I recorded from 160-240 pulses/liter. Given a final count of 93395 pulses, that suggests 128 gallons, in a possible range of 102-153 gallons.

This estimate probably overstates the total because there was about 8 gallons in the system that had to be brought home at the end. Still, given that it ran for 8.5 days, this represents 15 gallons/day (in a range of 12-18 gallons/day).

And there was a second evapotron running. It didn’t do as well, but it handled another 70 or so gallons. Between the two evapotrons, I estimate that we eliminated three-quarters of a ton of grey water. I’m calling this one a success, though there are many lessons learned and better stuff to build for next year.

The charging circuit worked pretty well. The idea here is that there are two batteries. One is connected to the bus which runs the Arduino, sensors, and pump. The other is connected to the AC charger. The Arduino controls relays which switch the batteries between the two. The upper line in the graph shows the voltage in the bus circuit. When the line is red, battery A is driving the bus. Each time a battery is switched into the bus circuit, it starts with about 13v, then voltage drops as it discharges.

What this graph shows is that the two circuits worked together. In each cycle, the charging circuit (on the bottom) got through the first phase (the slow ramp), then the second phase (the plateau at 14.8 volts), then the third trickle phase (the plateau at about 13.6 volts). When the bus circuit fell below 11 volts, the Arduino flipped the relays, reversing the batteries so the discharged one could charge, and vice-versa.

It seems like it’s actually working in this 45Ks (nearly 13 hours) run:

This is Box B, so it’s nice to see that it’s doing ok. The point here is that the batteries are handing off to each other smoothly. Note that if the bus battery runs out of power, it does a bunch of very short pumping cycles (see from 20-23Ks). This isn’t very effective, I don’t think, but it’s still probably the preferred behavior.

One slightly worrisome note: I’m clearly not sensing the charging cycle correctly. Note that the charging graph climbs, holds the peak, then drops to a plateau for a while (3600 seconds, actually) before handing off to the other battery. The handoff is being triggered by logic that notes a long plateau in the charging voltage. Somehow the logic that spots the peak and descent between phases 2 and 3 isn’t working. So time is being wasted while the plateau-sensing code waits to make sure this is a real shift to charging phase 3.

Maybe I should sense the slope of the charging cycle? Or just shorten the time the plateau is being watched? Dunno, but either way, the charging cycle can be shortened by at least 1800 secs, maybe even 3000s.

That’s it, testing time is exhausted. Time to go to the playa.

Most things are working properly:

The battery switching looks good. However, the pump hung at time==14617. At that point, for its own reasons and without input, the flow sensor decided that the flow rate is infinite. There’s a bug in it’s calculations, but whatever, at this point I have to ignore the flowrate calculation in the code from Adafruit, and monitor the flow sensor’s pulse count directly.

I did a six hour test run of the evapotron control circuit today, with mostly positive results.

This graph shows the bus voltage, the depth in the reservoir, the current drawn by the pump (in mA), and the voltage in the circuit being charged. It all makes sense, but it might benefit from a walk-through.

The bus voltage declines over time, of course, because this is the battery being drawn on to run the system. Periodically it drops about 0.8v — which is when the pump switches on. The depth stays roughly constant at about 25cm of water in the reservoir, which I’m measuring by using a load sensor. The pump can push water up faster than it returns, so occasionally the pump doesn’t finish it’s cycle before it runs out of water; those are the interrupted cycles. The current in the third panel is the inverse of the bus voltage and depth curves: it’s high when the pump’s running, and otherwise just noise and leakage (this is a little troubling but may just be sensor noise).

Then the charging circuit reminds us how three-stage lead-acid battery charging works. I’m watching it for when it drops back to 13.75v, which is when it hits stage 3. At that point, the battery on the bus could hand off to the newly charged battery, and charge itself.

This cycle doesn’t work the pump hard enough. I’m off until Monday, but I’ve got a couple of days to tune the work-charging cycle to find the max time the pump can run matched to the battery charge time.

Oh, and the second evapotron? Not done, but it’s close. The data logging shield for the Arduino doesn’t work (we’re debugging on the Adafruit forums); the sensor cables aren’t made, and the whole thing isn’t tested. I wish I were substantially farther along, but it’s all going to have to be enough.

(I have a long blog rant coming about how hard it is to measure liquid depth — the eTape failed; the Ping))) failed; and various attempts to test resistance of the water all failed)

if banshees were into hobbyist electronics, anyway.

Hard to see in the blurry photo, but this is the third coat, running. The three Otter-boxes housing the Arduinos are on the mat (only one is working, the other two have their signal and power cables flopped out).

It’s been a long road, and I still don’t have software or a control system. Each control box has a 4-bit dip switch to choose alternative programs, and a potentiometer knob for varying the refresh/flash speed. However, I’ve written software for neither.

I dumped a strand and Arduino on my friend Slobberchops, he’s an Alpha Geek. I’m hoping he gets interested enough to write me some cool patterns in the 10 days before I leave for the playa. Holy cats, only ten days; I’m not panicking, breathing, calm.