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

  • Thread starter Thread starter Iceman.Aragorn
  • Start date Start date
I

Iceman.Aragorn

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) "àà39·60ÌNM?<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?
 
Hi,

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?
Click to expand...

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).
 
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?
 
How did you know 7-E-1 would be the right combination?
Click to expand...

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 said:
(e-mail address removed) wrote: ....

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

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
 
Back
Top