so if it’s not due to a inductive load problem (which would be solved by capacitators), who has already use this relay board with success to switch 250v AC ??
@ Hyperlisk : with your direct wiring, GPio delivers only 3v, right ? is it enough to switch the relays ?
if i undrestand correctly, i will have to power the board in 12V + wiring 5V from the mainboard to the 5V pin on the board + GND to GND + each pin directly to a gpio. that’s all ? or am i missing something ?
I switch between digital input and output. One state sets them to 5V, other to 3.3V/0V which is considered low for the board and turns the relay on.
Relays are off when high (5V) and on when low (3.3V/0V).
I was referring to the optical isolation, not the issue.
Is there resolution on this issue? We produced several machines and just assembled two more of them(and of course, updated to latest firmware/etc) and suddenly when we first turn on the machines all the relays turn on flickering until the spider fully comes up and inits.
The suggestion of using an X1 to not turn on the power to the x16 relay board seems great, except, of course, the latest SDK doesn’t even include the X1(shoots self, new SDK should be up “shortly” of course).
How can we get the x16 to work with a minimal of fuss for the limited of electronics experience? The using a breakout board unfortunately doesn’t work because we need 8 relays(and potentially are going to need 9 on our next hardware revision)
From looking at https://www.ghielectronics.com/docs/94/relay-isox16-module am I correct in understanding that we need to get an extender module and add a 1K resistor between +3V and P3? (see drawing)
We can’t go adding the X1 Module and changing our code due to the SDK issue with the X1 module not currently existing.
@ NXTwoThou - [quote]We can’t go adding the X1 Module and changing our code due to the SDK issue with the X1 module not currently existing.[/quote] The SDK should be out in a matter of days. In the mean time here is the code for X11 driver:
using GTI = Gadgeteer.Interfaces;
using GTM = Gadgeteer.Modules;
namespace Gadgeteer.Modules.GHIElectronics
{
/// <summary>
/// A Relay X1 module for Microsoft .NET Gadgeteer
/// </summary>
public class Relay_X1 : GTM.Module
{
private GTI.DigitalOutput enable;
private bool state;
/// <summary>Constructs a new Relay_X1 instance.</summary>
/// <param name="socketNumber">The socket that this module is plugged in to.</param>
public Relay_X1(int socketNumber)
{
Socket socket = Socket.GetSocket(socketNumber, true, this, null);
socket.EnsureTypeIsSupported(new char[] { 'X', 'Y' }, this);
this.enable = new GTI.DigitalOutput(socket, Socket.Pin.Five, false, this);
}
/// <summary>
/// Gets or sets whether the relay is on or off.
/// </summary>
public bool Enabled
{
get
{
return this.state;
}
set
{
this.enable.Write(value);
this.state = value;
}
}
/// <summary>
/// Turns the relay on.
/// </summary>
public void TurnOn()
{
this.Enabled = true;
}
/// <summary>
/// Turns the relay off.
/// </summary>
public void TurnOff()
{
this.Enabled = false;
}
}
}
Okay about the X1…could I get clarification on the documentation of the x16 about the 1K resistor?
It would mean we wouldn’t have to rewrite our software and the fix would be less expensive. $4.95+1K resistor($0.29 at most from radio shack in a 5 pack)+two seconds of soldering versus $7.95+programming+wiring+figuring out how to compile driver.
As a fyi, we’ve put together 6 previous ones. It’s just the latest two(using latest firmware) that are having this issue. After doing the first one, we thought we had a faulty x16, but after assembling another one and having the same issue I jumped into the forums to find out if anyone else was having this “turn on, zzzzZZzzttttZZttttt of the different relays firing on and off furiously for 6-8 seconds, then once the program fully loads up on the spider, them all going off(what we would consider default state)”.
Is the resistor that’s described in the development docs eventually going to work it’s way into the hardware of the x16?
You could use 2 breakout boards but that would use 2 Y sockets. You don’t need extender module to do it. You can solder resistor straight to the relay board between correct pins around gadgeteer socket.
So let me also ask this
If the other devices you have don’t behave this way, why? Is the firmware different? Hardware different? App different? What’s triggering this only on your two latest devices?
No change in any of the hardware. We have a saved cart at Mouser and just basically did a reorder. We even moved the latest firmware updated spider over to the working setup(just moved all the ribbon cables over) so I don’t believe it’s the newer SDK. Double checked everything between working and the two not working, no change anywhere.
The only difference is looking at the x16, the capacitor closest to the gadgeter socket is slightly larger(even though it has the same number). Again, we would have sent the x16 back if we hadn’t gotten a second one and it had the exact same problem.
FYI, the one that is working is 1982A 16211H2.
The two that aren’t working are 1982A 28388H2.
We should have our extender modules in tomorrow and see if the proposed fix works. I don’t have two breakout modules here. I also really can’t call people and have them disassemble perfectly working machines to check the batch. This working machine also has to ship out by Wednesday, so I’m not going to go crazy testing things on it.
This IC would have been a better choice for driving the relays.
MAX7304
The only downside is that it is I2C and that requires a little more work under NETMF due to the fact you can only have 1 driver active at a time.
personal view: a cortex M0 like the DL40 would have been equally valid choice, although way more complex 
Today I was playing again with my Relay board from GHI and wired some led strips to the board. When pressing a switch wired to another relay board (the one without shift registers) it caused all relays to turn on on the second board!!! The only common thing to both of them was 12V supply and connection to FEZ Spider. I tested power supply and it was fine so it must be FEZ Spider and guess what - it was that stupid pin 3 (Enable pin). Putting a capacitor between p3 and GND fixed the issue (resistor between p3 and 3.3v is also there). GHI must redesign this board and fix this crazy pin 3.
What sized capacitor did you use?
UPS screwed up delivery of our extender boards, so we’re having to wait till tomorrow. To be on the safe side went ahead and ordered a few X1s since the latest SDK(2013 R2) put them back in.
I don’t know exactly and I cannot check because I’m not at home right now. It was a small one - 100nF or something.
Once this fix is confirmed can someone share an imagine of where to put the cap, and picture of the cap… thanks.
It was in fact 100nF between pin 3 and GND.
FYI, didn’t fix our issue. One machine works now, the other doesn’t. Using X1 to wait to send power to the X16 board stops the start up oddness. But during operation at a certain point it just freaks out again.
Waiting on another shipment of capacitors to try induction suppression on the relays from a separate thread on the X1.
Insanely frustrated.
It worked for me only for small load - LED strip. I didn’t test with 500mA motors, because they’re already directly wired to other relay board. Still if you don’t need more than 7 relays (or more if you have free Y sockets) your best bet is to wire them directly. Works every time.