RXTX virtual serial port read problem

Question

Background: Windows Server 2003 R2,Wire Service virtual serial port created with RealPort software, Serial Port configured as COM5, 9600 baud,8 data bits, no parity bits, 1 stop bit, no flow control, Using RXTX 2.1-7.

The port COM5 is found, the serial port is created using the portId.open method and port parameters and flow control are set to match the device driver settings above. I get the serialPort IntupStream and wrap it in an InputStreamReader so I can control the input encoding. The default encoding is of course Cp1252 I've read that if you are using 8 data bits the encoding should be ISO-8859-1 aka Latin1. and am using the InputStreamReader method: int c = isr.read(); in a while loop in the case SerialPort.Event.DATA_AVAILABLE Printing out the integer c and it's cast to a character ((char)c); The problem is that the numbers and resulting characters are shifted too high (range is 135 - 250) The messages all end with "All Rights Reserved.)" and the last characters in each message are the same. However, the shift is not consistent from character to character. Have tried other encodings: UTF8/UTF-8 shift the numbers even higher. as does ascii/us-ascii. Cp1252 shifts the numbers to the 130 - 350 range except for 3 characters which are shifted to 65533, 8222 and 8240. Note: using the InputStreamReader.getEncoding() UTF8 and UTF-8 are UTF8 and ascii and us-ascii are ASCII.

Are there other encodings I should try? Anyone else seen this sort of thing?

Answer 1

I'm doing almost the exact same thing. 9600 baud, 8N1 (8 data bits, no parity, 1 stop bit) and we have no issues with character shifting. We don't even set the encoding, anywhere.

Our input stream is simply of type InputStream and it's set with serialPort.getInputStream();

Try stepping back from InputStreamReader and just using a plain "InputStream." The encoding should take care of itself.

Hope that helps in some way,

--gMale

Answer 2

Have two of the wire service ports. I one I posted about turned out to be a conflict between the hardware configuration in the TCP to Serial device called a Digi. I was able to remedy the problem on that port by changing the COM5 serial settings to 9600,7,1,0,0. The shifting of values was due to using 8 data bits vs 7. This of course meant that I had to change the port params in the code to match. Your correct in that the Reader was unnecessary, however it did help me arrive at the solution by watching the shift change with encoding, till it dawned on me that fewer data bits would also have the same effect.

Now I'm looking for the magic on the second port.

The second port settings were 1200,8,1,0,0 using 9600 caused the stream to be mostly 0s with some 128s.