Must-haves for EASY DIY controller?

[der_wille_zur_macht]

Many people are doing really cool things with DIY controllers and documenting the efforts in this forum. I've mentioned using an Arduino for LED control in several threads, and am hoping to start a thread on that subject soon.

On my own tank, the LED control will just be one feature. It'll be the main feature, but there are other features available without too much effort. I'll likely also be using it for the following, at a minimum:

1) pH monitoring
2) A small number of relays to turn pumps and other accessories on and off
3) A small number of digital inputs - i.e. float switches, etc.

I'm trying to keep the entire project small and realistic, and I'm sure it overlaps with what other people want. My overall goals are:

1) Reduce hardware complexity.
2) Allow for future expansion.

I consider myself a beginner in the world of hobby electronics. I'm sure that there are people out there that would love to DIY a controller, but feel that the bar for entry is set too high. As I mentioned above, many people have posted really cool DIY controller projects, but most of them strike me as a hair too complicated for beginners like me, so I plan on designing the simplest implementation possible. I will be standing on the shoulders of giants.

Keeping with the Arduino environment, it should be easy to create a shield with a DS1307 RTC and the pH meter circuitry onboard, which would mean you'd only have 1 PCB to deal with, in addition to the Arduino itself. It should be possible to arrange headers on that shield to allow for plugging in a cable to connect X number of relays, and another cable to connect X number of digital inputs (float switches, etc). You'd also need some form of output - either an LCD (control for it could be included on the shield) or some method to transmit data to a PC or the internet.

With these features and this level of simplicity in mind, am I missing anything people would want in a simple controller design?

 

[nauticac4]

Majors on my list are

1. Top off control
2. Temp Control
3. Light Control
4. Monitor and possibly expand to logging of pH and temp
5. Nice Easy to read status or "heads up" display

I have looked into controllers as a DIY for quite a while and have not attempted to jump the bar as I am not exactly electrically inclined. As for the relay to on and of pumps it is not something that intrest me simply because I have 98% of that tied into a DJ Switch Panel and can take care of it with the flick of a switch.

Just my $0.02 Look forward to seeing you move forward.

 

[Skeptic_07]

With these features and this level of simplicity in mind, am I missing anything people would want in a simple controller design?

yes! been waiting for this.

I didn't see you mention a temp probe/heater control, i think that should be included. Maybe too advanced but ORP/ozone control could be considered part of a 'simple' controller (only say that because most controllers on the market have this feature). Being able to record data on a PC would be a HUGE plus, maybe not the simplest task though. Last thing I can think of would be the ability to control dc pumps.

 

[terahz]

I'd say the only thing you're missing is temp monitoring and how is user input handled. I've opted for remote control on mine but I see almost everyone uses some kind of keypad/button combination.

 

[terahz]

Maybe too advanced but ORP/ozone control could be considered part of a 'simple' controller.

That is not really a simple issue and also raises the price of the controller quite a bit IMHO. Salinity is another one.

Being able to record data on a PC would be a HUGE plus, maybe not the simplest task though.

That can be added with a firmware upgrade only requiring an active PC to be connected to the controller, and yes I agree it should be added but probably not in the first pass.

 

[stugray]

One thing I intended to do with my DIYRC is the power control module.

I designed & have all the parts for an AC control unit.
The concept was that it operates over 1-wire ( Dallas Semi) communication to the Dual Switch device (DS2413).
Each Dual switch would be able to CLOSE or OPEN a latching relay, one for every AC outlet.
Each latching relay would control one Grayhill AC Power module.
Through the DS2413 from the controller you would be able to Latch ON, Latch OFF, or query the state of the relay.

I liked the idea because I think there is some merit in having SOME of the components come back to the previously commanded state even if the controller stops talking after a power outage.

So I think one requirement of a DIY RC is 1-wire interface capability.
It only uses up 2 wires ;-)

OH, and if we add a 1-wire AtoD converter (DS2450) on the Ph Probe from the other thread, we can read the value over the same 2 wires ( then add as many as you want ).

Stu

 

[der_wille_zur_macht]

