Must-haves for EASY DIY controller?

[der_wille_zur_macht]

More than one MCP23008 on the same bus is no problem, as long as you set up the hardware address pins correctly.

 

[mammut89]

btw, I vote for #2 or #3 , as long as its not #1


another thing to think about when we decide where to put the ENC code. I would like to put it on a avr by itself. Why ? well because when we connect the ethernet to the AVR we no longer control what comes into the avr. we might get buffer overflow or some other bugs if we get packeted or some virus does some ****. If the AVR fails in that case we do NOT want some auto top off to latch in a bad position..................or other bad stuff that might happen.

 

[TheFishMan65]

MCP23008 has 3 address lines so you could have 8 on the bus. When a command is sent is has a 7 bit address and then data. The address of a slave is defined by some hard coded data (4 for the 23008) and some programmable (3 for 23008) pins. The IIC specification specify a certain range for different devices. Memory might be 00000XX (binary), exapnders 0001XXX, A/D 0002xxx, etc. So you can have upto 127 devices on the bus. The problem is when the upper bits match you maybe limited in how many of each device (family) you can have.

Note the 23016 also has thee programmable address pins so 8 of these could be on the same bus. They both have the same family code of 0100 so the address can range from 0100000 to 0100111. So you can mix the two device in any combination up to 8 devices.

 

[TheFishMan65]

mammut89,

I posted a little while back about secondary safety options. Not only reading a float valve so the AVR knows the status, but it shut off power to a pump. I was not thinking of a hacking problem, but just a lock up of the controller. I see you are thinking in sort of the same line and wonder if you have given this any thought.

 

[mammut89]

mammut89,

I posted a little while back about secondary safety options. Not only reading a float valve so the AVR knows the status, but it shut off power to a pump. I was not thinking of a hacking problem, but just a lock up of the controller. I see you are thinking in sort of the same line and wonder if you have given this any thought.

oh I must have missed your post. Yeah I wasnt thinking about hacking directly but lockups like you mention. It might work fine now but somewhere down the line someone writes some code that tries to read something in a bad way and 2000 dollars worth of corals die I feel we should limit the I/O that we dont control 100% to a seperate avr.

this is open source and people will try to do some mods to whatever firmware we put out. if they decide to put bad code on the avr that controls something important thats their own fault. but we should try to make this bulletproof for people that neccessarily arent programming wizes out of the box.

 

[der_wille_zur_macht]

Agree with what you guys are saying. If you go back to the first half-dozen or so pages, you'll see we had some discussion about this acting more like a monitor than a controller. That's definitely a safer option, and I wouldn't want to plug ANYTHING into a Hydra (or COTS reef controller for that matter) that didn't have a clear failsafe!

I'm seeing that option #2 is pretty much the most popular.

Is it time perhaps to do a "last call" for suggested hardware mods?

 

[DustinB]

Option 2 is good with me.

As for other changes, since we are on the subject of communication between the AVR's. From looking around on AVR to AVR communication it seems like i2c is the popular option by connecting the SCL/SDA of the 2 AVRs together (example here). Perhaps a 3x2 jumper block to connect/disconnect the i2c for AVR communication? Anyone know of any conflicts with anything on the board in doing this? Could we just connect the SCL and SDA pins together? I'm thinking it would work just fine since we connect to a particular i2c connection by address?

Other than that we have the following:
- Turn U11 180 degrees
- Move standoff hole between FTDI 1 and D13
- Inset BNC connector
- Connect CS and RESET of the ENC (CS: D10)
- Fix Connection of ENC pins 22 & 25 (22: GND, 25: +3.3v)
- Move ENC/Gate connections to second AVR

Anything else I'm missing?

BTW DWZM: I checked with the mouser techs and they can't recommend a through hole replacement for the ferrite bead.

 

[terahz]

Is it time perhaps to do a "last call" for suggested hardware mods?

Can we have this added to the hydra and adapted for various pests in our tank:
http://www.ted.com/talks/nathan_myh...m_campaign=newsletter_weekly&utm_medium=email

P.S. skipt the malaria story and just watch the end of the video ~ last 5 mins

 

[der_wille_zur_macht]

FWIW the I2C pins of the two AVRs are already connected. The main AVR needs to be on the I2C bus (as a master) to communicate with the RTC, MCP23008 for the LCD, etc. I suppose we could jumper the connection to the slave AVR, but I don't see too much benefit since if someone doesn't want to use it, they can just not activate the wire library on the slave, and/or cut traces.

The rest of the items in your list are already in place. I'll check the new files in to the repo now and people can take a look and make any comments.

 

[DustinB]

Great, I didn't realize SCL and SDA of the 2 AVRs were already connected. Shouldn't have any problems polling the main AVR for variables to display on the web then.

 

[mammut89]

nice mosqito laser

dwzm: Id love to have a 16 bit port expander on the board , ive been moving stuff around and its not got space for another 2x5 pins. so im thinking as many others are thinking , we need a breakout board for a multiplexer and a port expander. preferably 16 ports each to be set for any purpose. so im thinking , can we arrange the pins needed for that breakout board in a good fashion? They would require 9 connections between the avr and the brakout board which means that it would gracefully connect to each other with a IDC10 - IDC10 with the headers arranged for that.

the question is then, is this too specific for a generic project like this ? or are many people thinking of doing this breakout board ?

 

[der_wille_zur_macht]

mammut, I think I'm misunderstanding what you're asking for.

If you need a "breakout board" to get more I/O, you can use an MCP23008 or any other I2C port expander, and plug into the I2C header (not labeled as such, but the weird 4 pins in a vertical row to the right of the massive 3-row header at the top left of the board). The idea was basically that peripherals like relay drivers or port expanders would work on I2C via that connector.

So I'm not sure why you're asking for 9 ports to connect to an external board?

 

[DustinB]

The only other port expander I'm using is one additional MCP23008 as I only need 8 pins for my relay strip. In my case it seems more feasible to do it all on a breakout board and only have to connect 4 pins(5v,GND,SCL,SDA) as I had to create a board for 8 transistors anyway.

Personally I'm pretty content with the board after the listed changes. We have connections to add more port expanders and plenty of pins left for say ATO and temp sensors.

 

[mammut89]

I was thinking of doing the right side of this diagram as a breakout board which connects to the avr with 9 connections. ( which would be nice to have grouped in a way that makes a IDC10 connector slot right in ) instead of having a bunch of wires going as a single cable across. which wouldnt be a problem but not as neat.

 

[Foosinho]

another thing to think about when we decide where to put the ENC code. I would like to put it on a avr by itself. Why ? well because when we connect the ethernet to the AVR we no longer control what comes into the avr. we might get buffer overflow or some other bugs if we get packeted or some virus does some ****. If the AVR fails in that case we do NOT want some auto top off to latch in a bad position..................or other bad stuff that might happen.

So, uh, a bit of an aside, but... I think you'd (in the general sense) be absolutely crazy to open this up directly to the internet. I'd at least stick an authenticating proxy between it and the wild west, if not do what I do with my mythbox and completely firewall it from the outside world (I have access via an SSH tunnel from outside - SSH into my main box, and set up a tunnel to an open proxy hiding behind my firewall... and SSH is locked down pretty damn tight, since 3 incorrect logins in a row get you sent to hosts.deny, and any attempt to log in as root puts you there straight-away).

While we'd never get this project to the reliability of medical equipment, I tend to think of aquarium systems as life support, so for me it has to be as reliable and bombproof as possible. I'd even consider some kind of hardware watchdog that sounds an alarm if the AVR doesn't feed the dog every so often. IIRC, there is a built-in hardware watchdog on the AVR that will reset the proc if not fed, and with some way of determining state based on the RTC, that might be fine, but it seems to me that detecting repeated resets would be important.

(Sorry if this was covered already and I missed it. I've been following, but not so closely that I've poured over schematics and code in detail.)

 

[DustinB]

What exactly are you trying to use this for?

Fooshino: You shouldn't really have to worry about security without any code on the secondary AVR to control the main AVR should you?

 

[mammut89]

What exactly are you trying to use this for?

for fish tank but im thinking for more than one tank and scalablility for the future.

 

[DustinB]

I think that is something best left to breakout boards in keeping with the scope of the project. You could create a breakout board with all your probe connectors on it and connect that to your main project box with a 9pin serial cable still keeping a professional look.

 

[mammut89]

So, uh, a bit of an aside, but... I think you'd (in the general sense) be absolutely crazy to open this up directly to the internet. I'd at least stick an authenticating proxy between it and the wild west, if not do what I do with my mythbox and completely firewall it from the outside world (I have access via an SSH tunnel from outside - SSH into my main box, and set up a tunnel to an open proxy hiding behind my firewall... and SSH is locked down pretty damn tight, since 3 incorrect logins in a row get you sent to hosts.deny, and any attempt to log in as root puts you there straight-away).

While we'd never get this project to the reliability of medical equipment, I tend to think of aquarium systems as life support, so for me it has to be as reliable and bombproof as possible. I'd even consider some kind of hardware watchdog that sounds an alarm if the AVR doesn't feed the dog every so often. IIRC, there is a built-in hardware watchdog on the AVR that will reset the proc if not fed, and with some way of determining state based on the RTC, that might be fine, but it seems to me that detecting repeated resets would be important.

(Sorry if this was covered already and I missed it. I've been following, but not so closely that I've poured over schematics and code in detail.)

were thinking along the same lines but I kind of tried to point out that if this is on a seperate avr it doesnt matter what happens to it. if it fails you just lose remote surveilence. which everybody seems to agree on.

 

[Foosinho]

Fooshino: You shouldn't really have to worry about security without any code on the secondary AVR to control the main AVR should you?

Probably not - the only problem I could see is if AVR 2 ever "pings" AVR 1, rather than just listening passively, there is a very remote possibility that someone somehow manages to exploit a bug to flood the internal bus. I don't know enough about I2C to really know what problems that could cause.

I think that's incredibly unlikely, but again - "life support". When I build mine (probably one of these rather than re-engineering my own), it's definitely going to be firewalled. I just can't see a compelling reason to stick this directly on the internet.

(Another aside - I need to figure out how to get my phone to access protected webservers on my LAN from outside of my LAN. If I can't, I might have to go back to using Apache as a password-protected proxy to various web services I might need to use remotely when I don't have access to a laptop.)