Serial communication, issues using native com port vs prolific usb->serial

Question

I am not entirely sure this if this is a problem with my code, or a hardware problem.

I have a program that communicates one-way (receive only) with some equipment (fire alarm control panels to be specific.) When I wrote the program, it was done on PC that doesn't have a native serial port, so I used a prolific serial->usb dongle. It worked, for the most part. I occasionally got a random 3F/? in the data when connected to one of the two types of FACPs, but I figured that was just the converter acting up, so I just stripped them from the output.

Then I ported it over to some work laptops, which are Dell's with native com ports. And now my data is garbled nonsense (mostly 3F/?.) Occasionally I will see the correct character, but it's mostly nonsense. Usually not even the right length of nonsense. Using the prolific converter, it "works" in that I get all the data I expect - with the addition of a 3F/? between every single character. Displayed just fine if I strip the bad characters, but that's a cheap hack when something else is clearly wrong.

An example of expected data, and received data:

//Expected:

FIRE ALARM                     MAGNET    ELEVATOR SHAFT       HOISTWAY    
ELEVATOR SHAFT       Z111   HEAT(fixed)  09:34:19A FRI JUN 06, 2014     L02D041

//Received (approximation, not actual copy/paste as I don't have it on this PC):

F?I?R?E?A?L?R?M??????? ????????M????T????E?LEV?T?R S?H?A?F?T??H?O??S?T?W?A?Y???    
E?E??T???S?H?A?F?T   ?Z1?1?1HEAT(fixed)  0?9?:?34?19??AF?R?I?J???N?6??2?1?4????

My current method of retrieving data is via DataReceivedHandler event and ReadLine(). I previously used ReadExisting() and ReadByte(), but the result was the same for each, so I went back to ReadLine, because it works best with the data I'm receiving (80 characters followed by EOL)

The port settings are correct, 9600/8/1/None/XonXoff, as per manufacturer and personal experience. Both the prolific converter and the native serial port work just fine in other programs such as puTTY, procomm, or the manufacturer software. At one point I ran something called SerialMon to see what exactly it was sending, and I was getting the same garbled non-sense. I used that to test various port settings, to no avail.

I previously wrote nearly identical software in python and it worked fine on both the native com port on the laptop and the prolific converter. The fact that the python software worked and other terminal programs work makes me think it's something with .NET/C# that I need to fix on my end.

So yeah... any insight is greatly appreciated. Serial relevant code below.

//declaring
SerialPort com = new SerialPort();       

//opening port
com.PortName = Properties.Settings.Default.com;
com.BaudRate = Properties.Settings.Default.baudrate;
com.Parity = Properties.Settings.Default.parity;
com.StopBits = Properties.Settings.Default.stopbits;
com.DataBits = Properties.Settings.Default.databits;
com.Handshake = Properties.Settings.Default.handshake;
com.Open();

//reading data
buf = com.ReadLine();

TL;DR: Serial program works, with some bad data, using a prolific 2303 dongle. Program does not work using native COM port. Other programs (putty, procomm, etc) work just fine using both. Similar Python program on same laptop works fine with prolific and native com port. Tried other port settings, tried port monitoring program. Send help.

Edit: The equipment sends data in ASCII form

In your setup for the port is the zero your stop bits? If so that is non standard. The enumeration help states that it is not supported. Usually it is 1 1.5 or 2 — Mark Hall
Sorry, that was my mistake in the post. The manufacturer (and program) specifications are 9600 baud, 8 data bits, 1 stop bits, parity none. — Cal Hunter
Even though the specs say 8,1,none, I would try variations of those port settings and see what happens. It's been a very long time...20 years to be exact, but I seem to remember seeing results like this with bad port settings. (A pre-release version of Procomm Plus for Windows actually ate characters when the port settings were bad.) — Markus
What happens when you set the ParityReplace property to '*'? — Markus

Cal Hunter Cal Hunter · Accepted Answer · 2014-06-28T02:20:44

Thanks for the help guys. It turns out it was a parity error. The serial port was not accepting Parity.None when it was assigned via a user property, even when cast as Parity type. It was defaulting to Parity.Even (despite MSDN saying None is default?). What I ended up doing was setting the properties to application and letting the user toggle between the two acceptable sets, instead of having free run of the port settings. This seems to have solved the issue, and I am parity error free on both the native serial port and the converter.

What tipped me off was setting ParityReplace to another character, as Markus suggested. At that point it became clear that it was a parity error. I'm still not sure why the SerialMon program I was using was getting the same results, even with parity set to None.

For reference, ErrorReceived was not raised at any point.

Again, thanks for the help everyone.

Serial communication, issues using native com port vs prolific usb->serial

1 Answers