Just to share some of my own thoughts. I think it's important to separate hardware requirements from software requirements for a particular feature. If we want "features" like temp control or pH control, the first step I see is to convert that into hardware and software requirements. IME, if we include some basic hardware that's specific to universal features (pH control, temp control, etc.) PLUS some standard methods for expansion (I2C, One Wire, etc.) then we should have a very wide audience covered.

For instance, the features of having an LCD display, real time clock, port expanders, AtoD, etc, can all be met with a single piece of hardware - a header for I2C.

So right now, I'm trying to break desired features into a few sets:

1) universal, specific features everyone wants - pH, temperature, etc. If people want to do this project, they'll get these features by default, with no extra effort.

2) nearly universal features, that can be met through standard generic hardware interfaces like one wire or I2C. If people want these features, they may have to do a little hardware development work (a breakout board) plus a little software work.

3) oddball stuff, like ORP, etc. A few people might want this stuff. That's the beauty of using a platform like the Arduino. People who want oddball stuff can do it on their on with the standard pins, which we'll bring out on the shield. At least the ones we haven't used.

Expanding a bit on the audience I mentioned above, I want to make this as accessible as possible. People should be able to follow a standard set of instructions using commercially available parts and build this, without having to figure things out on their own.

Addressing some specific comments people have made:

Majors on my list are

1. Top off control
2. Temp Control
3. Light Control
4. Monitor and possibly expand to logging of pH and temp
5. Nice Easy to read status or "heads up" display

yes! been waiting for this.

I didn't see you mention a temp probe/heater control, i think that should be included. Maybe too advanced but ORP/ozone control could be considered part of a 'simple' controller (only say that because most controllers on the market have this feature). Being able to record data on a PC would be a HUGE plus, maybe not the simplest task though. Last thing I can think of would be the ability to control dc pumps.

Temp control - yes, I had that in mind but left it out of my list. Top off would just be creative application of digital inputs (a float switch) and a relay controlling an electrical outlet - both features which will be standard and easy to use.

ORP - I'm not really personally interested in that. In theory, it's similar to a pH circuit, in that it's just amplifying a very weak analog signal. Worst case, if people want it, they can do their own breakout board and add it on.

Display - yes, capacity for an LCD display will be standard.

PC interface - I see two or three options here. Worst case, you can leave it plugged in to a PC and write data across the USB interface. Best case, you stack an ethernet shield on top of the shield we design in this project, and your controller is available via the web. I'm not sure if either of these options should be "standard" as part of this effort - what do people think? Worst case, people would be able to develop either on their own.

I'd say the only thing you're missing is temp monitoring and how is user input handled. I've opted for remote control on mine but I see almost everyone uses some kind of keypad/button combination.

I really don't like keypads for these applications. No offense to people who like them, but it rubs me wrong. You'd have to write a menu structure and a way to navigate it with buttons, and it just seems like a lot of overhead on the controller vs. just editing the "firmware" and uploading it. Worst case, I would have a few general purpose buttons for things like activating a feeding mode or something.

One thing I intended to do with my DIYRC is the power control module.

I agree, controlling 120v AC is critical to a project like this. You need it for a variety of functional requirements - turning a heater on and off, a topoff pump, etc. terahz has volunteered to help with that part of the project. I could see a few different directions to go - one wire, I2C, etc. We're going to need those two for other functions, so might as well piggyback. Any input or help is fine by me. I don't plan to design the entire thing myself, or else it'll only be my controller, not everyone's.

In the end, I want this thread to be about idea generation and making sure we're covering all the true core needs - so please don't hold back if anyone has ideas about functions they'd want. Then we can run off and argue about how to develop this thing, and report back when it's done. Again though, I want to concentrate on making the end product accessible to people who are worried that a DIY controller is "too hard" for them, so things like documentation and testing/validating the design will be important - again, anyone that wants to help please speak up!

 

[SpacedCowboy]

As usual, we're thinking along the same lines [grin]

My plan is to use USB as a bus, and use FTDI chips as a USB<->serial converter (so the modules on the USB bus just look like serial ports) and have an AVR controlling each individual module. This is a little more expensive than using 1-wire, I2C etc, but it has a couple of advantages:

