Relay integration

[pfeerick]

is this the "3v Arduino Nano"   http://goo.gl/oHtVZx   ?

Unfortunately, not it isn't. That is a 5v Nano (5V16M), the 3 that comes up in the title is in reference to the 3rd hardware revision. (i.e V3.0) 

The 3.3v (which is typically shortened to 3v) Nano seems to be nearly impossible to get hold of now... I have two of them in service, and at the time they were almost as common as the 5v part, but they just don't seem to want to be found now. Having said that, the Pro mini is much more readily available, and is also cheaper than a Nano is. Only downside is that it doesn't have a USB port on it to program with - it has a FTDI-style header on the end that you are intended to connect your USB to serial connector to. Handily enough, the pine64 should be able to connect to it using one of it's own serial headers, so that shouldn't be a problem. So you could go for of these 3.3V Arduno Pro mini clones at a whopping US$2. 

Since the only important thing here is to make sure the micro-controller controlling the relay uses 3.3v logic so you don't need to add logic level/voltage level translation complexity to the link between the relay control board and the pine64, another good option is a Maple Mini. This can be programmed via the Arduino IDE just like other Arduino boards after installing the board support package. They have a lot more memory and run a *lot* faster than the Arduino Uno/Nano boards. You can pick one up for just over US$4.

If you're willing to spend a little more money, the Teensy-LC board that Paul over at PJRC makes is a really, really nice 3.3v Arduino compatible development board. It is slightly overkill for a garage door opener, but will ensure you have plenty of memory to add more features to the project, and is a very well supported board. 

At $42 + shipping from element14, the Gertboard is a nice board (although I prefer the Gertduino, as that gives you the flexibility of Raspberry Pi/pine64 + Arduino + any of the available Arduino shields). However, since all it seems you need from what you have said so far is some isolation from the pine64 to prevent from false triggering the Relay, a Pro Mini/Maple Mini/Teensy-LC is all you need since you already have the relay circuit working with the pine64 on it's own. 

Personally, I would go for the Maple Mine... I have used and will continue to use Arduino Nano/Pro Mini/bare Atmega328P chips in projects and designs in the future, but I think it is the simplest at best fit for your project. Plus you will have plenty of space and features on the board to add all sorts of other cool stuff later if you wish (led lighting, indicator lights, a second control system, etc). 

Hope that doesn't scare you off with information overload! 

[MarkHaysHarris777]

is this the "3v Arduino Nano"   http://goo.gl/oHtVZx   ?

Unfortunately, not it isn't. That is a 5v Nano (5V16M), the 3 that comes up in the title is in reference to the 3rd hardware revision. (i.e V3.0) 

good catch...

[vigor]

Thanks for all the ideas about intermediate board between pine64 and relay. However i still don't follow why would it prevent triggering relay on power on, that intermediate board that controls relay will be powered on at some point as well and it will trigger that relay once it is powered on, right ?

I noticed that on power on, it is really a fraction of second when the relay gets power (blip), so i wonder if there is
an inexpensive electronic component that will only pass signal if powered more than a ( 1 or 1/2) second, because on boot it is just the matter pf fraction of second when the relay gets power blip, if only i can skip/ignore that blip then the rest will just work.
another option comes to mind, using battery powered pine64 all the time, and keep charging battery whenever wire power present (most of the time) that should help to avoid blips.

[MarkHaysHarris777]

Maintaining an initial 'state' at power-up has always been a problem in electronic control circuits, because until the circuit is fully energized it 'logically' is not really functional. An MCU is more precise at the low level and has been designed to be more reliable for initial 'state' than either the Pine boards, nor the Raspberry PI.

If it were me, no automated door opener|closer would be attached to my garage door unless I could gaurantee that it would power-up reliably. There are many ways to do that, and most of them are more complex multi-level systems with redundancy and backup.

If I were designing the system it would be on a UPS battery backup system capable of sustaining control for several hours. Also I would have a power-timer on the relay board itself to make sure the relay cannot trip until POR is complete.

[pfeerick]

Thanks for all the ideas about intermediate board between pine64 and relay. However i still don't follow why would it prevent triggering relay on power on, that intermediate board that controls relay will be powered on at some point as well and it will trigger that relay once it is powered on, right ?

I noticed that on power on, it is really a fraction of second when the relay gets power (blip), so i wonder if there is  
an inexpensive electronic component that will only pass signal if powered more than a ( 1 or 1/2) second, because on boot it is just the matter pf fraction of second when the relay gets power blip, if only i can skip/ignore that blip then the rest will just work.
another option comes to mind, using battery powered pine64 all the time, and keep charging battery whenever wire power present (most of the time) that should help to avoid blips.

Micro-controllers, such as the Atmel328 used on the Nano/Pro Minis, start up with their pins in the input state, until programmed otherwise. In doing so, they don't actually trigger a high or low when powered up, so won't alter the relay state. Once you code is running, you can then do things like detect whether the relay is on or off (if it is bistable), or set the relay to the default state on power up.

However, I'm with Mark again on the reliability... if the system isn't battery backed in some way, there is always a chance that the power will brown-out at just the wrong time... and bad things could happen... like a brown-out happen just after the door has opened, and you're backing car out, and the unit reset, and promptly starts shutting the door on you...

This can be fixed by having extra sensors in place, to do things like check for the door position, obstructions and load on the motor to prevent it from burning out, but these are the sorts of factors you need to keep in mind when working on a system like this. Murphy's law will strike at some point... so you always try your best to design a project with that in mind. i.e. All of my designs use MOSFETs to protect against reverse polarity power, even though I use a standard 2.1mm centre positive 12v power connector... but there will always be that one time you plug in something that had to be the reverse polarity (damn you JR... why did you have to go and use centre negative connectors) and will blow something up!

My take on this is that if you have a dedicated micro-controller that has monitors the sensors, and does all the checks, it's less likely to crash or end up in a 'indeterminate' state, making it so the pine64 just needs to send the signal to open or close the door, and the micro will do so, if safe - or send a signal back saying why not, which the pine64 can relay back to the user. Depending on why you want to use the pine64, it not even be necessary in the design...

Having said that... what about a high value resistor (like a 1M one) on the I/O pin controlling the relay to GND (assuming low/false is indeed off for the relay)... if it is just a power up pulse... maybe that will be enough to bleed off the pulse? Do you think what would do the trick Mark? Or is something more complex like a logic gate needed?

[MarkHaysHarris777]

NOTE: The SBC GPIO is supposed to default to 'inputs' as well... and the Raspberry PI does ! ... but, the pine board does not ... not reliably anyway. Also the pine board comes up with the channels 'in use' which is also not correct. These are design flaws which need to be taken into account when using the GPIO on the pine board.