Connecting a 5V relay board


21 posts
by geoffr » Wed Aug 22, 2012 11:39 am
I am looking at the idea of connecting a 5V relay board (such as this one: http://www.elecfreaks.com/store/8-channel-5v12v24v-relay-module-p-268.html to the GPIO port on the PI.

While the schematic of this board indicates that it is using transistors to switch the relays, I am cautious about whether I would still not be safest to put a buffer between the PI's GPIO and this kind of board. - I was thinking of using a ULN2803 Darlington array in as a buffer between the PI and the relay board.

Any advice on this would be appreciated.

Thanks,
Geoff.
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by pjc123 » Wed Aug 22, 2012 4:08 pm
I have been using a relay card from another manufacturer with almost the exact same design as that for the past month (except my input is active low), and I have not had any problems with the GPIO 5V output driving the coils or drawing and/or feeding anything bad back into the pi, although I don't dare turn all 8 relays at the same time (480ma through all the coils). I did discover on mine that between the active low problem and the fact that the 3.3V output of the GPIO pins was not enough to drive the optoisolator, I needed to use transistors to convert the 3.3V input to 5V and everything works fine now.
Posts: 910
Joined: Thu Mar 29, 2012 3:37 pm
by kaos » Wed Aug 22, 2012 5:48 pm
I suspect that this particular board might give problems, if connected directly to the GPIO. Note that this board is "inverted"; an input has to be pulled low to allow current to pass from emitter to base in the (PNP type) transistor, which again allows current to flow from emitter to collector and on to relay and LED. If Vcc on the relay board is connected to 5V and the input to a Raspi GPIO pin, even with the pin pulled high (to 3.3V), enough current might flow through base on the transistor and the clamping diode in the Raspi SOC, that the transistor turns on and the relay operates. If, on the other hand, Vcc is connected to 3.3V, you get rid of this problem, but the 5V relay may not operate at all at 3.3V, and besides, will probably overload the 3.3V supply on the Raspi.

If you can find (or make) a relay board with a schematic that is a mirror image of this one; that is, uses NPN type transistors with emitter tied to ground, and the relay connected between Vcc and collector of the transistor, then chances are it will work with the Raspi's 3.3V signals, even if it is designed for 5V.

A transistor buffer could of course also solve these problems, but then again you could also use the same transistor buffer to drive the relays directly ;)

[A lightning transistor reference, for those that feel about to drown in acronyms:
There are two basic types of bipolar transistors (which leaves out FET's and a few other types that I won't cover here); NPN and PNP. PNP transistors go into conduction when a negative voltage of about 0.7V (for silicon transistors) is applied to base, relative to emitter. When that happens, current can flow from emitter to collector. NPN transitors are the same, except polarities are exchanged; they go into conduction when base is positive in relation to emitter, and the main current flow is from collector to emitter. The maximum collector current that will flow is a multiple of the base current. This multiple is known as hfe. It varies from one transistor type to an other, but is commonly about 100 to 200 for small signal transistors. Besides this, there is of course a maximum collector current and power that the transistor can handle. In schematics, the emitter and collector connections are the angled lines on one side of the symbol, while the base is the lone connection on the other side. The emitter is marked with an arrow. The direction of the arrow tells us whether it is an NPN or PNP transistor; it points outwards in an NPN symbol, but inwards is a PNP symbol.]

--
Best regards, Kári.
Posts: 102
Joined: Mon Mar 26, 2012 8:14 pm
by geoffr » Thu Aug 23, 2012 12:38 am
Thanks Kaos.

Based on what you are saying, I am probably just using either discrete transistors or an array like the ULN2803 to directly drive relays.
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by kg001 » Thu Aug 23, 2012 4:30 am
Please be very careful when interfacing any 5V device to the PI. and do not attempt it unless you fully understand the circuit operation. Any accidental feedback of 5V to the GPIO pins will more than likely destroy your PI. This type of problem has been my area of expertise for the last 20 or so years so once I get the issues sorted with my PI I will be pleased to help.