• Each module is stand-alone and can be developed by plugging into a normal linux/mac computer using libusb. Doing it this way makes debugging much easier
• The USB bus can extend for ~30m by using hubs, so it'd be easily possible to have the controller (I'll be using a linux touch-screen-driven device) distant from the modules. I'm not sure how far I2C would "travel", at least reliably... 1-wire would probably be ok but I2C is (IMHO) an internal-to-the-device protocol. I did consider (and in fact design) a multi-drop RS485 system, but USB is actually easier and cheaper

I've been planning it for a week or two - the first module was the mains relay. In order to control MH lights (yes, I plan to be all-LED, but you never know...) you have to take care of the huge inrush current at power-on. Most solid-state relays won't cope with that, so I used a triac design (with opto-isolators for the mains side) and triac-drivers coupled with a zero-crossing circuit so I can "dim" the devices as well as switch them off and on.

Since the expensive part of the whole thing is the triac circuit, I divided the main circuit up into a USB interface and a 4-socket driver module. The USB interface can control up to 3 of the 4-socket modules. That way I can make the 4-socket modules as-needed and not spend out money "just in case".

I put a couple of preliminary board layouts up (I have some changes to make, yet ) -

• the USB module that talks to the linux box and controls the mains modules. Total cost ~$18 in quantity-1
• the mains module that talks to the usb module and controls the electric circuits. Total cost ~$53.

Each of these circuits ought to be good for 8A continuous, 65A inrush current handling. The heatsinks are enormous - 2.5" tall and roughly 1.5"x1" base I did put a 15A fuse on the unit as a total draw limit though (not shown in the diagram because it's chassis-mounted). This is all based on using 3oz copper as well, just to cope with the current that could potentially be flowing through those traces ...

Simon

 

[justurmom]

just rhowing out there but wouldn't Digital Aquatics new salinity monitor allow people to set up ATO systems withotu having to worry about disfunction since we can base top off based on a specific salinity?

 

[der_wille_zur_macht]

As usual, we're thinking along the same lines

And as usual, your strategy is one or two steps more complicated than mine. :lol: I like your modular USB concept, though.

the huge inrush current at power-on. Most solid-state relays won't cope with that, so I used a triac design (with opto-isolators for the mains side) and triac-drivers coupled with a zero-crossing circuit

This is where my ignorance will show. Aren't most solid state relays essentially a pre-made version of what you're talking about - an opto-isolator, a triac, and a zero crossing circuit to turn it on? Just without the controllability I suppose.

just rhowing out there but wouldn't Digital Aquatics new salinity monitor allow people to set up ATO systems withotu having to worry about disfunction since we can base top off based on a specific salinity?

Mom, that's an interesting concept, but it introduces a LOT of complexity and I don't see the advantage over a tried-and-true method like using float switches. With any method, I'd want backup! What would happen if the salinity probe went out of calibration?

To start to quantify this, can people rate the following functions on a scale of 1 to 10:

-Read a pH probe
-Read a temperature probe
-Read float switches
-Turn heaters/pumps/chillers/fans/lights/other AC devices on and off based on above inputs
-An LCD screen to display system status
-A keypad to trigger simple functions (feeding mode, maintenance mode, etc)
-Read other probes - ORP, salinity, etc.
-PWM or analog output to control LED drivers
-Analog output to control DC pumps (Tunze stream, etc.)
-Ethernet connection to your home network, so you can log data, have alarm conditions send emails, etc.
-Expandability - fill in the blank with your favorite protocol - USB, serial, I2C, one wire, wireless, etc.

Knowing how these rate for people will help determine which features will be built in to the core project, vs. those people will have to add on their own if desired.

 

[TheFishMan65]

Comment on 120V controls

Comment on 120V controls

