[Doc] Collect "hardware hacker" documentation on Lego I/O and peripherals #2279
Description
I've been trying to understand:
- how many "generations" of Lego electronic peripherals exist, and which ones are compatible
- how the I/O ports on the EV3 work
- how peripheral auto-detection works
but I've been finding the relevant information scattered and somewhat unclear. I hope that this issue can be used to collect information to the detail level that would be useful for a hardware hacker.
Target markets / audiences
As part of Lego's strategy for making Lego a toy for everyone, different Lego products target different subgroups. Although there are no hard-and-fast boundaries, the nature of social networks (in the general, non-Internet, sense) results in at least the following (approximate and overlapping) clusters:
- Set builders (e.g. sets branded Lego Technic or Lego City)
- Train builders
- Robotics
- Classroom education
Hardware generations
A general overview of Lego electronics can be found here
Ancient history
Lego first introduced electronics into their sets since at least the 1960s. These used a number of systems, none of which are compatible with "modern" programmable Lego hubs. In general, these are relatively-electrically-simple DC motors. Several of these systems focused primarily on model trains.
RCX-era
The RCX was the first standalone programmable Lego hub and the first of the Mindstorms product line. It supported motors and sensors using a connector consisting of a 2x2 grid of Lego studs, with metal conductors along the sides of the studs. Although there are 4 studs in total, they are connected in pairs into two wires (in a manner that is tolerant of rotation).
This system did not originate from the RCX but has been used on prior Technic and train sets. It may also be called the "brick connector" or the "9V system" (especially by train/set builders).
These parts seem to use the "legacy" (bright solid colors) design language.
Motors are standard DC motors connected across the two conductors. On the RCX, these ports are connected directly to a motor driver IC.
Sensors can be "unpowered" or "powered". A simplified schematic of the RCX sensor port looks like this:
A slightly more detailed schematic can be found here.
An "unpowered" or "passive" sensor enables the 10k pull-up resistor but does not enable the 9V power source. The pull-up resistor allows for sensors such as a pushbutton or a passive resistive device such as a thermistor. These are connected between the "signal" and "ground" pins and form a voltage divider with the 10k pull-up resistor.
A "powered" or "active" sensor enables the 9V current-limited power source for a long period of time followed by disabling it and measuring the voltage during the remaining small period of time. This is explained in the NXT hardware developer kit:
Active sensors typically contain a large capacitor in order to remain powered during the time when the 9V supply is not present.
TODO: How does the RCX know if an active or passive sensor is connected? Do you have to manually specify?
TODO: Is the 10k pull-up enabled during the measuring time for active sensors?
Power Functions
These devices use a connector that has the size of a 2x2 Lego stud square, but the connector only has two Lego studs. The other half of the connector is replaced with an oval shape with four pins along the inside of the oval. Unlike the RCX-era connector, the shape of this connector restricts it to one possible orientation.
This connector succeeded the RCX-era connector for trains and Technic sets, but this connector was never used on a robotics platform. However, sensors using this connector existed as part of the "WeDo 1.0" system targeted for classroom education.
These parts seem to use the "NXT-era" (orange as the accent color) design language.
Two of the four pins supply battery voltage to devices. The other two pins are used for control signals. A diagram can be found on this page.
The Power Functions motors use these control pins to control the motor direction by connecting the motor across them (leaving the raw battery supply unused). The raw battery supply is used to power devices such as the infrared receiver and WeDo sensors.
TODO: Power Functions servo
TODO: WeDo sensors
An adapter, Lego part 8886, can be used to adapt between Power Functions and the RCX-era brick connector. This cable connects the two brick connector conductors to the two control pins and can only be used for motors.
NXT
These devices use a modified RJ12 with an offset tab. Cables have 6 wires.
These parts seem to use the "NXT-era" (orange as the accent color) design language.
Motor and sensor port circuitry appears to be a gradual evolution of the RCX-era ports.
Motors now contain encoders which send back digital pulses as they rotate. The following is a redrawn version of one motor port in the NXT schematics:
The motor power is supplied out from the NXT on pins 1 and 2. Pins 3 and 4 are used to power the encoders. Pins 5 and 6 receive digital pulses from the encoders. The input circuitry consists of some basic input filtering and protection followed by a Schmitt trigger.
Sensors can be either analog or digital. Most digital sensors, especially third-party ones, use I2C. The NXT color sensor uses a custom protocol. The following is a redrawn version of one sensor port in the NXT schematics:
Pin 1 is the pin normally used for passive analog sensors. It is also capable of supplying power to RCX active sensors, which can be connected using an adapter cable. Unlike the RCX, the 10k pull-up resistor cannot be disabled.
Pin 5 and 6 are normally used for digital signals. When using I2C, pin 5 is SCL and pin 6 is SDA. These pins contain basic input protection and then are connected directly to the main CPU. There are no pull-up resistors on these pins (the 82K resistor shown in the NXT schematics is NM not mounted). Compared to the motor ports, these pins have less filtering (significantly higher RC filter cutoff frequency) and do not have Schmitt trigger inputs.
The NXT HDK mentions that pin 6 is connected to an analog-capable pin on the NXT CPU, but this does not appear to ever have been enabled in the stock Lego firmware.
Port 4 is capable of RS485 communications over pins 5 and 6. This was used by at least one third-party peripheral.
All "5V" power supplies out of the brick to peripherals have a current limit which is not shown in the redrawn schematics.
The RCX<->NXT adapter cable ("x1676" or "54690") connects the RCX wires to pins 1 and 2 of the NXT port. This means that motors are connected directly (without speed feedback) and sensors are connected between the analog input pin and GND. On the NXT, this enables full compatibility.
EV3
These devices use the same modified RJ12 as the NXT.
These parts seem to use the "EV3-era" (red as the accent color) design language.
In general, the circuitry changes and increase in complexity between the NXT and the EV3 are to enable automatically detecting the type of peripheral connected to the brick. Some documentation on how this auto-detection works can be found here.
Motors are mostly interchangeable with the NXT, but EV3 motors have additional means for detecting the size of motor. EV3 motors also contain built-in Schmitt triggers (making them easier to interface with custom hardware). However, the EV3 hub still contains Schmitt triggers in order to support legacy motors.
The EV3 hub side of the motor circuitry is as follows:
Compared to the NXT, pin 5 has gained additional analog input capabilities. This is mostly used for autodetection but could theoretically be used for some form of data feedback.
Pin 6 has gained the ability to be driven to 0V or to 9V. This is supposedly used for autodetecting "new [dumb] actuators" (i.e. without encoders), but it does not appear that such devices were ever produced.
The EV3 has less input protection than the NXT on the motor encoder inputs.
Motor type detection is built around having the output impedance of the encoder signal on pin 5 be different depending on the type of motor. The "medium" motor contains an 8.2K series resistor and the "large" motor contains a 3.3K series resistor. This resistance parallels with the 100k resistors to 5V and 0V as well as the 4.7k resistor on the digital input path which can be pulled to 0V as part of the detection sequence. The resulting voltage is measured by the ADC.
Autodetection of the motor type needs to proceed in several steps because the encoder can be outputting either 5V or 0V depending on the mechanical position of the motor. The detection algorithm needs to handle both states.
Digital sensors now use UART communications, and the pinout is mostly compatible with NXT sensors. However, incompatibilities can arise due to the new use of pin 2 for autodetection.
Other than the addition of a filtering capacitor, the EV3 pin 1 circuitry is the same as the NXT. The EV3 retains the ability to supply power for legacy RCX active sensors. However, due to the changes to pin 2 to enable auto-detection (pin 2 is no longer wired directly to GND), the RCX<->NXT adapter does not work for sensors on the EV3 (although it still works for motors). It can be fixed by rewiring it to use pins 1 and 3 instead, but this would not be compatible with motors. Due to this incompatibility, the EV3 firmware never enabled support for legacy active sensors.
The EV3 pin 6 analog input's low pass filter has a lower cutoff frequency compared to the NXT.
EV3 analog sensors (i.e. the touch sensor) use pin 6 for the input, whereas NXT sensors use pin 1 for the input. The EV3 hardware is capable of reading analog values from either pin, which enables backwards-compatibility.
Pin 2 is now wired to a GPIO pin. This is typically used to detect whether the peripheral shorts pin 2 to pin 3 (indicating a legacy NXT peripheral), but it is theoretically possible to use it as an arbitrary digital signal. Pin 2 is tied to a particular voltage which is still a digital "high" but not 3.3V in order to be able to detect devices that connect pin 1 and pin 2. It is not clear if any such devices existed.
Pins 5 and 6 now contain very weak pull-up/down resistors optimized for the new UART protocol. I2C sensors designed according to the NXT HDK contain resistors which are strong enough (<= 82K) to overcome the pull-down.
When the UART protocol is used, the EV3 uses a separate buffer chip. It is not clear why this is necessary (stronger drive strength?)
Pybricks has documented the UART protocol here
Powered Up
These devices use a custom 6-pin connector. The pinout is a hybrid of the EV3's sensor and motor ports, and there is now no distinction between sensors and motors.
This system was called "Lego Power Functions 2.0" before the "Powered Up" branding was fully adopted.
This system uses a unified connector across all target markets, but not every device works with every hub and software combination when using official software. However, Pybricks aims to support every device on every hub.
In "mainstream" sets such as Technic, these parts seem to use the "EV3-era" (white and grey with red as the accent color) design language. The "robotics" product lines seem to use bright pastels, with teal accents in the "home education" Mindstorms product line and yellow accents in the "classroom education" Lego Education product lines
This system is also used for "WeDo 2.0" sensors.
The Powered Up UART protocol is an extension of the EV3 UART protocol. As part of the convergence into a single connector standard, motor encoders are now digital and speak the UART protocol rather than sending raw quadrature digital pulses.
Passive adapters between EV3 and SPIKE sensors are possible due to them both using a very-similar UART protocol. However, they may require special or custom software on the hubs to enable support. Examples of (likely) passive adapters include:
- mindsensors.com EV3<->SPIKE adapter. TODO: Is this actually a passive sensor? Does it work for motors?
- https://github.com/a10036gt/EV3-SPIKE_Sensor_Adapter-Staff . This adapter does not work with motors.
An active adapter is sold by QikEasy. This uses a microcontroller to fully adapt the protocol from EV3 to SPIKE and also contains circuitry to support motors.