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