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

301Re: [intellibrain] Re: Air cable slow compared to rs232 cable

Expand Messages
  • Paul King
    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
       
    • Show all 6 messages in this topic