problem with serial data transmission

Hello,

I encountered a problem concerning the usage of serial devices to set
up a connection between two Linux boxes. Although it has nothing to do
with IP traffic it is a kind of data exchange and therefore I hope
that this group is the correct place to ask for help. If not please be
so kind to point me to a location which is more appropriate!

But now to my issue: I have to receive binary data that is send out by
some proprietary system via a serial link (9600 baud, 8 data bits, no
parity, 1 stop bit and no flow control). As I do not have access to
this system at the moment I wanted to perform a preliminary test using
two linux machines connected by a nullmodem cable (ordinary i386
hardware running KNOPPIX V5.0.1-2006-06-01 which is based upon Kernel
2.6.17).

At first I configured both serial interfaces by

> stty -F /dev/ttyS0 9600 raw

which results in the following set-up:

> stty -F /dev/ttyS0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

As far as I know this should be okay for the transfer of binary data.
Now I listen for incoming data on the receiving Linux box

receiver> cat /dev/ttyS0 > target_file.raw

and start the data transfer on the sending system

sender> cat source_file.raw > /dev/ttyS0

At first glance the transmission looks okay but at around 4000
transmitted bytes the data stream becomes completely erroneous:
fractions of the beginning of the stream appear again interfused by
sequences of control characters (0x07 = bell). That happens regardless
of transfering binary or ASCII data!

This behaviour does not occur if I try an alternative operating system
on the receiving machine: no problem using FreeBSD (live cd based upon
FreeBSD 6.1-STABLE) or an OS from M$ (Windows XP). Everything works
without problems, even binary data gets transmitted without any error.

This makes me think that probably there is a problem with the serial
driver under linux! It looks like it is not depending on the utilized
hardware as I see this issue not only with the 16550A based onboard
interface but also using an RS232-USB adapter.

Did anybody encounter similar problems?
Does anybody have an explanation for this behaviour?

Best regards and thanks in advance
Ulrich

On Tue, 24 Oct 2006 16:52:55 +0200, Ulrich Ölmann rearranged some
electrons to form:

> Hello,
>
> I encountered a problem concerning the usage of serial devices to set
> up a connection between two Linux boxes. Although it has nothing to do
> with IP traffic it is a kind of data exchange and therefore I hope
> that this group is the correct place to ask for help. If not please be
> so kind to point me to a location which is more appropriate!
>
> But now to my issue: I have to receive binary data that is send out by
> some proprietary system via a serial link (9600 baud, 8 data bits, no
> parity, 1 stop bit and no flow control). As I do not have access to
> this system at the moment I wanted to perform a preliminary test using
> two linux machines connected by a nullmodem cable (ordinary i386
> hardware running KNOPPIX V5.0.1-2006-06-01 which is based upon Kernel
> 2.6.17).
>
> At first I configured both serial interfaces by
>
> > stty -F /dev/ttyS0 9600 raw
>
> which results in the following set-up:
>
> > stty -F /dev/ttyS0 -a
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
> eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
> flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
> -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
> -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
> bs0 vt0 ff0
> -isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
> -echoprt echoctl echoke
>
> As far as I know this should be okay for the transfer of binary data.
> Now I listen for incoming data on the receiving Linux box
>
> receiver> cat /dev/ttyS0 > target_file.raw
>
> and start the data transfer on the sending system
>
> sender> cat source_file.raw > /dev/ttyS0
>
> At first glance the transmission looks okay but at around 4000
> transmitted bytes the data stream becomes completely erroneous:
> fractions of the beginning of the stream appear again interfused by
> sequences of control characters (0x07 = bell). That happens regardless
> of transfering binary or ASCII data!
>
> This behaviour does not occur if I try an alternative operating system
> on the receiving machine: no problem using FreeBSD (live cd based upon
> FreeBSD 6.1-STABLE) or an OS from M$ (Windows XP). Everything works
> without problems, even binary data gets transmitted without any error.
>
> This makes me think that probably there is a problem with the serial
> driver under linux! It looks like it is not depending on the utilized
> hardware as I see this issue not only with the 16550A based onboard
> interface but also using an RS232-USB adapter.
>
> Did anybody encounter similar problems?
> Does anybody have an explanation for this behaviour?
>
> Best regards and thanks in advance
> Ulrich

The serial driver even under my very old kernel works fine.
Try looking here:

http://tldp.org/HOWTO/Serial-Program...WTO/index.html
http://tldp.org/HOWTO/Serial-HOWTO.html


--
David M (dmacchiarolo)
http://home.triad.rr.com/redsled
T/S 53
sled351 Linux 2.4.18-14 has been up 27 days 9:32

Ulrich Ölmann <(E-Mail Removed)> wrote:
> > stty -F /dev/ttyS0 -a
> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D;
> eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
> flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts

-crtscts means there is no flowcontrol enabled.

....

>At first glance the transmission looks okay but at around 4000
>transmitted bytes the data stream becomes completely erroneous:

The input buffer just overflowed.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

Dear group,

the problem is solved! After doing this and trying
that I finally wrote a tiny C program to receive the
data from /dev/ttyS0. Within this program I used
amongst others the libc function 'cfmakeraw(...)'
to configure the serial interface for raw mode.
Heureka - this worked!

But why is it working there while it malfunctions
on the shell? After digging a little bit deeper I
finally realized that 'cfmakeraw(...)' and the
command 'stty ... raw' do not touch the same bits
of the termios-structure! Especially the local mode
bit ECHO is cleared by 'cfmakeraw(...)' while it
is not touched by 'stty ... raw'. As this bit is
set per default (at least in the Linux distros I
tried in my experiments) the receiver immediately
echoed the data back to the sender who mixes them
under the data to be transfered to the receiver:
the two Linux boxes played data-ping-pong on the
serial line. This explains why I found fragments
from the beginning of the transmission in later
parts of the data stream again.
An ugly thing...

FreeBSD btw has the ECHO bit cleared per default
and I assume that Windows XP behaves similarly.

So the only thing that remains is the question why
the set of bits that 'stty' sets or clears is not
completely identical to the set of bits that are
touched by the libc function call. Does anybody
know the historical reason for that?

Okay, that's the whole story. Last, but not least,
I would like to thank you for your help!

Best regards
Ulrich