Raw stream of bytes to / from Hyperterminal
July 6, 2006 9:12 PM Subscribe
How can I find out the raw stream of bytes that the Hyperterminal is sending to the EPABX machine and the raw stream (including the control characters) that it is getting back from the EPABX machine ?
My client has installed an EPABX machine and he wants me to connect my VB software with the EPABX machine to generate automatic telephone billing.
The EPABX machine is connected to the computer on a serial port and all the telephone usage details like Dialled number, Call duration, extension from which call was made, etc. are available through the HyperTerminal software (after configuring it properly).
I dont have any technical manual of the EPABX machine. All I have is the HyperTerminal configuration.
If I can find out the raw stream of data, it will help me in decoding the format, by comparing it with the actual data.
My client has installed an EPABX machine and he wants me to connect my VB software with the EPABX machine to generate automatic telephone billing.
The EPABX machine is connected to the computer on a serial port and all the telephone usage details like Dialled number, Call duration, extension from which call was made, etc. are available through the HyperTerminal software (after configuring it properly).
I dont have any technical manual of the EPABX machine. All I have is the HyperTerminal configuration.
If I can find out the raw stream of data, it will help me in decoding the format, by comparing it with the actual data.
Serial sniffers are quite useful. Here's one, though I haven't tried it.
posted by effugas at 12:40 AM on July 7, 2006
posted by effugas at 12:40 AM on July 7, 2006
Decoding transactions without a manual is done all the time when dealing with legacy and/or obsolete hardware. A manual is the best thing to have, however, and is worth the time it takes to get one. Failing that, there are a lot of tools and techniques for getting what you want.
In my experience, more often than not, data coming over a serial port from a remote machine is directly readable, as opposed to binary. (e.g., the number "5551212" would be encoded as the ASCII equivalents of 5, 1, and 2 ($35 $31, $32) and that's what you'd see on the screen.... 5's, 1's and 2's.)
The alternative, sending the bytes in binary form (as either 05050501020102 or 05551212 would come out looking like gibberish and be very hard to decode. The reason it's seldom done this way is to separate data (readable characters) from control codes (usually unreadable) like ETX and CR, LF, which are used to format data and frame transactions and to deal with flow control.
Either way, if you use an old program like Procomm, you can display data coming across a link in hex form and log it to a file for review. ( Hyperterm may allow that, too, but I have so many installations of Procomm that I seldom use anything else for serial comm troubleshooting and I don't know. ) You can make a cable that picks off the serial lines (2, 3, and 5 on a 9-pin D-sub connector) running between two machines and look at the transactions with a third machine without interfering with them. It's a useful technique and tool.
Chances are you have a simple and limited variety interaction going on between the two boxes and it won't be all that hard to figure out what's going on.
There are other programs and techniques for doing this, and it sounds more complicated than it is.
posted by FauxScot at 5:20 AM on July 7, 2006
In my experience, more often than not, data coming over a serial port from a remote machine is directly readable, as opposed to binary. (e.g., the number "5551212" would be encoded as the ASCII equivalents of 5, 1, and 2 ($35 $31, $32) and that's what you'd see on the screen.... 5's, 1's and 2's.)
The alternative, sending the bytes in binary form (as either 05050501020102 or 05551212 would come out looking like gibberish and be very hard to decode. The reason it's seldom done this way is to separate data (readable characters) from control codes (usually unreadable) like ETX and CR, LF, which are used to format data and frame transactions and to deal with flow control.
Either way, if you use an old program like Procomm, you can display data coming across a link in hex form and log it to a file for review. ( Hyperterm may allow that, too, but I have so many installations of Procomm that I seldom use anything else for serial comm troubleshooting and I don't know. ) You can make a cable that picks off the serial lines (2, 3, and 5 on a 9-pin D-sub connector) running between two machines and look at the transactions with a third machine without interfering with them. It's a useful technique and tool.
Chances are you have a simple and limited variety interaction going on between the two boxes and it won't be all that hard to figure out what's going on.
There are other programs and techniques for doing this, and it sounds more complicated than it is.
posted by FauxScot at 5:20 AM on July 7, 2006
Response by poster: OK. I got t his information that the EPABX sends data in "ASCII Packet format".
How can I find out more about this "ASCII Packet format" ? As I said, I dont have any technical manual of the EPABX.
While configuring the HyperTerminal, we have to set Bits per second to 4800, Data Bits = 8 and Parity = None and Stop Bits = 1 and Flow Control = None.
And when I connect the HyperTerminal to the EPABX, then as soon as a call is made using the EPABX, the Hyperterminal displays a line showing the call details after the call is over.
Pls. note that the Hyperterminal does not need to send any command to the EPABX machine.
It just needs to connect with the settings I described above, and then the EPABX starts sending the data.
posted by inquisitive at 9:04 PM on July 9, 2006
How can I find out more about this "ASCII Packet format" ? As I said, I dont have any technical manual of the EPABX.
While configuring the HyperTerminal, we have to set Bits per second to 4800, Data Bits = 8 and Parity = None and Stop Bits = 1 and Flow Control = None.
And when I connect the HyperTerminal to the EPABX, then as soon as a call is made using the EPABX, the Hyperterminal displays a line showing the call details after the call is over.
Pls. note that the Hyperterminal does not need to send any command to the EPABX machine.
It just needs to connect with the settings I described above, and then the EPABX starts sending the data.
posted by inquisitive at 9:04 PM on July 9, 2006
Ascii Packet Format is just three words with capital letters.
It doesn't have any special meaning.
Get a bootable linux CD, run it on the machine you normally run HyperTerm on, and
cat /dev/ttys0 >/tmp/file
Then
hexdump /tmp/file
which should tell you everything you need to know.
Adjust to taste. (If you're not equipped to adjust, find a Linux geek to ask; we're everywhere.)
posted by baylink at 8:41 PM on July 10, 2006
It doesn't have any special meaning.
Get a bootable linux CD, run it on the machine you normally run HyperTerm on, and
cat /dev/ttys0 >/tmp/file
Then
hexdump /tmp/file
which should tell you everything you need to know.
Adjust to taste. (If you're not equipped to adjust, find a Linux geek to ask; we're everywhere.)
posted by baylink at 8:41 PM on July 10, 2006
How can I find out more about this "ASCII Packet format" ?
ASCII is just the standard computer use to create text. The fact that the EPABX is sending ASCII packets means nothing more than the device is sending plain text over the serial port. There's nothing to "decode" there -- the "raw stream" is comprised of the alphabet and numbers!
See this Wikipedia article for more information on ASCII.
While configuring the HyperTerminal, we have to set Bits per second to 4800, Data Bits = 8 and Parity = None and Stop Bits = 1 and Flow Control = None.
Did you see above where I linked to this Microsoft article about how to write a little subroutine in Visual Basic to read the data coming across the serial port instead of using HyperTerminal? In the example, there's a line that reads:
.Settings = "9600,n,8,1"
In this case, based on the information you listed above, you would change it to:
.Settings = "4800,n,8,1"
And then you could use that subroutine to gather the text coming off the serial port and do whatever your client wants you to do with it.
It just needs to connect with the settings I described above, and then the EPABX starts sending the data.
The EPABX is sending data to its serial port whether HyperTerminal is connected or not. All HyperTerminal is doing is displaying what's coming across the line. As above, you can write a little VB app to do the exact same thing using the example I linked to, saving the data and manipulating it however you want.
Regardless, I stress -- what you're seeing in HyperTerminal is the actual data that the EPABX is sending. The issue here isn't some encode/decode process, it's just getting your app to connect to the serial port to receive the data coming across the line.
posted by I EAT TAPAS at 12:24 AM on July 14, 2006
ASCII is just the standard computer use to create text. The fact that the EPABX is sending ASCII packets means nothing more than the device is sending plain text over the serial port. There's nothing to "decode" there -- the "raw stream" is comprised of the alphabet and numbers!
See this Wikipedia article for more information on ASCII.
While configuring the HyperTerminal, we have to set Bits per second to 4800, Data Bits = 8 and Parity = None and Stop Bits = 1 and Flow Control = None.
Did you see above where I linked to this Microsoft article about how to write a little subroutine in Visual Basic to read the data coming across the serial port instead of using HyperTerminal? In the example, there's a line that reads:
.Settings = "9600,n,8,1"
In this case, based on the information you listed above, you would change it to:
.Settings = "4800,n,8,1"
And then you could use that subroutine to gather the text coming off the serial port and do whatever your client wants you to do with it.
It just needs to connect with the settings I described above, and then the EPABX starts sending the data.
The EPABX is sending data to its serial port whether HyperTerminal is connected or not. All HyperTerminal is doing is displaying what's coming across the line. As above, you can write a little VB app to do the exact same thing using the example I linked to, saving the data and manipulating it however you want.
Regardless, I stress -- what you're seeing in HyperTerminal is the actual data that the EPABX is sending. The issue here isn't some encode/decode process, it's just getting your app to connect to the serial port to receive the data coming across the line.
posted by I EAT TAPAS at 12:24 AM on July 14, 2006
This thread is closed to new comments.
If you want to capture that stream within VB itself, this Microsoft article explains how to capture data coming off of a serial port. You'll note that the variables specified in the Form_Load subroutine are the same as the configuration options in HyperTerminal.
As for the format itself, you're best off contacting the manufacturer of the EPABX. Chances are that they have freely available documentation on the format of the CDRs being sent over the serial port. The actual specifications vary from manufacturer to manufacturer, which is the big problem, but chances are that they look something like this or this (which admittedly are just the first reasonably complete CDR specs I found Googling). It may be difficult to figure out by trial and error.
posted by I EAT TAPAS at 9:42 PM on July 6, 2006