Loading ...
Sorry, an error occurred while loading the content.

Data transmit problems with USB-serial port with LB4

Expand Messages
  • anoop
    Hi, I am wondering if someone else has similar problems and there is a solution to this problem. Problem summary: When data is written from LB4 to a USB-serial
    Message 1 of 6 , Feb 2, 2012
    • 0 Attachment
      Hi,

      I am wondering if someone else has similar problems and there is a solution to this problem.

      Problem summary:
      When data is written from LB4 to a USB-serial port, all data may not go out on serial line and the problem occurs on some PCs and not on
      some other PC's.

      Here are the details:
      I am using LB4 with WinXP PC, with a USB-to-serial adapter based on FTDI's FT232 chip. It shows up on my PC as COM8.
      I communicate with another device which has my own microcontroller
      that just receives data and displays on a LCD screen.
      This data communication happens in packets of 32 bytes, at 9600 baud.
      The receiver of data sends back an ack after it receives all 32 bytes.

      What I have seen is that this works fine on some PC's. But on some other
      PC's (all with WinXP) part of the data goes out but some does not.
      The LB program says it finished sending data out but when I monitor
      the serial line, I see that only some data has come out.
      So, my program goes to next section, trys to read the ack from receiver
      of data and hangs.

      Basically, it looks like FTDI drivers on WindowsXP do not work the
      same way on all PC's. I do not see any command in LB4 to flush data out of COM port after all data is written (which makes me think that data should go out character by character as it is written to COM port, except it does not always does that)

      I have tried to tweak all available driver parameters under
      Control panel-system-device manager-hardware-COM/LPT port-USB/serial
      (like TX and RX buffer sizes from 32 bytes to 4K and different
      timeout values from 0 to a few hundred milli-seconds but nothing
      helps.

      If someone has seen such a problem and know a solution or workaround, kindly let me know.

      Thanks

      Anoop Hegde
      anooph@...
    • Fritz Oppliger
      I have no clue. Since you are able to intercept, is there any pattern... last character sent, CR or LF or such? I don t know how these would differ between
      Message 2 of 6 , Feb 2, 2012
      • 0 Attachment
        I have no clue.
        Since you are able to intercept, is there any pattern... last character
        sent, CR or LF or such? I don't know how these would differ between
        machines but it could be print policy thing somewhere...
        Can you inject (fake) an override ACK and see if/where the packet resumes?
        Good luck
        Fritz

        On Thu, 02 Feb 2012 18:48:52 -0800, anoop <anooph@...> wrote:

        > Hi,
        >
        > I am wondering if someone else has similar problems and there is a
        > solution to this problem.
        >
        > Problem summary:
        > When data is written from LB4 to a USB-serial port, all data may not go
        > out on serial line and the problem occurs on some PCs and not on
        > some other PC's.
        >
        > Here are the details:
        > I am using LB4 with WinXP PC, with a USB-to-serial adapter based on
        > FTDI's FT232 chip. It shows up on my PC as COM8.
        > I communicate with another device which has my own microcontroller
        > that just receives data and displays on a LCD screen.
        > This data communication happens in packets of 32 bytes, at 9600 baud.
        > The receiver of data sends back an ack after it receives all 32 bytes.
        >
        > What I have seen is that this works fine on some PC's. But on some other
        > PC's (all with WinXP) part of the data goes out but some does not.
        > The LB program says it finished sending data out but when I monitor
        > the serial line, I see that only some data has come out.
        > So, my program goes to next section, trys to read the ack from receiver
        > of data and hangs.
        >
        > Basically, it looks like FTDI drivers on WindowsXP do not work the
        > same way on all PC's. I do not see any command in LB4 to flush data out
        > of COM port after all data is written (which makes me think that data
        > should go out character by character as it is written to COM port,
        > except it does not always does that)
        >
        > I have tried to tweak all available driver parameters under
        > Control panel-system-device manager-hardware-COM/LPT port-USB/serial
        > (like TX and RX buffer sizes from 32 bytes to 4K and different
        > timeout values from 0 to a few hundred milli-seconds but nothing
        > helps.
        >
        > If someone has seen such a problem and know a solution or workaround,
        > kindly let me know.
        >
        > Thanks
        >
        > Anoop Hegde
        > anooph@...
        >
      • Jim Hiley
        Are you using the same version of the FTDI drivers on all PCs? I would try updating to the latest or at least a version that does work. Can you test the
        Message 3 of 6 , Feb 2, 2012
        • 0 Attachment
          Are you using the same version of the FTDI drivers on all PCs?
          I would try updating to the latest or at least a version that does work.
          Can you test the communications with some other program such as teraterm.
          With teraterm, you can easily vary the time between characters.
          If that works you could feed the characters one at a time but there should
          be no need to do it if all is well.

          I have had no problems with LB and serial comms but I have certainly had to
          deal with faulty/buggy USB to serial converter.


          Jim

          -----Original Message-----
          From: libertybasic@yahoogroups.com [mailto:libertybasic@yahoogroups.com] On
          Behalf Of anoop
          Sent: Friday, 3 February 2012 13:49
          To: libertybasic@yahoogroups.com
          Subject: [libertybasic] Data transmit problems with USB-serial port with LB4

          Hi,

          I am wondering if someone else has similar problems and there is a
          solution to this problem.

          Problem summary:
          When data is written from LB4 to a USB-serial port, all data may not go out
          on serial line and the problem occurs on some PCs and not on
          some other PC's.

          Here are the details:
          I am using LB4 with WinXP PC, with a USB-to-serial adapter based on FTDI's
          FT232 chip. It shows up on my PC as COM8.
          I communicate with another device which has my own microcontroller
          that just receives data and displays on a LCD screen.
          This data communication happens in packets of 32 bytes, at 9600 baud.
          The receiver of data sends back an ack after it receives all 32 bytes.

          What I have seen is that this works fine on some PC's. But on some other
          PC's (all with WinXP) part of the data goes out but some does not.
          The LB program says it finished sending data out but when I monitor
          the serial line, I see that only some data has come out.
          So, my program goes to next section, trys to read the ack from receiver
          of data and hangs.

          Basically, it looks like FTDI drivers on WindowsXP do not work the
          same way on all PC's. I do not see any command in LB4 to flush data out of
          COM port after all data is written (which makes me think that data should go
          out character by character as it is written to COM port, except it does not
          always does that)

          I have tried to tweak all available driver parameters under
          Control panel-system-device manager-hardware-COM/LPT port-USB/serial
          (like TX and RX buffer sizes from 32 bytes to 4K and different
          timeout values from 0 to a few hundred milli-seconds but nothing
          helps.

          If someone has seen such a problem and know a solution or workaround, kindly
          let me know.

          Thanks

          Anoop Hegde
          anooph@...
        • Rod
          Do some loop back tests. First loop straight back to the com port you are using. Second use another pc on a short link rather than your device. If you find
          Message 4 of 6 , Feb 3, 2012
          • 0 Attachment
            Do some loop back tests. First loop straight back to the com port you are using. Second use another pc on a short link rather than your device. If you find that transmission is ok in these circumstances (and I think you will) then you need to look at line length and signal quality. Try a pc at the termination rather than the device. Be sure you are using twisted pair good quality cable. Debug the device by getting it to print or display what it is getting.

            Liberty does have a command to check the length of the transmit queue but I don't think that is where your problem is.

            --- In libertybasic@yahoogroups.com, "anoop" <anooph@...> wrote:
            >
            > Hi,
            >
            > I am wondering if someone else has similar problems and there is a solution to this problem.
            >
            > Problem summary:
            > When data is written from LB4 to a USB-serial port, all data may not go out on serial line and the problem occurs on some PCs and not on
            > some other PC's.
            >
            > Here are the details:
            > I am using LB4 with WinXP PC, with a USB-to-serial adapter based on FTDI's FT232 chip. It shows up on my PC as COM8.
            > I communicate with another device which has my own microcontroller
            > that just receives data and displays on a LCD screen.
            > This data communication happens in packets of 32 bytes, at 9600 baud.
            > The receiver of data sends back an ack after it receives all 32 bytes.
            >
            > What I have seen is that this works fine on some PC's. But on some other
            > PC's (all with WinXP) part of the data goes out but some does not.
            > The LB program says it finished sending data out but when I monitor
            > the serial line, I see that only some data has come out.
            > So, my program goes to next section, trys to read the ack from receiver
            > of data and hangs.
            >
            > Basically, it looks like FTDI drivers on WindowsXP do not work the
            > same way on all PC's. I do not see any command in LB4 to flush data out of COM port after all data is written (which makes me think that data should go out character by character as it is written to COM port, except it does not always does that)
            >
            > I have tried to tweak all available driver parameters under
            > Control panel-system-device manager-hardware-COM/LPT port-USB/serial
            > (like TX and RX buffer sizes from 32 bytes to 4K and different
            > timeout values from 0 to a few hundred milli-seconds but nothing
            > helps.
            >
            > If someone has seen such a problem and know a solution or workaround, kindly let me know.
            >
            > Thanks
            >
            > Anoop Hegde
            > anooph@...
            >
          • Fritz Oppliger
            Test for bad cabling, abused USB ports , consistency between USB ports on the same machine...
            Message 5 of 6 , Feb 3, 2012
            • 0 Attachment
              Test for bad cabling, abused USB ports , consistency between USB ports on
              the same machine...
            • thedreamer1901
              Microcontrollers have very limited buffers and somewhat primitive receive systems. PIC devices for example normally only have a two byte buffer. If the data
              Message 6 of 6 , Feb 3, 2012
              • 0 Attachment
                Microcontrollers have very limited buffers and somewhat primitive receive systems. PIC devices for example normally only have a two byte buffer. If the data handling is not performed fast enough, bytes can be lost. PICs will have an overflow flag set but it has to be read to know the overflow has happened. Interrupts need to be handled in a timely manner or polling must be regular to handle every byte correctly.

                Additionally, setting the output to 1 stop bit can sometimes result in framing errors if timings are inaccurate. It might be worth setting two stop bits or providing a short pause between bytes to allow a longer idle time between bytes. This will provide for a controller running a baud rate generator slightly slow due to errors in clock division. PICs typically have an error of 1 - 2% for 9600 or 19200 rates when using clocks of 4MHz or 8MHZ.

                If these don't fix the problem, it is worth finding out which bytes are being lost. Try a test routine with 32 bytes of value 00, 01, 02 etc and by reading the received data from the micro-controller, you will find out which bytes are being lost. Missing bytes at regular intervals or consistent positions within the 32 byte packet would point to the controller rather than the PC.

                My experience with a variety of internal and USB serial ports on several machines is that Liberty is absolutely consistent and stable when using them. All my serial problems have been tracked down to custom micro-controllers and their software so keep looking

                --- In libertybasic@yahoogroups.com, "anoop" <anooph@...> wrote:
                >
                > Hi,
                >
                > I am wondering if someone else has similar problems and there is a solution to this problem.
                >
                > Problem summary:
                > When data is written from LB4 to a USB-serial port, all data may not go out on serial line and the problem occurs on some PCs and not on
                > some other PC's.
                >
                > Here are the details:
                > I am using LB4 with WinXP PC, with a USB-to-serial adapter based on FTDI's FT232 chip. It shows up on my PC as COM8.
                > I communicate with another device which has my own microcontroller
                > that just receives data and displays on a LCD screen.
                > This data communication happens in packets of 32 bytes, at 9600 baud.
                > The receiver of data sends back an ack after it receives all 32 bytes.
                >
                > What I have seen is that this works fine on some PC's. But on some other
                > PC's (all with WinXP) part of the data goes out but some does not.
                > The LB program says it finished sending data out but when I monitor
                > the serial line, I see that only some data has come out.
                > So, my program goes to next section, trys to read the ack from receiver
                > of data and hangs.
                >
                > Basically, it looks like FTDI drivers on WindowsXP do not work the
                > same way on all PC's. I do not see any command in LB4 to flush data out of COM port after all data is written (which makes me think that data should go out character by character as it is written to COM port, except it does not always does that)
                >
                > I have tried to tweak all available driver parameters under
                > Control panel-system-device manager-hardware-COM/LPT port-USB/serial
                > (like TX and RX buffer sizes from 32 bytes to 4K and different
                > timeout values from 0 to a few hundred milli-seconds but nothing
                > helps.
                >
                > If someone has seen such a problem and know a solution or workaround, kindly let me know.
                >
                > Thanks
                >
                > Anoop Hegde
                > anooph@...
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.