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

Air cable slow compared to rs232 cable

Expand Messages
  • navaho4x4
    Air cable communication is very slow. Bluetooth is configured as COM5 at 115200 baud on PC and so is the RoboJDE GUI. 115200 speed on rs232 cable is much
    Message 1 of 6 , Jun 20, 2008
    • 0 Attachment
      Air cable communication is very slow. Bluetooth is configured as COM5
      at 115200 baud on PC and so is the RoboJDE GUI. 115200 speed on rs232
      cable is much faster than 115200 on Air cable. Intellibrain itself is
      configured at 115200.

      Blue tooth is suppose to have a range of 30feet but I was testing at
      range of only 3 feet and still very slow.


      I plan to use Intellibrain bot with heavy communication to PC in order
      offload the processing and memory requirements.
      Will Air cable become a communications bottle neck ?
      How can improve on the speed ?
    • RidgeSoft
      Communication via the AirCable will not be as fast as via a real cable. The input and the output of the AirCable are RS232 at 115200. The AirCable can t
      Message 2 of 6 , Jun 21, 2008
      • 0 Attachment
        Communication via the AirCable will not be as fast as via a real cable.
        The input and the output of the AirCable are RS232 at 115200. The
        AirCable can't increase the input and output speed since these aare
        fixed, it can only slow communication down, or at best match the speed
        with a real cable. The main reasons for this are 1) latency added by
        converting protocol fromRS232 to Bluetooth and back to Rs232 and 2)
        interference. If there are other 2.4 GHz devices in the area such as
        802.11b/g networks, cordless phones and other Bluetooth devices, they
        will interfere with each other and have to share the airwaves. Check
        for other 2.4 GHz devices in the area and turn them off if possible, or
        try testing at a different location, far away from such devices.

        If you are writing a communication protocol over your own to use the
        AirCable, it will generally work better if you send data in larger
        messages than smaller messages and write entire messages to the port in
        one operation rather than writing one byte at time.

        Regards,

        RidgeSoft Support


        --- In intellibrain@yahoogroups.com, "navaho4x4" <dsuarez1@...> wrote:
        >
        > Air cable communication is very slow. Bluetooth is configured as COM5
        > at 115200 baud on PC and so is the RoboJDE GUI. 115200 speed on rs232
        > cable is much faster than 115200 on Air cable. Intellibrain itself is
        > configured at 115200.
        >
        > Blue tooth is suppose to have a range of 30feet but I was testing at
        > range of only 3 feet and still very slow.
        >
        >
        > I plan to use Intellibrain bot with heavy communication to PC in order
        > offload the processing and memory requirements.
        > Will Air cable become a communications bottle neck ?
        > How can improve on the speed ?
        >
      • Paul King
        I was interested in understanding this serial communication issue a bit better myself. Before I start, let me say that I have been playing with the
        Message 3 of 6 , Sep 29, 2008
        • 0 Attachment
          I was interested in understanding this serial communication issue a
          bit better myself.

          Before I start, let me say that I have been playing with the
          IntelliBrain 2 board off and on for a year now, and I am very
          impressed with it. It is the most cleanly designed and feature-
          packed controller board I have come across. I like it better than
          Parallax, Arduino, VEX, and others I have tried out. Every design
          decision, and especially the design decisions in the Java VM and
          control library seem first rate and professional.

          Now back to the bluetooth/RS232 issue!

          I'm using the GridConnect serial bluetooth "virtual cable" and am
          experiencing the same slow bandwidth relative to RS232.

          In both the RS232 and bluetooth cases, the baud rate is set to
          115,200 bps.

          When I use RoboJDE to download a program with code size 13KB, it
          takes 4 seconds to download with the RS232 cable (actually RS232 to
          USB cable), which works out to about 32,000 bps. Using the bluetooth
          virtual serial cable, it takes 20 seconds to download, which is 5x
          slower at only 6,500 bps.

          Supposedly Bluetooth 2.0 with "Enhanced Data Rate" supports data
          transfer speeds up to 2.1 Mbps (2,100,000 bps). Even bluetooth 1.2
          is supposed to support 721 kpbs (721,000 bps). So blaming the delay
          on bluetooth seems suspect.

          It is also puzzling that in both cases, the JDE program download
          speed is substantially below even the 115,200 bps RS232 baudrate.
          Over bluetooth, it appears to be a low 6,500 bps which is
          substantially under the theoretical bluetooth speed of 2.1 Mbps or
          721 kpbs, depending on the version.

          Perhaps the culprit is a synchronous protocol used by the JDE program
          download. If a round-trip with ACK occurred for each packet, then
          the additional transmisison latency introduced by bluetooth wireless
          transmission could account for the 5x slowdown. It is okay if this
          is the case -- it would just be good to know so as to understand what
          is going on. If this is the explanation, then a cleverly-written
          asynchronous serial protocol shouldn't see any bandwidth reduction at
          all between RS232 and bluetooth, and should be able to sustain
          115,200 bps bidirectional transfer.

          Any thoughts about this?

          btw, I am rewriting the pyrorobotics driver for IntelliBrain.
          Pyrorobotics is a python robotics workbench. The updated driver I'm
          working on will be high-performance, asynchronous, and extensible
          with optimized use of memory. I'm happy to share it if anyone else
          wants to use it.

          Best,
          Paul
          www.pking.org
          email@...


          --- In intellibrain@yahoogroups.com, "RidgeSoft" <rs1@...> wrote:
          >
          >
          > Communication via the AirCable will not be as fast as via a real
          cable.
          > The input and the output of the AirCable are RS232 at 115200. The
          > AirCable can't increase the input and output speed since these aare
          > fixed, it can only slow communication down, or at best match the
          speed
          > with a real cable. The main reasons for this are 1) latency added
          by
          > converting protocol fromRS232 to Bluetooth and back to Rs232 and 2)
          > interference. If there are other 2.4 GHz devices in the area such
          as
          > 802.11b/g networks, cordless phones and other Bluetooth devices,
          they
          > will interfere with each other and have to share the airwaves.
          Check
          > for other 2.4 GHz devices in the area and turn them off if
          possible, or
          > try testing at a different location, far away from such devices.
          >
          > If you are writing a communication protocol over your own to use the
          > AirCable, it will generally work better if you send data in larger
          > messages than smaller messages and write entire messages to the
          port in
          > one operation rather than writing one byte at time.
          >
          > Regards,
          >
          > RidgeSoft Support
          >
          >
          > --- In intellibrain@yahoogroups.com, "navaho4x4" <dsuarez1@> wrote:
          > >
          > > Air cable communication is very slow. Bluetooth is configured as
          COM5
          > > at 115200 baud on PC and so is the RoboJDE GUI. 115200 speed on
          rs232
          > > cable is much faster than 115200 on Air cable. Intellibrain
          itself is
          > > configured at 115200.
          > >
          > > Blue tooth is suppose to have a range of 30feet but I was testing
          at
          > > range of only 3 feet and still very slow.
          > >
          > >
          > > I plan to use Intellibrain bot with heavy communication to PC in
          order
          > > offload the processing and memory requirements.
          > > Will Air cable become a communications bottle neck ?
          > > How can improve on the speed ?
          > >
          >
        • RidgeSoft
          Hi Paul, You are correct that the combination of the protocol and the latency introduced by the cable affects the program download speed. The download
          Message 4 of 6 , Sep 30, 2008
          • 0 Attachment
            Hi Paul,

            You are correct that the combination of the protocol and the latency
            introduced by the cable affects the program download speed. The
            download protocol is a simple request-response protocol. It is
            sensitive to latency. It was designed for simplicity and mininal
            memory use on the robotics controller when the original version of
            the RoboJDE virtual machine was created for the Handy Board, which
            only has 32K of RAM in which to fit the VM, the application program
            and the data and buffering for both. Supporting high latency wasn't
            an important requirement back then. However, this protocol is only
            used for VM to host communication. Java applications written for the
            robotics controller are free to implement more advanced protocols, as
            you are doing.

            You might want to take a look at the Mailbox class in the MS Robotics
            Studio integration example. See
            http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm
            . This class provides an example of a much more advanced protocol
            that supports reliable delivery and windowing. The class is
            symmetric, so the same class can be used on the host computer as on
            the robotics controller.

            In implementing your own protocol, be aware that there is only a 64
            byte buffer in the serial port receiver on the robotics controller.
            Your Java class needs to service the receive stream at a high enough
            frequency to avoid bytes being lost due to overruning this buffer.
            64 bytes gives about 5 milliseconds of buffering at 115.2K.

            Regards,

            RidgeSoft Support



            --- In intellibrain@yahoogroups.com, "Paul King" <email@...> wrote:
            >
            > I was interested in understanding this serial communication issue a
            > bit better myself.
            >
            > Before I start, let me say that I have been playing with the
            > IntelliBrain 2 board off and on for a year now, and I am very
            > impressed with it. It is the most cleanly designed and feature-
            > packed controller board I have come across. I like it better than
            > Parallax, Arduino, VEX, and others I have tried out. Every design
            > decision, and especially the design decisions in the Java VM and
            > control library seem first rate and professional.
            >
            > Now back to the bluetooth/RS232 issue!
            >
            > I'm using the GridConnect serial bluetooth "virtual cable" and am
            > experiencing the same slow bandwidth relative to RS232.
            >
            > In both the RS232 and bluetooth cases, the baud rate is set to
            > 115,200 bps.
            >
            > When I use RoboJDE to download a program with code size 13KB, it
            > takes 4 seconds to download with the RS232 cable (actually RS232 to
            > USB cable), which works out to about 32,000 bps. Using the
            bluetooth
            > virtual serial cable, it takes 20 seconds to download, which is 5x
            > slower at only 6,500 bps.
            >
            > Supposedly Bluetooth 2.0 with "Enhanced Data Rate" supports data
            > transfer speeds up to 2.1 Mbps (2,100,000 bps). Even bluetooth 1.2
            > is supposed to support 721 kpbs (721,000 bps). So blaming the delay
            > on bluetooth seems suspect.
            >
            > It is also puzzling that in both cases, the JDE program download
            > speed is substantially below even the 115,200 bps RS232 baudrate.
            > Over bluetooth, it appears to be a low 6,500 bps which is
            > substantially under the theoretical bluetooth speed of 2.1 Mbps or
            > 721 kpbs, depending on the version.
            >
            > Perhaps the culprit is a synchronous protocol used by the JDE
            program
            > download. If a round-trip with ACK occurred for each packet, then
            > the additional transmisison latency introduced by bluetooth
            wireless
            > transmission could account for the 5x slowdown. It is okay if this
            > is the case -- it would just be good to know so as to understand
            what
            > is going on. If this is the explanation, then a cleverly-written
            > asynchronous serial protocol shouldn't see any bandwidth reduction
            at
            > all between RS232 and bluetooth, and should be able to sustain
            > 115,200 bps bidirectional transfer.
            >
            > Any thoughts about this?
            >
            > btw, I am rewriting the pyrorobotics driver for IntelliBrain.
            > Pyrorobotics is a python robotics workbench. The updated driver
            I'm
            > working on will be high-performance, asynchronous, and extensible
            > with optimized use of memory. I'm happy to share it if anyone else
            > wants to use it.
            >
            > Best,
            > Paul
            > www.pking.org
            > email@...
            >
            >
            > --- In intellibrain@yahoogroups.com, "RidgeSoft" <rs1@> wrote:
            > >
            > >
            > > Communication via the AirCable will not be as fast as via a real
            > cable.
            > > The input and the output of the AirCable are RS232 at 115200. The
            > > AirCable can't increase the input and output speed since these
            aare
            > > fixed, it can only slow communication down, or at best match the
            > speed
            > > with a real cable. The main reasons for this are 1) latency
            added
            > by
            > > converting protocol fromRS232 to Bluetooth and back to Rs232 and
            2)
            > > interference. If there are other 2.4 GHz devices in the area
            such
            > as
            > > 802.11b/g networks, cordless phones and other Bluetooth devices,
            > they
            > > will interfere with each other and have to share the airwaves.
            > Check
            > > for other 2.4 GHz devices in the area and turn them off if
            > possible, or
            > > try testing at a different location, far away from such devices.
            > >
            > > If you are writing a communication protocol over your own to use
            the
            > > AirCable, it will generally work better if you send data in larger
            > > messages than smaller messages and write entire messages to the
            > port in
            > > one operation rather than writing one byte at time.
            > >
            > > Regards,
            > >
            > > RidgeSoft Support
            > >
            > >
            > > --- In intellibrain@yahoogroups.com, "navaho4x4" <dsuarez1@>
            wrote:
            > > >
            > > > Air cable communication is very slow. Bluetooth is configured
            as
            > COM5
            > > > at 115200 baud on PC and so is the RoboJDE GUI. 115200 speed on
            > rs232
            > > > cable is much faster than 115200 on Air cable. Intellibrain
            > itself is
            > > > configured at 115200.
            > > >
            > > > Blue tooth is suppose to have a range of 30feet but I was
            testing
            > at
            > > > range of only 3 feet and still very slow.
            > > >
            > > >
            > > > I plan to use Intellibrain bot with heavy communication to PC
            in
            > order
            > > > offload the processing and memory requirements.
            > > > Will Air cable become a communications bottle neck ?
            > > > How can improve on the speed ?
            > > >
            > >
            >
          • Paul King
            Thanks for the explanation. It s reasonable that RobotoJDE would not have been optimized for high-latency channels, since those are not usually used during
            Message 5 of 6 , Oct 1, 2008
            • 0 Attachment
              Thanks for the explanation.  It's reasonable that RobotoJDE would not have been optimized for high-latency channels, since those are not usually used during development.
               
              > In implementing your own protocol, be aware that there is only a 64
              > byte buffer in the serial port receiver on the
              robotics controller.
              > 64 bytes gives about 5 milliseconds of buffering
              at 115.2K.
               
              Good to know.  This will be a good reason to put all serial communication into its own thread that doesn't block on robot activities.  For example it looks like the Parallax Ping sensor can take up to 20 ms to read due to sound transmission latency. And I'm guessing the system beep blocks for 200+ ms.
               
              > You might want to take a look at the Mailbox class in the MS Robotics
              > Studio integration example. See
              >
              href="http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm">http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm.
              > This class provides an example of a much more advanced protocol
              > that supports reliable delivery and windowing. The
              class is
              > symmetric, so the same class can be used on the host computer
              as on
              > the robotics controller.
              I did see the Mailbox class for reliable message delivery.  It looks like a nice implementation. Unfortunately its symmetric nature won't help me, since the host language for pyrobotics is python and not Java.
               
              I'm also curious about the premise of the Mailbox class that the serial port is an unreliable channel. Is this really true? I would assume the implementers of the Serial Port Profile (SPP) over Bluetooth would have implemented a reliable channel protocol to compensate for the inherent unreliability of radio transmission.
               
              In looking into it, Bluetooth SPP appears to be implemented on top of L2CAP, which supports reliable (lossless) communications.  So I wonder if a retransmission and packet sequencing layer is really needed since the SPP used in bluetooth serial cables seems to already provide this.
               
              Thoughts?
               
              Paul
               
            • RidgeSoft
              Paul, You bring up a good point regarding reliability provided by the Bluetooth link layer protocol. There are two benefits of the reliability of provided by
              Message 6 of 6 , Oct 2, 2008
              • 0 Attachment
                Paul,

                You bring up a good point regarding reliability provided by the
                Bluetooth link layer protocol.

                There are two benefits of the reliability of provided by the Mailbox
                class: 1) it provides end-to-end reliability between a program
                running on one machine and a program running on another machine and
                2) it works over any IO stream, regardless of the underlying
                transmission mechanisms.

                End-to-end reliability can recover from lost messages regardless of
                where they occur, which might not be over the air. For example, if
                the program running on the robot occasionally didn't service the
                receiver fast enough and the 64 byte buffer was overrun, the Mailbox
                class would detect the failure and attempt to recover.

                The second point allows flexibility to substitute different
                transmission alternate (unreliable) transmission mechanisms without a
                major rewrite of the higher layer program. For example, you might
                substitute an unreliable infrared transmission mechanism for the
                Bluetooth link.

                Granted, these issues may not be worth worrying about for many
                projects.

                Regards,

                RidgeSoft Support


                --- In intellibrain@yahoogroups.com, "Paul King" <email@...> wrote:
                >
                > Thanks for the explanation. It's reasonable that RobotoJDE would
                not have been optimized for high-latency channels, since those are
                not usually used during development.
                >
                > > In implementing your own protocol, be aware that there is only a
                64
                > > byte buffer in the serial port receiver on the robotics
                controller.
                > > 64 bytes gives about 5 milliseconds of buffering at 115.2K.
                >
                > Good to know. This will be a good reason to put all serial
                communication into its own thread that doesn't block on robot
                activities. For example it looks like the Parallax Ping sensor can
                take up to 20 ms to read due to sound transmission latency. And I'm
                guessing the system beep blocks for 200+ ms.
                >
                > > You might want to take a look at the Mailbox class in the MS
                Robotics
                > > Studio integration example. See
                > >
                http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm
                .
                > > This class provides an example of a much more advanced protocol
                > > that supports reliable delivery and windowing. The class is
                > > symmetric, so the same class can be used on the host computer as
                on
                > > the robotics controller.
                >
                > I did see the Mailbox class for reliable message delivery. It
                looks like a nice implementation. Unfortunately its symmetric nature
                won't help me, since the host language for pyrobotics is python and
                not Java.
                >
                > I'm also curious about the premise of the Mailbox class that the
                serial port is an unreliable channel. Is this really true? I would
                assume the implementers of the Serial Port Profile (SPP) over
                Bluetooth would have implemented a reliable channel protocol to
                compensate for the inherent unreliability of radio transmission.
                >
                > In looking into it, Bluetooth SPP appears to be implemented on top
                of L2CAP, which supports reliable (lossless) communications. So I
                wonder if a retransmission and packet sequencing layer is really
                needed since the SPP used in bluetooth serial cables seems to already
                provide this.
                >
                > Thoughts?
                >
                > Paul
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.