CDR serial cable tNetTask: restarting receive

[RichardLynch]

I'm trying to get CDR data to an external CentOS computer for analysis by an application I am writing.

The hardware guy has hooked up a cable, and told me to use 9600 7-N-1, no flow control, no handshakes.

I have set up /dev/ttyS0 as follows:

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 cs7 hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-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


When I make a call, I get output such as this:

http://6112northwolcott.com/serial.txt

There seem to be a fair number of garbage characters in the output, including a lot of ^@ (NULL byte?) and an error message:
tNetTask: restarting receive RxNect=## forever=1 counter=0

I have tried every reasonable stty setting, and more than a few UN-reasonable ones.

I can make the whole thing not work at all with baud other than 9600.

I can make it all gibberish with the wrong length/parity/stop bits.

Some settings seem to have no effect...

But I can't get it any cleaner than this.

I was reading a very lengthy tNetTask SNS/Tornado document, which describe in excruciating detail what happened when, but it didn't seem to illuminate my particular issue.

Any suggestions what I could try next? I'm out of ideas.

 

[Altayan]

RichardLynch,

I use a solution called Microcall that attaches via serial cable to a CDR out of the PBX. The settings on the data collection machine are 2400 Baud Rate E-7-1. You might also need a modem eliminator, not necessarily, but it couldn't hurt to try throwing one in.

 

[Reusser]

you seem to be sending info the switch - lot of applicatioins we would remove transmit pin so you could only receive.

Also should not have any flow control turned on.

 

[RichardLynch]

Not sure which setting it was, but we got it working with minicomm, and then just copied the settings over into the shell script, and it's working flawlessly.

I suspect the settings are configuration dependent, so I won't cloudy the waters posting ours.

Use something like minicomm and tweak it until you see the right data, then dump its settings out to the dfl file, and look inside that, and Bob's yer uncle.