logo       

Re: for robots and industry: BlueTooth bad, Zigbee good - thanks for res: msg#00011

hardware.lego.robotics

Subject: Re: for robots and industry: BlueTooth bad, Zigbee good - thanks for response

At 01:47 PM 6/1/2005, Bruce Hopkins wrote:
I'm biased, so here's my rebuttal:

I should have made it more clear that all my BT remarks were in the context of use in the industrial or embedded spaces such as robotics where we get access to the hardware. Sure, millions of BT cell phones are shipping, but that's no help to this robotics group. BT may be fine in other spaces, but in the embedded or industrial space - I still don't see any traction there.


1. The JB-22 is a great, affordable Bluetooth development kit under $200 USD.
http://www.javabluetooth.com/jb22.html

Wow! Thanks! This is the most interesting BT device I've ever seen. I was wondering if JSR-82 was going anywhere.

Have you used them?

So if you then want to add BT to a robot (which is not a USB master), then what? You'd want a JSR-82 compliant chipset or pluggable module with a serial, parallel, SPI or I2C interface.

This kit looks mainly aimed at PC to PC or PC to existing BT device development, rather than "add BT to your hardware"


2. Class 1 Bluetooth devices have a range of +300ft. Anycom makes one
that is rated at 330ft, but tests have shown that it can communicate
at 500 ft.
http://www.anycom.com/anycom/products/prod_main.php?prodid=CC3035&lang=us

Also very interesting. They don't list power consumption, but it must be less than 500 mA to work off the USB 1.1 port.

So to what other devices can you connect?
http://www.javabluetooth.com/jsr82devices.html
Just cell phones, that's all.
No embedded control or industrial devices.

Do you think this will change?

3. Bluetooth services can be cached, and connections from clients can
be made without the latency of device and service discovery.

I don't know enough about how that works to comment in detail. If you do this, what then is the connect time from a sleeping state?


4. Cell phone vendors (Motorola, Nokia, SonyEricsson, etc) do NOT
cripple Bluetooth functionality. Blame that on the mobile networks
(Sprint and Verizon are notorious).

True, but the end result is the same - seen from the eyes of the users, BT doesn't deliver what it promised. There's no way the user can undo the crippling, so we're stuck with BT devices which can't do anything.


5. Bluetooth has a VERY strong momentum in the industry. Over 5
million, Bluetooth devices ship per week. No, that's not a typo; 5
million devices per week:
http://www.bluetooth.com/news/releases.asp?A=2&PID=1521&ARC=1

Regards,

Bruce Hopkins

From the above these are going into:
"mobile phones, cars, portable computers, mp3 players, mice and keyboards"

Nothing in the industrial or end-user-programmable embedded space.

These are all mass-market devices sold by a relative handful of large companies and the end users can't change them. So it's like point and shoot cameras vs DSLR. For embedded systems and robots we need to be able to fuss around with the BT device, or at least access its (hopefully standard) API. Like JSR-82 and the BT USB slave you mention above.

Thanks for the reply.

Now I recognize your name: Bluetooth for Java, by Bruce Hopkins and Ranjith Antony

So -- what's your take on the future of BT in applications accessible to developers (that is, not the canned mass market apps like cell phones)?

Thanks

Bruce (the other - Bruce Boyes)

------- WWW.SYSTRONIX.COM ----------
Real embedded Java and much more
+1-801-534-1017 Salt Lake City, USA





<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise