views:

49

answers:

1

I encountered an unexpected behavior while debugging a WinMo 6 program last night, and I wonder if I was dreaming. But first, some context.

The program communicates through a serial port with a GPS device. It uses either a physical port with cable, and also tries via Bluetooth. After a suspend or power-off, I don't need to close and reopen the port if it was using the physical link. However, if using Bluetooth, I need to reconnect : no bytes are transmitted with the old handle. Reopening takes about 6 or 7 seconds, so the app is not usable right away after a suspend on Bluetooth.

However, I remember one debugging streak where my Bluetooth serial port would be still valid and functional after several power-off/power-on cycles, and it surprised me pleasantly. I cannot reproduce the behavior now. Was that a bug in the BT driver?

Any hints you have about configurations or API to try would be great, if you ever got that to work.

+1  A: 

The Bluetooth protocol is designed such that there must be communication between the GPD device and your Windows device at least once every few seconds. If the communication is not present, then the link will time-out and must be established again from the ground up.

And secondly, there is the way in which you perform the power cycle. A properly implemented Bluetooth stack will explicitly close-down any open connections if it goes into a power-off state in a normal way.

In short, a Bluetooth connection is not meant to survive across a power cycle, so your program must be prepared to re-establish the connection to a remote Bluetooth device after a power cycle.

Bart van Ingen Schenau
Yes, however, I would believe most of the layer states to be conserved and the connection more quickly reestablished. Maybe also that the handle would become functional again. Is there even an API call to determine if a port handle has become invalid? After a suspend, ReadFile/WriteFile on that handle return true, but have no discernible effects.
joelr
@joelr: When a physical Bluetooth link is disconnected, all logical links on top of that are fully reset as well. As the serial port emulation has to be negotiated between the two devices, there is no distinction on Bluetooth level between an initial connect and a reconnect. Unfortunately, I am not that familiar with the Windows-Mobile API, so I don't know how you can tell if a handle is still valid.
Bart van Ingen Schenau
@Bart: Windows Mobile is supposedly designed so as to make suspends transparent to the programmer. I have implemented a Bluetooth stack last year and understand Windows Mobile and my other device certainly close the connection, internally. However, I supposed WinMo would automatically retry establishing the connection on resume since one handle is allocated by my program. This is what I'm really after right now : the OS abstraction of the port emulation, not the actual physical link.
joelr