X10 used to make a serial port converter (http://www.x10.com/promotions/ck18a_ed_4th_0704.html) - still does. It would attach to the serial port and convert the commands to radio signal and pick them up in their transceiver.

Advantages:

• no wire interface
• The device can be remote (in the basement).
• It can control 16 devices.
• If I remember you can control another 16 with an additional transceiver.

Disadvantages:

• possible on/off due to line noise
• The serial commands aren't documented. But a serial analyzer should fix that

 

[shackscs]

I got my Arduino and a few protoshields to play around with while putting together my own controller as well. I put some of my other projects on hold to work on this project as time ptermits.

With that in mind I am going jump on board here with this project as it is in the same stage as mine, planning.

To start to quantify this, can people rate the following functions on a scale of 1 to 10:

I think the relative use for many of the below items would be if there was a condition set to correct the problem or notify the owner of a problem. Here is my .02 worth:

10 -Read a pH probe
10 -Read a temperature probe
05 -Read float switches
10 -Turn heaters/pumps/chillers/fans/lights/other AC devices on and off based on above inputs
10 -An LCD screen to display system status
5 -A keypad to trigger simple functions (feeding mode, maintenance mode, etc)
(Not really a fan of buttons either) Maybe put something in the software that triggers the events at set intervals and possible an LED alert system that informs you that something is approaching, ie pumps off for feedings, etc.
7-Read other probes - ORP, salinity, etc.
10-PWM or analog output to control LED drivers
(Unless you don't have LEDS in which case I would rate this a 5 or less. But who does not have LEDS, right????
5-Analog output to control DC pumps (Tunze stream, etc.)
10-Ethernet connection to your home network, so you can log data, have alarm conditions send emails, etc.
5-Expandability - fill in the blank with your favorite protocol - USB, serial, I2C, one wire, wireless, etc.

I have got a Tellymate Shield to connect to a TFT LCD monitor that I was going to install in the headrest of a car, many, many, many life times ago. It has a large enough display that I can read it from a distance and can get a lot more information displayed on it.

Once I get a PS for it (12v 4watt) I can work on adding to this system.

 

[shackscs]

Has any one looked into the ability for the Arduino to read information from any of the existing reader made by Pinpoint?

For people who already have them this would be great be able to do.

 

[gilweb]

I built a room temperature monitoring controller. It uses an Arduino, LCD and a Dallas 1-wire temp sensor. I have it setup so if my fish room gets over a certain temp it sends me an email. I plan on adding possibly control to turn on an AC or something in the future. This was the one thing my RKE dosent do. If you can put something like this in it it would be great.

 

[BeanAnimal]

No real interest in the project, but I will add a bit of advice.

The goal appears to be a keep-it-simple project. Keeping the project simple and modular is going to be tough. Little changes in code to handle bus additions and I/O changes can create huge timing problems with a "real time" operating system. Timing problems create bugs and/or unexpected behavior.

Many of you are asking for "life support" type features without realizing the complexity of ensuring that they can be trusted. While temperature monitoring is a very reasonable goal, temperature control is best left to a stand alone device. The same holds true with ORP, Salinity or any other "control" that can easily cause a catastrophic failure if a software or logic bug crops up. It would be wise to "monitor" not control these events.

Lets put this in perspective. There is a reason that your IV drip rate or oxygen mask is not tied to your heart monitor, O2 monitor, or other sensors in the ICU. A central board or display MAY monitor all of your critical parameters, but it does not by any means control ANY of the equipmnent that regulates them.

Look to monitor parameters for anything you wish to see or log but only strive to control what you can do so safely. Lights and things like skimmer pumps, etc. If you MUST control things like temperature, return pumps, top-off, Calcium reactors, etc.. then they should have dedicated controllers that only report to the main controller.

While the setup sounds more complicated, it is actually MUCH easier. The main controller only needs to handle the hardware it is designed for and have a message interfce to accept messages from the main controller and display them. Each sub-controller is a stand-alone device that manages itself without using logic from the main controller.

Like most porjects that are open to feature requests, the scope quickly becomes runaway... "I would like it to make my toast and let the dog out..."

Just food for thought

 

[shackscs]

I agree Bean, which is why I am opting for my larger LCD screen instead of the 2 or 4 line display units available. My Solaris takes care of itself when it comes to turning on and off. The ATO keeps the system where it needs to be and I turn off a series of switches to feed or perform maintenance. Which reminds me I have to feed Coral Frenzy tonight.

With the exception of the LED lighting system I am building, which I do want controlled at some point, I guess what I am putting together now is an elaborate monitoring system more than a controller.

Gil:

I built a room temperature monitoring controller. It uses an Arduino, LCD and a Dallas 1-wire temp sensor. I have it setup so if my fish room gets over a certain temp it sends me an email.

What shields are you using to accomplish the email notification? Are you going through your own ISP or through something like Gmail or yahoo?

Can you post your sketch? I am sure this will help plenty of people here putting together their systems.

 

[gilweb]

Gil:


What shields are you using to accomplish the email notification? Are you going through your own ISP or through something like Gmail or yahoo?

Can you post or PM me your sketch?[/QUOTE]

I have the Arduino, the ethernet shield and I am using the prototype shield where I allached the LCD, an LED that lights if the temp gets too high and the 1-wire temp sensor.

Since I am using simple Telnet commands to send the email, you will not be able to directly send an email to a mail server like Gmail or Yahoo. You would have to ad TLS authentication to the code. I setup a simple Windows SMTP server and I Telnet from the Arduino into that and the SMTP server sends the mail to my Gmail account for me since it has TLS built into it. I can send you the sketch and anyone else who who wants it when I get home tonight.

 

[terahz]

BeanAnimal, I agree that software gets quite complicated when you control things. However a timer based power center is not out of reach and is not complicated at all. It just requires a basic scheduler. So the idea is not to let the arduino make decisions but rather act as a smarter digital timer that is originally set by a person and just has some fault tolerance in it. For example you don't really want a rule like " if the temperature goes below 79.5 turn the heater on and if it is above 80.5 turn it off" but rather preset a timer for your heater's outlet that you know works in general and have a rule like "If the temp is above 90F turn the darn heater off and beep like crazy, send an email, call 911 etc...". I do like the idea of dedicated arduino per task though and if it is only adding another Atmega CPU then it might be worth looking into.


-Read a pH probe 10
-Read a temperature probe 10
-Read float switches 10
-Turn heaters/pumps/chillers/fans/lights/other AC devices on and off based on above inputs 3-4
-Have digital timers for AC devices 10
-An LCD screen to display system status 10
-A keypad to trigger simple functions (feeding mode, maintenance mode, etc) I'm a 1 on the keypad, but 10 on understanding user input in general. RC is nicer IMHO
-Read other probes - ORP, salinity, etc. 5
-PWM or analog output to control LED drivers 10
-Analog output to control DC pumps (Tunze stream, etc.) not interested really
-Ethernet connection to your home network, so you can log data, have alarm conditions send emails, etc. 7 (on the logging/reporting part, not sure if Ethernet is really needed here)

 

[SpacedCowboy]

And as usual, your strategy is one or two steps more complicated than mine. :lol: I like your modular USB concept, though.

Hmm. I think it's conceptually quite simple, really. The controller is a standard PC, and the bus is well-established with cheap parts. Development is easy because you don't need to have everything working together, you can test in isolation. That, to me, (and I think it's what Bean was alluding to above) is a real benefit. Effectively, the controller becomes a whole set of {"timer fires", "read from serial port", "do_logic", "write to serial port"}, and USB is way overkill in terms of bandwidth.

Building a little intelligence (in my case, a cheap AVR) into the modules is useful too - modules can ping the controller at intervals and can "fail safe" if a module loses connection to its controller (eg: the cat chewed the USB wire) by doing whatever is appropriate for that module. Result: no ATO pumps stuck in the ON position overnight...

This is where my ignorance will show. Aren't most solid state relays essentially a pre-made version of what you're talking about - an opto-isolator, a triac, and a zero crossing circuit to turn it on? Just without the controllability I suppose.

Well, yes. But you get to choose the individual parts to make sure they work, and it's a *lot* cheaper. The cheapest SSR's I'd actually trust to switch currents of that size (digikey: 365-1484-ND) cost over $12 each without any heatsink. Without a heatsink, my equivalent costs come to $5.60.

There are cheaper 8A SSRs available, but you need to read the fine-print of the temperature/switching-load graphs. Some manufacturers make the "infinite heatsink" graph the one that they rate their products with, and then show 20cmx20cm Al heatsinks as other options... By the time you get to realistically-sized heatsinks, you've divided your current-rating by 4... Other manufacturers state that their loads are calculated with cooling air flowing over the device (code: "in a well-ventilated environment"). This is a pretty shark-infested body of water, is all I'm sayin'

You also don't get the control, as you say. Whereas I can't think of any conceivable use for a dim-facility on an AC power line at this *moment*, it's a trivial addition, so might as well have it. You want the zero-crossing circuit anyway to reduce the current/voltage phase discontinuity to a minimum on switching. Some SSRs will do that for you, of course.

Simon.

 

[der_wille_zur_macht]

Simon, I'm 100% on board with the advantages of your modular approach, but don't think it totally jives with my direction. I'm hoping I can put everything we need for a super basic controller into the following components:

1) An Arduino. People can buy this.
2) A shield that plugs onto it, people will assemble on their own. This shield will include "core" hardware that everyone wants (RTC, pH amplifier, maybe LCD interface) plus standard interfaces for relay boards, sensors, etc. (i.e. one-wire, I2C)
3) One or more relay modules for controlling 120v AC - assemble on your own.
4) Sensors, float switches, etc. - all just single components on cables.

