none
Detecting Status of Bluetooth COM Ports RRS feed

  • Question

  • Hi,

    We have a VB app that communicates over COM ports.  We need to be able to detect if the COM port has failed, then warn the user, and stop any future use of the port within the app.  This works well when we are using Virtual COM ports over USB, as we can monitor the status of the connection using the SerialPort.IsOpen property.

    However........... if the COM port is over a Bluetooth connection, we can detect if the COM port cannot be opened, but if it has been opened and somehow has failed, our app simple hangs.  We have been unable to debug it.  Before we send any data we check the IsOpen property to make sure the port is available.

    Any help appreciated.



    Thursday, November 16, 2017 7:13 AM

All replies

  • if the COM port is over a Bluetooth connection, we can detect if the COM port cannot be opened, but if it has been opened and somehow has failed, our app simple hangs.

    If it really is impossible to detect when it hangs then you need a timer.   You code should be continually re-setting the timer so that it normally never times out.  But if the code hangs, the timer times out and code in the timer tick event handler attempts to recover the application.  It's not foolproof, however.

    A much better solution would be to prevent the application from hanging in the first place.  Most of the Serial I/O methods either operate asynchronously or have a timeout option that means that your code records an error and continues if an operation takes longer than expected.  You may need to modify the processes that you are using to access the port so that you can make use of the timeout property.  For instance: 
    https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readtimeout%28v=vs.110%29.aspx

    Thursday, November 16, 2017 8:15 AM
  • Thanks for your reply.

    I'm suspecting that the .IsOpen property in the serial port class is blocking, but only after a com port has been opened successfully.  The code I have written handles quite well the situation where a Bluetooth COM port is not available to connect to, but can't handle what happens when after the connection has been established. 

    This only happens on Bluetooth serial port connections - my error handling on serial over USB virtual COM ports is working perfectly.  I suspect the SerialPort.Write method is blocking.  I will perform a few more detailed tests.

    I will experiment with the .WriteTimeout property... I'm not entirely clear how to handle timeout events but will do some research.  Other posts have suggested when this problem occurs, the Write Timeout event is never fired.

    I wish there was a way to perform a non blocking write call.


    Thursday, November 16, 2017 9:44 AM
  • I'm suspecting that the .IsOpen property in the serial port class is blocking, but only after a com port has been opened successfully.

    Then don't use it.  Keep track of whether or not you have opened the port using a variable you declare for the purpose.

    I wish there was a way to perform a non blocking write call.

    The Write method supports a timeout option.

    Thursday, November 16, 2017 11:00 AM
  • The Write Timeout example on MSDN uses a new thread to catch the timeout exception:

    https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.writetimeout.aspx

    I can't seem to find an example that works in the same thread.

    FYI, the reason we are monitoring the IsOpen property is to detect if the link has dropped out.  We can't do that using a flag.  I agree though that indirectly a write timeout would suggest the same outcome.  That's the path we will head down.

    thanks again for your input.

    Thursday, November 16, 2017 11:22 AM
  • The Write Timeout example on MSDN uses a new thread to catch the timeout exception:

    That's correct - the serial port uses threading to manage its procedures.  There is no reason not to use threads for this purpose.

     the reason we are monitoring the IsOpen property is to detect if the link has dropped out.

    IsOpen does not tell you anything about the state of the connection.  It only tells you that the port has been opened in the application and has not been closed - exactly what a flag will tell you.   It will not indicate whether or not the link has been dropped.

    The correct way to monitor the status of the connection is to use the signal lines defined for that purpose, such as CD or DSR.  Not all port emulators support the full set of status lines.  Break can sometimes be used to detect a line that has been dropped, but that depends on the protocol for the link.
    https://msdn.microsoft.com/en-us/library/system.io.ports.serialpinchangedeventhandler.aspx

    Thursday, November 16, 2017 8:29 PM