Cheers Kg001
Posts: 14
Joined: Wed Jul 25, 2012 1:06 pm
Location: Pt Augusta South Australia
by kaos » Thu Aug 23, 2012 9:16 am
Based on what you are saying, I am probably just using either discrete transistors or an array like the ULN2803 to directly drive relays.


That's what I would do, certainly. One important tip; connect a diode in parallel with the relay coil, with cathode connected to positive (see f.x. schematic of the relay board you originally posted). This is to short-circuit the high voltage pulse generated in the relay coil when it is turned off.

--
Best regards, Kári.
Posts: 102
Joined: Mon Mar 26, 2012 8:14 pm
by geoffr » Sun Sep 09, 2012 12:57 pm
I've given up on the idea of using the GPIOs directly, and will give the I2C bus a bash. My current thinking is still to use a ULN2803 to drive relays. - In the attached diagram I have only got as far as the indicator LEDs for each output. I plan to use the other 8 lines from the MCP23017 as inputs. I will use a separate 5V supply to the Pi once I am driving relays, although at the prototyping stage, I will first test just with LEDs while I work on the I2C stuff.

This approach also allows me to create a lot more GPIOs, and I won't have to deal with the confusion caused by the crazy GPIO allocation on P1 - I only need to take pins from P1 through onto my relay board.

Using I2C, assuming I get it working, will have the added bonus that I can integrate a real time clock into my board.
Attachments
driver-board.png
driver-board.png (43.1 KiB) Viewed 7086 times
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by mahjongg » Sun Sep 09, 2012 1:02 pm
kaos wrote:
Based on what you are saying, I am probably just using either discrete transistors or an array like the ULN2803 to directly drive relays.


That's what I would do, certainly. One important tip; connect a diode in parallel with the relay coil, with cathode connected to positive (see f.x. schematic of the relay board you originally posted). This is to short-circuit the high voltage pulse generated in the relay coil when it is turned off.

--
Best regards, Kári.

The ULNxxxx chips already incorporate these diodes.
User avatar
Forum Moderator
Forum Moderator
Posts: 5201
Joined: Sun Mar 11, 2012 12:19 am
by mahjongg » Sun Sep 09, 2012 1:10 pm
geoffr wrote:I've given up on the idea of using the GPIOs directly, and will give the I2C bus a bash. My current thinking is still to use a ULN2803 to drive relays. - In the attached diagram I have only got as far as the indicator LEDs for each output. I plan to use the other 8 lines from the MCP23017 as inputs. I will use a separate 5V supply to the Pi once I am driving relays, although at the prototyping stage, I will first test just with LEDs while I work on the I2C stuff.

This approach also allows me to create a lot more GPIOs, and I won't have to deal with the confusion caused by the crazy GPIO allocation on P1 - I only need to take pins from P1 through onto my relay board.

Using I2C, assuming I get it working, will have the added bonus that I can integrate a real time clock into my board.

Sounds like you like to take the more problematic route!
Interfacing the GPIO's directly to an ULN2803 should work without any issue.
GPIO allocation is not that complicated the SoC has 53 GPIO's only some of which are routed out from the chip to the board, and of these only some are routed to the pinheader. Once you understand that and are not fooled by calling the pinheader the "GPIO port" you should fare much better in understanding which SoC GPIO port is used to control a specific pin of the pinheader.
The Wiki should have all the details.

You are right that using I2C and I/O expanders can give you many more interfaces, but is also more complex to control them. And yes, I2C is the way to interface a RTC.
User avatar
Forum Moderator
Forum Moderator
Posts: 5201
Joined: Sun Mar 11, 2012 12:19 am
by geoffr » Sun Sep 09, 2012 1:38 pm
mahjongg wrote:Sounds like you like to take the more problematic route!
Interfacing the GPIO's directly to an ULN2803 should work without any issue.
GPIO allocation is not that complicated the SoC has 53 GPIO's only some of which are routed out from the chip to the board, and of these only some are routed to the pinheader. Once you understand that and are not fooled by calling the pinheader the "GPIO port" you should fare much better in understanding which SoC GPIO port is used to control a specific pin of the pinheader.
The Wiki should have all the details.

