Backyard Aquaponics
A place to discuss aquaponics

No, as a classical approach (using a clock) is more robust (more easy to watchdog and less prone to fail, as a light-sensor may be covered, silently fail or be fooled by police-chopper projector...).

Other parts of the system will probably need a clock, therefore adding it is welcome.



This would be a good way to obtain less at a greater cost.



Way to go!

(A classic PC mainboard integrates a clock).

This will be OK at first, but "fighting against yourself" as the system will do more and more things, because the wallclock time consumed in the subroutines (GOSUBs) is not accounted for. Add some nontrivial subroutines, and this "clock" will drift (be "late", "lag behind the wallclock"), proportionaly to the computing cost of those subs, and their "pause"s...

If the system is very simple and "does nothing" (mainly does "pause") it will be OK but its functionality will remain low,and the service/cost ratio will probably be low.

To have it pursue more and more missions the main routine may be retrofited into a version taking subroutines execution times into account.

Kiss KISS goodbye because some subs will be of paramount importance (priority), or one will sometimes run for too long (forbiding another to be scheduled as often as necessary), or you will need to debug a sometimes-crashing one which never "returns" and freezes the whole system...

The main routine architecture will prove unable to handle this, and a real multitasking prioritizing scheduler and task isolation will be in order.

There is no way out even on a slow-paced system because without any isolation each and every modification of the source code may cause some side-effect or latency which may impede some other point in the system. Even on a slow-paced one (like an aquaponic monitor) the corresponding debugging phase duration will last because you have to test each new version of the system against all states of the complete system.

Been there, done that, got the t-shirt.

For such an ordeal, when one cannot accept to only reach for limited (simple) and non-evolving functionality, do yourself a favor and prefer a more complete operating system, environment and programming language.

Hum, so I would need 3 of them plus the external probes and I would need to keep them from being out in the weather it looks like.
Keep watching, I'm hoping to find something where I might only need one base station and be able to have remote sensors for the other two fish tanks either wireless or wired.

This will be OK at first, but "fighting against yourself" as the system will do more and more things, because the wallclock time consumed in the subroutines (GOSUBs) is not accounted for. Add some nontrivial subroutines, and this "clock" will drift (be "late", "lag behind the wallclock"), proportionaly to the computing cost of those subs, and their "pause"s...

If the system is very simple and "does nothing" (mainly does "pause") it will be OK but its functionality will remain low,and the service/cost ratio will probably be low.

To have it pursue more and more missions the main routine may be retrofited into a version taking subroutines execution times into account.

Kiss KISS goodbye because some subs will be of paramount importance (priority), or one will sometimes run for too long (forbiding another to be scheduled as often as necessary), or you will need to debug a sometimes-crashing one which never "returns" and freezes the whole system...
quote:
The main routine architecture will prove unable to handle this, and a real multitasking prioritizing scheduler and task isolation will be in order.

There is no way out even on a slow-paced system because without any isolation each and every modification of the source code may cause some side-effect or latency which may impede some other point in the system. Even on a slow-paced one (like an aquaponic monitor) the corresponding debugging phase duration will last because you have to test each new version of the system against all states of the complete system.

Been there, done that, got the t-shirt.

For such an ordeal, when one cannot accept to only reach for limited (simple) and non-evolving functionality, do yourself a favor and prefer a more complete operating system, environment and programming language.

Unquote

You bring up a very good point about computing overhead and one I'm thinking about how to avoid.

How about a dedicated timer built up from something like a 555 chip?

Anybody?

The reason I was thinking of going with the dawn reset, is because fish respond to dawn and dusk, and most fish dont care so much about a de facto standard based in Greenwich

I dont think timing is critical for this application.

I can also build in some easy redundancy in the form of ...

if elapsed time is less that 23 hours then dawn is fake, caused by U-fo space aliens landing on your lawn, so put on your foil hat and ignore the false reading

and

if elapsed time is greater than 25 hours then reset anyway because there is a leaf on the sensor

either way the fish wouldnt notice, and you could be alerted by a flashing orange LED that dawn reset failed

I think I should also add a "Low voltage indicator" to warn against flat batteries

I think the real time clock is a good idea, because it will be required for the data logger of the future, but perhaps that should be in a data logger device and be able to take data from other things like temperatures probes and whatever else people want

This may solve the drifting clock problem. Beware: interrupting subroutines will condemn you to never let them depend upon (or modify!) any global variable, but this is good practice.

However having a NE555 orchestrating with respect to priorities or handling this mission to a central scheduling routine able will open another can of worms (in a few words: reinventing the PIC...).

And we still have the multitasking and isolation problems.

I think so (as already written: Other parts of the system will probably need a clock, therefore adding it is welcome.)



Do you plan to offload the logging function to another device? Think about a functionality served by an algorithm needing a measure done by such a logger. If, for example, your fish-feeding device needs to know the temperature in order to reduce rations when it's cold: you either buy another temperature sensor for the feed controller (you now have 2 of them: one in the logger device, another in the feed controller. You lose bucks), or interconnect the feeder and the logger (breaking isolation and adding any logger failure as a potential cause of feeder failure).

