471,627 Members | 1,692 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,627 software developers and data experts.

comm port input bytes getting...randomly?...offset by 128

I'm having an odd problem where im reading input from a comm port (the
maker of the software that exports the data TO the comm port is
unhelpful).

What im reading is fixed length (13 character) sets of data seperated
by CR/linefeed. At first, it simply seemed like i was getting messed
up data, due to encoding it wrong, or using the wrong font, or
something like that, but it turns out, when i analyze the byte stream,
that the data i get is, for example:
160 160 51 57 183 54 48 204 78 77 141 10

which would translate to (in terminal font) "3960NM?<LF>"

however, notice, if you subtract 128 from all the bytes larger than
127, you get
32 32 51 57 55 54 48 76 78 77 13 10

which would translate to " 39760LNM<CR><LF>"
which IS exactly the data we expect to get.

So, my question is,...does anyone know why in the world the data from
the commport (read using ReadByte()), would have various characters
offset by 128?

Dec 21 '05 #1
4 2514
Hi,

Ic************@gmail.com wrote:
So, my question is,...does anyone know why in the world
the data from the commport (read using ReadByte()), would
have various characters offset by 128?


Incorrect data/parity/stop bit settings for the port. It's been a long time
since my serial terminal days, but I recall those being off producing
precisely that sort of result.

I'd further guess that you have left the port at default 8-N-1, but your
hardware device is trying to send 7-E-1. The SerialPort class has
properties for these (DataBits, Parity, StopBits).

--
Chris Priede

Dec 21 '05 #2
Thanks so much! This immediately fixed the problem. I had in fact
tried setting bits to 7, as it would make a lot of sense for that to be
the problem, but the comm port wouldnt open. I didn't try messing with
the various other comm port options in conjunction with that change
though. How did you know 7-E-1 would be the right combination?

Dec 21 '05 #3
Ic************@gmail.com wrote:
How did you know 7-E-1 would be the right combination?


The parity bit your UART wasn't expecting was becoming your 8th data bit (if
the total number of bits between start and stop was off, you'd be getting
framing errors). When the parity bit happened to be 0, you wouldn't even
notice. When the parity bit happened to be 1, of which there is about 50/50
chance... :)

Between that and no one ever using odd parity, it was an easy guess. I'm
glad it worked out.

--
Chris Priede
Dec 21 '05 #4

"Chris Priede" <pr****@panix.com> wrote in message
news:uB**************@TK2MSFTNGP11.phx.gbl...
Ic************@gmail.com wrote: ....
Between that and no one ever using odd parity, it was an easy guess. I'm
glad it worked out.


You don't have to guess, as converting sample numbers to binary would show
that every number has even number of bits set :).

Regards,
Goran

Dec 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by al | last post: by
1 post views Thread by sarath1111 | last post: by
7 posts views Thread by Michael Chong | last post: by
6 posts views Thread by Leandro Berti via DotNetMonster.com | last post: by
3 posts views Thread by Amjad | last post: by
9 posts views Thread by Mircea | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.