System.IO.Ports.SerialPort - can IOCTL_SERIAL_SET_WAIT_MASK be configured?

Question

I've been trying to learn a bit about how .Net (3.5) interacts with the Serial port through the System.IO.Ports.SerialPorts class by writing a small Windows Forms application to gather caller display data from an old external modem.

I've tested that the modem supports caller display; using Putty or Hyperterminal I can configure the modem to collect caller display data (using the command AT#CID=1, which I found here), and when the phone rings, the data is displayed. In the terminal window, it looks like this:

RING

DATE = 0308
TIME = 2045
NMBR = 01234567890

RING

My C# application appears to successfully configure the modem and displays a RING message when the phone rings; however, it never displays the caller ID data.

In an effort to understand why this is, I compared the actions taken by the different clients using Sysinternals Portmon.

The primary difference appears in the connection configuration; my C# application includes the following line, which Putty and Hyperterminal do not;

0.00000307  callerID.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR RXFLAG CTS DSR RLSD BRK ERR RING

As I understand it, IOCTL_SERIAL_SET_WAIT_MASK is an inclusive list of message types to filter for.

So, three questions:

Is it possible that the caller ID information is being suppressed by IOCTL_SERIAL_SET_WAIT_MASK?

If so, how can I configure it to show the caller ID info? It doesn't appear to be accessible from the class properties.

If I can't configure it, is my only option to get around this to write my own wrapper to the lower-level system functions controlling the serial port?

My understanding of serial port communications is very basic, so I expect I'm way off in my diagnosis. Any guidance gratefully received.

Answer 1

I found this on MSDN which looks like a decent example of how to access the serial port via P/Invoke on the system dll's.

I'd still like to know if I can get around my issues with the .Net class.

Answer 2

I was way off with my diagnosis.

It seems that the WriteLine method doesn't terminate the commands it sends with the line terminator my modem is expecting.

All I needed to do was add a carriage return to the commands I am sending, and send them using the Write method.

Apologies for wasting anybody's time.