Grove XBee Carrier / RFBee hardware fault?

Products & Technology Grove
#1

Minimum setup to see this issue…
Grove XBee Carrier with RFBee installed
Grove - Relay connected to I/O Twig
USB cable connected to PC

Load the code below and observe that the relay may or may not manage to pull in. It is most likely NOT going to pull in if you turn the power switch off and then back on.

/*
  Test1
  Turns on PD5 (eg: grove relay) on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
*/

void setup() 
{
  // initialize the digital pin as an output [Pin 5 is the Twig connector for I/O
  pinMode(5, OUTPUT);

  // These lines are needed to ensure that the relay will pull in [hardware bug?]
//  pinMode(16, OUTPUT);     
//  digitalWrite(16, LOW);
}

void loop() {
  digitalWrite(5, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(5, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

Dodgy solutions…
Wait and eventually the relay starts “clicking”
Tap pin “PC2” on the RFBee with your finger

Reliable (but non-ideal solution)…
Remove the “//” from lines 14 & 15 of the code

What causes this problem?
The ATMega168 itself?
The connections on the RFBee?
The lack of connections on the XBee carrier?
Other?

#2

The two twig connectors are powered per mosfet on pin 16 and 17. You can see this in the Eagle files.
Edit: its not a bug, its a feature :wink:

#3

Ah - Now that you point it out, I see them. I’m more experienced with software than hardware, so the purpose of each and every chip is not something I’m focused on. Took me several hours of experimentation to figure out that PC2 had to be driven low to make the relay trigger consistently when connected to an XBee Carrier.

Forgive my ignorance - but I’m not clear on the purpose of this “feature”
Is the mosfet used to pass more current than the output of the ATMega could provide? I could understand that if the drain fed D5, but not for VCC which could simply be full supply.
Is the mosfet provided to limit the current that a connected Twig can draw? Then what purpose does having control over that?

PS: It would be worth noting this “feature” on the XBee Carrier wiki page - why it is there and how to use it - the link to the datasheet doesn’t say much to people like me with limited circuit design experience :wink:

PPS: A note on the Grove Relay page wouldn’t go astray either :wink:

PPPS: Feel free to post my test code (suitably edited to explain the mosfet control) as an example of using the Grove Relay on the XBee Carrier!

#4

I am still hoping for a reply… I invested so many hours in figuring out the issue, I’d really like to understand exactly what the “feature” is meant to do.

#5

Next week i get my latest order (XBee Carrier included). I would try this out. Then i can reply you :wink:

#6

Anyone else wish to explain more about this “feature”?

Pulling the I/O “down” provided enough power to the twig to reliably run the relay. Would pulling the I/O “up” stop power to the twig, thus providing a sort of power switch to devices on the twigs? Does anyone know if that is the case or do I have to test it?

If that is the case, the problem for me may just be when the I/O is not pulled up or down, in which case there is power to the twig - just not enough [and not consistent].

PS: I’ve updated several of the wiki pages to mention the need to drive the extra I/O low to get the power flow!

#7

Pulling pin 16 or 17 down = device powered. Works fine…

Thank you :slight_smile: