Paul Penfield, Jr.D. C. Jackson Professor of Electrical Engineering, Department of Electrical Engineering and Computer Science, MIT. Affiliated with the Microsystems Technology Laboratories.
The Penfield Cottage, located in New York's Adirondack State Park, is a group of three buildings on a 1.5-acre site with 400 feet of lake shore. It has been in my family since my Grandfather bought it in 1912, and is currently used by all his living descendants, over 100 in number, for summer fun -- swimming, boating, hiking, etc.
View from the porch of the large building.
None of the buildings is winterized. There are two kitchens and twelve bedrooms, and about 30 beds in all.
Over the years one of the major problems has been the septic system (there are no town sewers). We had five septic tanks, four pump tanks, four pumps, three leaching fields, and one dry well. Almost every year one or more of the pumps had to be repaired or replaced.
In 1993 one leaching field failed and we decided to replace the entire system. An engineer, H. Thomas Jarrett of Glens Falls, NY, worked with me to design a suitable system that meets the requirements of the town, does not use too much land area, satisfies all environmental concerns, and runs on gravity except for one pump tank.
Building codes have become tighter in recent years because of modern concern about the environment. Generally leaching fields cannot be located within 250 feet of the lake or a tributary (this rules out our entire property), and the system must be sized as though the property is used year round with all beds occupied. We designed a system that, although not strictly meeting code, (1) works satisfactorily under planned usage, (2) has extra capacity for temporary overload, and (3) can, as a last resort, be pumped out, at the owner's expense. The town granted a variance because the design meets its intended purpose and protects the environment much better than our previous system.
The system as finally built has two 1500-gallon septic tanks, one 1500-gallon pump tank with two pumps, two drainage fields, and an overflow tank that receives effluent only if the drainage fields are full. The overflow tank has an interesting "trickle-back" feature: a small pipe drains the tank slowly back to the pump tank. There are four float switches that detect the liquid level in the pump tank and the overflow tank, and these drive a controller that energizes the two pumps alternately, and sounds an alarm in case either the pump tank or the overflow tank fill. The system was placed in service June, 1995.
Any system this complex has many possible failure modes. Ground water can leak into the system. Pumps can fail. Power outages can occur. Float switches can stick open or closed. The overflow tank can fill. Pipes can clog. Any of the five controller relays can fail.
In the winter there is nobody around. There is no water service, and the water pipes are drained to prevent freezing damage. However, the septic system must remain energized, in case ground water gets into the system.
If the system fails during the winter, with nobody in residence, we want to know about it right away. Normally such systems do not have remote alarm systems, or reporting systems that can be used to identify and diagnose various malfunctions. My son David <firstname.lastname@example.org> and I decided to build our own.
We took an old DOS laptop PC, and wrote a program to acquire the status of the system, and periodically report by dumping its accumulated data to a remote computer. We requested that the controller be outfitted with "dry contacts" which are nonenergized relay contacts corresponding to the various states of the float switches and pumps. There is a dry contact for each of the four float switches and each of the two pumps. Every second, these six contact positions are read in via the computer's parallel port. In addition, the status of external power (on or off) and the state of the local data buffer (full or not) is determined. When any of these eight state variables changes, a record consisting of the eight bits of status and the time is written to a local data buffer. From this data, we can tell how long the pumps are energized, and knowing the height of the float switches we can calculate how many gallons are pumped, at what rate.
There are many important variables that our system does not deal with, such as whether the pumps are actually running (we detect whether they are energized), the pumping rate, the state of the drainage field, the liquid level in the septic tanks, the depth of snow cover, and the outdoor temperature.
Once a week the computer uses its internal modem to upload its data, and then clears the data buffer. In case of a power outage, the data is transmitted immediately, since battery backup time is limited. In case the overflow tank fills, data is transmitted immediately and the host computer sends me e-mail announcing the emergency. In case the pump tank fills (a less serious condition) data is transmitted the next night.
We had some interesting problems to contend with. During the winter, the temperature can be well below freezing; we assume that the laptop computer's hard disk will not operate. The entire program, with data buffer, fits in RAM, and we went to some trouble to insure that none of the system calls require hard-disk access. Since power outages are to be expected, we tried to minimize battery drain. To help keep the temperature up, we placed the computer in a styrofoam beverage cooler, and obtained a temperature 20 degrees F above ambient. As of this writing we do not know whether this will be enough. The floppy disk drive is loaded with a boot disk with all the software, and we hope that the computer will restart by itself after any power outage long enough to drain the battery.
We tried to make the system robust because to fix it would require a ten-hour drive. We now have great respect for the engineers who design space-probe telemetry systems.
We are in the process of writing programs to analyze the uploaded data for detection of various failures. We are also writing programs to display septic system load in four ways:
We are also planning to use the data generated to see whether the rates of water usage assumed by building codes are consistent with our experience.