You are right that using I2C and I/O expanders can give you many more interfaces, but is also more complex to control them. And yes, I2C is the way to interface a RTC.


I agree - the approach I am taking is more complex, but it has greater longer-term expansion potential. Given how cheap the MCP23017 is, it is not a major thing adding another one. I ultimately also plan to expose the I2C bus via a header on my board, allowing me to just add a daughter board later. I may want to add some AD converters later on - and there are readily available chips with I2C interfaces to do this. That is the stage where all the extra work will pay off.
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by karl101 » Sun Sep 09, 2012 2:01 pm
On my Pi Raspberry project I used an opto-isolator between the GPIO and the relays to control a motor.

Image

More info on The Pi Raspberry http://www.g7smy.co.uk/?p=81

Karl
Posts: 63
Joined: Wed Jan 11, 2012 10:09 am
by mahjongg » Sun Sep 09, 2012 2:47 pm
geoffr wrote:
mahjongg wrote:Sounds like you like to take the more problematic route!
Interfacing the GPIO's directly to an ULN2803 should work without any issue.
GPIO allocation is not that complicated the SoC has 53 GPIO's only some of which are routed out from the chip to the board, and of these only some are routed to the pinheader. Once you understand that and are not fooled by calling the pinheader the "GPIO port" you should fare much better in understanding which SoC GPIO port is used to control a specific pin of the pinheader.
The Wiki should have all the details.

You are right that using I2C and I/O expanders can give you many more interfaces, but is also more complex to control them. And yes, I2C is the way to interface a RTC.


I agree - the approach I am taking is more complex, but it has greater longer-term expansion potential. Given how cheap the MCP23017 is, it is not a major thing adding another one. I ultimately also plan to expose the I2C bus via a header on my board, allowing me to just add a daughter board later. I may want to add some AD converters later on - and there are readily available chips with I2C interfaces to do this. That is the stage where all the extra work will pay off.
Okay, I can fully relate to that, I was only under the impression that you took this route only out of desperation because you could not figure out the GPIO numbering.
User avatar
Forum Moderator
Forum Moderator
Posts: 5201
Joined: Sun Mar 11, 2012 12:19 am
by mahjongg » Sun Sep 09, 2012 2:54 pm
karl101 wrote:On my Pi Raspberry project I used an opto-isolator between the GPIO and the relays to control a motor.

Image

More info on The Pi Raspberry http://www.g7smy.co.uk/?p=81

Karl
Nice, but opto isolation is really not necessary, just to control some relays.
I think there is too much hype about that it is "necessary" to take such measures when interfacing to the PI. There is really no difference between a PI and an Arduino in this regard, as long as you do not put hard 5V signals (that is signals directly from a 5V power supply) on to a GPIO port, as that means that the 5V will end up feeding the 3V3 power supply of the PI, and that can have dramatic consequences.
It quite safe to feed a weak 5V (that is from a pullup or something like that) to the PI, the excess voltage above 3V3 will simply be absorbed. A 5V TTL driver however will try too feed several 100mA into the GPIO port, and that can indeed lift the 3V3 supply above its normal safe level.
User avatar
Forum Moderator
Forum Moderator
Posts: 5201
Joined: Sun Mar 11, 2012 12:19 am
by geoffr » Sun Sep 09, 2012 10:08 pm
mahjongg wrote: Okay, I can fully relate to that, I was only under the impression that you took this route only out of desperation because you could not figure out the GPIO numbering.


