Must-haves for EASY DIY controller?

[DustinB]

I agree DWZm I was trying to throw out possible cases that might want to be considered. While I don't agree with some of the answers Dustin gave, I am not familiar enough with the limitation of the system to provide a better solution. So I must leave it to those that have them up to decide what is best.

What answers were those? I'm very open to discussion of ideas or concerns, this is certainly not "my" project at all. I was just under the impression we were trying to nail down a basic firmware for the "average" user, that was both simple and "nearly" impervious to faults.

 

[TheFishMan65]

terahz, I am doing a convoluted ATO. I intend to have relays (primary and back up) that will be 5 volts. They will feed into standard 7400 series logic and a signal from the Arduino to turn on and off the ATO. Also the switches will be readable by the Arduino.

Why - he asks.

I have read that having short duty cycles on pump is bad. So my plan was 4 times a day the arduino reads the switches and sets a port to turn on the pump if needed. It will then shut the pump off 15 minutes later. However before the 15 minutes is up I already expect the ATo to be shut off by the float switch.

My goal is to have every float switch readable by the Arduino, but also incase of logic or other failure have some redundancy in the safeties.

Note on duration. If you have a varialbe they is decremented every time through an interrupt that occurs every minute then it covers the midnight case. Have a struct and a point to a function (fast time wise). In the interrupt decrement the variable if zero call the function. You can have a linked list and the function can either remove itself from the list or reset the counter variable.

Oh I forgot wave maker. Every X minutes turn it on or off.

 

[TheFishMan65]

Dustn I respect what you are doing. I just don't agree that my request are above average. I think the problem is that we don't know what average is.

Earlier we said that all the function the "average" user needs are on the main board, IIRC. So the fact that you are adding code to support outside ports is above average .

Maybe we need to start with a list of possible function and decide if the average user needs them and if so decide how they would implement them. The actual user may implement them differently in which case they are above average.

 

[DustinB]

Maybe we got things a little crossed on what we are looking at.

The way I saw it was like TeraHz was describing. We would have a way to set start and stop times for a function on each port through a menu. These times/functions would be parsed each second and react as such. Then the ATO would be almost completely separate from the scheduling. The only thing to account for that I was thinking was to be able to set the number of ports controlled by the scheduler.

Like my previous example: You could set the number of scheduled ports to say 6, which would leave you with 2 open ports for functions such as ATO and heater control. This would keep their functionality away from scheduling and rely more on condition based functions triggered by input pins the float valves are connected to or temperature readings.

On my setup I will be using an aqualifter pump controlled by a float switch typically activated after roughly 1/2" drop in water level. My pump would be running for say 10 minutes or so where your pump would only be running a matter of seconds. Either way, our setups are going to be impacted by the level the water is allowed to drop. In my case I can expect my pump to likely only come on 4 times a day or so by itself. I don't really see yours doing anything different unless your pump is activated after a very small drop in water level.

What do you mean by adding code for outside ports?

 

[der_wille_zur_macht]

Retreat! Retreat!

Seriously, I think we need to pull back a bit, agree on a very, very basic bulleted list of functions included in the firmware, and then write a sentence or two for each function. THEN we can talk about implementation. I think the current discussion is great, but is putting the cart before the horse.

I'm assuming we want the following code on the master AVR:

