HP iPAQ and Bluetooth Stack

  • Thread starter Thread starter Lonifasiko
  • Start date Start date
L

Lonifasiko

I've got a HP iPAQ h5550 and I've today noticed that this hellish
device does not use Microsoft's Bluetooth Stack. I think it uses
Widcomm's Bluetooth Stack. What a pain!
Therefore, I cannot use "open-source" libraries such as Peter Foot's or
OpenNETCF's.

Which are my options guys? Pay for a commercial DLL such as High Point
Software's BTAccess? I can't believe my eyes! Having an iPAQ is really
a pain when developing for it!

The problem is I must support as much devices as possible, but I think
it's very nasty to have to use a commercial DLL to some of them (iPAQ)
and Peter Foot's libray for the rest.

What do you experts think about this urgent issue?
 
That's the state of things. Where there isn't a defined standard, then you
get disparate interfaces to a feature. Widcomm chose to may it a for-pay
item. Honestly I don't see it as all that expensive - sure free is nice,
but if your product depends on a feature, a few hundred dollars isn't really
that much of an investment.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate
 
I know that a few hundred of dollars really can deserve. Also in my
case!

But I, as many other prefer initially to see what open-source libraries
are out there. And today I've got really angry when I've noticed that
Bluetooth Stack used by my iPAQ was different from others, from the
standard indeed.

Therefore, as far as I understand, the unique choice for supporting
Bluetooth in my iPAQ would be to buy Widcomm's library, wouldn't?

What about supporting many devices, with initially at least two
different Bluetooh Stacks? It would suppose two different ways os
accessing Bluetooth functionality. How do you see this mess in my head?
Are there any more Bluetooth Stacks?

Regards.
 
Believe me, I've always felt this kind of SDK should be free too! But
without our BTAccess product for $750, literally the only other alternative
for the Widcomm stack for the last 4 years is to buy the Widcomm SDK for
TWICE that price, a product which is far more complicated than ours and
which has far less technical support. Since many developers simply want a
way to make a connection we've also long offered a $30 BTConnect.exe
utility, which is very reasonable given the alternative.

It's like the TCP/IP stack situation for PCs in the 90's - there were 5 or 6
vendors, each around $800, and each one's SDK was different (FTP, NetManage,
3Com, Sun, etc). It was a nightmare writing a single app for sockets apps,
ifdefs everywhere. Then along came Microsoft's free Winsock and the other
products simply disappeared. Every year I've approached HP and Dell about
licensing BTAccess from us so they could give it away free, but no one has
ever been interested. Bluetooth is just not a priority for them. Even
though for 90% of developers the only functions needed are Search, Serial
Connect/Disconnect, CreateBond/RemoveBond, which would very easy to
implement in their ROM image.

It can't last. Microsoft has a free, working bluetooth stack with a usable
API, and Peter has an excellent set of free wrappers around that. About the
only thing the MS stack doesn't do is let you exchange business cards over
bluetooth - and when was the last time you needed to do that? So why would
an OEM continue to pay royalties to Widcomm, forcing developers pay more for
an SDK than they did for the device itself?

I've read that Dell's new device for Windows Mobile 2005 will be using the
Microsoft stack, and my hunch is HP will do the same (either with their
WM2005 upgrade or with their new devices due out next year). So we realize
that BTAccess's days are numbered, which is as it should be. Meanwhile we'll
continue to offer our products and support as long as there's a demand. We
still think it's a bargain compared to the alternatives.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Thanks Tim for your deep but concious explanation around all this
issues surrounding Bluetooth stacks and the different available ways of
accessing them.

Although my application is going to be mainly used by new devices (that
as you said will almost go towards Microsoft Bluetooth Stack) , I think
I would also support devices not upgradeable to Windows Mobile 5.0 (for
example, my iPAQ), all of them Widcomm's Bluetooth Stack. In that case,
I'm sure we'll use your library.

If I have any more doubts around this issue, I'll ask you if you don't
mind.

Really glad to have heard your explanation. Best regards.
 
What about supporting many devices, with initially at least two
different Bluetooh Stacks? It would suppose two different ways os
accessing Bluetooth functionality. How do you see this mess in my head?
Are there any more Bluetooth Stacks?
Click to expand...

Franson BlueTools supports both Microsoft and Widcomm

$100 to act as a client, $300 to act as a server (per project)

..NET, .NETcf and ActiveX components for desktop and PPC/WinCE

http://franson.com/bluetools/
 
The Franson Bluetools SDK just came out this week and they say it supports
both MS stack and Widcomm stack. It looks like a good SDK but still very
beta (some functions not working yet according to the documentaiton), but
more complicated than ours (25 classes vs. 2 classes). They have excellent
other products so I'm sure their support will be good too.

Yes, I am giving information about a competitor - I guess I have an
open-source soul in a capitalist's body.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Back
Top