Lego protocol

The software provided by Lego uses a protocol that is designed for maximum reliability. The basic idea is that the number of 0-bits and 1-bits should be nearly equal inside any packet and that no long sequence of identical bits may be transmitted. This allows the receiver to adapt very well to the signal so that even weak signals can be interpreted reliably. On the other side, the protocol uses less that 50 percent of the available bandwidth. The following figure shows the layout of a packet that is used to transmit data bytes d1 to dn.

The first 3 bytes form the header. Their pattern gives the receiver enough time to synchronize with the signal, their actual data is not interpreted by the Lego code and must not even match the pattern presented above. Following is the payload, in which every byte is transmitted as-is, followed by its binary complement. The packet ends with a checksum, which splits again into a byte and its complement.

  /x = x xor 0xFF
   c = ( d1 + ... + dn ) and 0xFF

The PC sends data packets to the RCX which contain single instructions of a bytecode program. The Interpreter executes them and sends a reply back to the PC. Many functions that are intended for applications can be used this way directly from the PC. Some commands are only available for remote access (e.g. downloading programs) or may only be used by applications (e.g. manipulating the control flow). In case of errors the PC repeats the command as long as it gets a valid reply. The RCX executes the first command it receives and sends a reply. If it receives the same command again, the previous reply may not have made its way to the PC, so the RCX repeats the reply without executing the command again. Every command is available in two versions that are identical except for one bit just in case the user wants to execute the same command twice. PC and RCX must alternate between the two versions.

The protocol developed by Lego is designed to match the properties of the receiver and includes several levels of error checking (parity, complements and checksum) which guarantees a fairly good reliability. On the other hand it is very slow and intended to remote control a RCX, not to send arbitrary messages. The only user-definable message contains a single payload byte. An independent observer cannot safely interpret the received data stream if it does not know which parts have been sent by a PC or a RCX. The protocol should not be used for complicated communication tasks, but for some languages like NQC it is the only alternative available. A detailed description of all commands and replies is contained in the Lego Mindstorms SDK http://mindstorms.lego.com/eng/community/resources/.