Basics:

 

Speed, data bits, parity, stop bits.

Pinouts

Pins used

Connectors

 

Connectors:

 

Pin headers, DB9, etc.

 

Pinout Adapters:

 

Null modem, gender changers, etc.

 

USB to serial Adapters:

 

1. Some adapters have microcode/firmware that is less forgiving than real serial ports.  e.g. the Palmconnect USB<->serial adapters *require* some of the standard signals that most duplicator hardware doesn't care about (e.g. not just flow control RTS/CTS but also DCD/DTR/DSR) - this isn't a windows driver issue but an issue with the code that runs on the bridge chip.  You can create a jumberbox adapter to wire these pins so that they always present the state that the USB<->serial bridge expects, even if at the far side you simply have two wires connected for TxD and RxD. You might even just open up the casing of the adapters and add your own jumper wires in there to get around this foolishness (note that this might make then inappropriate for use with other projects).

 

2. Removing the USB connection while the port is open/connected will often completely lock out use of that com port during the PC session, requiring a reboot.  This can be worked around by either moving the USB cable to another port (which often opens a different virtual com port) or, if the driver allows for it, choosing a different com port in the driver, disconnecting the cable, waiting 10 seconds and reconnecting the cable again.

 

3.IMPORTANT - Some USB to Serial chipsets, chipset revisions, or particular implementations of them...seem to have an inexplicable propensity to lock-up when connected to some robots but not others, which leads to failures communicating and perhaps even crashes of the ULCLI.  All robots I have come across simply wire two signal lines TxD and RxD (and perhaps a third "signal", GND the ground line...but usually not, instead depending on a common ground on the chassis) so this odd behavior has me somewhat mystified as it appears with some robots but not others when using the same USB to serial bridge cable.  I've noticed that use of the jumper box mentioned in #1 can reduce the incidence of this problem with the bridges that have problems with some robots and not others...leading me to believe it's probably a grounding or noise issue that is causing some unconnected signal lines to read inconsistent values, perhaps dependent on the noise and voltage levels seen over the two/three wires varying from robot to robot.

 

USB to serial is not Bulk USB:

 

The Datatronics-based robots (the 25-disc Minicubis/Baxter and the 100-disc DA-5500/Pronto series) communicate via USB, but they use a low-level approach called "Bulk USB".  They do not a virtual com port and will probably not be covered by this wiki.

 

Custom Connectors/Adapters:

 

Wiring an adapter to fake the RTS/CTS/DCD/DTR/DSR pins to indicate the port is always ready...

Adding taps, ports and switches to your robot's case.

Multi-use testing and tap cables