A light sensor only used to predict sunrise/sunset may be useless because given its coordinates your system may predict sunset and sunrise times ( some show how to calculate it http://www.jstor.org/pss/3595771 , others even do it for you: http://aa.usno.navy.mil/data/docs/RS_OneYear.php , http://aa.usno.navy.mil/data/docs/RS_OneDay.php ).
Pass water temperature to the evaluating function (if the temperature rises or falls sharply, the sun is prolly appearing or disappearing) and let it use past predictions, it will be even more efficient.

I take for granted that your system have a reliable time source...

With a standard PC (with a full IP stack) connected to the Internet your software may periodically download calculation tables, enjoy a precise clock (NTP), send notifications and alarms to some mail to SMS gateway, automagically backup precious data, be remotely monitored and used...

Same for the "Low voltage indicator" to warn against flat batteries: on standard and ubiquitous material ACPI is your friend.



Indeed. Then think about a power failure. When the mains (power) comes back a mainboard not equipped with a saved clock coldstarts but cannot infer the elapsed time, and all bets are off.

As it stands now, in the event of a power outage and a restart, say at 2pm, the system would reset to dawn.

This would mean the user selected number of feeds for the day would be distributed equally over the next 24 hours as far as the system would be concerned. Not really a problem.

It wouldn't really be 24 hours, because the system would reset at dawn, but I don't think it would have any impact on the aquaponics system in general.

But in my case the device would be running through my always charging 200amphour deep cyc,e battery backup system.

But it is a very good point.

Perhaps it might be a good idea to have a 12 hour pause after a power outage where no feed is allowed. Just to give the system a chance to process any spikes in ammonia.

The user could press a button to override the 12 hour pause if it was because they restarted the system for some reason.

Granted: an aquaponics system needs active pump, therefore the UPS comes at 'no cost' from the controller point of view.



If the average duration between consecutive outages/restarts stays below 12 hours there will be no feeding for an extended period. Let it happen as the system runs unattended or badly attended for too long, and there will be floaters, then a nitrogen cycle collapse.



In nearly all standard setups the dangerous foes are nitrites. Ammonia is a much more potent toxic stuff but it is processed into nitrites by bacteria which AFAIK are more ubiquitous, stronger, more prolific and working faster than the ones processing nitrites into ammo, and who nearly never collapse when faced with an ammo spike. I bet there is, in our contexts (aquaria, aquaculture, aquaponics...) at least one order of magnitude more beasties lost to nitrites than to ammonia.



This will adequately handle this case, but all those exceptions lead to a complex user interface, which is bug prone because many operators will forget the underlying protocol or even avoid reading the fine (but huge) manual exposing it. Each time you think "ok, in such a case the system may inform the operator who may decide for the system" you add a cause of failure. With time going even the system's designer (you!) will err on the interpretation of this string of fairy lights activity, and think about people who may try to handle the system, temporarily replacing the trained operator. It has to be as foolproof as possible, therefore as automagic as possible.

generally speaking if the pump went off every 11 hours, not feeding for a week would be better than feeding as if nothing happened.

re: "process any spikes in ammonia" by "process" I mean from ammonia to nitrites to nitrates to bok choy.

I think the user manual would look something like this...

---------------page 1 of 1---------------------------------------

BullwinkleII is wonderful.

section 1 --------Start up procedure.--------------

1.Turn on unit at the switch marked "Power on/off".
2.Press the button near the yellow flashing light labelled "Press to resume normal operation"

If you have a short blackout and would like to forgo the 12 hour wait before feeding resumes, press the button near the yellow flashing light labelled "Press to resume normal operation"


section 2 -------------adjustments------------------------
To adjust feed amount turn screw marked "Feed Amount" towards the "+" for more, towards the "-" for less.

To adjust number of feeds per day, turn screw marked "Number of feeds per day" towards the "+" for more, towards the "-" for less.

To check adjustments place a bucket under the feed outlet and press the button marked "Dump a days feed into a bucket". While the alarm is sounding (20 seconds), press the button again to confirm you have a bucket under the outlet.

section 3-----------reporting--------------------------------
The red light on top of the unit reports feeds delivered so far today.
The internal orange lights next to the two adjustment screws report the currently set number of feeds per day, and size of feed in 10ths of a second of motor rotation.

A long flash represents 10's, a short flash represents units.
Thus 23 would flash - long long short short short.
---------------------------------------------------------


[the rest of this page is intentionally left blank]

------------------end page 1 of 1-------------------------------------------


If they failed to understand the operation, the system would start again in 12 hours. Either way the fish would be fine.

I think anyone who can use a water test kit can work out a start up procedure like that

And anyone who cant use a water test kit should learn

Aquaponics people are smarter than we look

Depends upon power loss durations. Stopping the pump for up to a few minutes then having it run for 10 hours has no effect. But for the controller even 1/1000 of a second w/o power means implies a reboot and, w/o any real-time clock, some wild guess about the next feeding time.







That's not very crystal-clear. Some will wonder about the max duration of a "short blackout". (Some will wonder why no integrated real-time clock takes all this into account ).

That's a promising manual: each special case will make it larger. At least for you to learn about electronics and software development will it be useful!

everything will be just fine