So in my view, the shield and the relay board are the only "modules." And, perhaps I'm taking this direction because of my limited knowledge in this area, but that is what it is. In the end it doesn't strike me as a huge deal - if people want to blend the two approaches, it'll work fine. I'm planning on basing this on a standard-issue Duemilanove, or 100% compatible clone, which means there will be a USB chip onboard, so the hardware I design could just plug into your USB network.

In the end, I want to reinforce what I said above - I'm trying to lower the bar as far as people interested in DIY'ing a controller, and implement some basic functions. So I'm imagining that documentation and super-easy-to-follow steps are probably just as important as the design we implement.

And thanks for the info on the relay circuit - I'd wondered about some of that (pricing, cooling requirements vs load capacity, etc) and you're confirming my suspicions.

Many of you are asking for "life support" type features without realizing the complexity of ensuring that they can be trusted. While temperature monitoring is a very reasonable goal, temperature control is best left to a stand alone device.

A very valid point and maybe I've taken it for granted, instead of emphasizing it more - but I agree with terahz's approach - the "controller" we're building might have limited control input, but would absolutely never be the only control method. This is probably a poor example, but for temperature control, I wouldn't go buy a bare heating element (i.e. some of the titanium heaters sold in the hobby that have no thermostat) and run it with a temp sensor plugged into an Arduino. But, I would run a "standalone" heating system - an off the shelf heater, or an element plugged into a ranco, or something - with the Arduino's temp sensor also monitoring the tank's temperature. Then, you could "rely" on the prove, purpose-built standalone system, but have the arduino handle "off the charts" situations - cut power to the heater and sound an alarm if temperature goes out of range, etc.

Same with topoff - use a standard "floatswitches and relays/pumps/solenoids" ATO, but have the Arduino "listening" to floatswitch position. Or, it'll have it's own dedicated float switches above and below the normal water level in the sump. It could sound an alarm if the sump's water level was out of bounds, and cut power to the ATO. It could cut power to the return pump if water level fell too high. And so on.

So you're right - the goal here isn't to use this "controller" for 100% automation to the fullest extent - it's to augment and double-up standard practices, plus add some sense of intelligence where you can't get it from standard practices. For instance, instead of having a dumb timer turn my lights on and off, I want a controller to fade them on and off, and so on.

Like most porjects that are open to feature requests, the scope quickly becomes runaway... "I would like it to make my toast and let the dog out..."

Half my day job is unleashing a beat down on people that attempt scope creep on my projects. The other half is making sure the project actually meets the customer's needs. It is indeed a fine balancing act. However, I'm pretty content with what people are interested in so far. The good part about this sort of project is that the initial effort can concentrate on core functionality, and there will inherently be enough "extra capacity" for people to expand on their own - unused GPIO pins, I2C, one wire, USB, plus the whole universe of Arduino shields for things like motor control, ethernet, wireless radio, etc.

Again, my goal by making this public instead of just running off and building my own controller is to convince others to get off the couch and actually do a DIY controller, instead of just reading threads by people who have done it and saying "oh that's cool but I could never do that."