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…
The distributer did not dicern the difference between “host” and “passive” modules when I purchased them. I ordered 6 and they randomly sent me 5 host modules and 1 passive. Now, I see that they make the distinction and are selling them seperately. Grrr… the passive ones are more useful for me… I’ll be ordering more passive units…