Electronically controlled water tank inlet flush unit


Senior Member
Hi again guys, This is a project that I made a few years back. I actually have 2 of them operating on two tanks.

The main disadvantage with a standard Water Tank 'First Flush', is that they don't get rid of enough debris from the water collection point and the organic matter that builds in them must be empty within days, or it starts to decay. This will cause bacteria to flow into the tank at the next rain fall.

Most people think that 'First Flush' systems aren't worth the effort. So they just let the organic matter flow into the tank and later use a low micron water filter to remove Bacteria from drinking water. This works mostly, but the part that gets over looked, is that Aerobic Bacteria will consume the oxygen from the water over time. This leads the water becoming some what stagnate.
This is why I design this system. So it removes at least 95% of possible inlet solid contaminates and eliminates the need to be continuously replacing the porous paper filter.

It basically uses a motorized ball valve to dump a preset amount of water from the collection area, before it then allows the rain water to flow into the tank. It also uses an fine inlet strainer that is cleaned periodically by a solenoid fresh water back flush jet.

The Picaxe uses a 5psi piezo pressure sensor, that is connected to a Pitot tube that is fitted to the bottom of the flush pipe. The nature of the pressure line prevents matter and water from actually getting to the sensor and clogging it up. It just interprets the air pressure that the water compresses.

The unit has many features that help it over come issues that may occur. And it also uses a serial RF connection to a multi use diagnostic unit, that warns of any failure.
At least 1/3 of the code is taken up by the RF interface. But its just nice to see how things are going. And it helped debug it in the beginning.

Functions :

Dumps the first flush pipe 6 times. Can be set according to the roof, gutter or dump pipe length.

2) Extreme down pour occurring during valve opening. Level not dropping fast enough to trigger valve closing. Close valve for tank filling after 35sec(flushing complete)

3) Not enough rain occurs for a complete roof flush, on flush #6. Water hasn't risen to filling level in 4.5mins. Add 2 extra flushs(8 total)Drizzling rain, poor roof cleaning.

4) Heavy rain falling. Flush pipe fills in < 60secs. Reduce the flush's needed each time this happens by 1, due to good roof cleaning.

5) 6 hours have passed from the last rain fall. Reset ALL flush related variables. If the level is not increasing, Do Not transmit level/count to diagnostic unit.

6) Every 18hrs, check if water level is >15%. If so, empty water from pipe to prevent stagnation.(frost or dew detected)

7) After flushes are complete. Allow tank filling for 60mins, before checking if its still raining. If its still raining(>4% in 2.5mins), keep valve closed. If not, empty flush pipe. Displayed on diagnostic unit

8) Clean water, back flush's the pre-filter before the 6th flush and also after rain stop check.

9) Valve close overload detection, in case valve gets jammed by a sticks etc. It will open after jamming then try to close again, before
alarming.(Diag unit RF reset available , else power reset required) **The valve overload check is done in two stages**

10) Manual valve override switch, to allow manual valve opening/closing and back flush pre-filter cleaning.
(if valve is left open, it will automatically close after 2mins)

11) System monitors - Jammed valve while closing - pressure Sensor or valve motor failure.

12) Transmits flush pipe level percentage and flush count, then sends messages when flushing is complete(tank is now filling)

13) Flush can be RF remotely controlled for manual operation in the filling stage of the program. Valve open or closed state is also transmitted
after this operation.(auto close if left open)

14) Flush count filling stage is stored in Eeprom in case of power failure or disconnection. So the flush process will not start again when power is

15) Holding down manual button(for longer than 1 sec) while powering up the unit. Then releasing the manual button, will clear flush counter to
zero.(Roof is dirty, extra flushes needed)

If the system has any floors, it is that the ball valves nylon seals do get abraded over time, depending on how much rubbish they encounter.
The valve overload detection has only tripped once, that require attention. And the best fix was just to put a dob of tap grease on the ball every couple of months.


Last edited:


Senior Member
Nice project. Thank you for posting. Lots of ins and outs, and showing how much can be accomplished with the 14M2.

Can you explain a little more fully the reason for this code (and other similar SERIN sequences)?
   For loops = 1 to 22
       Serin[40],C.1,n4800_16,(116,122),RF_control          ;0.5sec(approx)total timeout between both, Diagnostic unit manual override command, to OPEN or CLOSE valve - qualifier(TZ)  
       pause 45
   Next loops

   For loops = 1 to 22
       Serin[40],C.1,n4800_16,(92,64),tx_off                ;0.5sec, command from diagnostic unit STOPS flush Level/Count TX when alternate slot is running. qualifier-(BP)
       pause 45
   Next loops


Senior Member
Thanks Ibenson.
You know..I'm sort of embarrassed of the way the serial comms looks in this project.. in fact in all of the 5 project that I have built, that talk back and forth with the central diagnostic unit.
I tried 4 different RF communication methods. And spent months trying to get them all talking with a single 14m2... BUT the only way that worked all the time and consistently was this type. Which is funny, because it is the simplest, looks less reliable and hacky.
It was the high precision program loop time, that caused the problem on two of the projects.

And as we all know, Serin timeout and qualifiers don't play well together in an RF environment. But by having specific delays and a timing sequence between the TX's and RX's. i.e. a variably increasing transmit time and a looping Serin receive time with specific timeouts, it always catches the signal.
The signal duty cycle is in fact very low. Its hard to even detect it on my spectrum analyzer. And it worked to my advantage, that the RF noise floor in my area is also low on that frequency.

This specific piece of code does two things. It also uses the serial Timeout as part of the timing for that part of the program.
1) This allows a manual override of the flush valve, sent from the diagnostic unit.
2) Prevents both flush units transmitting real time data to the diagnostic unit at the same time. Although alarms still get through.

I have made a new dual processor board that I will one day swap out on the five projects. It will give better more robust two way RF communications, if the noise floor ever increase in my area. But its a big job to swap out the hardware and then debug it..

Here are some pictures to give you the idea of the diagnostic unit I mentioned. The display is showing the current flush pipe level and flush count on one of the tanks. (this is just water from dew)


Last edited:


Senior Member
Thanks for the detailed information. I've about given up on ordinary RF. I'm finding the ESP8266 ESP-01 in AT-command mode to be good, but I'm flip-flopping between using SERIN with qualifier (when I know something is coming, as in response to a request), and HSERIN when arrival is indeterminate--with 14M2s and 20M2s. Can't say that I've had enough experience yet to be confident of what works best.


Senior Member
Requesting data does work best for me as well. As you would know, this is almost impossible to do without a secondary picaxe that can handle that task alone.
There are many things that I encountered that needed to be address with polling RF. e.g. the request for re-transmission of data in a continuous stream, if signal blocking occurs... which it does from time to time.
That's why the current system I used sends the same data multiple times, not knowing whether it gets it the first time or not.