The main reasons for deciding to try the I2C approach were the fact that I realised that with GPIOs I was going to get limited quickly by the number of pins actually available on the P1 header, and that if I wanted analogue inputs GPIOs would not help.
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by mahjongg » Sun Sep 09, 2012 10:47 pm
Actually I think that for analog input/output (that is when using an ADC or DAC, I don't mean audio, for that use a codec on I2S) the best route is to go with SPI I/O, many excellent and cheap ADC and DAC have an SPI interface, and remember you got two of these (two chip selects that is, so you can use (at least) two devices). I think analog I/O over I2C is possible but more limited.
User avatar
Forum Moderator
Forum Moderator
Posts: 5201
Joined: Sun Mar 11, 2012 12:19 am
by techpaul » Mon Sep 10, 2012 12:08 am
If doing analog unless you have extreme requirements greater than 10KHz continuous update in or out I2C will be fine. If doing audio unless it is short bursts of audio, from a a/d with an external buffer or to a DAC with an external buffer, use I2S, the vagueries of execution will cause problems with software polled A/D or D/A on SPI or I2C for anything other than short bursts.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by geoffr » Mon Sep 10, 2012 3:15 am
techpaul wrote:If doing analog unless you have extreme requirements greater than 10KHz continuous update in or out I2C will be fine. If doing audio unless it is short bursts of audio, from a a/d with an external buffer or to a DAC with an external buffer, use I2S, the vagueries of execution will cause problems with software polled A/D or D/A on SPI or I2C for anything other than short bursts.


Nothing anywhere that ambitious! All I am thinking of is polling some analogue sensors, most probably hourly, definitely no more frequently than every 5 or 10 minutes. I2C will work fine for that. - 0.0016Hz, I don't think I2C will have a problem with that.... *grin*
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by techpaul » Mon Sep 10, 2012 9:34 am
geoffr wrote:
techpaul wrote:If doing analog unless you have extreme requirements greater than 10KHz continuous update in or out I2C will be fine. If doing audio unless it is short bursts of audio, from a a/d with an external buffer or to a DAC with an external buffer, use I2S, the vagueries of execution will cause problems with software polled A/D or D/A on SPI or I2C for anything other than short bursts.


Nothing anywhere that ambitious! All I am thinking of is polling some analogue sensors, most probably hourly, definitely no more frequently than every 5 or 10 minutes. I2C will work fine for that. - 0.0016Hz, I don't think I2C will have a problem with that.... *grin*

Yep I2C will have no problems with that.

Loads of 8/10/12bit I2C A/Ds about, but I would suggest sampling slightly faster and filtering the data at least averaging or roliing average over 3 to four samples. Avoids 'noise spikes' giving you funny readings every so often.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by geoffr » Fri Sep 14, 2012 1:45 pm
Here's the first prototype - only 4 LEDs hooked up, and using port B of the MCP23017, because that was convenient. The idea of using the MCP23017 is working. The level conversion from 3.3V to 5V using 2 mosfets is also working nicely.
Attachments
20120914-IMG_0846.jpg
20120914-IMG_0846.jpg (61.19 KiB) Viewed 6889 times
Posts: 17
Joined: Wed Aug 22, 2012 11:25 am
by mckillnm » Fri Mar 08, 2013 12:30 pm
Hi folks,

I've been working on a PCB for this.. It's an i2c 8 channel IO board with relays, the relays are 250V 10A and there are 8 inputs too. You can use it on the RPi no problem.. I've used it with a BeageBone and a Carambola too.. It's a single sided PCB so making it home is easy..

http://mark.mckillen.com/2013/01/i2c-8-channel-io-board-with-relays/

Hope it's of use...

-Mark

PS: Quick photo below...
Attachments
I2C-Relay-Board-top-side-Finished-3.jpg
I2C-Relay-Board-top-side-Finished-3.jpg (39.37 KiB) Viewed 3942 times
User avatar
Posts: 2
Joined: Wed Sep 05, 2012 2:04 pm
Location: Ireland
by Mistertee » Thu Feb 13, 2014 4:56 pm
There is a link on this page to a circuit diagram http://www.sf-innovations.co.uk/custard-pi-6.html

This uses an 8 channel driver IC (the ULN2801). This uses outputs directly from the GPIO and can drive a relay.
Posts: 13
Joined: Tue Aug 13, 2013 6:43 am