Has anyone used a Xbee as a battery powered remote to control direction or simple commands to communicate with another Xbee attached to an Arduino? I have seen several people just talking through USB and such. Basically I am wondering if there is a way to get the Xbee to say a button has been pressed. I don’t own any yet but was thinking about buying. If not then I am going to just go with an IR remote/sensor.
Yes, an XBee can be used and there is a Send on Port input Change feature in the XBee.
The downside is that XBee’s, without sleeping, is not exactly a low power device so plan on a largish and/or rechargeable battery.
An IR remote is very friendly on batteries as the push switch can turn on the unit to transmit and be off when the switch is not pushed.
XBee Series 1 can sleep, but you need to learn/use that capability.
Series 2 is ZigBee and that’s a different scenario.
for low power, IR transmitting is sure easy, but of course, it’s optical line of sight only, for about 25 ft. max.
From what I understand, you can use the Xbee as either sending signals across one arduino to the other (whatever data u want) or via “interrupts” by setting up the xbee to notice changes on the digital IO pins and send that data once it changes. Is there a way to send digitized analog signals like potentiometer readings or accelerometer readings? I have a project similar to the poster where I have 2 Xbee’s working together with Arduinos. I have no idea how to set it up though. Can you successfully use just the minimal 4 pins (DIN,DOUT, Vcc, GND) and have 2 arduinos talking out of the box? Or is there setup involved. I have an Arduino pro mini which is kinda a PITA to connect things with and I need to simplify things as much as possible
Ofcourse you can send whatever bytes between 2 microcontrollers/arduinos. It’s just limited to 11.5kbytes/sec. (theoretical limit, in practice less due to flow control and buffers) You’ll have to make your own sort of communication protocol to encapsulate the data and keep the microcontrollers in sync. It’s basically a serial connection with no wires in between. And it’s not limited to a single endpoint Xbee.
An Xbee module can also measure analog voltages on some of its pins, instead of just digital. But there is a maximum sample rate for all pins combined of max 1000 samples/sec. There are only 2 pins for PWM output (to simulate analog voltages) so I wouldn’t go that route.(virtual analog wire) Just send the data over in binary form.
Thanks for the information. I guess i could just create some wired remotes with some pushbuttons for now. I would really like to use some form of RF remote to communicate with my micro. I just need the remote to press one of three buttons. I already have one IR remote in this project and would like to avoid several others. The only issue is that the Xbee modules are $25 bucks and I would like to avoid spending money on something that isn’t going to work out that well.
The cheapest way to figure out what it can do is reading the manual (series 1 aka 802.15.4):
so I need to make my own protocol? I cant just send bytes over without any protection and have it be relatively plug n play? On one side I just need to send info on two potentiometer values. On the other, I gotta send accelerometer information so like 2 or 3 analog lines on that side. Is the ADCing going to be complicated by one of the arduinos being 5V and the other one being 3.3V?
EDIT: Also, can I set the sampling rate for the analog peripherals? Id prefer to sample at 200hz
XBee Series 1 comes with firmware that can get A/D samples at an interval you choose and send that to a designated mating XBee. That data can then appear on the serial port to go to some PC or device.
Also, XBee’s stock “virtual wire” firmware can sense digital input bits and recreate them on the mating unit as outputs.
If you send bytes into the serial port of an XBee, with it configured for serial port extension (wirelessly), it will do so. You do have to ensure you don’t send more bytes per second than can be handled end to end. You can do this with simply a low speed, or use RTS/CTS as you would for a modem, or device some software messaging for this flow control. This is needed on any communications medium.
Now, it’s time to RTFM.
So how does one program the Xbee firmware? Do you need an Xbee explorer or can it just be done by rogramming an Arduino to send the commands to the Xbee after it is flashed?
So out of the box, can I just send data to and from an Xbee from Arduino A and it appears on the serial buffer of Arduino B just like that? I just need to connect DIN, DOUT, VCC, and GND, right? If I wanted to have it send on an analog input change, I would have to reprogram the Xbee. But could I just let the Arduino handle this and sample the analog signals and output the data when it decides to and it will automagically appear on the other one?
XBee firmware comes from Digi’s web site. Their XCTU utility installs various firmware revisions. For Series 1, there is an 802.15.4 firmware load; just use the latest if it’s not already loaded.
Then you CONFIGURE the firmware to do what you want, in terms of virtual wire, remote A/D data acquisition, etc. These are explained in the comprehensive user or OEM manual. I and others can help you understand that after you read it a few times.
Well all I want to do is say send out a “65” to the other board. If the other guy reads this 65 then it knows that two (8bit number) words will be coming with a “75” to complete the transmission. Just a super duper basic protocol. Can this be done with the minimal 4 pins of connection and untouched firmware?
This can be done out of the box. But it is proper to update the firmware through XCTU. There are a number of bugfixes that might be important, depending on the firmware version that it shipped with. Worst case scenario is that you have a very old one, and then pull your hair out because you can’t get them to connect. (perhaps after some time and tweaked settings)
Atleast one Xbee explorer to update the firmware and/or configure the devices with your PC is very much advised. Configuring and setting default values using XCTU is much easier than writing your program code in the microcontroller to send those commands over usart. Verifying the settings is also much easier.
p.s. That was sort of the synchronisation protocoll that I had in mind. You have to consider that the wireless link might die during sending of data. Then the receiving module might start receiving in the middle of your packet and interpret that as the start of the data. Then it receives garbage or out-of-sync data. The XBees can also be switched into API mode. This requires the data and configuration commands to be encapsulated into a specific data structure. The advantage is that it comes with error-checking, and reports of failure/succes on packet arrival. But the required header is substantial (in the order of 20-40 bytes when I counted), and requires you to write a CRC-check routine, and work around encountering some specific values in the data-stream (escaped control-characters). In short, it is much more complicated. But does allow the possibility to configure the remote Xbee over the wireless link if it is of interest to you. This is not possible in ‘transparrent’ command-mode.
dang.well so I need the explorer? crap. My project is due very very soon. You think this will simplify a lot of things? What is the standard shipping mode called?
Here’s the protocol I had in mind. It’s very simple, but hopefully itll work:
controller:
-
send decimal word “75” as start word
-
map 10-bit ADC value to 8-bit value and send throttle first, then steering.
-
send “57” as end word
car:
-
send “42”
-
map … accelerometer y-axis and send
-
send “24”
Could this work at all? It doesnt need to be super secure or accurate, but in the event of a error, how would I handle it?
Also, if I programmed the Xbee to just look at the analog inputs and send them, does that include any type of error checking/correcting? Would that simplify my project? I really need a quick n dirty solution as my project is due in 2 weeks. eek!
I get the feeling you have not taken our suggestion of reading the manual serious. A lot of your questions are answered by spending one day reading the manual/googling XBee tutorials (i.e. Tom Faludi ). If you have only 2 weeks I suggest starting today with that. You do not need to read it from front to end. Most is just detailed descriptions of each and every command. Important, but probably not immediately. The important parts are pin arrangements, line passing, difference between ‘Transparent’-mode/config mode/API mode. Don’t forget the XCTU manual that you can find on the Digi website. (I haven’t linked to it yet)
You can have a look at the Explorer board schematic and fix up a clone yourself. But I guess that requires more time to figure out and bug-fix. Buying it (I suggest Xbee explorer USB) is easier, and known to work. The same with letting your microcontroller configure the Xbee. You can write a program making it (the microcontroller) send the propper commands to the XBee to configure it, and hope it is bug-free, or not troubled by timing issues. You need a way to visualize which commands are actually set, and how or what data is actually sent to or received on the other end. You cannot blindly trust your microcontroller(s) to do it perfect. Bugs are everywhere. Make sure your microcontrollers can send the data to a Explorer board (so connected to a PC just listening and one of your microcontrollers working with it’s Xbee) which shows it’s output on a terminal application (XCTU has one built-in). When that is correct, deal with the other microcontroller that is supposed to interpret the data. You either trust that the ‘commanding’ microcontroller works perfect (Bad Idea!!!), or you use a second Explorer-board to allow feedback to your PC of what goes on on the other side aswel. (you can have multiple XCTU programs listening on different ports) Guessing games are very inefficient. You don’t have the time for that in 2 weeks.
makasin:
dang.well so I need the explorer? crap. My project is due very very soon. You think this will simplify a lot of things? What is the standard shipping mode called?
Student in panic mode. Too much beer & pizza.
Thanks Valen, I have read the Xbee manual somewhat. I havent really read it front to back but have been doing research but Ill get to it more soon. I just ordered the explorer. I hope thatll make it a tad easier. I get that there are several modes I can put the thing in, but I thought that just using the standard transparent mode would be simplest. Having the software take care of the thing, but I realize that it is a particularly bad idea to assume everything is working as it should using wireless when it's so unpredictable. I'll do some serious reading/research today and tomorrow and ill ask questions when I know more. Thanks for the feedback. I definately dont have the money to spend on another explorer, though. I have already spent like 300+ on this school project.Valen:
I get the feeling you have not taken our suggestion of reading the manual serious. A lot of your questions are answered by spending one day reading the manual/googling XBee tutorials (i.e. Tom Faludi ). If you have only 2 weeks I suggest starting today with that. You do not need to read it from front to end. Most is just detailed descriptions of each and every command. Important, but probably not immediately. The important parts are pin arrangements, line passing, difference between ‘Transparent’-mode/config mode/API mode. Don’t forget the XCTU manual that you can find on the Digi website. (I haven’t linked to it yet)You can have a look at the Explorer board schematic and fix up a clone yourself. But I guess that requires more time to figure out and bug-fix. Buying it (I suggest Xbee explorer USB) is easier, and known to work. The same with letting your microcontroller configure the Xbee. You can write a program making it (the microcontroller) send the propper commands to the XBee to configure it, and hope it is bug-free, or not troubled by timing issues. You need a way to visualize which commands are actually set, and how or what data is actually sent to or received on the other end. You cannot blindly trust your microcontroller(s) to do it perfect. Bugs are everywhere. Make sure your microcontrollers can send the data to a Explorer board (so connected to a PC just listening and one of your microcontrollers working with it’s Xbee) which shows it’s output on a terminal application (XCTU has one built-in). When that is correct, deal with the other microcontroller that is supposed to interpret the data. You either trust that the ‘commanding’ microcontroller works perfect (Bad Idea!!!), or you use a second Explorer-board to allow feedback to your PC of what goes on on the other side aswel. (you can have multiple XCTU programs listening on different ports) Guessing games are very inefficient. You don’t have the time for that in 2 weeks.
LOL I wish there was beer and pizza. More like stress and biting fingernails. Havent had a beer in many weeks hahastevech:
makasin:
dang.well so I need the explorer? crap. My project is due very very soon. You think this will simplify a lot of things? What is the standard shipping mode called?Student in panic mode. Too much beer & pizza.
makasin:
Thanks Valen, I have read the Xbee manual somewhat. I havent really read it front to back but have been doing research but Ill get to it more soon. I just ordered the explorer. I hope thatll make it a tad easier. I get that there are several modes I can put the thing in, but I thought that just using the standard transparent mode would be simplest. Having the software take care of the thing, but I realize that it is a particularly bad idea to assume everything is working as it should using wireless when it's so unpredictable. I'll do some serious reading/research today and tomorrow and ill ask questions when I know more. Thanks for the feedback. I definately dont have the money to spend on another explorer, though. I have already spent like 300+ on this school project.Valen:
I get the feeling you have not taken our suggestion of reading the manual serious. A lot of your questions are answered by spending one day reading the manual/googling XBee tutorials (i.e. Tom Faludi ). If you have only 2 weeks I suggest starting today with that. You do not need to read it from front to end. Most is just detailed descriptions of each and every command. Important, but probably not immediately. The important parts are pin arrangements, line passing, difference between ‘Transparent’-mode/config mode/API mode. Don’t forget the XCTU manual that you can find on the Digi website. (I haven’t linked to it yet)You can have a look at the Explorer board schematic and fix up a clone yourself. But I guess that requires more time to figure out and bug-fix. Buying it (I suggest Xbee explorer USB) is easier, and known to work. The same with letting your microcontroller configure the Xbee. You can write a program making it (the microcontroller) send the propper commands to the XBee to configure it, and hope it is bug-free, or not troubled by timing issues. You need a way to visualize which commands are actually set, and how or what data is actually sent to or received on the other end. You cannot blindly trust your microcontroller(s) to do it perfect. Bugs are everywhere. Make sure your microcontrollers can send the data to a Explorer board (so connected to a PC just listening and one of your microcontrollers working with it’s Xbee) which shows it’s output on a terminal application (XCTU has one built-in). When that is correct, deal with the other microcontroller that is supposed to interpret the data. You either trust that the ‘commanding’ microcontroller works perfect (Bad Idea!!!), or you use a second Explorer-board to allow feedback to your PC of what goes on on the other side aswel. (you can have multiple XCTU programs listening on different ports) Guessing games are very inefficient. You don’t have the time for that in 2 weeks.
Well, I wouldn’t say that XBees or wireless in general is unpredictable. But when you start to get into network-design (even if it is only 2 devices) then it does get alot more complicated. Unpredictable things can happen if you don’t know what’s going on. Adding to this that you are learning how this all works, it becomes even more important to receive feedback from your devices.