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

Re: Air cable slow compared to rs232 cable

Expand Messages
  • 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 1 of 6 , Jun 21, 2008
      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 2 of 6 , Sep 29 11:44 PM
        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 3 of 6 , Sep 30 7:58 AM
          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 4 of 6 , Oct 1, 2008
            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 5 of 6 , Oct 2, 2008
              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.