Possible Bluetooth SerialPort Issue?

[Jerod Houghtelling]

Hi all,

I'm new to Bluetooth programming so if I've missed something obvious
please feel free to body slam me. This could also possibly be a
threading issue that I'm messing up.

I have a Bluetooth device that I'm able to connect/read/disconnect
from all just fine. The problem I'm running into is that I would like
to detect when the Bluetooth device is powered off or taken out of
range. To further my problem, programming should be generic if
possible (all Bluetooth stacks must work: WIDCOMM, MS Stack, etc).

Through my testing I have found that the PinChanged event is fired
when the device breaks the connection. I'm using that in combination
with the CDHolding flag to determine if the connection was dropped.
Does that sound logical?

That seems to work fine and dandy, but now comes the problem of
reconnecting. When stepping through in debug mode I've found that the
connection port remains open. So, logically I would think the port
should be closed. When I call the close method an IOException is
thrown (which I'm catching) and then the thread dies. Does any body
have a clue why the thread dies?

As a work around, I've tried to close the port on a background thread,
which sets the IsOpen flag to false so I can call the open method
later. Although this method also terminates the thread unexpectedly! I
think this is a horrible hack and I'm not comfortable putting it into
production code. [This work around not shown in the following code.]

Here is some halfway stripped down test code.

using System;
using System.Diagnostics;
using System.IO.Ports;

namespace BlueToothTest
{
public abstract class SerialBase
{
#region Constructors

public SerialBase( string port )
{
mSerialPort = new SerialPort();
mSerialPort.PortName = port;
mSerialPort.BaudRate = 19200;
mSerialPort.Parity = Parity.None;
mSerialPort.DataBits = 8;
mSerialPort.StopBits = StopBits.One;
mSerialPort.DtrEnable = true;
mSerialPort.RtsEnable = true;
mSerialPort.PinChanged += new
SerialPinChangedEventHandler( _HandlePinChanged );
}

#endregion Constructors

#region SerialBase Members

public string PortName
{
get
{
return mSerialPort.PortName;
}
set
{
if( !mSerialPort.IsOpen )
{
mSerialPort.PortName = value;
}
}
}

public void Connect()
{
try
{
if( !mSerialPort.IsOpen )
{
mSerialPort.Open();
}
}
catch
{
Debug.WriteLine( "Open command failed" );
}
}

public void Disconnect()
{
try
{
mSerialPort.Close();
}
catch
{
Debug.WriteLineIf( mSerialPort.IsOpen, "Close command failed" );
}
}

#endregion SerialBase Members

#region Events

public event EventHandler ConnectionLost;

#endregion Events

#region Private Members

private void _HandlePinChanged( object sender,
SerialPinChangedEventArgs e )
{
if( e.EventType == SerialPinChange.CDChanged && !
mSerialPort.CDHolding )
{
OnConnectionLost();
}
}

#endregion Private Members

#region Protected Members

protected SerialPort mSerialPort;

protected void OnConnectionLost()
{
EventHandler handler = ConnectionLost;
if( handler != null )
{
handler.Invoke( this, EventArgs.Empty );
}
}

#endregion Protected Members

}
}

In the calling program I'm catching the ConnectionLost event and
trying to disconnect the port. I would eventually like to actually
disconnect the port in the _HandlePinChanged method before calling
OnConnectionLost.

void _HandleSerialReaderConnectionLost( object sender, EventArgs e )
{
if( InvokeRequired ) //TODO: Rework to Invoke speical UI method
{
Invoke( new EventHandler( _HandleSerialReaderConnectionLostUI ),
sender, e );
return;
}

mSerialReader.Disconnect(); //Inherits from SerialBase
MessageBox.Show( "Serial Port Connection Lost" );
}

When stepping through in debug mode these two messages are received
when mSerialPort.Close() is executed.

A first chance exception of type 'System.IO.IOException' occurred in
System.dll
The thread 0x127f3f26 has exited with code 0 (0x0).

Sorry about the lengthy post and thank you in advance,
Jerod

 

[Dick Grier]

Hi,

IMO, Bluetooth implementations vary, even when using the same stack! BT,
just seems to be technology that isn't quite finished -- after all these
years.

I suspect that your "hack" is as reasonable as any approach. And, no, there
is no assurance that things won't change in the future. Perhaps changes
will improve "things."

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.