German
English
Support for Vendors
User Configuration
Code examples
Analysing tools
Support for BiDiB
What's DCC-A?
With DCC-A it is possible to automatically detect decoders and their characteristics on a model layout.
This is done using the procedure defined in RCN-218. BiDiB supports this procedure
with corresponding components and messages. DCC-A is based on DCC and Railcom and is particularly useful when
and is particularly useful if Railcom and corresponding detectors are available everywhere on the model layout.
DCC-A defines the following core functions:
- Automatic registration of decoders
- Assigning a locomotive address
- Detecting the scope of functions and function assignment
- Assignment and recognition of manufacturer, version, user-defined names
Registration with DCC-A
The registration itself consists of the following steps:
- Exchange of registration messages
- The track output opens registration areas (and transmits its identifier), decoders attempt to make themselves
known in these registration areas.
If the transmission of the decoder recognition is successful, the most important parameters (including the desired address) are queried by the track output. - Assignment of a driving address
- Once the decoder's characteristics have been detected, the track output can assign an address. The decoder responds to the address assignment with a summary of its change status. This allows the control program to recognize whether the decoder is already 'known' or whether important decoder parameters for operation have been modified elsewhere (e.g. max. speed changed).
- Fast acquisition of the most important decoder parameters
- For this purpose, there are namespaces in the decoders, the contents of which are e.g. user names, driving characteristics, function assignments etc.. These namespaces can be read 'en bloc' with fast track commands.
Principle of Registration with DCC-A
- Basis
- The prerequisite for automatic registration within a shared bus system (track + locomotives can be considered as being one) is the ability to distinguish between individual participants. In DCC-A, this is achieved by a unique identification number in the decoder, consisting of a 12-bit manufacturer ID and a 32-bit product/serial number.
- Separation
- In order to address individual participants, a separation method must be available. There are various methods available
(e.g., a binary search tree). DCC-A uses a statistical method with dynamic backoff. Decoders attempt to make themselves known after
a login request - if this process is successful, the decoder is 'registered' (i.e., it receives an
address assignment (ASSIGN), and from then on, this decoder ignores login requests.
If the login fails, the decoder waits for a random number of login requests and then tries again.
For small numbers (<50) of components to be registered, dynamic backoff terminates very quickly. Furthermore, for already known decoders, the address assignment is usually performed before the login request.
This specification is based on RCN-218, Stand 09-2024
Glossary
| Name | Meaning | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DEC_MUN[0…3] | Manufacturer-specific unique identification of the decoder, 32 bits | ||||||||||||||||||
| DEC_MID[0…1] | Manufacturer ID. This comprises 12 bits, the top nibble of DEC_MID[1] is coded with 0. | ||||||||||||||||||
| ZID[0…1] | Central identifier. For timing reasons (short message), this is only sent with 16 bits on the track and should be obtained using a hash algorithm from the manufacturer ID and serial number of the control center/software project. In addition to the ZID, a session number is transmitted on the track. The session number is incremented by 1 each time the user logs off and each time an address that has already been assigned once is assigned. An increment of at least 2 on the session number forces a new registration of all decoders. | ||||||||||||||||||
| Namespace | The information of the decoder is grouped in logical units, the so-called namespaces. These namespaces are addressed via a reference number
(0…255). The content results from RCN218.
|
Features for DCC-A
Brief overview of the features relevant for DCC-A. Details can be found in the corresponding sections on track output or occupancy detection.
| Number | Name | Meaning |
|---|---|---|
| 111 | FEATURE_GEN_EXT_AVAILABLE, Bit 2 | Displays whether DCC-A is possible with the track output. |
| 114 | FEATURE_GEN_EXT_ENABLED, Bit 2 | Display and setting option as to whether DCC-A is used. |
| 29 | FEATURE_BM_EXT_AVAILABLE, Bit 2 | The occupancy detector can evaluate and forward DCC-A messages. |
Control of track output unit
First check whether the track output unit has DCC-A available (FEATURE_GEN_EXT_AVAILABLE) and whether it is switched on (FEATURE_GEN_EXT_ENABLED). If it is not yet switched on, the track signal generation must be switched off, bit 2 in FEATURE_GEN_EXT_ENABLED must be set and the track output can be reactivated after 3s. Locomotive decoders recognize active DCC-A by a 20us longer start bit, which is present from the start.
The central identifier must be set before the login request is sent (before enabling the generator unit) for the first time: This is done with MSG_CS_DCCA, opcode BIDIB_DCCA_SET_TID.
- Initial decoder capture:
At startup (and after the booster OFF) it makes sense to transmit the system ID to the decoders (e.g. by sending the login request DCCA_LOGON_ENABLE(Now) once).
You can then repeat an address assignment for all decoders active in the control software using a LOGON_ASSIGN and thus record any changed locomotive statuses via the corresponding Railcom message. Decoders that have received a LOGON_ASSIGN are no longer part of the registration process.
It may be useful to repeat LOGON_ASSIGN: this helps if, for example, the railcom detector is not permanently available and a decoder confirmation is not forwarded.
Now you can send further logon requests (again with DCCA_LOGON_ENABLE(Now)) and observe the reaction of the system:- Further registrations are coming in and there are no collisions: the registrations that are still open are to be processed accordingly.
- Further registrations are coming in, including collisions: the registrations that are still open must be processed accordingly. In order to resolve the collisions, the decoders must now be given the opportunity to separate by means of backoff. Instead of sending DCCA_LOGON_ENABLE(Now), a sequence of normal LOGON messages is sent to the track.
- If there are no mo collisions reported, the registration process should return to the use of DCCA_LOGON_ENABLE(Now). This reactivates decoders with a currently large backoff value.
- There are no further registrations when sending DCCA_LOGON_ENABLE(Now): apparently all decoders are registered and operation can start.
- Handling of a single decoder:
A decoder transmits its unique identifier during registration. If the identifier is already known, the previous address can (and should) be used.
There are two modes of address assignment:- Permanent assignment: The normal DCC address (defined by CV29/CV1/CV17+18) is set combined with the address assignment.
- Temporary assignment: This address is valid (simplified) as long as the ZID and session number remain unchanged or the decoder was able to validly track a change. If the locomotive returns to a non-DCC-A layout, its 'old' address applies again.
When assigning addresses, the decoder responds with change flags, which indicate whether and how parameters in the decoder have changed since the last login (to this central ID). Thus for example, you can see on a layout whether the speed steps used for calibration are still the same. Once you have recorded the parameter change, you can reset the change flags with BIDIB_DCCA_SELECT_SET_DEC_STATE.
With a new identifier, this identifier can be used to request more precise data from the decoder. This is done by 'single activation' of the target decoder and the following transport commands, which with very short DCC messages (GET_DATA_START and GET_DATA_CONT) create many Railcom transmission options for the selected decoder.
The data in the decoder is divided into namespaces; together with the activation, you also select the namespace:
The 'ShortInfo' data field, which contains the most important parameters, plays a special role. This field is returned directly with the select, GET_DATA commands are not required for this.# Content 0 Capabilities: Overview of the DCC capabilities available on the decoder 1 Namespaces: List of the namespaces available on the decoder 2 ShortGUI: Brief overview of the decoder with (short) vehicle name 3 CV: Namespace for fast reading of CVs 4 FunctionInfo: List of functions and icons to be assigned 5 LongName: (user-defined) name of the vehicle and a brief description 6 ProductInfo: Manufacturer information on the decoder (name, version) 7 VehicleInfo: Information about the vehicle.
The data spaces have a variable size of up to 256 bytes, which is always transmitted in partial packets of max. 31 usable bytes. This means that 6 transport commands should be triggered after a SELECT. You can then view this first sub-package and, depending on the content, trigger further transport commands or cancel the selection.
If the decoder makes full use of the data space, including the packaging bytes a total of 46 GET_DATA messages are required. - Example of a Namespace Transfer
The following example shows the transfer of a namespace. The decoder also changes the message section, resulting in data overlap.
In the example, the lowercase sequence 'abcdefghi...' is assumed to be the namespace content. The content has a total size of 33 bytes, resulting in two subpackets.Characters used in the example Character Meaning a,b,c, ... Payload Data H Header byte according to RCN218, consisting of X, S, C, and size. C CRC8 (calculated using the namespace number as the starting value, calculated using H and all subsequent payload bytes) ~ ACK symbol or zero byte from the decoder #1: GD_INDEX, Getdata index; the step size is 6 bytes per increment. Data Transfer Stelle Zeitachse → Content of Namespace abcdefghijklmnopqrstuvwxyzabcdefg (=33 bytes payload) Decoder, Railcom-Messages Habcde fghijk lmnopq rstuvw xyzabc deCHfg C~~~~~ BiDiB Message A #0:Habcdefghijk BiDiB Message B #1:fghijklmnopqrstuvwxyzabc BiDiB Message C #2:lmnopqrstuvwxyzabcdeCHfgC