in reply to Win32:SerialPort not reading all characters

What UART does your machine have?

And is FIFO buffering enabled?

This probably isn't relevant with modern systems, but I had a similar problem many years ago and enabling FIFO buffering was the cure.


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re: Win32:SerialPort not reading all characters

Replies are listed 'Best First'.
Re^2: Win32:SerialPort not reading all characters
by sxmwb (Pilgrim) on Mar 31, 2008 at 14:58 UTC
    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

      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] ...
      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.
        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

        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