SparkFun Forums

[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?

[DarioG]

Well, you can always add your own checksum (16bit at least) and use those transceivers.

[Krogoth]

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.

[stevech]

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.

[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.

[stevech]

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.

[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.

[stevech]

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

[mzoran]

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
1. Nordic or generic RF
2. XBee/XBee Pro
3. Bluetooth

[stevech]

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.

[riden]

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.

[linuxguy]

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.

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 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.

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

[mzoran]

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.

[mzoran]

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.

[riden]

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.