Reading data from the Serial Port

[Anonymous Monk]

I am trying to read data from a paging receiver which is connected to the serial port. Here is the problem, I can only read/store the first 14 characters that are sent to the device. Here is part of my code:

 
$ob->lookclear;    #clear the buffers
$ob->buffers(4096,4096); #read, write 
sleep 1;
until($return ne "")
{
   if (($return = $ob->input) ne "")
   {
      $ob->write ($return);
      print "return:$return a";
   }
   else
   {
     print "ERROR!! Did not receive a page yet!\n";
   }
}#end until
print "return is:$return";
undef $ob;

Is there any way to store more than 14 characters in the variable. Also, any sample "serial port" code would be helpful. Thanks for your help, Jason

[BrowserUk]

There are a lot of assumptions (on my behalf) inferred from the information you have given us.

14 bytes sounds like the default FIFO buffer size for COMn: ports (under win32 anyway).

That you get the first 14 bytes and no more suggests that some form of handshaking is involved. That it isn't being reset automatically means that it (the comm port) is probably set up for software (Xon/Xoff) handshaking.

If you are on a win32 system, the easiest way to verify this would be to open a CMD window and issue the command:

C:\test>mode com1 /STATUS

Status for device COM1:
-----------------------
    Baud:            1200
    Parity:          Even
    Data Bits:       7
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON


C:\test>

That was from the (currently inactive) com1 on my NT system.

If you are simply reading from the port and want to 'slurp' as much as possible, you could use the control-panel->ports (or the mode command (see help mode) to switch the handshaking off.

This isn't going to help much if the device attached to the other end needs the hadshaking though. If the device is waiting for you to empty the buffer, and has recieved an Xoff (ascii 14?) ... it will be waiting for an Xon (ascii 15?). Maybe just writing the appropriate one will restart the flow. There is probably a module that will take care of this nastiness for you on CPAN.

Of course, if your not using win32, ignore me and wait for one of the "real programmers" to supply similar info for *nix systems:)

[talexb]

XON is ^Q, XOFF is ^S -- I just remember that they are S and Q, with the S standing for Stop and the Q for Qontinue. ^A has a hex value of 1 (0x01), so if you know that T is the twentieth letter in the alphabet, then you can figure out that ^S is 0x13 and ^Q is 0x11. SOme ASCII charts have them as DC3 and DC1, respectively -- the DC part stands for Device Control.

--t. alex

"Mud, mud, glorious mud. Nothing quite like it for cooling the blood!"
--Michael Flanders and Donald Swann

[BrowserUk]

++. I couldn't remember, its been a long time since I played with comm ports. 14 & 15 are of course ShiftIn and ShiftOut which are (or maybe have been) used for similar handshaking purposes under some protocols.

[talexb]

• What software are you using to read from the serial port?
• How do you know that Perl is losing data after 14 characters? Is it possible that Perl is catching up after 14 characters and the loop fails after getting an 'empty buffer' from the read subroutine?
• How fast is the data entering the serial port? Is there any flow control (XON/XOFF or CTS/RTS) that might be interfering?
• What other experiments have you conducted?

--t. alex

"Mud, mud, glorious mud. Nothing quite like it for cooling the blood!"
--Michael Flanders and Donald Swann

[Anonymous Monk]

The device (Waveware paging data receiver) doesnt have flow control. I connect to the receiver at 9600 8 N 1. I am using the perl program that i posted to read the serial port, i have checked what i am receiving with hyperterm. Also, i am the one generating the pages (POCSAG format being sent at 512bps) from a paging client so i can be sure of what should appear on the serial port. Thanks, Jason

[talexb]

When I did data communications programming as my job, my favourite tool was the HP 4951A protocol analyzer -- it would tell you anything about everything that was going on over a serial communications channel.

You probably don't have one of those .. you might be able to get a break-out box which at least would tell you if there is some flow control stuff going on. Alternatively, look for breakout box software on Google -- I'd pass you some links but either Google is slow or my connection is tired right now. Highly recommended.

Based on what little information is available, I expect it's going to be some type of flow control problem -- is there any way you can set up the serial port or the software talking to the port to enable, disable or automate the flow control?

--t. alex

"Mud, mud, glorious mud. Nothing quite like it for cooling the blood!"
--Michael Flanders and Donald Swann

[Nitrox]

Take a look at the streamline() function in WIN32::SerialPort.

Also take a look at PortMon from SysInternals, it allows you to "sniff" the port traffic in real time(and it's free!). I live by it when developing serial communication apps.

-Nitrox