in reply to Re: Win32:SerialPort not reading all characters
in thread Win32:SerialPort not reading all characters

BrowserUK,

I will have to look at the laptop. Using a USB serial device to download data from the radio scanner. I am monitoring the port and all the data is coming from the scanner but it seems as if the program is filtering out specific bytes 00, 01, 02 and 03 from what I can tell so far. It may be filtering out these bytes as control characters that should just pass through as I see them in the monitor and the other program I am mimicing handles them just fine. I wonder if this is the way Win32::SerialPort is suppose to work or if I just have an incorrect setting.

Mike

  • Comment on Re^2: Win32:SerialPort not reading all characters

Replies are listed 'Best First'.
Re^3: Win32:SerialPort not reading all characters
by BrowserUk (Patriarch) on Mar 31, 2008 at 15:23 UTC

    A couple of things you could try:

    1. Check/configure the port using the MODE command. 
      C:> mode com1

Status for device COM1:
-----------------------
    Baud:            1200
    Parity:          None
    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:> help mode
Configures system devices.

Serial port:       MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
                                [to=on|off] [xon=on|off] [odsr=on|off]
                                [octs=on|off] [dtr=on|off|hs]
                                [rts=on|off|hs|tg] [idsr=on|off]

Device Status:     MODE [device] [/STATUS]
...

      [download]
    2. Then you can isolate whether it is perl or the module or the port configuration by driving the port manually.

      Write the command sequence into a file using a (binary capable) editor. Then send that sequence to the device: copy file.bin /b comN: /b

      Then retrieve the response using the same technique: copy comN/b response.bin /b. Then you can check the file to see what you get.

      By configuring the port using mode, you can start with a slow transmission rate (say 1200), and whatever handshaking (rts=on or xon=on) until you get reliable transmission. Then slowly ramp the baud rate until it starts to fail or you reach the maximum.

      Once you've figured out what the device is capable of, you can automate the process using the module .

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      BrowserUK, You idea solved the problem. I was able to check the status of the com port before and after running different programs and using the copy to port mechanism.

      What I found was that I was using xoff for handshaking and when I changed that to none the additional characters come through Win32::SerialPort. Looks like xoff handshaking handles certain bytes differently.

      Thanks for the guidance. I have added the information you provided to my toolbox. So Win32::SerialPort was working correctly, I just had wrong parameters.

      Mike

[reply]
      BrowserUK, You idea solved the problem. I was able to check the status of the com port before and after running different programs and using the copy to port mechanism.

      What I found was that I was using xoff for handshaking and when I changed that to none the additional characters come through Win32::SerialPort. Looks like xoff handshaking handles certain bytes differently.

      Thanks for the guidance.

      Mike

[reply]

        That makes a certain amount of sense. Traditionally software handshaking was only used for keyboard/terminal devices where on 'printable' character code were data and the control characters are reserved for control purposes. xon/xoff being done with ^Q/^S and the other control characters had defined meanings: 

        SOH (Start of Heading)
STX (Start of Text)
ETX (End of Text)
EOT (End of Transmission
ENQ (Enquire)
ACK (Acknowledge)
BEL (Bell)
BS  (Backspace)
HT  (Horizontal Tab)
VT  (Vertical Tab)
FF  (Form Feed)
SO  (Shift Out)
SI  (Shift In)
DLE (Data Link Escape)
DC1 (Device Control 1/X-On)
DC2 (Device Control 2)
DC3 (Device Control 3/X-off)
DC4 (Device Control 4)
NAK (Negative Acknowledgement)
SYN (Synchronous Idle)
ETB (End of Transmission Block)
CAN (Cancel)
EM  (End of Medium)
SUB (Substitute)
ESC (Escape)
FS  (File Separator)
GS  (Group Separator)
RS  (Record Separator)
US  (Unit Separator)

        [download]
        It's quite possible that the serial device driver retains special handling for some of those characters when xon is enabled.

        With modern UARTs and FIFO buffering, handshaking is often unnecessary, at least at resonably low speeds, but if your device supports one of the flavours of hardware handshaking, it would be a good idea to enable that.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom