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

Re: Air cable slow compared to rs232 cable

Expand Messages
  • 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 1 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 2 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 3 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 4 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.