-Act as an I2C master (i.e.
-Read/set time on the RTC
-Drive the LCD
-Read pH
-Read generic input events (float switch on or off)
-Schedule output events (the current discussion)
-Send data to slave AVR via I2C (for use with the Ethernet interface on the slave)

The Slave AVR would need the following:

-Act as an I2C slave, receiving data from master
-Implement Ethernet interface
-Implement generic I/O (?)

I'm assuming we'd have some common extensions for the master, including:
-A "fading" scheduler - fade PWM channels instead of just turning them on or off. This would be for LEDs, moonlights, or DC wavemakers (i.e. Tunze)
-ATO implementation. You guys can battle this one out.
-IR interface
-One Wire interface for temp probes (or should this be core?)
-"Other" interfaces for temp probes
-etc.

Let's get comments as far as if this list is missing anything or has anything extra. Then we can work on what we actually mean by each item on the list. Then we can work on how we'd implement each item.

I realize that several of you have already implemented some or all of this functionality but I feel like we need to go through the motions of this discussion to make sure we're all on the same page.

 

[TheFishMan65]

putting the cart before the horse - are you trying to say we are going downhill.

Maybe I am remembering wrong, but I did not think the Hydra had any open ports to control. Maybe that is where I am confused.

Extension that I would consider adding
Water change
Wave makers (on/off cycles)

 

[DustinB]

That's the good thing, we do have a few open pins for different things. The use of the onboard MCP23008 for the LCD allows this. The relay control through i2c as well preserves these open ports. This allows easy use of temp sensors, ir remotes, etc... Even PWM for LED control.

You are thinking of the typhon controller I believe, there are no free pins that I know of due to the LCD.

 

[DustinB]

By the way DWZM, I edited the relay board a bit and double checked the serial connector position. Feel free to make any changes you see fit if something catches your eye.

http://code.google.com/p/hydra-reef/source/browse/#svn/trunk/hardware/RelayBoard

 

[der_wille_zur_macht]

Since we switched the SPI bus to the slave AVR (to control the Ethernet interface) there are actually a lot of open pins on the main AVR. It's my approach that the pins on the main AVR should be used for "core" connectivity (i.e. IR or One Wire), not for general purpose I/O (i.e. controlling a relay). But that's just me.

I'm going to pound this out here and include it in our future documentation. Currently on the main AVR the following pins are used:

PD0 and PD1 (digital 0 and 1 in Arduino-speak) : Serial port for TTL-USB programming
PC3 (Analog 3): pH
PC4 and PC5 (Analog 4 and 5): I2C

The slave AVR has the following consumed:

PC4 and PC5 (Analog 4 and 5): I2C
PB2, PB3, PB4, PB5: (Digital 10, 11, 12, 13): SPI bus
PD2 (Digital 2): INT pin from ENC

 

[der_wille_zur_macht]

Regarding the relay board - there are a whole bunch of vias not connected to anything all over the board. Were these intended to be connected to GND to tie the ground planes together?

Also, SCL and SDA are reversed with respect to the orientation on the Hydra mainboard's I2C header. Probably want those switched around.

I made those changes and changed a few things on the silk layer and checked in.

 

[DustinB]

The files I uploaded last night had the SDA/SDA switched around, with regards to the header by the second avr. GND, 5V, SDA, SCL.

Yes, the vias were just good measure for a ground signal, probably not necessary.

 

[der_wille_zur_macht]

Now I see the problem. The labels on the Hydra mainboard schematic are wrong. The correct pinout is GND, 5V, SDA, SCL. The mainboard's schematic had the labels for SDA and SCL reversed, but the board and board silk were correct. The relayboard WAS correct, I just "broke" it because I looked at the incorrect mainboard schematic for reference. I'll fix both now.

 

[sanddune600]

Things I want in relay setup the ato will probably be out of the scope of the standard but I think the option to keep pump running for a set time after float raises would be useful


Heater; control from low temp
Fan; control from high temp
pump control; shut off pump for x amount of time from push of a button for feeding ect
alk/calcium dosing pump control; I want this to come on a few times a day or possibly an adjustable on/off timer rather then set times
actinics; time on/time off (my tank is by my tv so to be able to turn it off and on via remote would be nice)
daylights; time on/time off
ATO; ran from 2 floats one would be the main and the secondwould be the backup. If the main goes low turn relay on if main goes high wait for 1 minute then turn off, if total run time is over 15 minutes turn off pump and sound alarm dont let ato run till I see alarm and reset. If backup goes high turn off relay and sound alarm wait till I reset.

 

[TheFishMan65]

Nice description of the ATO, it is about what I had planned. I was going to add a float switch in my top of water. It would keep the pump off if there was no water and sound and alarm.

Add to this a sensor in new saltwater. Right after theATO fills it up then if there is new salt water drain for some amount of time (or another float switch). Then fill with NSW until float switch trips again.

 

[TitaniuIVI]

The Time library on the arduino website does have scheduling built in. On a second glance of that page I noticed it's not documented there, but If you download the library you'll see there's a header file called TimeAlarms.h that can be called with just 1 line of code "Alarm.alarmRepeat(8,30,0, MorningAlarm);" That will turn the lights off at 8:30am. There's example code that come with the download too that explains it more in depth. I don't think we should waste too much time on code that was literally already made to turn lights on and off. If you can't find the scheduleing part of the time library, let me know and I can mail you a copy of the TimeAlarm.h file.

 

[terahz]

TitaniuIVI, thanks for the pointer. Last time I looked at TimeAlarms it was still being developed, but I guess they have a good working library now.

Time seems to come with a library for a DS1307 as well, so in theory we can replace our RTC lib with that and make TimeAlarms the main scheduler. From the example it seems to have repeat daily, repeat every X amount of time and run once after X amount of time.

This might work.

 

[der_wille_zur_macht]

Wow, talk about a useful undocumented feature.

At any rate, I don't think the real time and effort here is going to be developing the code - it seems like the bigger challenge is going to be deciding what we want it to do.

 

[TheFishMan65]

Certainly sound like what I was looking for. IN the code fragment tianiIVI posted is MorningAlarm a function?

 

[der_wille_zur_macht]

Take a look at the full demo sketch, it should explain the included functionality pretty well:

/*
 * TimeAlarmExample.pde
 *
 * This example calls alarm functions at 8:30 am and at 5:45 pm (17:45)
 * and simulates turning lights on at night and off in the morning
 *
 * A timer is called every 15 seconds
 * Another timer is called once only after 10 seconds
 *
 * At startup the time is set to Jan 1 2010  8:29 am
 */

#include <Time.h>
#include <TimeAlarms.h>

void setup()
{
  Serial.begin(9600);    
  Serial.println("TimeAlarms Example");
  Serial.println("Alarms are triggered daily at 8:30 am and 17:45 pm");
  Serial.println("One timer is triggered every 15 seconds");
  Serial.println("Another timer is set to trigger only once after 10 seconds");
  Serial.println();
  
  setTime(8,29,40,1,1,10); // set time to 8:29:40am Jan 1 2010 

  Alarm.alarmRepeat(8,30,0, MorningAlarm);  // 8:30am every day
  Alarm.alarmRepeat(17,45,0,EveningAlarm);  // 5:45pm every day 
 
  Alarm.timerRepeat(15, RepeatTask);            // timer for every 15 seconds    
  Alarm.timerOnce(10, OnceOnlyTask);            // called once after 10 seconds 
}

void MorningAlarm()
{
  Serial.println("Alarm: - turn lights off");    
}

void EveningAlarm()
{
  Serial.println("Alarm: - turn lights on");           
}

void RepeatTask()
{
  Serial.println("15 second timer");         
}

void OnceOnlyTask()
{
  Serial.println("This timer only triggers once");  
}

void  loop()
{  
  digitalClockDisplay();
  Alarm.delay(1000); // wait one second between clock display
}

void digitalClockDisplay()
{
  // digital clock display of the time
  Serial.print(hour());
  printDigits(minute());
  printDigits(second());
  Serial.println(); 
}

void printDigits(int digits)
{
  // utility function for digital clock display: prints preceding colon and leading 0
  Serial.print(":");
  if(digits < 10)
    Serial.print('0');
  Serial.print(digits);
}

 

[der_wille_zur_macht]

PS - I agree, with various combinations of the four included functions, we should be able to cover just about all of the "scheduler" situations described in the last few days. The only problem I can think of is if power goes out - you aren't guaranteed that things will restart in the correct state.

For instance, if you use the alarmRepeat function to turn lights on at 8 AM, and use another instance of it to turn lights off at 5 PM, imagine if your power goes out at noon. When power resumes, the lights will be off (I'm assuming that default status for relay control will be "off").

Actually, this raises a bigger question. How are we storing state information when the power goes out? How are we storing user-configured settings when the power goes out?