OpenDCC GBM16, track occupancy sensor, configuration and integration

    This page covers the usage and integration of the GBM16 track sensor. By default, the track sensor can be used without any additional actions to be performed.
    However, in case specific properties need to be changed, some fine tuning is required. Also, assignment of an address to each of the GBM16 units might be required depending on the feedback protocol chosen.

Assignment of addresses to sensor tracks

    GBM16 may use various ways in parallel to transmit feedback messages. Depending on the way of transmission chosen the assignment of addresses varies:
  • S88:
    When using the S88 protocol, the GBM16 address-space is defined by the unit's location within the physical feedback chain, so no configuration of address is required.
  • Xpressnet:
    Each of the track sensor units GBM16T connected to a control unit GBM16C uses its programmed detector ID (DID) as base address. The control unit in turn properly inserts the sensor messages into the GBM16 address space for feedback messages assigned (16 bits for each of the connected track units starting with 0 and skipping open interfaces).
  • Hostinterface:
    Various protocol emulations may be used. For each of them (except BiDiB) the statements made on Xpressnet also hold true: the track occupancy messages are handled according to the DID of the track sensor unit attached to the control unit.
    When using the BiDiB-protocol, all addresses are assigned automatically with no additional configuration required.

Setting of addresses and identification of feedback sensors

    GBM16T consists of a track sensor module and a DCC-accesories decoder, which is not required for sensoring functionality but allows configuration access using availabe configuration variables (CV). As a result, there are two configurable addresses for each GBM16T:
  • DCC-address: The 'turnout'-address of the built-in accessories decoder.
  • Feedback-address: The address used to transmit sensor messages to the command station or the PC. Note: when using the BiDiB protocol the feeaback-address is assigned automatically.
    • Both addresses are set using the 'key-method': The GBM16T is set to program mode and afterwards - using the command station - the desired address is sent out as a turnout-command.
  • Identification mode:
    When shortly pressing the button, GBM enters the identification mode. In this mode, all sensors are set to 'flashing'; standard track sensoring is disabled. The respective sensor bits can easily be identified and verified on the PC / command station.
    Another short key-press will exit the identification mode of the GBM.
  • Program mode:
    When pressing the button for a long time, GBM first enters the identification mode (track sensors LEDs flashing), then proceeds to program mode, which can be identified by the PROG LED flashing rapidly in addition to the track LEDs. Initially this mode is in "DCC-address learning mode" signalled by a flashing DCC LED. Once an accessory address has been received, that LED ceases flashing and is on permanently. Addresses 1-4 are used as the base addresses for the GBM (see also details of OpenDecoder for more information)
    short key-press: GBM remains in program mode but proceeds to "Feedback-address learning mode" signalled by a flashing POWER LED. Once an accessory address has been received, that LED ceases flashing and is on permanently. The addres mod 8 is used as the feedback addresses for the GBM
    short key-press: GBM remains in program mode, but returns to "DCC-address learning mode".
    A long key-press will exit the program mode of the GBM.

Configuration of track sensor unit GBM16T

    GBM16T may be configured using three different ways:
  • DCC: GBM16T may be programmed as standard DCC-accessories decoder: learning the address works as described above (using the key-method), internal variables are accessible in program mode or per PoM.
  • GBM16C: using the USB-interface of the feedback-system it is possible to access distinct GBM16T and to mdoify properties.
  • FTDI-RS232: GBM16T optionally has a debug interface for configuration and debugging. The debug interface is accessible via a 6-pin connector located at the lower end. The pin layout matches FTDI USB-RS232 (3V3 or 5V, both possible). Interface parameters are 115200 Baud, 8N1. An overview on available commands is returned after issuing ?<cr>.

