Are all of the XBee pins available to code, or just the COM1 pins?
Initially I am just thinking reset, but later it may be cool to have the analog pins available as well.
Afraid not…
Thanks, but that diagram looks like the reset is connected, am I reading that right?
Yes reset (PB0) and sleep (PC13) are connected
@ pintsize.me - Justin’s “afraid not” means the analog pins are not routed. The thinking probably is along the lines of why would you need those pins when the Cerbuino has them already… my answer would be a question - why do you climb a mountain? Because it’s there!
You could do some kind of small intermediate board to break them out, kind of like a mini XBee shield…
Because I think (and I could be totally completely absolutely positively wrong) the analog pins can be used to transmit analog data from one XBee to another, so I could have things in a remote location connected to an XBee transmitting analog data over the XBee and then read that value from the XBee with the cerb.
You certainly can use the analog pins on a standalone XBee, but what does this have to do with the Cerbuino? Your question seems to imply that you want to read the XBee analog pins with the Cerbuino directly…
Exactly, write to an analog pin on the remote XBee (no Cerb), then read that value on the Cerbuino’s XBee.
Very doable.
The XBee acts as it’s own little microcontroller. You program it to read the analog pins, and then it transmits the data serially to any other XBees on the same PAN (private area network?) WIth just two XBees you should be able to send/receive wireless data “out of the box” in transparent mode just by plugging them in. You’ll have to read up on how to use the analog pins, but basically you configure them via AT commands. Then there is API mode, this gives you more functionality and lets you tweak every last little setting (and there are lots). There are several examples of libraries to control XBees in API mode floating around this forum. My personal favorite is a project I co-created with @ Gralin. The source is at http://xbee.codeplex.com.
That’s basically what my understanding was. So my thinking is once the receiving XBee gets it, the analog pin can be connected to the Cerb to drive some other action. Hit a web page, send an email, turn on an LED, whatever.
It’s all just a half-formed idea in the back of my skull at the moment.
You’re missing my point. You could do that, but why? The idea is to pass the received serial data to the Cerb. The XBee socket is on COM1, so any data coming wirelessly into the XBee automatically gets retransmitted to COM1. After collecting the data using the SerialPort object’s DataReceived event handler, then do something with it using any of the features available on the Cerbuino.
I believe your idea of manually routing the Cerbuino XBee analog pins to the Cerbuino’s other pins is causing the confusion. It is entirely like re-inventing an unnecessarily complicated extra wheel.
One example could be sticking an XBee and temp and humidity sensors inside a fridge connected on an analog pin, that data constantly transmits to the XBee on the cerb, where it is read from the analog XBee pin to the cerb analog pin and then acted upon. Wireless analog sensors is the basic idea.
@ PintSize.Me - Why use the analog pin on the Cerb? the data is coming into COM1 unless is am missing something?
Does the analog value from the sensor have to processed first before sent via XBee? Or does the XBee have the native ability to send data from an analog input?
Here’s some interesting guff,
XBee Direct Limitations
Projects that use the XBee alone for its input/output features may face significant limitations compared to projects that incorporate an external microcontroller such as the Arduino. The XBee has limited input and output pins, with no simple way to extend them. Also, the Series 2 hardware that the ZigBee firmware requires doesnt currently support analog output at all, which means it cant be employed to dim a light or control the speed of a motor without additional electronic components. The single biggest limitation is that the basic standalone XBee radio doesnt allow access to any kind of logic. This means no decisions can be made on the local device and no standalone operations can be performed besides transmitting data or changing the state of digital pins as the result of remote commands.
Note: A new variation of the XBee radio was recently released that incorporates a second microcontroller to allow some forms of local logic. However, this comes at additional cost, will need to be accessed with special programming methods, and requires knowledge of C or Assembly, both lower-level approaches than using Arduino.