Hi guys,

First, thank you for the great product you guys build here :-)

I'm currently in the process of writing up an application that communicates via Bluetooth. I thought I had all bases covered, as it worked great with the Microsoft stack on both Windows Mobile 6.1 and Windows 7. When I tried to run my app on a phone that runs the WidComm stack, some minor problems occured (setting radiomode for example - which is easily solved) but I ran into another issue.

Using the MS stack, I open a connection to my notebook via BT send some stuff, reply if it was ok or not, and it all works.

Now using the WidComm stack, I open a connection to my notebook, send some stuff, but when I want to send the reply, the "Input PIN" screen pops up on the phone saying it needs to pair before it accepts the incoming connection. I have no clue how to solve this (been messing with SetPin but no luck there). My notebook and phone both use the BluetoothClient and Listener from the 32feet assemlby.

Are there any differences I should account for when sending data to the phone which is running WidComm? or maybe a solution is already available?

Ok, little update. I solved the issue with the PIN authentication by re-using the connection the BTlistener had accepted on my notebook so that all traffic is sent across one connection instead of reconnecting every time. A new issue now popped up. The networkstream used by the BTclients is very inconsistent. The first time I send data to the notebook all works well. But when I write data back trough the networkstream (in about 80% of all tries) it does not reach the phone :-\ No data is recieved at all. But in some cases, data is received fine and is complete as well. I've been trying to figure it out but I can't find any clues to how to fix it Edit: Just tried it on a phone running the MS stack, and it works flawless. Widcomm stack however... about a 20% success rate... when sending-then receiving some simple string data :-(

Glad to hear you are making progress.

Maybe the section in the (current) user guide applies:

In all situations there is no guarantee that any call to Stream.Read will return the full number of bytes requested in the count argument.  This is particularly the case on NetworkStream and SerialPort Stream etc.  The Read method is allowed to return as soon as one byte is available.  One must thus always use the return value, looping until the required number of bytes has been received, see the example below.

If you read again I suspect you'll find your missing data, or perhaps its in the buffer returned at a previous read...

I based my reading code on the example found at the link in the documentation (the section you refer to) I have set a very small buffer size to make sure the the Read(..) method is called at least 2 times to get the complete result. The strange thing is, when I write data to my notebook, and then halt the writing back on the open connection, the stream.Read(...) method on the phone will block, because there has to be at least one byte read to unblock it, so there is data coming back, but it's all empty on most cases when on the Widcomm stack. The example works great on the MS stack, but on the Widcomm stack it's anyones guess :-P Sometimes I get the whole thing, and the next time I get nothing. As sort-of a hack I added a very basic retry mechanism that keeps re-requesting the results until it eventually returns what I expect, but that can make it very slow because there is no telling how many tries it takes :-D

In the Microsoft case it might be that it can receive larger chunks over data over Bluetooth that Widcomm, and thus if any of the data is there its all there -- unless sometimes that the send length is greater than the maximum transmission unit and it overflows to two chunks again...

Its normal when doing network programming to add a "protocol" onto the data stream, for instance adding a length byte before each piece of data, or adding a separator, for instance HTTP, FTP and SMTP are text based and each mark the end of each command/response with a newline.  Perhaps you could add something like that to your stream.