Must-haves for EASY DIY controller?

Although I have followed the thread I am just starting to really get into it. Is there parts list by part rather than by board id. The typhoon BOM basically says buy 10 of these and place them here, here, and here. The Hydra bom says bu one of these and place it here, but the same item can show up in multiple places.
Thanks
 
Thanks, I missed it probably because I am not familiar enough with the viewer (every time I looked I swear it wasn't there - thanks for enabling it :)). I still use 2003 which won't open it.
 
I realize that this project is not perfect and that you guys keep saying wait, but I mean really
Due to world-wide Atmega shortages, we won't have more Atmega328's to sell individually until mid-December.
From Modern Devices Web Site
What did you do buy them all up so you could finish?
 
Sorry for the long hiatus guys, but moving, the resulting unpacking of boxes, life changes, etc... took much, much longer than I anticipated. I'm caught back up with the thread now and glad to see that the ethernet section has been fixed.

Since my setup was only breadboarded, I have workable parts (plus I bought duplicates of most parts) and will get my hands on a PCB as soon as possible so I can get back to helping when/where I can. I like the decision to move the ethernet controller to the second controller.

As many have said already - thanks for all the work and by all means, please keep it up...
 
naticac4: I found what the problems were. You never used the name tool to name the ground planes "GND". You also had some of the wires with different name somehow. Did you use the wire tool instead of the net tool?

Anyway, I started over on mine and moved a few things around. Still a few things I'm not happy with and some things that could be better. I removed the second 12v/GND plug, it's essentially whatever is incoming to the board anyway. Also added the INT pin for DWZM.

Any suggestions anyone?

 
I've never really done anything with interrupts, but from what I understand it is a way to perform a certain action when a triggering condition happens on the interrupt pin.

From reading the datasheet it shows there is a register to hold the desired pin statuses. So basically you can set all GPIO pins to turn on/off or set each specific one on/off.

For example, maybe you have a water sensor on the floor under the tank. You could set it up to pull the interrupt pin high/low when it get's wet. That could have an interrupt value to set all GPIO pins low, turning everything off.

Should be at least a few things you could do with this.
 
Looks good to me. Sorry I couldn't do better this was my first shot with Eagle. Can you send me the files so I can take a look at them and possibly see what I did wrong, I'll PM you my email address.
 
Few comments:

1) Don't think we need the separate SDA and SCL header right next to the other header on the right.

2) Speaking of that other header - if you're going to add INT to it, I'd put it at the end (or put it on the big header in the middle of the board). This way, we preserve the pin count and order of the "I2C" header on the Hydra mainboard.

3) The parts you used for Vin and Vout are meant to represent a molex-style plug that inserts horizontally, typically used at the edge of a board. If you're going to keep those headers in the middle of the board, you should probably switch that to a standard 2-pin header instead - at the very least to avoid confusion with respect to the appearance of the outline on the silk.

4) Your top copper layer isn't transparent so I can't see most of the bottom layer to comment on it!

Otherwise looking much better. Might as well put the eagle files up on the google code site so people don't have to email them around (plus then I can take a look). Actually, one more thought - take a look at the actual part you intend to use for the X1 connector on the bottom. Make sure it will work with the dimensions you're using it - i.e. make sure it doesn't have little nubs on the bottom that will be hanging off the board, or a faceplate that will get in the way, or anything else weird. We ran in to that with the BNC connector we used on the mainboard - in the first rev it hung off too far and wasn't stable. No way to know that just playing around in Eagle - sometimes you have to look at real parts.
 
Few comments:

1) Don't think we need the separate SDA and SCL header right next to the other header on the right.

This was done for SCL/SDA IN from the hydra board, and for output to other expansion boards.

2) Speaking of that other header - if you're going to add INT to it, I'd put it at the end (or put it on the big header in the middle of the board). This way, we preserve the pin count and order of the "I2C" header on the Hydra mainboard.

Good idea, I'll make the changes.

3) The parts you used for Vin and Vout are meant to represent a molex-style plug that inserts horizontally, typically used at the edge of a board. If you're going to keep those headers in the middle of the board, you should probably switch that to a standard 2-pin header instead - at the very least to avoid confusion with respect to the appearance of the outline on the silk.

I did this for all the power connections, I can change it.

I added the board files to the code site.
 
speaking of these relay boards,

what type of logic are you guys using (for those that have implemented this)
to turn them on/off in relation to time. I'm assuming everyone's going to have them operating as timers.

I've got a massive IF statement. that still gives me some problems. I've got most of the kinks worked out, but I have a hard time believing this is the most optimum way.
 
Last edited:
I don't have any specific code other than testing code to control my relay setup on startup and feeding/cleaning mode.

If I can keep from getting distracted by other things catching my eye I was planning on doing a scheduling system. Users will be able to select a channel and set the start/end times through the menu.

I'm really wondering about this though as I was already hitting memory limits until I did a fair amount of optimization, this may just push it back over the edge. The only other option I see is trying to simplify the work done by the main AVR to do the bulk of the relay control on the second AVR with the ethernet. I imagine the main AVR code wouldn't be that much different in the end, on the "RAM" side of things anyway. I would prefer anything to do with time be kept on the main AVR with the clock though.
 
I don't have any specific code other than testing code to control my relay setup on startup and feeding/cleaning mode.

If I can keep from getting distracted by other things catching my eye I was planning on doing a scheduling system. Users will be able to select a channel and set the start/end times through the menu.

I'm really wondering about this though as I was already hitting memory limits until I did a fair amount of optimization, this may just push it back over the edge. The only other option I see is trying to simplify the work done by the main AVR to do the bulk of the relay control on the second AVR with the ethernet. I imagine the main AVR code wouldn't be that much different in the end, on the "RAM" side of things anyway. I would prefer anything to do with time be kept on the main AVR with the clock though.

I don't think it would change much pushing it to the 2nd AVR. all you would really need to do would be send a true/false statement back to the main controller on what the outcome of the relay function is.

I'll try and get a snippet of code up. but pretty much my issue is. I'm trying to make it universal, one of the things throwing me for a loop is if someone sets their OFF time before their ON time. and vice versa, trying to come up for a statement that continually returns the value I want (true/false) regardless. I think i'm on the verg of having done, but not yet. It's all very simple if the controller has been running for sometime. (i.e has on/off time passed yes/no, pretty simple) but it's the initialization thats kicking my arse.
 
Back
Top