Skip to content
Advertisement

Communicating with CashCode bill acceptor in linux

I’ve implemented CCNET protocol to communicate with CashCode bill acceptor from my software on Linux. Initially I spent lots of time trying to figure out why the device does not respond to the commands I’m sending. Using trial-and-error method I found the solution to set the following options for the serial port:

stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb clocal -crtscts -ixon -ixoff ignpar -icrnl -opost -isig -icanon -iexten -echo

It was working on the development machine and on two another testing machines (all of them had different motherboards). However, on the third testing machine (having yet another mobo) it seems that the device is not responding again. It is, however, working on Windows with different software on the same machine.

Under “does not respond” I mean that nothing can be read from the serial port during 10-second timeout after sending the command. The whole code is tested and working on another motherboards. The port itself is detected by the kernel correctly as stated in dmesg:

[    1.099382] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.127531] 00:0b: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

There are no warnings in dmesg regarding this serial port. Any ideas on how to debug this issue?

The full output of “stty -F /dev/ttyS0”:

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

Advertisement

Answer

Problem is solved. This model of bill acceptor is working at 19200 baud. Switching the port to 19200 solves the problem.

User contributions licensed under: CC BY-SA
6 People found this is helpful
Advertisement