We Keep Coding

Detecting live serial port connection in c#

I am trying to detect whether the serial connection still exists or is broken down. How to detect live serial port connection in c#? Can the SerialPort.PinChanged Event be used for the same?

The term "life" has no useful meaning on serial ports. They are very primitive devices that date back to the stone-age of computing. It is where you plugged in your ASR-33 teletype to start banging in your Fortran program. There is no logical connection state and no error recovery, there is no way to share a serial port between multiple programs. Just a raw byte stream, it sits at the very bottom of the OSI model, implementing the physical layer.
It is never useful to use the IsOpen property, you want to immediately Open() the port so no other program can steal the port away from you. Don't call Close() until the very end of the program. Or never, Close() has several gritty deadlock problems.
The electrical standard does include handshake signals, about as close you could get to discover what is happening on the other end of the cable. The SerialPort.DsrHolding property is true when the device has turned on its DTR signal and can usually be interpreted as a power-on signal. Not every device implements it however. Not initializing the SerialPort.Handshake property is a standard bug and the core reason why you don't get a TimeoutException when writing to the port when it is disconnected. Most devices implement Handshake.RequestToSend, they use the RTS and CTS signals to tell the other side that it is ready to receive data and to prevent buffer overflow. Always check the manual first.

C# SerialPort communication protocol

I did write a small C# app that reads from a COM port a series of numbers sent by an Arduino board.
Question:
If the Arduino sends a single value every 500ms but my C# program reads a single value every 1s doesn't the C# get left behind the Arduino? If that is true, does the data sent from Arduino get stored in a buffer or is it simply discarded?
[Edit]
Bellow is the code I use to read from COM
System.Windows.Forms.Timer tCOM;
...
tCOM.Interval = 1000;
tCOM.Tick += new System.EventHandler(this.timer1_Tick);
...
SerialPort port = new SerialPort();
port.PortName = defaultPortName;
port.BaudRate = 9600;
port.Open();
.....
private void timer1_Tick(object sender, EventArgs e)
{
log("Time to read from COM");
//read a string from serial port
string l;
if ((l = port.ReadLine()) != null)
{
......
}
}

Serial port communications normally require flow control. A way for the transmitter to know that the receiver is ready to receive data. This is often overlooked, especially in Arduino projects. Which tends to work out okay, serial ports are very slow and modern machines are very fast compared to the kind of machines that first started using serial ports.
But clearly, in your scenario something is going to go bang! after a while. Your Arduino will cause a buffer overflow condition when the receive buffer in the PC fills up to capacity. And that causes irretrievable loss of data. Listening for a notification of this condition is something else that's often skipped, you must register an event handler for the SerialPort.ErrorReceived event. You'd expect a SerialError.Overrun notification in this case. There's no clean way to recover from this condition, a full protocol reset is required.
There are two basic ways to implement flow control on serial ports to avoid this error. The most common one is to use hardware handshaking, using the RTS (Request To Send) and CTS (Clear To Send) signals. Provided by Handshake.RequestToSend. The PC will automatically turn the RTS signal off when its receive buffer gets too full. Your Arduino must pay attention to the CTS signal and not send anything when it is off.
The second way is software handshaking, the receiver sends a special byte to indicate whether it is ready to receive data. Provided by Handshake.XonXoff, which uses the standard control characters Xon (Ctrl+Q) and Xoff (Ctrl+S). Suitable only when the communication protocol doesn't otherwise use these control codes in their data. In other words, when you transmit text instead of binary data.
The third way is a completely different approach, very common as well, you make the device only ever send anything when the PC asks for it. A master-slave protocol. Having enough room in the receive buffer for the response is easy to guarantee. You specify specific commands in your protocol, commands that the PC sends to query for a specific data item.

When you open a serial port for input, a buffer (queue) is automatically created to hold incoming data until it is read by your program. This buffer is typically 4096 bytes in size (although that may vary according to the version of Windows, serial port driver etc.).
A 4096-byte buffer is normally sufficient in almost all situations. At the highest standard baud rate (115200 baud) it corresponds to more than 300 msecond of storage (FIFO) first in first out, so as long as your program services the serial port at least three times a second no data should be lost. In your particular case, because you read the serial every 1 second, you may loose data if the timing and the buffered data do not match.
However in exceptional circumstances it may be useful to be able to increase the size of the serial input buffer. Windows provides the means to request an increased buffer size, but there is no guarantee that the request will be granted.
Personally I prefer to have a continuous stream of data from Arduino and decide in my c# app what to do with those data but at least I am sure I do not loose information due to limitation of the hardware involved.
Update:
Playing with Arduino quite often, I also agree with the third option given by Hans in his answer. Basically your app should send to Arduino a command to get printed out (Serial.Print or Serial.Println) the data you need and be ready to read it.

using a COM port - Close after each use, or leave always open?

Till now I opened when I needed to send data, and closed right away.
I get random "Access to Port" errors (although I always close the port after I use it),
so I was thinking maybe to leave it always open.
What is the right approach of use, assuming that every minute or two I need to send data in some COM ports?
Thanks..

Calling SerialPort.Close() frequently is a mistake. Having another app steal the port away from you isn't exactly very desirable. But more problematic, and the problem you are having, is that Close() doesn't wait for a worker thread that is started by SerialPort to exit. That worker thread raises the DataReceived, PinChanged and ErrorReceived events. It takes "a while" for it to exit, could be between milliseconds and seconds. Calling Open() again will fail until that's done.
It's a flaw in the class, but induced by the common usage for serial ports. Apps don't normally close them until the app terminates. Including never, avoiding a common deadlock scenario. Do note that the MSDN article for Close warns about this:
The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.

If you're worried about the opening/closing and other apps stealing the COM port away, you could use the approach used by Microsoft for the GPS intermediate driver in windows embedded, i.e. to write an aggregator, one which opens the port, keeps it open, then provides connection points for other apps to connect to.
How you create the connections is up to you: you can get right down deep in the hardware and write a virtual com port driver that's shareable, or you can do what I did and write a simple win32 socket service that allows client programs to connect via regular windows socket connections.
Maybe not a straight forward answer, but food for thought.

There is very little harm in leaving a serial port open, so yes, keep it open. It saves you the overhead of open/closing it.

Serial Comms programming structure in c# / net /

I'm an embedded programmer trying to do a little bit of coding for a communications app and need a quick start guide on the best / easiest way to do something.
I'm successfully sending serial data packets but need to impliment some form of send/ response protocol to avoid overflow on the target system and to ensure that the packet was received ok.
Right now - I have all the transmit code under a button click and it sends the whole lot without any control.
What's the best way to structure this code , i.e sending some packets - waiting for response .. sending more .. etc etc until it's all done, then carrying on with the main program.
I've not used threads or callbacks or suchlike in this environment before but will learn - I just need a pointer to the most straigtforward ways to do it.
Thanks
Rob

The .NET serialport uses buffers, learn to work with them.
Sending packets that are (far) smaller than the Send-buffer can be done w/o threading.
Receiving can be done by the DataReceived event but beware that that is called from another thread. You might as well start your own thread and use blocking reads from there.
The best approach depends on what your 'packets' and protocol look like.

I think to have a long experience about serial comm, both MCU and PC-based.
I strongly UNSUGGEST the single-thread based solution, although it is very straigthful for light-speed testing, but absolutely out for final releases.
Surely you may choose among several patterns, but they are mostly shaped around a dedicated thread for the comm process and a finite-state-machine to parse the protocol (during receiveing).
The prevoius answers give you an idea to how build a simple program, but it might depends on the protocol specification, target device, scope of the application, etc.

there are of course different ways.
I will describe a thread based and an async operation based way:
If you don't use threads, your app will block as long as the operation is performing. This is not what a user is expecting today. Since you are talking about a series of sending and receiveing commands, I would recommend starting the protocol as a thread and then waiting for it to finish. You might also place an Abort button if neccesary. Set the ReadTimeout values and at every receive be ready to catch the exception! An introducing into creating such a work thread is here
If you want to, use Async Send/Receive functions instead of a thread (e.g. NetworkStream.BeginRead etc.). But this is more difficult because you have to manage state between the calls: I recommend using a Finite State Machine then. In fact you create an enumeration (i.e. ProtocolState) and change the state whenever an operation has completed. You can then simply create a function that performs the next step of the protocol with a simple switch/case statement. Since you are working with a remote entity (in your case the serial target system), you always have to consider the device is not working or stops working during the protocol. Do this by starting a timeout timer (e.g. set to 2000ms) and start it after sending each command (assuming each command will get a reply in your protocol). Stop it if the command was received successfully or on timeout.

You could also implement low-level handshaking on the serial port; set the serial port's Handshake property to rts/cts or xon/xoff.
Otherwise (or in addition), use a background worker thread. For simple threads, I like a Monitor.Wait/Pulse mechanism for managing the thread.
I have some code that does read-only serial communications in a thread; email me and I'll be happy to send it to you.