CVs of track sensor unit GBM16T

    The behavior of the track sensor unit can be configured using configuration variables CV (as known from loco decoders). In general, the default values should be fine, only the address of the GBM16T needs to be configured. The sensitivity of the inputs and the overall timing of the track sensors unit may be configured using CVs.
  • CV34: Operation Mode
    This CV defined the mode of operation of the track sensor unit. Default 0.
    ValueMeaning
    0track occupancy sensor, optimized for DCC
  • CV35: Jumper
    This CV contains the positions of the configuration jumpers on the board. (read only).
    BitMeaning
    0Jumper 1, bottom, Bootloader
    1Jumper 2, middle, (reserved)
    2Jumper 3, top, (reserved)
  • CV36: Power supply
    This CV defines whether an external power supply may be used in case of a booster failure.
    ValueMeaning
    0do not use external power supply
    1use external power supply 10mA in case of booster failure
    Note: In order to use external power supply, the following prerequisites must be met:
    • The external power supply must be available and jumper R27 (SJ) must be closed.
    • A separate power supply for GBM16T must be available.
    • Extreme sensitive loco engines (Faulhaber) may be stuttering.
  • CV40: Detector-ID low
    This CV (in combination with CV41) contains the base address of the track unit sensor. It is used to define the address when using bus systems that support addressing. CV contains the real bit address and must contain values that are multiples of 8 (0, 8, 16, etc.)
  • CV41: Detector-ID high
    This CV (in combination with CV40) contains the base address of the track unit sensor.
  • CV42: Activate Delay
    This CV defines how many successive times a surpassing of the threshold must be detected before the sensors is switched to "occupied". This allows for filtering of disturbances.
    default: 5
  • CV43: Hold Time
    This CV defines how long a detected occupancy will be held. This might prevent sensor flickering caused by bad contacting.
    unit: 100ms
    default: 15 (=1,5 sec)
  • CV44: threshold active input signal
    This CV defines the threshold for considering a track as occupied if surpassed by the input signal.
    unit: approx. 0.5mV
    default: 10
    Note on sensitivity: When using a resistor of 22 ohms, a current of 22uA results in a voltage of 0,5mV. The default of 10 therefore reflects a current of 220uA. When using the DCC voltage of 12V, a single car axis with a resistor of 50k triggers the track as being occupied.
    In case of false detection (for instance caused by leak currents due to humidity), the default value should be increased.
  • CV45: threshold inactive input signal
    The track sensor optionally can provide all track outputs with 10mA in case of inactive inputs. This CV defines the threshold for detecting a track as occupied in case on such inactive inputs.
    unit: approx. 0.5mV
    default: 5
  • CV46: Track loop mode
    This CV defines the layout of the outputs of a track loop.
    ValueMeaning
    0Track loop outputs are handled as single outputs by DCC
  • CV47: track loop, activate trigger, low
    CV48: track loop, activate trigger, high
    Those CVs define the track occupancies that activate the track loop
  • CV49: track loop, deactivate trigger, low
    CV50: track loop, deactivate trigger, high
    Those CVs define the track occupancies that activate the track loop

Integration

    Messages from trackproc (GBM16T) are collected by controlproc (GMB16C) and forwarded to the host interface, i.e. Die Meldungen der Trackproc (GBM16T) werden am Controlproc (GBM16C) gesammelt und an die jeweilige
  • USB
  • Xpressnet
  • S88
    • Configuration settings of GBM16C define what information is forwarded using what interface.

Controlproc - USB-Interface

    Controlproc is provided with a USB-interface used for messages and firmware updates that also allows for easy configuration. Communication on this interface uses a virtual COM-Port.

Firmware-Update

    If the boot jumper is plugged during startup if the device, the bootloader is activated and a firmware-update my be performed. The LED is permanently on at the beginning and flashes with each byte transferred. Bootloader uses AVROSP-protocol with 19200 Baud, 8N1. For more information refer to the throttle construction manual.

Configuration interface

    In standard operation mode, the USP port implements a command interface (API) that can be used to submit commands to the device. A simple terminal emulation like hterm can be used for this purpose.

    The API uses a serial protocol with 115200 Baud, 8 Bit, no parity, 1 stopbit (8N1). 8-Bit ASCII is transmitted, the API is not case-sensitive. All commands transmitted are terminated by <cr> or <cr-lf> terminiert, responses use <cr-lf> as termination.
    Unknown commands are answered with 'unknown command' messages.

API Commands

  • Help
    parameter: none
    response: a help-text briefly describing the API commands available
  • Info
    parameter: none
    response: "OpenDCC_BiDiGBM hw 1.0, sw 02, api 01" (example)
    The response is a character string starting with the Hardware Identifier ("OpenDCC_BiDiGBM) and followed by version numbers. The following key words are possibly returned
    hwHardware-Version
    swSoftware-Version
    apiVersion number of the parser that can be used to determine the supported command set.
  • EH
    parameter: none
    response: running HSI88 Emulation
    GBM permanently switches from EDebugmode to HSI88-emulation mode. HSI88-mode can be quit using command 'X'. Note: at the momment, the connection parameters are not modified when switching to HSI88, i.e. this mode still uses 115200 Baud.
  • REBOOT
    parameter: none
    response: none
    Device performs a reboot (required, for instance, after CV modifications)
      • Text missing here!!!
    The following commands are intended to be used for debugging purposes only. Use with care, since no parameter checks are performed. :-)
  • XER ADDR
    read from EEPROM address (e.g. XER 0x34)
  • XEW ADDR DATA
    write to EEPROM address (e.g. XEW 0x34 0x45)

Commands in HSI88-Emulation mode

    OpenDCC GBM is able to emulate the HSI88 of Littfinksi (LDT) at the host interface. There are two modes of operation for HSI88: binary und ascii. In binary mode, addresses and data are transmitted as unsigned int8, whereas ascii mode transmits information as hex consisting of two chars without prefix (e.g. 0F). LDT uses the term Terminalmode for modes of operation.

    A command or a a response is always terminated by <cr> (no <lf>). The following command are available:
  • v <cr>
    resposne: Ver. 0.01 / 14.10.10 / HSI-88 / OpenDCC <cr>
    request version information, apart from the 'core' HSI-88 all parts of the response may be subject to future changes (as is the length of the string as well).
  • t <cr>
    response: t[MODE]<cr>
    switch the mode of operation (Terminalmode). Each time the command is issued the mode of operation is switched, startup default is binary. MODE = '0' equals binary, MODE = '1' equals ascii.
  • s [LINKS][MITTE]RECHTS]<cr>
    response (part 1): s[SIZE]<cr>
    This command sets the size of respective chains (or parts of it) in modules with 16 Bit each. OpenDCC GBM only considers the total amount of modules, which is reported back in SIZE.
    Depending on the mode of operation, both the parameters and the response are binary or ascii.
    The second part fo the response contains the initial message (see below), for each of the modules.
    This command needs to be issued once after startup, only after that initial run, messages from modified/added sensors can be received.
  • m <cr>
    response: Bytesequence as follows:
    m [SIZE] [ [MODUL] [DATA_HIGH] [DATA_LOW] ] <cr>
    SIZETotal number of modules that are reported
    MODULModule number. Each module comprises 16 sensorbits.
    DATA_HIGHHigh 8 sensorbits
    DATA_LOWLow 8 sensorbits
    This command queries all attached sensor mdoules. Depending on the mode of operation the overall response length varies: binary: 3+SIZE*3, ascii: 4+SIZE*6
  • X <cr>
    response: X <cr>
    X terminates HSI88 emulation and returns to configuration-interface. This command is not available in the original HSI88 command set.
  • Initial message
    Bytesequence as follows:
    i [SIZE] [ [MODUL] [DATA_HIGH] [DATA_LOW] ] <cr>
    SIZETotal number of modules that are reported
    MODULModule number. Each module comprises 16 sensorbits.
    DATA_HIGHHigh 8 sensorbits
    DATA_LOWLow 8 sensorbits
    Initial messages are sent spontaneously and only report changed sensor modules. Depending on the mode of operation the overall response length varies: binary: 3+SIZE*3, ascii: 4+SIZE*6

Commands in RC-Talk-Emulation

    !!! text missing here !!!