OpenDCC Z1 - Command Station for DCC - Feedback

Introduction

    Here is a summary of various aspects (address ranges and mapping, update rates, etc.) regarding the OpenDCC Z1 command station.

Physical Implementation, Timing

    The S88 data and clock lines are generated by 'bit-banging' in the software of the command station. The feedback will be read in periodically in by a task, which is called endless. The minimum set timing is guaranteed by a hardware timer. The maximum timing will scatter, depending on the current processor load, so that the signals CLK, LOAD, RESET contain some jitter. But this is irrelevant.
    Timing is adjustable in steps of 10µs, the default setting is 20µs for high an lowe pulse width. OpenDCC Z1 is thus probably one of the fastest s88 implementation.
    All three connectors are read in simultaneously, whereby the longest s88 chain determines the number of clock pulses. Example: asume 288 connected feedbacks, which are divided into three chains: a complete read cycle will last 5ms.

Upstream Protocol (to PC)

    There are three different protocols available to send data to the PC, these have the following properties:
    Protocol: Intellibox
    (p50xb)
    Lenz
    (xpressnet)
    Littfinski
    HSI88
    max. No. of Bits:1024 1024 496
    divided into: je 8 je 4 je 16
    bit order: invers normal normal
    technology: polling push service push service
    One of these protocols can be selected as the host protocol during compilation, (obviously, with HSI88 there is no DCC out possible) Normally, I running my tests with p50xb.

    A note on the polling method of the IB-protocol:
    OpenDCC tries to grep the states of the detector as soon as possible to ensure a immediate response by the pc. So typically the feedback bits inside the command station are a mirror of the bits of the detector. It could happen, that the detector bit goes back to 0 before the event was picked up by the host pc. In this case, the host will see the 0, not the intermediate 1. The command station does not 'integrate' detector bits. But the notify bit for 'change of feedback bits' will be reported anyway!
    This leads to a contraint: The host software must simply ask more often than the holding time of the detectors or the bus read intervall of the S88 bus.

Address Assignment

    There are four address ranges within the command station for feedback. These areas are sequential, it is allowed that an area has a length of 0 bytes.
    Range 1 2 3 4
    Assigned to: S88-1 S88-2 S88-3 turnout position feedback
    defined by: CV9 CV10 CV11 CV16
    The hardware ranges S88-1, -2 and -3 are each defined by their size (number of feedback bits in units of 8 bits each) and join each other. It is important to ensure that the respective sizes are set correctly, otherwise the feedback bits will be messed up. The beginning of the area for turnout position feedback is defined by CV16, it is therefore possilbe, that there is a gap in the feedback bits. Advantage: When you add another S88 module, the addresses for turnout feedback will not change.

    When using p50xb all four areas are reported by the standard feedback commands, the bits for the turnout feedback are simply put into the normal feedback bit range. The analysis, whether a switch has reached it's end position must then be made by the host program.

Xpressnet and switching/feedback information

    In the case of Xpressnet, limitations arise, since the feedbacks command and switch share the address space. According to Lenz Documentation there are 1024 feedback addresses, which are coded as follows: byte 1 has a range 0..127 and each byte covers 8 feedback bits (1024 = 128 * 8).
    On the other hand, this range is intended for 1024 switches, byte 1 has a range from 0..255, and 4 switches are addressed with on byte ( 256 * 4 = 1024). The address ranges overlap each other, so it will be max. 2048 bits addressed.
    0                            1024                        2048
    |--------  Feedback  ---------|
    |-----------------------   Switches   ---------------------|
    
    Looking at this graph one can see that only the 512 switches can have position feedback signal and this range overlaps with the occupancy detection.

    What are the consequences for OpenDCC?
    OpenDCC can handle external feedback/occupancy devices (like S88) and internal feedback in parallel, thus one must assign the usage of the common address space:
  • If a turnout command is acknowledged with a broadcasted message (standard behavior of xpressnet), these acknowledge messages overlay necessarily the s88 detectors if the turnout address is <512. The result: when operating s88 hardware devices, is is only possible to assign turnout addresses >= 512, which is unpleasant.
  • If however one attempts to exchange roles (ie start the address space for turnouts from address 0 and give the feedback bits an offset), then a differentiation on the basis of byte 1 is required. This will lead to the following restrictions:
    Byte 1:Meaning
    0..63 this range 0..63 is assigned to DCC accessory and is filled decoder feedback information (range 4). This means 256 possible turnout addresses.
    64 .. 127 This range is interpreted as feedback range (i.e. the occupancy detectors start at 513 or unit 65-1). This means 512 possible detector addresses
  • Implementation in OpenDCC
    I've choosen the second choice: External hardware detectors (S88 bus, the ranges 1, 2 and 3 mentioned above) are sent as feedback broadcasts (with bits TT = 10) starting with address 513. Throwing a switch will induce a broadcast of an accessory switch information, but only up to turnout 256. This broadcast is issued when the according coil is turned off and the corresponding feedback has arrived in the command station.
    The range 4 is indexed with the turnout address.

    It is possible to change this mapping for special cases (ie huge number of feedback bits) by means of CV29.

Multi-protocol Operation

    OpenDCC (version OpenDCC_XP) and can operate p50xb and XpressNET™ in parallel. For this purpose, the corresponding change flags for the two interfaces are kept twice. This allows both the push service (used by Xpressnet) and the event polling of p50xb. No occupancy detection or feedback event is lost either protocol environment.