I wasn't sure from your question if you were designing both the PC and embedded sides of the communication link, if you are you might find this SO question interesting.

How do I force a serial port write method to wait for the line to clear before sending its data?

Here's some background on what I'm trying to do:
Open a serial port from a mobile device to a Bluetooth printer.
Send an EPL/2 form to the Bluetooth printer, so that it understands how to treat the data it is about to receive.
Once the form has been received, send some data to the printer which will be printed on label stock.
Repeat step 3 as many times as necessary for each label to be printed.
Step 2 only happens the first time, since the form does not need to precede each label. My issue is that when I send the form, if I send the label data too quickly it will not print. Sometimes I get "Bluetooth Failure: Radio Non-Operational" printed on the label instead of the data I sent.
I have found a way around the issue by doing the following:
for (int attempt = 0; attempt < 3; attempt++)
{
try
{
serialPort.Write(labelData);
break;
}
catch (TimeoutException ex)
{
// Log info or display info based on ex.Message
Thread.Sleep(3000);
}
}
So basically, I can catch a TimeoutException and retry the write method after waiting a certain amount of time (three seconds seems to work all the time, but any less and it seems to throw the exception every attempt). After three attempts I just assume the serial port has something wrong and let the user know.
This way seems to work ok, but I'm sure there's a better way to handle this. There are a few properties in the SerialPort class that I think I need to use, but I can't really find any good documentation or examples of how to use them. I've tried playing around with some of the properties, but none of them seem to do what I'm trying to achieve.
Here's a list of the properties I have played with:
CDHolding
CtsHolding
DsrHolding
DtrEnable
Handshake
RtsEnable
I'm sure some combination of these will handle what I'm trying to do more gracefully.
I'm using C# (2.0 framework), a Zebra QL 220+ Bluetooth printer and a windows Mobile 6 handheld device, if that makes any difference for solutions.
Any suggestions would be appreciated.
[UPDATE]
I should also note that the mobile device is using Bluetooth 2.0, whereas the printer is only at version 1.1. I'm assuming the speed difference is what's causing the printer to lag behind in receiving the data.

Well I've found a way to do this based on the two suggestions already given. I need to set up my serial port object with the following:
serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.
Then I just need to do the write call:
serialPort.Write(labelData);
Since the Zebra printer supports software flow control, it will send an XOff value to the mobile device when the buffer is nearly full. This causes the mobile device to wait for an XOn value to be sent from the printer, effectively notifying the mobile device that it can continue transmitting.
By setting the write time out property, I'm giving a total time allowed for the transmission before a write timeout exception is thrown. You would still want to catch the write timeout, as I had done in my sample code in the question. However, it wouldn't be necessary to loop 3 (or an arbitrary amount of) times, trying to write each time, since the software flow control would start and stop the serial port write transmission.

Flow control is the correct answer here, and it may not be present/implemented/applicable to your bluetooth connection.
Check out the Zebra specification and see if they implement, or if you can turn on, software flow control (xon, xoff) which will allow you to see when the various buffers are getting full.
Further, the bluetooth radio is unlikely to be capable of transmitting faster than 250k at the maximum. You might consider artificially limiting it to 9,600bps - this will allow the radio a lot of breathing room for retransmits, error correction, detection, and its own flow control.
If all else fails, the hack you're using right now isn't bad, but I'd call Zebra tech support and find out what they recommend before giving up.
-Adam

The issue is likely not with the serial port code, but with the underlying bluetooth stack. The port you're using is purely virtual, and it's unlikely that any of the handshaking is even implemented (as it would be largely meaningless). CTS/RTS DTR/DSR are simply non-applicable for what you're working on.
The underlying issue is that when you create the virtual port, underneath it has to bind to the bluetooth stack and connect to the paired serial device. The port itself has no idea how long that might take and it's probably set up to do this asynchronously (though it would be purely up to the device OEM how that's done) to prevent the caller from locking up for a long period if there is no paired device or the paired device is out of range.
While your code may feel like a hack, it's probably the best, most portable way to do what you're doing.
You could use a bluetooth stack API to try to see if the device is there and alive before connecting, but there is no standardization of stack APIs, so the Widcom and Microsoft APIs differ on how you'd do that, and Widcom is proprietary and expensive. What you'd end up with is a mess of trying to discover the stack type, dynamically loading an appropriate verifier class, having it call the stack and look for the device. In light of that, your simple poll seems much cleaner, and you don't have to shell out a few $k for the Widcom SDK.