I’m looking to establish a wireless serial data link between my robot and my PC. I’ve used the inexpensive RF transmitters and receivers (like http://www.sparkfun.com/commerce/produc … cts_id=872), and I must say, they are pretty good, but don’t provide error checking, so they are not completely reliable. I’m thinking about using bluetooth or XBee, but I’m not quite sure I understand the differences and advantages of each. Which is a better choice for someone who wants to create a wireless serial data link between their PC and their robot?
Well, you can always add your own checksum (16bit at least) and use those transceivers.
Bluetooth: FAST (50KB/s+ transfer rate), already internal to most laptops, modules connect directly to PC, short range (100m for Class 1, 10m for Class 2), CRCs and error correction.
XBee: Slower, need circuitry to connect to a PC, 1 MILE range, CRCs and error correction.
Personally I’d go for the XBee, since the longer range means you’ll get a more reliable signal indoors and you don’t need anywhere the transfer rate of Bluetooth. If you can get a dev board with USB or RS232 then connection to the PC is much easier, otherwise you’ll have to roll your own with a MAX3232 or equivalent. That said, you can just add error checking to those cheap sparkfun modules like DarioG said.
steve joblin:
I’m looking to establish a wireless serial data link between my robot and my PC. I’ve used the inexpensive RF transmitters and receivers (like http://www.sparkfun.com/commerce/produc … cts_id=872), and I must say, they are pretty good, but don’t provide error checking, so they are not completely reliable. I’m thinking about using bluetooth or XBee, but I’m not quite sure I understand the differences and advantages of each. Which is a better choice for someone who wants to create a wireless serial data link between their PC and their robot?
XBee - super simple. Low cost. No PC side drivers.
XBee without ZigBee = simple.
XBee is but one of 10 or more interoperable modules for 802.15.4.
No debate.
The big advantage of Bluetooth, IMHO, is that lots of PCs, laptops, phones, PDAs, etc., have Bluetooth built in, which means you can talk to your robot from all those things without additional hardware.
wiml:
The big advantage of Bluetooth, IMHO, is that lots of PCs, laptops, phones, PDAs, etc., have Bluetooth built in, which means you can talk to your robot from all those things without additional hardware.
Not so simple when you try to use the Bluetooth Serial Data Profile, at least when I tried.
XBee or equivalent in 802.15.4 (no ZigBee) mode has Hayes modem AT commands and has no PC drivers at all.
And Bluetooth modules supporting serial interfaces are 2 or 3 times cost of XBees.
Just relating my experience.
I haven’t had any trouble using the serial profile, the remote device just shows up as /dev/ttyblahblah.
I agree that if you don’t need connectivity with random devices like that, then 802.15.4 is probably a better choice.
wiml:
I haven’t had any trouble using the serial profile, the remote device just shows up as /dev/ttyblahblah.I agree that if you don’t need connectivity with random devices like that, then 802.15.4 is probably a better choice.
/dev/ttyblahblah sounds like Linux/Unix rather than Windoze
I would personally stay away from bluetooth. The modules are expensive and very unrealible. I’ve been trying to use bluetooth off and on for a robot project for awhile and I’ve been alittle frustrated.
One problem is that the timing is very unpredictable, you need to deal with encoding the data to prevent hitting the escape sequence, and performance seems to be very dependent on the bluetooth module and stack on the PC.
Personally, if you just want to control a robot I would use a RC car controller. That’s what I did first. You can capture the PWM from the radio controls and have the microcontroller on the robot generate the signals to control the robot based on the captured data.
If all you want to do is sent control information to the robot and receive telemetry information, generic RF modules like the nordic or Linxtechnologies modules are great. You just periodically send a control packet and receive a telemetry packet as a reply. You can have your own checksums and if the checksums fail just throw out the data untill the next packet. With something like a robot it’s better to have strict timing requirements and have errors( or data loss ) then it is to have retries(Bluetooth SPP ).
I think the XBee would be the next chose since from my glances at the documents it has a packet mode. This is closer to what you want for a robot then a serial cable replacement.
Here is my stack ranking
-
Nordic or generic RF
-
XBee/XBee Pro
-
Bluetooth
with the $19 ea Xbee/XbeePro or any of the many competing equivalents, you have this much communications protocol work to do and code and debug:
zero
It’s a Hayes modem from the serial port viewpoint. Just use it. Set the baud rate and destination network address for each packet or a session using +++ AT commands.
Over the course of many projects I have used inexpensive RF links, Bluetooth modules, and most recently the XBee modules. Without a doubt the XBee modules have been the most painfree and easiest to use. They work just like stevech has said. I was pleasantly surprised to learn (actually to remember) that the XBee modules have general purpose I/O ports and ADC channels as well as two communications. If you need bi-directional communication, the choice is clear.
Interesting. It doesn't seem like they are all that difficult to hook up and use. I'll soon have one of the new [[Bluetooth DIP Modules](http://www.sparkfun.com/commerce/product_info.php?products_id=8469) based on the NXP BGB203 Bluetooth chips. We'll see how I do with it. :) I also ordered the large 2.4 GHz antenna for it. :Dmzoran:
I would personally stay away from bluetooth. The modules are expensive and very unrealible. I’ve been trying to use bluetooth off and on for a robot project for awhile and I’ve been alittle frustrated.
I will be adding this to one of my robots. One of the main uses will be to see and capture debugging output as the robot is running around. This is a fully autonomus two wheeled rover.
8-Dale](http://www.sparkfun.com/commerce/product_info.php?products_id=8469)
First of all, for some problems a serial line replacement is not the correct answer. Sometimes you are sending large amounts of binary data and the extra bandwidth needed and extra processing time to encode and decode the data is too much. Sometimes more control is needed.
XBee does have an API interface as an alternative to transparent mode. Maybe this is better.
For this topic, we are talking about building a robot which is clearly a hobbiest project. Sometimes half the joy of working on that stuff is figuring out things for yourself. If you want a canned system, go buy one of the many prebuilt or mostly prebuilt robot kits.
From a professional point of view, building on top of a high level black box module can be more challenging and time consuming then developing things yourself. I know this from professional experience. Often bugs and limitations in commerical projects are kept very quite so that a customer doesn’t find them until they have made commitments and invested a good amount of resources. Sometimes the documentation only tells you 20% of what you need to know. Often when these modules don’t work, you spend a huge amount of time scratching your head. Then when you do find out the undocumented limitations you usually don’t have many options.
When you develop something yourself or when you at least have source code that you got from someone else, you can debug it and actually fix it yourself without resorting to gross hacks. Sometimes just being able to step through code even if you don’t want to modify it can assist you in finding bugs in your own code. That’s why source code to operating systems and runtime libraries are available for debugging purposes if you are willing to pay for it.
That said, I wonder how the XBee modules compare to using a generic RF module and using a freeware zigbee stack like the one that Microchip provides for PIC chips. My understanding is that like the TCP/IP stack you can do whatever you want with it as long as you only use it on Microchip products. Hobbiest and researchers generally don’t need to get the project through FCC complience tests.
I reread my posting after posting it, and I think I was blowing off alittle too much steam sorry.
If you are going to go with a canned module I would definatly recommend the XBee over bluetooth. I’ve heard many good things about it and like I said it has a packet/api mode as an alternative to serial cable replacement.
This just hit a big thorn in my side. Sorry.
mzoran:
I reread my posting after posting it, and I think I was blowing off alittle too much steam sorry…This just hit a big thorn in my side. Sorry.
You make some good points and I don’t disagree with your arguments. As a long time radio amateur operator, I have built a lot of my equipment as well as being an “appliance operator” who purchased some ready made rigs. I also agree that you can learn a lot by developing your own solutions. My first foray into embedded wireless was using the inexpensive RF links. I spent a great deal more time learning about the “quirks” with the technology, but in the end I had a working project and gained knowledge. It is a matter of balance between the rewards of gaining knowledge versus the time (and frustration) of the process. You want to strive for a sense of accomplishment and avoid the feeling that you wished you never started the project. 
I may be biased… I usually want to spend my time on the application objective. It is possible with the Xbee/XBeePro, to add code to their microprocessor. I don’t recommend it unless you are doing a very, very cost-sensitive product. There’s a long learning curve and the cooperative OS must keep up with the timing demands of the MAC. So a separate microprocessor for the non-trivial application is what I’d recommend. I just did a project like this, where the XBeePro’s were plugged into a $40 baseboard from Coridium on which there is an ARM7. (For many needs, a much cheaper/simpler processor would suffice). My rapid-application was a 1,000 lines of code running on the ARM, and the XBee was just a transparent modem, however, the ARM changed the PAN network node destination MAC address to send messages to either the coordinator (addr 0) or a specific node, or a do a broadcast - I had 12 such devices running, battery powered, for a complicated proof of concept test, using 250Kbps (or net 80-120Kbps after overhead).
I’ve done this same kind of thing, to a lesser extent, with Xbee-equivalents from SiLabs, ZMD, Jennic and plan to try Meshnetics (Atmel chips). The nice thing about 802.15.4 with or without the ZigBee stack, is the IEEE standard MAC/PHY, unlike all proprietary prior low power bi-directional chips. (I leave Bluetooth out, due to cost and PC/PDA-centric protocol stacks on one side of the link).
Other people may want to rediscover how certain MAC and PHY layer communications work. For this, I think you are better off buying a development kit from TI, Ember, or FreeScale (XBee series 1 are based on FreeScale). As a practitioner in wireless for years, it’s best to hit the books on MAC and PHY rather than tinker and code.
Each has it’s own strengths and weaknesses for a given application. What are you trying to do with wireless?
8-Dale
I completely agree with that, just that it isn’t 100% clear to me that using turnkey solutions is a time saver in the long run. Instead of rediscovering MAC and PNY( something generic, relatively well understood and changes slowly ) you need to rediscover how to interface with the modules and various quirks of the module( something that changes very rapidly ). Often these quirks are undocumented. The module is a black box. Black boxes are hard to work with.
I think turnkey solutions are mostly used in cases where a company or an individual doesn’t have either the knowledge or the inclination to acquire that knowledge about something( For example you want to quickly RF enable an existing project yet don’t want to recruit an RF engineer .) I’ve taken apart many commercial products yet very infrequently do I find a turnkey solution.
For example, I’ve been trying to get the old bluetooth DIP module to work with a serial camera using a PIC as glue logic for a robot project for awhile. Yes, I got something sort of working very quickly, but as I try to polish it it has become more and more frustrating. Crashes/Hangs on the PC side in various Bluetooth stacks, unpredicable delays in the transmission, cost of encoding data to avoid escape sequences, unexplained failures of RTS/CTS hardware based flow control, unexplained loss of data, and a quirky command set. BlueRadios is a small company so that may be part of the problem. Maybe the Phillips/NXP modules are better. I don’t know.
The 250kbps of the XBee is a bogus number. That might be the RF speed, but the external UART can do a max of ~115kbps( port speed ). Then you have to consider how often flow control is engaged and lastly the encoding and decoding cost. What end to end data rate are you actually getting? You also have to consider that while the module “pretends” to be full duplex, the underlying system is only half duplex which can lead to traps if you are not careful. What you don’t know about really can hurt you.
In the past I’ve used the Linxtechnologies HP3 modules and the Semtec XE1205 modules. Both of them have direct access to the FSK modulator/demodulator. The XE1205 modules allow full access to the frequency in 500Hz increments and even the frequency deviation and baseband bandwidth. Both have a out of band mechanisms for control so that module configuration doesn’t get mixed in with the data allowing for complete freedom in data encoding. I learned alot about how to implement frequency hopping spread spectrum on these modules which is something I haven’t been able to find a whole lot of information about on the web. I’m putting an order in today for the nordic modules from SparkFun as they allow similar control but at a lower cost with RF datarates upto 1Mbps. Software is something I have alot of knowedge about yet don’t have the equiptment to assemble or debug the analog components of modern high frequency RF equiptment which can easily exceed thousands to as much as hundreds of thousands of dollars( oscilloscope that can view GHz signals).