Reading Serial port data from Nortel/Meridian PBX how to decode?

[snorkel]

well, got some bad news on this.  I had it working with the serial port splitter with Procomm and my app running at the same time.
We turned procomm off and the macro express thing and when the PBX sent data with just my app running with no splitter software on com1 we got a bunch of garbage back(see below)
So now I have no idea what the heck is going on.  Was procomm sending a command to get the PBX to send the data?  I have no idea now.

ohDhb&@b@C8cmh@

bG

DeF(

DHBBB@#BBLD

@GU@)VB`A

CPHC xL

HFH#BBBBBB@

HF

<@#

@`!

J18@BBBB@B@BBFD@KAe!BFCHL@G$OEFFLD,FFNJu@B@@@BBPD

[engkin]

Was procomm sending a command to get the PBX to send the data?

No. You do not have the right settings, yet!

When you wrote:

we where able to install and use that serial port monitor software and it captured this

You did show simple text.

I just found out that the phone people upgraded the PBX software a few months ago

That has nothing to do with your data now or in 2010.

I found the data output from 2010 and this is what it looked like:

It was not bad. Someone suggested that you needed to turn off bit 8.

we got the port splitter software on there and it worked perfectly

I assume the port splitter used the settings YOU want on YOUR side. Did not let you see the real settings of the original data.

Again, find the correct settings.

[snorkel]

we turned the port splitter back on and it's still spitting out the garbage, the settings are correct.  we think procom may be sending a command back that tells the PBX to output the report.

This was a old process that was not documented at all.

While the port splitter was enabled procom and my lazarus app ran at the same time with the splitter sending the data to virtual com2 for procomm and virtual com3 for my lazarus app, and they both worked perfectly, it's not the comm settings, procom and my app have the exact same settings.   Back to the drawing board :-(

[engkin]

Turning the port splitter on again is not going to make it discover the settings. If there is no other connection at all except from your software with wrong settings, the port splitter can not do the trick.

I'll be more than happy to be wrong. 

[snorkel]

well, we put the port splitter back on and as a test had procomm connect to the virtual com3 and it received garbage.
We then put it back with Procomm on vcom2 and my lazarus app on vcom3 and low and behold it started working again.
vcom2 is read/write while vcom3 is read only.  All setting remained the same.  Not sure what is going on here. is it possible the PBX had
some kind of issue and this is coincidence?

[engkin]

is it possible the PBX had some kind of issue...

No.

...this is coincidence?

No.

[snorkel]

I have done some more testing and it's not the communication settings.  The parity baud etc is the same on procomm and my lazarus serial port reader app.

Here is what happens, when using the serial port splitter after procomm receives a one good data stream, I can shut procomm down and my app
will continue to received good data.   If procomm uses one of the read only virtual com ports connected to the physical com1 it also receives garbage data, when procomm is connected to a read/write virtual port off of com1 it works fine and then my app connected to the read only virtual com3 works fine as well.  If my app is connected to the physical com1 it recieves this:

o"FJ)b   cCDH BA!OFh DDB(@BChh,FlFF

!`"JdeDNDeL(FFFFF@#(BBC(PF@Ho
`P"<$

FaB(BBC(#
FF
 F
 <EAL`
lBCB
 "ODFFF
OEFDFFu,#hPFFF{

I have attached the file showing my app receiving perfect data up until the point I turn off procom and restart my app.

I know engkin you thing it's the comunication settings, but I can assure you that's not the problem.
Procomm is sending some commands that's putting the PBX terminal in state that sends the data properly, is it VT100?  That's what procom is set to use for the direct connect on virtual com2.

So how can I make my Lazarus app tell the PBX to output in the correct format?

Is procomm somehow adjusting the bits or parity on the fly?   All I know is if procomm is connected on virtual com2 read/write and my Lazarus app is connected on virtual com3 read only I get perfect data reads from my Laz app, or if I keep mine connected and then shut down procomm the PBX continues to send good data, if I shut down mine and restart it after procomm is shut down I get the data shown above and as shown in the end of the attached file.

[snorkel]

I opened the data in notepadd++ which shows VT100 codes as graphical images and the data is VT100.
Procomm is putting the pbx terminal in VT100 mode, and once it's in VT100 I can continue to get the good data as long as I connected my
app before I shut down procomm this works because the com port splitter stays connected on the physical com1, but as soon as I disconnect my app and then start it again with no procomm first I get garbage vt100, probably saying it's a invalid terminal or something.

I am positive that is what's going on now, the lazarus synaser connection settings are fine, the problem is I somehow need to get the session in
VT100 mode and after that everything is cool.

[engkin]

You already have a serial port monitor software, if you use it would it show any data sent by ProComm?

Another question, do you consider handshaking a type of data? I assume a read-only port would not be able to provide handshaking.

I'm sure you're pretty smart, so I will not push further toward the settings used in ProComm.

[snorkel]

I did run the monitor software and it does show handshaking going on with procomm, which is probably why it recieved junk when connected to
the read only virtual com port.  The monitor software did show procom executing a serial_set_XON, so maybe procomm is overriding the settings
that we have it set to.  The procomm modem setting have the flow control set to NONE, not XON/XOFF.

So the thing I have to find out is how to get my Lazarus app to do the same handshaking.  I am now running hyperterminal instead of procomm to see if that works with the same comm settings procomm has defined in the setup screens.

It sucks because I can only test once per hour.

If all else fails I can just use the splitter software and have procomm and my app running at the same time, at least that will take macro express out of the equation.

[engkin]

How often do you see XON signals?
What serial port monitor software are you using? does it show connection settings?

[snorkel]

I am using the Advanced Serial Port Monitor:

My Lazarus app that uses synaser shows this: while sitting idle waiting for data:
<20131120154335.092 SYS>
COM is open
<20131120154335.092 SYS>
In/out queue size 4096/0
<20131120154335.092 SYS>
Set timeouts: ReadInterval=65535, ReadTotalTimeoutMultiplier=0, ReadTotalTimeoutConstant=0, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0
<20131120154335.092 SYS>
RTS on
<20131120154335.092 SYS>
DTR on
<20131120154335.092 SYS>
Purge the serial port: RXABORT, RXCLEAR, TXABORT, TXCLEAR

I also got it to work in hyperterminal as a test and that shows:

<20131120155157.330 SYS>
COM is open
<20131120155157.330 SYS>
In/out queue size 8192/8192
<20131120155157.330 SYS>
Baud rate 9600
<20131120155157.330 SYS>
RTS on
<20131120155157.330 SYS>
DTR on
<20131120155157.330 SYS>
Data bits=8, Stop bits=1, Parity=None
<20131120155157.330 SYS>
Set chars: Eof=0x00, Error=0x00, Break=0x00, Event=0x00, Xon=0x11, Xoff=0x13
<20131120155157.330 SYS>
Handflow: ControlHandShake=(DTR_CONTROL, ERROR_ABORT), FlowReplace=(AUTO_TRANSMIT, AUTO_RECEIVE, TRANSMIT_TOGGLE, RTS_CONTROL, XOFF_CONTINUE), XonLimit=80, XoffLimit=200
<20131120155157.330 SYS>
Set timeouts: ReadInterval=10, ReadTotalTimeoutMultiplier=0, ReadTotalTimeoutConstant=0, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=5000

It works in hyperterminal with a few different terminal types.  It appears procomm was overriding the settings we had and enabling flow control
and my laz app had flow control set to None.  It's going to run again soon and my app now has flow control set as the monitor software shows.

hopefully that is the issue.   I have my app on the read/write port and hyperterminal on the read only, I expect to see junk in hyperterminal because it could not do the flow control handshake and my app "should" get good data now...crossing fingers.

[snorkel]

well, it didn't work, with hardware flow control enabled I got this in my Laz app, will have to try software xoff/xon next.


<20131120160140.881 RX>
_FF<DC1>F<NAK>S<BS><BS>(<ACK><SO><ETX><NUL>c<FF><EOT>dg<EOT>b<ETX><DC4><STX><STX><EOT>A<FS><EOT>`.<EOT><EOT>FJ<SI><ACK>DF<BS>F<STX>h<ETX>C<ETX>h<BS>B<ETX>B<ETX><FF><ACK>H<SO>DG<ACK>F<BS><EOT>E*@<NUL><EOT><DC4>`<ENQ><LF><BS><ACK><STX>C<STX>o<SO>b<LF><ENQ><NUL>F<SO><STX><BS><ACK><RS>&<BS><EOT><ACK><EOT>C<SO><ACK><LF><BS><ACK><ACK><BS>F<BS>@BBCC<ETX>(<STX>B<ETX>F<BS>F<BS><EOT><ACK><BS><ACK><ACK><VT><ACK><NUL><EOT><ETX><ACK><STX><ACK><STX><ACK><SO>0CC<ETX><DC2><LF>%<ACK><BS><NUL><NUL><ACK><ACK><BS><EOT>F<BS><NUL><ETX>B(@#(@<ETX>BCB#<ACK>Fj<ACK><ACK>F<LF><ACK><BS>F0<ENQ>PKALR<LF>@<<EOT><BS><NUL>x<ETX>BIa`<ACK><VT> [len=194]
<20131120160142.444 RX>
@<NUL>O9<ACK><ACK><ACK>F<BS>D<BS><ACK>FH<ACK>F<LF>e<FF><EOT><ACK>F<LF>D (B<STX>CB<ETX>#<BS>Bb<ACK><BS><ACK>HN<LF><ACK><BS>@F~

wrote this in the file:

_FFFS( cdgbA`.FJDFFhChBBHDGFE*@ `
Cob
 F&C
F@BBCC(BFF 0CC
%  F B(@#(@BCB#FjF
F0PKALR
@< xBIa`
@ O9FDFHF
eF
D (BCB#BbHN
@F~

[snorkel]

looks like my laz app is missing this:

Handflow: ControlHandShake=(DTR_CONTROL, ERROR_ABORT), FlowReplace=(AUTO_TRANSMIT, AUTO_RECEIVE, TRANSMIT_TOGGLE, RTS_CONTROL, XOFF_CONTINUE), XonLimit=80, XoffLimit=200

Not sure how to set this.

[engkin]

I am using the Advanced Serial Port Monitor:
...
My Lazarus app that uses synaser shows this
...
I also got it to work in hyperterminal as a test and that shows:
...
Baud rate 9600
...
Data bits=8, Stop bits=1, Parity=None
...

I have two questions:
1-Why didn't you do that same test on ProComm?
2-Can you explain why it showed settings used in HyperTerminal, but not in your Lazarus app?