SRCP is a comprehensive TCP/IP Protocol designed to serve all the needs of model railroading enthusiasts.
SRCP is a TCP/IP Protocol designed to cater to all aspects of model railroading. It operates based on ascii text and strictly adheres to a command-response schema. In the world of SRCP, the interface to the model railway system is the server. Every client that connects to the server receives information about the status of any component (including the server) and sends commands to alter the status of any component. This makes SRCP a fully multiuser system. To prevent issues, a client session can lock a component.
SRCP stands for Simple Railroad Command Protocol and is an IP based protocol. It covers all aspects of model railroading, and the srcpd project implements a client-server architecture. SRCP defines an abstract layer above the model railroad system, addressing differences between systems. A client developer doesn't need to know which signalling is in use. Even if a completely new system launches, once an SRCP server implements it, any SRCP client can use it without alteration.
SRCP is composed of command words and devices that these commands act upon. Devices include locomotive decoders (GL == generic loco), impulse decoders (GA == generic accessoire), and feedback sensors. To address decoder programming, so-called "Service mode" devices are defined. Components are organized into busses, which bundle components that are accessible through a shared device (e.g., a central unit). These busses may segment the address space. SRCP never modifies the hardware address. For example, NMRA's short and long addresses can be structured into two independent busses. It's the server developer's job to define the bus structure properly. A client developer should make sure that every component address contains two elements.
Not all components are available on all systems. To get details, the server can supply the client with information on all devices it recognizes. In situations where the target doesn't support the specified feature (e.g., obtain current speed: many railroad systems do not support this operation), the server can emulate some of the functionality.
SRCP includes a time "device" that maintains the current model time for all clients. This time is capable of running at any ratio to real-time (e.g., 6 real-time minutes can equal 1 model hour). SRCP has evolved through time. The initial version, which is currently outdated, is called 0.7.3. The current stable version for over a year is 0.8.2, and we encourage all software to use it. The most recent edition, 0.8.3-wip, contains some enhancements that require correction and may be affected in the future.
Future Versions of SRCP will remain compatible with the current 0.8 specification. A client can request a special SRCP version during the initial handshake. The discussion of SRCP takes place in the German newsgroup de.rec.modelle.bahn.
SRCP stands for Simple Railroad Command Protocol and is an IP based protocol. It covers all aspects of model railroading, and the srcpd project implements a client-server architecture. SRCP defines an abstract layer above the model railroad system, addressing differences between systems. A client developer doesn't need to know which signalling is in use. Even if a completely new system launches, once an SRCP server implements it, any SRCP client can use it without alteration.
SRCP is composed of command words and devices that these commands act upon. Devices include locomotive decoders (GL == generic loco), impulse decoders (GA == generic accessoire), and feedback sensors. To address decoder programming, so-called "Service mode" devices are defined. Components are organized into busses, which bundle components that are accessible through a shared device (e.g., a central unit). These busses may segment the address space. SRCP never modifies the hardware address. For example, NMRA's short and long addresses can be structured into two independent busses. It's the server developer's job to define the bus structure properly. A client developer should make sure that every component address contains two elements.
Not all components are available on all systems. To get details, the server can supply the client with information on all devices it recognizes. In situations where the target doesn't support the specified feature (e.g., obtain current speed: many railroad systems do not support this operation), the server can emulate some of the functionality.
SRCP includes a time "device" that maintains the current model time for all clients. This time is capable of running at any ratio to real-time (e.g., 6 real-time minutes can equal 1 model hour). SRCP has evolved through time. The initial version, which is currently outdated, is called 0.7.3. The current stable version for over a year is 0.8.2, and we encourage all software to use it. The most recent edition, 0.8.3-wip, contains some enhancements that require correction and may be affected in the future.
Future Versions of SRCP will remain compatible with the current 0.8 specification. A client can request a special SRCP version during the initial handshake. The discussion of SRCP takes place in the German newsgroup de.rec.modelle.bahn.
What's New
Version 2.0.12: N/A