Software/loconetd/UDP Loconet

Introduction

The Loconet protocol was developed by Digitrax, Inc. to interconnect throttles and other devices to their digital command and control (DCC) command station for use on model railroads. This protocol uses standard low-speed asynchronous serial interfaces such as the PC serial port augmented with a multidrop "wired-or" modulation scheme, an access arbitration protocol and a message set. The protocol is proprietary, but Digitrax did publish a subset under the title "LOCONET Personal Use Edition," which can be found here.

Interfacing to Loconet has been somewhat daunting to the hobbyist. The protocol does not cleanly separate the functions of layers 1-3 of the ISO Reference Model, which makes it difficult to modularize and abstract some of its complexities. Additionally, the access arbitration protocol requires millisecond precision timing, which can be hard to achieve in a multitasking operating system. Early on, John Kabat produced a Loconet driver, Locont1, for the IBM PC that presented a software interrupt interface and a somewhat abstracted set of operations from the message formats; it can be found here. This library is tightly tied to the IBM PC. Locont1 and a few other interfaces within the confines of commercial model railroad control software packages were until recently the only alternatives short of from-scratch development for hobbyists to interface to Loconet. Recently, John Jabour has developed a module that tackles the hardest part of Locnet: access arbitration. His Locobuffer allows any computer with a serial port to deliver raw Loconet packets for buffering and transmission on a connected Loconet. Documentation on Locobuffer can be found here.

The Locobuffer opened up the Loconet, IMHO. Particularly, it allowed me to start thinking about how to interface Loconet to other protocols, particularly TCP/IP. I've always been a fan of transaction-based protocols like HTTP, where a single TCP connection was used to accomplish a single action e.g., retrieve a web page. For control applications, this sort of client-server model has a lot of advantages, not the least being that TCP will queue connect requests, eliminating the need for locks and other mechanisms to arbitrate multiple simultaneous accesses. I wrote such a server a few years ago in anticipation of building a Centralized Traffic Control (CTC) system for my model railroad. With it, I could write clients that displayed the railroad and updated block occupancy, turnout status, etc., in real-time, as well a train simulators that would "travel" over the railroad presented by the server. A lot of fun to program, very educational experience regarding client-server apps, but it really amounted to no more than a curiosity.

Where I work, we use the User Datagram Protocol, or UDP, to forward radar and telemetry data to network subscribers. Paricularly, we use UDP multicast to do this, as multiple receivers can get the data without having to code the server to manage individual connections. This application really hit home with Loconet, for there are a number of Loconet applications (fast clock, for one) that could benefit from a simple way to deliver updates to a large number of clients. So I set out to develop a gateway program that took Loconet packets, stuck them in UDP datagrams, and sent them to a multicast group. Conversely, it would receive UDP datagrams, pull out their contents and forward it on Loconet as a valid packet. This program, written for Linux, (will probably work on other Unixes), can be found here.

Protocol Specifics

Gatewaying Loconet to UDP is quite simple; the full Loconet packet, including checksum, is simply wrapped in a UDP datagram. There are no other payload fields. The specifics for doing this currently lie in the selection of ports and addresses; the current loconetd uses multicast group 225.0.0.2 and port 4501. loconetd can also be set up to do simple UDP broadcast on a single subnet using the same port. UDP clients who want to forward Loconet packets simply wrap valid Loconet packets including checksum in a UDP datagram and send them to the machine running the loconetd gateway, which is listening for them on port 4500. These group and port numbers were picked arbitrarily from the numbers >1024 in order to stay away from well-know services.

loconetd - A Loconet-UDP Gateway

loconetd is my reference implementation of the Loconet/UDP gateway protocol. It can be configured to gateway Loconet to either UDP mulicast, simple UDP broadcast, or both. It is .conf file configurable, and will also log packet receipt for debugging.

The mulicast group is statically identified in the configuration file; however deployment of multicast networks to date has established conventions where sessions are assigned group numbers when they are scheduled, and the group number is valid until the session expires. To work in this concept, loconetd would have to interact with sdr, the standard UDP multicast session scheduling tool; this modification is not currently planned.

Lessons Learned

  1. Loconet packets correspond to UDP packets. This may sound trivial, but ask the TCP developers what they have to go through to mark Loconet packet boundaries in the TCP stream. Using a packet protocol to encapsulate another packet protocol is a clean solution.

    2.  
  2. The unreliability of UDP can be an issue in certain types of traffic. UDP is an unreliable protocol for a number of reasons, foremost being that routers can and do legally drop packets in certain traffic conditions. This is in addition to all the other things that can happen to a packet, especially when transiting WAN network segments. This is not an issue with certain types of traffic; if one speed packet is lost in a stream of them generated by twisting a throttle knob, the next one will take its place. However, you really don't want to lose the emergency stop packet! For my client programs, I ended up writing a reliable_send() function that waited to see the echo of the sent packet and retransmitted if it didn't see it.

    3.  
  3. UDP multicast is probably overkill. Now that I've used loconetd, most applications that I can envision really only need simple UDP broadcast to a single subnet. I'm also finding that the technology is still fairly new in router products, and still maturing. Finally, the reaction I've received from the model railroading community has been, "uh, that's nice..." If anyone is using it, I'd like to know.

    4.  
  4. Loconet has serialization problems when divorced from the hardware. It is possible for two UDP throttles to think they've received authority to use a locomotive because the ACK packet does not distinguish "who won the race." Directly on the Loconet, throttles avoid this race condition because they do not transmit in the middle of another's request-ack transaction. It should be pointed out that clients using Locobuffer have the same problem; the only reliable way to completely arbitrate client access to Loconet is for the clients to be on the physical net itself, tracking CD Backoff. For throttle assignment, this race can be mitigated operationally, e.g. using only one client to assign locomotives, only assigning locomotives in close physical proximity, etc.

Conclusions

A lot of flexibility will be gained by gatewaying Loconet to the Internet. I happen to believe that a UDP solution is the cleanest way to do this, and I proved it to myself in implementing and using loconetd. However, I do not see any Loconet gateway being commercially fielded until the Loconet protocol is modified to eliminate dependence on direct knowledge of the network state to arbitrate transaction integrity.


Version 1, 3 December, 2002

Contact me at: