vb.net serial IO problem

[gene.james]

One of those cases where the problem is probably right under my nose
but I can't see it. This serial test code fails to send the right data:

Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles ButtonCAM1.Click
Dim TestData() As Byte = {&HFE, &H11, &H11, &HFF}
Using KeyerCom As IO.Ports.SerialPort = _
My.Computer.Ports.OpenSerialPort(KeyerPortName, 38400,
IO.Ports.Parity.None, 8, IO.Ports.StopBits.One)
KeyerCom.DtrEnable = True
KeyerCom.Write(TestData, 0, 4)
End Using
End Sub

Checking with a serial monitor, I find that it actually sends code
sends a NUL (&H00) after every byte sent. So the stream actually sent
(as hex)is: FE 00 11 00 11 00 FF 00

Any ideas?

 

[Chris Dunaway]

One of those cases where the problem is probably right under my nose
but I can't see it. This serial test code fails to send the right data:

Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles ButtonCAM1.Click
Dim TestData() As Byte = {&HFE, &H11, &H11, &HFF}
Using KeyerCom As IO.Ports.SerialPort = _
My.Computer.Ports.OpenSerialPort(KeyerPortName, 38400,
IO.Ports.Parity.None, 8, IO.Ports.StopBits.One)
KeyerCom.DtrEnable = True
KeyerCom.Write(TestData, 0, 4)
End Using
End Sub

Checking with a serial monitor, I find that it actually sends code
sends a NUL (&H00) after every byte sent. So the stream actually sent
(as hex)is: FE 00 11 00 11 00 FF 00

Any ideas?

It sounds like an encoding issue. You could try using the Encoding
class to get a string using a different encoding:

Dim s As String = Encoding.UTF8.GetString(TestData)
KeyerCom.Write(s)

I'm not sure if this will solve your problem, though.

 

[gene.james]

It sounds like an encoding issue. You could try using the Encoding
class to get a string using a different encoding:

Dim s As String = Encoding.UTF8.GetString(TestData)
KeyerCom.Write(s)

Been there. My data is declared bytes because if I encode as UNICODE
UTF8 or ASCII, output for bytes >7F is translated to multi byte strings.

 

[Chris Dunaway]

Been there. My data is declared bytes because if I encode as UNICODE
UTF8 or ASCII, output for bytes >7F is translated to multi byte strings.

Have you tried Encoding.Default?

 

[Stephany Young]

Because SerialPort uses ASCIIEncoding by default, and you have not set any
other Encoding, I would expect your transmission to be translated to {&H3F,
&H11, &H11, &H3F}. That is with all bytes above &H7F (127) translated to
&H3F (63 or ?). This behaviour is clearly stated in the documentation.

 

[gene.james]

Because SerialPort uses ASCIIEncoding by default, and you have not set any
other Encoding, I would expect your transmission to be translated to {&H3F,
&H11, &H11, &H3F}. That is with all bytes above &H7F (127) translated to
&H3F (63 or ?). This behaviour is clearly stated in the documentation.

You are correct. That is almost the behavior if I send a string it
actually sends 3F 00 11 00 11 00 3F 00. If I say xxx.write (Chr(&FF)) I
will get 3F 00 out of the serial port.
I am sending a byte array and so should not be getting any UNICODE
translation. I am puzzled by the incusion of the NUL after each
character.

I might think there's an anomaly with my serial monitor, but I have
another program that sends these strings and it shows the right data on
the monitor.

 

[Dick Grier]

Hi,

I send binary data frequently, and haven't seen this problem. Are you sure
that the code that you've posted is accurate. I added a button the the
VS2005Terminal example code on my web site as follows:

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click

Dim TestData() As Byte = {&HFE, &H11, &H11, &HFF}

'Dim TestData(3) As Byte

'TestData(0) = &HFE

'TestData(1) = &H11

'TestData(2) = &H11

'TestData(3) = &HFF

SerialPort.Write(TestData, 0, 4)

End Sub


The array initializer code AND the explicit assignment code sent the correct
data (verified by viewing it on a serial data analyzer). Encoding applies
to String data only, not arrays of type Byte -- so, it should work "as
advertised" unless there is something far from my experience. If you send
me email, I can forward the example that I fiddled for this test.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Dick Grier]

Actually, I suspect that you have a receiving/viewing problem. If you are
attempting to assign receive data to a String (don't do this!) using
ReadExisting, your code will not work. Instead, you must assign binary data
to an array of type Byte -- using the Read method.

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[gene.james]

Actually, I suspect that you have a receiving/viewing problem. If you are
attempting to assign receive data to a String (don't do this!) using
ReadExisting, your code will not work. Instead, you must assign binary data
to an array of type Byte -- using the Read method.

Thanks. You're right, the code is fine. My serial monitor is not!

My serial monitor program (COMMSNIFFER 1.0.32) WAS tested and working
fine weeks ago ... on an XP box. I was monitoring, however, with a
WinME machine and there the COMMSNIFFER shows that extra NUL. Thinking
I was crazy, I retested COMMSNIFFER on the XP box today and it works
fine there. And so does my code.

Thanks very much for your kind help.
-Gene

 

[Dick Grier]

Hi,

Try my VirtualNullModem/DataMonitor program (software downloads on my
homepage) and see if this works on your trouble machine.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.