Hello ! What is the most inexpensive, yet stable robust and relatively fast micro-controller + wireless setup?
I have been asking this question to myself for way too long... Now, I'm curious of your experiences in the different flavors available..
In my specific situation talking back and forth to a computer or laptop would be the primary objective.
Bluetooth For the computer this is great (because often there are no needed parts - most modern computers or laptops come with bluetooth) - so that makes it cheap on the computer side $0
#3 I've tried 2400 RF modules with BBB - I would say "not very stable" - "FritsMayHaveSavedHisHairButThisThingIsNotThatStableNorFast".... and there is always contention with Servos (Grrr)
#4 I made a IR transciever which worked off my computers serial port and its twin for the BBB - was very slow, not that stable.. bit banging solutions always seem problematic...
#5 MSP420 $5 + CC2560 ? @ 2.6 Ghz
#6 MSP430F5438 Experimenter Board - $149 (too spendy .. and not even on the market yet..)
Ok, I would say first off, that the question is between X-bee and Bluetooth. Lets get through the obvious (much of which was covered above --and-- in no particular order)
(It can be assumed that I am talking about a “BlueSmirf”)
Xbee requires breakout boards to deal with the metric pins
The Xbee on the computer end is going to need a USB thingie/breakout board
Bluetooth is built in to most lappys now and/or dongles are wicked cheap $2
Bluetooth from uC to uC is not readily available (uC to computer only)
Xbees from robot to robot is super easy
Xbees are built for swarms and mesh’es and do it well (if you can figure it out)
Xbees have a TON of handy stuff, ADC’s and extra I/O’s --all neat
Bluetooths eat 115,200 for lunch --Xbee’s (at least the basic models) seem to want to top out at 38,400 or so
Any, if not all, work done with a smart phone or tablet will be Bluetooth
(Back to the breakout boards) Bluetooth usually comes with a standard row of pins for connections
Xbees can be addressed (via the xbee itself, not within your code)
2 Xbees is just slightly more money than one basic BT unit (again, + the breakouts)
BT plays nice with 3.3 and 5v
X-bees do not play nice at 5v (well, they do, but only once)
Personal experience:
(It should be assumed that all communications were done with the Tx and Rx in the same (average sized) room)
I have used both Xbee and BT with picaxe, arduino and propeller all with fantastic results. I have not found any difference in performance between either the uC platforms or the Xb/Bt units themselves. --Other than the fact that I was able to go faster with the bluetooth. That said, when running within their speed “limits”, I have never lost a single byte of data (using either one) nor lost a connection. For me, this is the whole picaxe/arduino argument all over again. I think they are both great and both have their place. If my intention is to do any kind of PC/robot communication, I will go BT every single time. If I intend to go robot/robot or transmitter/robot I will go with X-bees every time.
Specific units:
I say go cheap. I would think that the vast majority of us are going to have the Rx and TX unit in the same room. In this case, I see no reason to go “Gold” on the BT or “Pro” on the Xbee. I use the basic models of each and never give them a second thought. I would also add that if an upgrade on the Xbee’s is desired, one would be well served by skipping the series 2 and going straigh to Pro. The series 2 are a spectacular pain (almost impossible) to configure for 2-way communication, and very little info exists on how to solve this problem. I know it has been done, but I could not get it to go and I personally wasted much time in trying. That said, series 1 and pro’s are good to go.
I disagree with Chris’ limitied list of solutions. I know I’ll catch hell for this, but don’t count the msp430 solution out…I noted that you had a couple on there, but I think the one I mention below might be closer to your needs.
The msp430 solution is a very valid and with the deals that they have on the kits every so often, you could possibly pick this one up for $25-$30. At it’s regular price, it goes for $55 at mouser. This is a nice kit with the target boards(you get 2) containing a proc(msp430f2274) which is very capable(hw uart, i2c and spi) as well as the cc2500 2.4ghz rf tranciever. The kit also comes with the programming and interface board that you can easily use as a passthrough for data via serial port(check the userguide doc for more info on this). Mind you I seem to be one of the few on this site that uses the msp430 procs, but this kit would seem to be a good option.
as far as price goes you have a lot more room to save on wireless than on a microcontroller, so I think any micro with a hardware serial port in conjuction with a cheap bluetooth module with serial port profile is a winner! I haven’t used the linked $10 bluetooth module but I intend to.
That’s what was frustrating me… SparkFun has had Smirfs for ages but they are always @ $40 to $50 a unit… seemed frustrating when the uC is less than half that price.
So now we are looking at :
115K Serial with no Servo contention, Computer->Robot with a BBB $16 + Cheap BT $10 = $36 a unit
Thanks for all the information CTC and advice. I have successfully avoided Xbees because of their price and voltage requirements. I am interested in swarming, but all the information will either be directed by the computer or routed from one robot through the computer to another robot…
Its encouraging you have had solid results with both, now to see if Rogues super cheap BT example is just as solid !
It says these modules have password 1234 … which is fine, but what about BT identifiers? Do they all come with unique IDs like ether MACs? or can the id’s be programmed?
Everyone gets their own mac address. I will do some tests but I am pretty sure they will just show up as different com ports and thus, eclipse or processing would simply run multiple serial lines. --one for each unit.
you typically can’t reprogram a bluetooth MAC address, but they should be different. on the other hand you can likely change the module name which shows up during a search, but that feature is module dependent.
I’ve found the bare Bluetooth modules are difficult to solder even with a microscope and surface mount soldering station, I really don’t like the half via pins they use. The four dollar premium for the presoldered breakout board is worth every penny to me.
in windows each bluetooth device with serial port profile will have a unique COM port associated with it. You can discover it by right clicking the bluetooth icon in the windows tray and clicking Show Bluetooth Devices, then right click the bluetooth device and click properties. Then by viewing the different tabs of the properties window it will show a COM port for the Bluetooth services offered for that device. Helpful when you have a swarm and you need to determine which device is communicating on which COM port.
By the fact that Windows (or other OS) understands them as seperate devices was the part I was concerned about. When I get the pieces together, I suspect that MRL will ask each uC who it is. That way regardless of how the OS identifies the BT/Com devices, MRL will identify with the uC’s response and bind them with the appropriate SerialService during runtime.
In the past I have seen com ports register differently depending on bootup, and many other variables.
But having the uC respond (as long as there IS a connection) would allow identification of the each uC consistently…
Good for when the bots have slightly different capabilities, e.g. IR sensor on bot #1 vs WiiDAR on bot #2 vs Servo gripper on bot #3…
