Home/Support/Support Forum/Acceleport loses bytes
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Acceleport loses bytes

0 votes
Acceleport adapters lose input bytes, specifically byte 0xff and any following it. This happens at :

- Fedora release 13 (Goddard) kernel 2.6.33.3-85 - with AccelePort 16em

- and also at ASP Linux 12 kernel 2.6.22.9-91 - with Acceleport 8r 920.


Every time when byte 0xff arises in input stream, it is dropped by the driver together with the byte which follows this, so I don't see these two bytes in received data.

Both these adapters work OK at RedHat 7.3.
asked Nov 1, 2010 in Serial Cards by ssv New to the Community (4 points)

Please log in or register to answer this question.

9 Answers

0 votes
Sounds like a port setting.

I recommend comparing the ditty.dgap -a ttyxyz between the working RH 7.3 port and non working ports to make certain they are identical.

Also, what happens if you use the built in serial port on the Fedora hosts?
answered Nov 1, 2010 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Sorry, settings are identical, not counting those which don't exist at RH 7.3 :
[root@u5 dgap]# ditty.dgap -a ttya05
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd -altpin -fastbaud (57600) -printer eia232 -rtstoggle -dtrtoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS- CD- DSR- RI-
speed 57600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = <undef>; 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



/deb/ttyS[01] work OK.
answered Nov 2, 2010 by ssv New to the Community (4 points)
0 votes
Please post the ditty.dgap -a ttyS0 results for comparison.
answered Nov 2, 2010 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
There were slight differences, so I made all settings (which I can) of Digi port like ttyS0. Result is the same - byte 0xff and the following are lost.

Settungs for Digi ports:
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd -altpin -fastbaud (9600) -printer eia232 -rtstoggle -dtrtoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS- CD- DSR- RI-
speed 9600 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; 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



Settungs for ttyS0:
DTR+ RTS+ CTS- CD- DSR- RI-
speed 9600 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; 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
answered Nov 3, 2010 by ssv New to the Community (4 points)
0 votes
If you look at the ditty settings before starting the application and while the application is running, what settings are changed?
answered Nov 3, 2010 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Sorry for delay, I was at holidays.

All the settings are taken when the program runs. Settings are not changed in fact, because they correspond to what the program needs.
answered Nov 8, 2010 by ssv New to the Community (4 points)
0 votes
What driver version are you using?

Do the characters display within dpa.dgap when monitoring the serial data?
answered Nov 8, 2010 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
> What driver version are you using?
dgap-1.3-19.src.rpm. I also tried releases 16 trough 18.

> Do the characters display within dpa.dgap when monitoring the serial data?

Sorry, there is no program dpa.dgap, and no notion in docs, and I don't understand what monitoring do You mean.

I You are in doubt about my program: I have simply cross-connected Rx and Tx on two ports (5 and 7, to be exact), and then made:
cat </dev/ttya07 >file2 &amp;
cat test test >/dev/ttya05
Binary file "test" contains all byte codes from 00 to ff. And output file "file2" lacks bytes 'ff' with one byte following these.
answered Nov 9, 2010 by ssv New to the Community (4 points)
0 votes
You may want to try the latest driver candidate:

ftp://ftp1.digi.com/support/beta/linux/dgap

An actual 0xff in the data is reported as 0xff 0xff, so an 0xff
followed by an 0xff is in fact an 0xff of data.

If IGNBRK is set, a break condition detected on input is ignored that is, not put on the input queue and therefore not read by any process.

If IGNBRK is not set and BRKINT is set, the break condition will flush the input and output queues, and if the terminal is the controlling terminal of a foreground process group, the break condition will generate a single SIGINT signal to that foreground process group. If neither IGNBRK nor BRKINT is set, a break condition is read as a single 0x00, or if PARMRK is set, as 0xff 0x00 0x00.

If IGNPAR is set, a byte with a framing or parity error (other than
break) is ignored.

If PARMRK is set, and IGNPAR is not set, a byte with a framing or parity error (other than break) is given to the application as the three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag preceding each sequence and X is the data of the byte received in error. To avoid ambiguity in this case, if ISTRIP is not set, a valid byte of 0xff is given to the application as 0xff 0xff. If neither PARMRK nor IGNPAR is set, a framing or parity error (other than break) is given to the application as a single byte 0x00."

If you continue to experience problems with this, I recommend obtaing an strace and contacting Digi Tech. Support.
answered Nov 12, 2010 by userid0 Veteran of the Digi Community (2,158 points)
...