BlueTooth stacks (WidComm, BroadComm, MS) (peter?)

[Yechezkal Gutfreund]

This probably a Peter Foot question....

We are going to be trying to interface a couple of different devices (GPS,
laser rangefinders, etc.) to a PDA.

We are tempted to buy the Dell Axims with the WidComm (is it now BoradCom
stack? since Widcom was bought by BroadCom?).

Newer Ipaqs (VGA) list BroadComm as the stack.

Does anyone have any kvetches or preferences that can lead us to buy
equipment that has a better bluetooth stack protocol? (better meaning easier
to use!).

We also are aware of things like btConnect and McSoft BlueThunder for
working with the stacks, but we don't really know what they are needed for
exactly or which are better.

(Sorry, it is pretty clear we are novices in this area, from the above
questions).


--
==================================
Yechezkal Gutfreund
Chief Scientist
Kesser Technical Group, Inc.
==================================

 

[Peter Foot [MVP]]

Yechezkal,

It really depends at what level you want to work with the devices, for
example bonding the device and setting a virtual com port may be sufficient.
There are two main stacks available, the Microsoft one and Widcomm/Broadcom.
They both have very different programming models, and both have advantages
and disadvantages, the Microsoft stack has a free documented SDK, but the
Widcomm/Broadcom stack has support for a wider range of profiles.

What specifically do you want to achieve? you mention both GPS and
range-finder devices, do you need to work with multiple devices connected at
the same time, are you using an external application/library to process the
raw GPS data?

Peter

 

[Yechezkal Gutfreund]

Minimally, we are looking at the following setup

1. Dell Axim 30 (or equiv) with WidCom stack talking to these two Bluetooth
devices simultaneously

A. Nokia 6820 - for internet tcp/ip service to the PDA (we use the AT&T
Communication manager on the
PDA which can connect and use the Nokia cell phone as a modem to the
internet. We believe it is using
a serial connection to do this

B. Delorme EarthMate GPS Bluetooth logger. We can confirm that this can
be done in isolation (without #A)
over serial port #7. We are getting a solid feed of lat/long
positions. We are currently having problems doing
both #A and #B.

We using J.W. Hedgehog's GPS library (written for .NET in C#).
http://www.jwhedgehog.com/

The GPS device provides a continuous stream (text) over the serial point of
GPS track points. The cell phone is providing a variety of open TCP sockets
for inter-player communication.


In the future we will also want to tie in a sony Bluetooth camera and a
Leica distance rangefinder. We can provide model numbers, but let's see
about just the first basic two items.

 

[Peter Foot [MVP]]

If you definately need simultaneous connections then simple virtual COM
ports might not be suitable, on most devices you are limited to a single
incoming and single outgoing COM port (although it is possible to register
ports with other prefixes) - this may not be an issue with Broadcomm, but
you have another issue with the broadcomm software giving you a choice of
devices when you try to establish a connection, this can be overridden with
some of the software libraries available. The OpenNETCF library will allow
you to establish a Socket connection to each device and you can send and
receive bytes using fairly familiar Socket programming for the MS stack
only. For Broadcomm support there are a few options, at the one end is their
own SDK which is rather costly, but there are some other offerings e.g.
http://www.high-point.com/ which offer good all-round functionality.

Peter

 

[Yechezkal Gutfreund]

Peter, we are taking this a step at a time and seeing when we fall of the
cliff.

Friday, we were able to get an iPAQ 3950 with the Widcom stack to talk both
to a Nokia 6820 (via Bluetooth) and keep an internet connection while
receiving
1hz GPS info from our EathMate GPS that was also connected via Bluetooth.

So it seems that we might be able to use serial port connections and not
have to
go to the socket based model (yet!). Not that we have any real problem with
socket
based programming. We just want to get to demo-ability as quickly as
possible.