Hi,

I'm currently working on an application which connects to a Bluetooth serial port and listens for incoming sensor data. The application works fine on the phones using the Microsoft stack but not on the HTC phones I got that use the WidComm stack.

The application is permanently connected to the serial port and listens for incoming wireless sensor data. When data is received an ACK is sent back to put the sensor back to sleep. Additionally it sends regular keep-alive message to "bridge device" to make sure that the bluetooth connection is still up and running. Due to the problems with large delays on incoming data, the bridge device also sends binary zeros on fairly regular basis to keep the bluetooth stack on the phone busy (I know thats very ugly, bot otherwise that one phone would wait up to two seconds before reporting the first incoming byte, which is completely unacceptable due to timeouts in the protocoll).

The problem on the HTC phones is that after a variable but rather short period of time (couple of minutes) where everything works fine, they suddenly seem to loose the connection to the device. Out of range is definitely not the case since both devices are only centimeters away from each other. In my debug output I can see that the phone doesn't even receive that zero bytes anymore which are sent every 500ms if I remember correctly now. After three unsuccessful "pings" to the bridge device, my application terminates that connection completely and tries to establish a new connection. On the Microsoft stack and during the initial phase of the Widcomm stack (before first connection loss appears) that works perfect. Trigger the bridge device and a couple of seconds later the connection is alive again. But on the WidComm phones from now on, most of the time the WidComm stack reports that it can't find the device at all when I try to connect to it. From time to time it will re-establish the connection though, only to loose it again within 2-3 seconds...

All the reading from the datasource (NetworkStream) is done in a dedicated listening thread, which also directly sends the ACKS back. Other requests are sent from different threads within the application. I used a lock { } statement to make sure only one thread at a time writes data though. I don't know if that maybe a problem with the WidComm stack ... maybe only one thread is allowed to read/write??? I could restructure my communications DLL to buffer all outgoing packets somewhere until the listening thread has time to send them, but a) it will create additional delays and b) I would have to rewrite quite a lot of code :).

Maybe somebody found a similar behaviour and has an idea/solution on how to debug/solve this kind of problem.

Many thanks in advance,

Markus

It is possible that is is threading related. :-(  I haven't had reports problems with writing data (only with listener accepting connections) but perhaps noone is writing from multiple threads...

Threading is a subject that the Widcomm documentation doesn't cover very well, and I was not pessimistic enough when I first wrote the interface. :-(  I was very very careful about providing a thread-safe library, so I do locks and etc where required.  What I did not do was assume that Widcomm was not thread safe.

We've found problems subsequent testing.  So, firstly that we shouldn't do anything complex on the Widcomm callbacks, in particular not to call back into Widcomm. In current repository code we have all callbacks re-raised on a .NET threadpool thread.   If you are using Stream.Write, and not Stream.BeginWrite, similarly for Read, then as far as I can see that won't affect you.  Ohh see lots of discussion on the blog http://32feetnetdev.wordpress.com/

Secondly on Win32 there is a line in the documentation about the "application main thread".  So back in 2.5 we changed Win32 to use one thread, based on one sentence on its documentation (not in WM/CE documentation).  This could likely be enable in WM/CE if required.

Is there any way you can do a quick test to see if threading seems to be the problem.  Perhaps there's something else about the connection going wrong...  Anyway I'll look at enabling the single-threading on NETCF.

 I changed the code today making sure that all reading/writing from the datasource is done in the same thread. So far it looks like that solved it. Left it running over night in the office now to see if it keeps stable... Still got a problem on the HTC HD2 though, but I think that the Bluetooth support in general is faulty on that phone. It doesn't even find any other Bluetooth devices anymore... (not with 32feet.NET or using the builtin dialogs from HTC).

Will report status of the Touch2 tomorrow after reviewing the logs generated over night. Already thanks for pointing out that threading could be the issue here...

Thanks for letting us know, that's really interesting.  But sad. :-,(

I have a first version of single-threading working on NETCF.  I'm worried that its quite a bit slower however.  I'm away for the rest of the week but I'll do some testing when I get back.

Looking forward to see what more you find.