XpressNet is a bus protocol, developed by Lenz. The bus is a multi-to-multy type, and is used for all transfer of data between the central unit, controllers and PC software as Traincontroller. Regardless if your using standard DCC turnout decoders, feedback modules connected to the Lenz RS-bus or stnadard handheld devices for train speed and direction, the information goes thru the XpressNet bus. So if you want to listen to whats going on in the railroad, the XpressNet is a great place to tap in for information.
Architecture
Almost all model railroads have a central unit (Lenz LZ100 in my case). In XpressNet, the logic for communication over the bus is contained in all connected devices that can send data over the bus. The central unis os responsible for generating the DCC packages, prioritize what is sent to the track (thru J & K connections) and last, but not least, have a total responsibility of the bus and with that, takes care of detecting new devices and make sure that these are plug-and-play. Worth noticing is that the XpressNet bus only sends updates and changes, and only one time. If you compare to the DCC signal on the tracks, there the message will be repeated a lot, because some of the engines might have missed the message to slow down because it was over a turnout with a bad connection. So if you are going to listen to the XpressNet bus, you can’t miss a single package. Puts higher requirements on your implementation, but nothing that’s impossible to do
XpressNet is in the end a standard RS-485 signal. The communication is done half-duplex, with the following characteristics.
- 1 start bit (0)
- 9 data bits
- 1 stop bit (1)
- no parity
- 62500 baud
Connections
The XpressNet standard is using the following cables/wires, connections and colors.
- L – +12 VDC
- M – Ground
- A – Receive/Transmit not inverting
- B – Receive/Transmit inverting
| Pin # | XpressNet usage |
| Pin 1 | No Connection |
| Pin 2 | Gound “M“ |
| Pin 3 | – RS-486 “B“ |
| Pin 4 | + RS-486 “A“ |
| Pin 5 | +12 volt “L“ |
| Pin 6 | No Connection |
When it comes to cabling, you can according to Lenz XpressNet standard wire the devices in a bus with dropouts, according to the picture. But keep in mind that you should never connect it so it becomes a circle. According to my own experience, the dropouts dont work very good. So I avoid them at all cost. I also uses shielded wires, and only connects the shield to ground on one side of the cable. This is kind of important, because you don’t want current going in the shield as a ground wire.
XpressNet communications
Here I have gathered the most common packages that is sent over the bus. Atlease the most common for me, and the once I listen to. I use these for turnout changes, signals, power of servos and so on.
Turnout changes
| Header Byte | Data Byte 1 | Data Byte 2 | X-OR Byte | |
| Binary: | 0101 0010 | AAAA AAAA | 1000 DBBD | X-OR |
| Hex: | 0x52 | Adress | 0x80 + DBBD | X-OR |
| Decimal: | 82 | Adress | 128 + DBBD | X-OR |
Description
The turnouts sits in groups of 4. So if you take the turnout adress in example TrainController and divide by 4, you get the address group. And that group will come in Data Byte 1. With one of the 4 turnouts in the group that will change position will come in the BB bits
For D & D bits, the following applies
- D1 = 0 means that the port should be activiated
- D1 = 1 means that the port should be deactivated (so there wont be voltage to the turnout at all times)
- D2 = 0 means that port 1 should be activated or deactivated
- D2 = 1 means that port 2 should be activated or deactivated
So for every turnout change, there will come two packages. One for activating the correct port and one for deactivating the port afterwards. The time between these messages can be controlled in example TrainController.
References
For a complete description of the XpressNet standard, including specification for all packages, I can recommend the XpressNet Specification from Lenz