OpenDCC - FAQ and Change Log

FAQ - frequently asked questions

    There are often the same questions around OpenDCC - I try to answer them here:

  • What are the costs of OpenDCC?
    Courage and nerves ;-)
    Seriously spoken: the PCB is 25,90€ the components are approx. 30-40 Euro.
    Sorry, but I can't offer neither ready boxes nor kits.
    Norbert Martsch is willing to supply partlist and casually kits. You will find a (loadable) order list for reichelt.de.
    PCBs are avaiable (20€), please ask by mail (see impressum).
  • How many locomotives can be operated with OpenDCC?
    The integrated booster is sufficient for 2-3 locomotives. The logic in the software is capable of 64 locomotives running simultaneously. More is really not useful for DCC. However You may call as many locomotives as you like - OpenDCC will administer them dynamically - running are the 64 recently used locomotives. Of course this limit is alterable in the source code. If you want, you can run even 200 locomotives.
  • OpenDCC is quite nice, but I would like to have a throttle!
    There is an extension for Xpressnet® throttles (ie Roco® Multimaus®). This Adapter requires an enhanced CPU: Atmega644P; The suffix P is important, only this type comes with the second USART. Atmega644-20PU is not the correct type, Atmega644P-20PU is required. (see also: AVR DIL40 TQPF44 Adapter)
    In the meantime, there is also an OpenDCC Throttle, which IMHO is not really bad.
  • I would like to upgrade my OpenDCC box, what do I need?
    Upgrading is simple:
    • Replace CPU Atmega32 with Atmega644P (the suffix P is important), the rest of the board remains as is.
    • Plug the xpressnet adapter
  • How can I load the locomotive names into the throttle?
    Roco® Multimaus® features selecting a locomotive by an user defined name. OpenDCC supports this with a data base for locomotives.
  • Is there a support for Märklin®?
    No. Does the so called marketleader need support? Mixing MM and DCC would impact the outstanding performance of OpenDCC.
    (You will find an untested implementation of MM1 and MM2 protocol in dccout.c, this is not supported by organizer.c)
  • Does OpenDCC support BiDi (railcom®)?
    Yes. There are some Configuration variables:
    Setting CV25 to 1 creates teh cutout. additionally the commands for BiDi read are available and tested. Reading back the railcom messages is not done in OpenDCC. An external detector system like Tams RC is required.
  • I connected some s88 modules, but the readout is flickering. What is wrong?
    Probably the setup number of connected feedback modules does not correspond the really connected ones. Please adjust this number to your currently used hardware. Another cause could be a too fast timing of OpenDCC on S88 - this is adjustable as well. All vendors of S88-N modules must publish the timing.
  • How can I setup the number of the s88 modules in each line?
    Either during compilation, or by adjusting special options. And there are also special IB instructions. S88 maps as follows:
       S88-1 = X10 / X22, "left", view from front
       S88-2 = X8 / X23, "middle"
       S88-3 = X9 / X24, "right", view from front
  • How can I program locomotives?
    OpenDCC supports normal programming and programming on the main (PoM). For the easier operation one of the following programs can be used: Rocrail offers perfect support for OpenDCC including menues for configuration.
    Unsuitable is DecoderProgrammer of Henning Voosen, this program controls DCC locomotives with Maerklin commands - and therefore can't address more than 14 speed steps. (reduced functionality in the IB mode on the side of DecoderProgrammer)
    Also the support for long address and further CVs is quite rudimentary.
  • How can I switch between programming track and main track?
    You may connect both outputs together (pay attention to polarity - connect same polarities) to use OpenDCC on a single track for both programming and riding. Please use a resistor of 10 ohms between M+ and P+ (pins 2 and 4 of X5) and connect your track at the M+ / M- terminals.
    Note: do not use this when a layout is connected - You will get a lot of identically programmed locos :-)
  • Why is reading CVs with OpenDCC so much faster than with my current command station?
    OpenDCC uses a fairly intelligent algorithm to read CVs and implements the minimal timing of NMRA. In some cases it may be neccesary to extend the timing, see below.
  • I can program and read out the decoder, but the values are wrong and Cvs aren't set. Why?
    Apparently the command station is in the mode for access to internal CVs. This is normally done by pressing the GO button when you power up. In case (normally not fitted) capacitors C37 and C38 are present, it takes a too long timer after power-up until the line GO reaches high level and the firmware wrongly assumes a key press. Please remove C37 and C38!
  • I can't do a readout of locomotive parameters, but programming seems to work, what is going wrong?
    If there is timeout during the readout or if the readout is wrong, then OpenDCC does not recognize the ACK pulse of the locomotive. Check out following items:
    • The locomotive/decoder must be attached at the programming output (connector P)
    • The power supply to the loco must be in perfect condition.
      (Reason: The receipt pulse for a read command is done by a current increase by at least 60mA - the decoder produces this current increase by a 6ms long switching on of the engine. Side effect: the locomotive also moves a little bit and can loose power supply)
    • If the locomotive is equipped with a faulhaber motor, it may happen that the required current increase is not achieved. A smaller value for resistor R22 (change from 13k to 12k) could increase sensitivity. Otherwise a load resistor (while programming) must be inserted to the locomotive.
    • Is the decoder able to handle the selected programming style?
      Particularly with older decoders there are some problems, it can happen that a decoder does not understand 'DCC byte mode' or bit instructions. Be sure that the used PC programs also uses the correct modes, i.e. 'register-mode' for Lenz LE200.
    • Sometimes a slower read timing may help.
      There are two special options (18 and 19) to add some extra cycles to the read and write timing.
    • You done the change of hardware? (see below)
  • How do I connect OpenDCC?
    Go to Wiring of a complete layout for information and notes about connecting OpenDCC, decoders and boosters.
  • Do I really need the optocouplers?
    Depends on your application. OK1 is a general purpose output, currently not used. It may be used in the future. OK2 is used as input for true position feedback of turnouts together with OpenDecoder2.
  • With programs are working together with OpenDCC?
    OpenDCC supports Lenz and Intellibox emulation. This is to a large extent compatible, but however can't (and don't want to) cover all cases. E.g. multi-traction instructions are missing in OpenDCC, since so far no PC progamm uses them.

    Software producers orient themselves at the market and self structural systems do not play a role there. So it is only naturally that they take no consideration for these systems. It can therefore happen that a new version of a control program uses new instructions, which are not implemented in OpenDCC (or not yet implemented). So the following tests apply only to the status quo of the addressed software. Please do not derive a preference for a certain control program out these tests.

    Moreover, some vendors of control programs even reserve the right to block some types of command station (without any reason given). (who can actually sign such a licence with good conscience?). In the other way I reserve the right to block control with a certain control programs, esp. when there are licencing issues or problematic interaction with the vendor.

    So far OpenDCC was tested successfully with the following programs:
  • I would like to use the code or parts of it for my own project, what have I to obey?
    OpenDCC is not freeware, but is subject to a license (gnu). This permits the private use, but when used commercial license conditions are to be considered. You will find source code here or at sourceforge.net. If a password is required, please ask by mail (and supply Your full name and address).
  • I want to build this box, but I don't have a certain component
    • Question to IC7: default: 74AC244N. my supplier doesn't have it, can I use 74HC244 instead?
      Here in principle you can any 74244. The AC version was selected because of it's powerful output stage, but also the HC version is not bad. To have the threshold in the middle of the range, AC or HC should be used, not HCT or ACT.
    • I don't have L6206N (Dual H-Bridge in PDIP24 housing).
      The L6203 does not fit; In case of no other solution you can build up a booster with L6203 an connect directly to the DCC output lines of the processor.
      Obviously the L6206 is hard to get ... if you can't find one - please send a mail.
  • I cannot load the boot loader into Ponyprog.
    First select the correct processor, then load the file. The code for the bootloader starts at hex 7800. In the first moment it looks like nothing happened but if you scroll down to 7800, you will see the loader.
    Sorry to say, but right now (Sept. 2008) ponyprog does not support Atmega644P.
      it is possible, to load the bootloader with the ponyprog serial adapter and AVRDUDE (run also under Linux):
    • Setting the fuses with avrdude:
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U lfuse:w:0xD7:m
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U hfuse:w:0x9C:m
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U efuse:w:0xFC:m
    • Reading back the fuses with avrdude:
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U lfuse:r:-:i
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U hfuse:r:-:i
         avrdude -c ponyser -p m644p -P /dev/ttyS0 -U efuse:r:-:i
    • Now load bootloader (flash):
         avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:bootloader.hex:i
    • Optional: load OpenDCC (flash and eeprom):
         avrdude -c ponyser -p avr911 -P /dev/ttyS0 -U flash:w:OpenDCC_XP.hex:i -U eeprom:w:OpenDCC_XP.eep:i

      • If windows is used, /dev/ttyS0 must be replaced with comX.
      All later updates are done with avrosp.exe over USB (by using update_opendcc.bat).
  • AVRDUDE does not work, any hints?
    AVRDUDE is able to use a ponyprog adapter. The orignial adapter from lancos.com inverts the reset line. If the used adapter doesn't invert reset (like the 'minimal adapter' on OpenDCC) following changes are required in avrdude.conf:
    orginal:programmer
      id = "ponyser";
      desc = "design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts";
      type = serbb;
      reset = ~3;
      sck = 7;
      mosi = 4;
      miso = 8;
    changed:programmer
      id = "ponyser2";
      desc = "design ponyprog serial, reset=txd sck=rts mosi=dtr miso=cts";
      type = serbb;
      reset = 3;
      sck = 7;
      mosi = 4;
      miso = 8;
    Logically, AVRDUDE must now be called with "-c ponyser2" .
  • How can I actively participate in the project?
    Assistance with programming, tests and translating is appreciated. There is also a Yahoo Group to share experience and discuss developments: http://groups.yahoo.com/group/opendcc/
  • S88 doesn't work, why?
    Is the solder jumper SJ2 on bottom of S88 pcb closed?
  • I don't like the s88 bus, I would prefer RS bus or Loconet.
    S88 can easily removed from the software (see #define S88_ENABLED and omit the adapter plate). My own feedback modules are S88, therefore I did not implement other bus protocol - however a draft version for the RS bus is somewhere on my computer. Besides the s88 is not as bad as often stated. With OpenDCC it is quite fast and the transmission problems can be solved.
  • The short-circuit protection switches off too fast, what I can do?
    The wiring and the output filter impose a capacitive load to the output stage. Therefore the short-circuit monitoring is activated in principle every polarity change of DCC.
    Due to this I changed R19 and R20 downto 2k2 and additionally added a weighting filter to the software (status.c).
    You could change the filter characteristics and make it less aggressive: e.g.use main_short_mean + = 2 instead of main_short_mean + = 4;
    SHORT_TURNOFF_TIME is the duration for a short condition to exist befor switching off takes place. currently this is adjusted to 15ms.
    Another cause for trouble are servo decoders: A servo generates load spikes (even when not moving) of up 1.5A. These spikes could trigger the short detection of OpenDCC.
  • When I try to use the boot laoder, I always get a timeout!
    If boot loader was loaded sucessfully and later on no connection can be established, a possible reason is the rights management of windows. Proceed with adminstrator rights.
  • I want to use Lenz emulation, how can I activate it?
    The development of OpenDCC started with Lenz emulation; Since this protocol has limitation in accessing the CV's and the maximum address range, I changed over to IB emulation. All tests of the last time were done with IB emulation.
    Lenz is still contained in the software and can be re-activated by compile switches.
  • The LEDs are flasching fast, what's wrong?
    If Prog, Stop und Go are flashing simultaneously: the software didn't find the correct data in EEPROM. The program will be aborted. Solution: power down, press stop-button, power up, download data file.
  • The command station behaves 'strange' (=turns off track output, restarts ...), what's the cause?
    More than once the power supply was faulty. Obviously, there are power converters out there with spikes and dropouts at the output. These could trigger short curcuit detection or the brownout detection of the atmel.
  • What are the differences between version 1.3, 1.4 and 1.5?
    Nearly no difference. There are no electrical change from 1.3 over 1.4 to 1.5, I just changed the PCB vendor and had to make different milling marks.
  • How to create a logging?
    For persistent problems I need a log file of the traffic between computer and OpenDCC to do the analysis. This is created as follows:
    • Download the need tool (portmon.exe) from Microsoft's webpage.
    • Start portmon before You start your control program.
    • Make the following settings in portmon:
      Select the com port to be logged (could even be a virtual com port on a USB)
      Set a filter (that is the funnel) to exclude messages: add IOCTL_SERIAL_GET_COMMSTATUS (this will reduce log size)
      at options: add Show Time and Show Hex.
    • Now start your control program.
  • What's better: OpenDCC or DiCoStation?
    That is not easy to answer - everybody praises his own box!
    Simply to compare are the features: DiCo does not have an emergency stop tracer, no booster, no programming track connection.
    On the performance: I'm quite shure that my algorithm for the locomotive stack is the optimum of performance which can be achieved with DCC. The latencies are smaller than with SX! And this performance remains also with many locomotives and 128 speed steps! When using P50x emulation, the DiCo causes some CPU load on the host, OpenDCC doesn't. The s88 bus of OpenDCC is very fast and interference-proof.
    The DiCo can generate Märklin Motorola. I don't want to implement this. DiCo uses a pc software, a key cd in the drive is required to run this software.

Change Log and Release Notes

    This is the change history. OpenDCC is a non commercial project (I do this in my spare time). I try to do things as good as possible, but there is always the chance to discover a new bug or a missing feature. Your support for testing is welcome as well as constructive discussion. Thanks to all, who contributed so far to the project.

Change Log and Release Notes (for Xpressnet version, Atmega644P)

  • OpenDCC_XP_V0.23.12
    • 31.10.2017: bugfix: check on dcc[0] could lead to block of low prio queue when two similar long addresses are used.
  • OpenDCC_XP_V0.23.11
    • 04.12.2013 Bugfix with adressing of extended accessory > 63. (detected by R.Blank)
    • 26.08.2015: Bugfix in DCC Optimizer: under certain circomstances a function command of F21-F28 cound go to the wrong loco.
    • 27.03.2015: Bugfix: possible Progshort if Cutout is on. solved with an additional debouncer.
    • 27.03.2015: added dummy loco command (loco 3, speed 0) if no loco is in the command queue.
    • 22.03.2015: added selectabel power up mode
    • 12.03.2012: added BiDiB Support
  • OpenDCC_XP_V0.23.5
    • 10.11.2009: added Extended Accessory Command (for p50xb: XTrntX and TX, for Xpressnet 0x1*)
    • 21.11.2009: Bugfix POM Accessory Command, third byte startet with 0x7 instead 0xE
    • 20.02.2010: added BiDi read command (XPDR) and XLokX (Tams EC Mode), added command for restricted speed (Xlimit)
    • 01.03.2010: minor bugfix (CV addresses got decremented) when doing PoM on the Xpressnet side
    • 03.03.2010: minor bugfix in XevtLok
    • 16.03.2010: minor bugfix in Extended Accessory
    • V0.23.4: 02.04.2010: PoM-Read Command for Xpressnet added
    • V0.23.5: 29.04.2010: BiDi: start gap for cutout slightly increased from 30µs to 38µs
    • End of DMX-support in the command station
  • OpenDCC_XP_V0.22.0
    • New: CV2 codes the feature of hardware and software. CV26 sets fast clock ratio.
    • 23.06.2009: Extension with DCC FAST CLOCK.
    • 15.05.2009: for turnouts with true feedback a broadcast on xpressnet is created (instead of a feedback only to the emitter).
  • OpenDCC_XP_V0.21.0
    • 15.03.2009: External power off will be ingored for some time after system start (CV37) - this gives booster units some time to remove the turn-off request after system start.
    • 11.03.2009: loco data base extended to 10 chars, data base transfers for both multimaus and OpenDCC thorttle, better handling of external hardware emergency stop line.
  • OpenDCC_XP_V0.20beta, 24.02.2009
    • 24.02.2009: Version 0.20.8 (release candidate 3) Bugfix for xpressnet command 0x92 (emergency stop one locomotive)
      Note: change R3 and R4 on Xpressnet-Adapter from 4k7 to 1k5 to avoid spurious start bit detection in mixed voltage environments.
    • 01.12.2008: Version 0.20.7 (release candidate 2) added: command tunnel, added feedback info for Xpressnet, Lenz V3.6
    • 06.09.2008: Version 0.20.5 (release candidate) added programming modes, added railcom support
    • 28.08.2008: Version 0.20.2 added LOCO DATA BASE, tested so far: adding entries, dump content, transfer to multiMaus.
    • 23.08.2008: First release, tested so far: locomotives, turnouts, multiple control units including handover, control transfer pc/handheld
      open: programming interface

Change Log and Release Notes (for normal version, Atmega32)

  • V0.17.0, 22.02.2010
    • Extension with DCC FAST CLOCK; this also meant a change in the interrupt structure, but should have no detremental influence (hopefully;-); see also CV26.
    • New: CV2 (Option in hardware and software).
    • New OpenDCC.yrc
    • 21.11.2009: Bugfix POM Accessory Command, third byte startet with 0x7 instead 0xE
    • 20.02.2010: added BiDi read command (XPDR) and XLokX (Tams EC Mode)
  • V0.16, 20.08.2008
    • Bugfix: return value in IB-Parser for accessory commands errornous showed 'nearly full'
    • Bugfix: default baud was always 19200, couldn't be changed
  • V0.15, 12.08.2008
    • The default setting for speed steps (28 steps) is configurable with a CV.
    • The repeat number of DCC commands (like PoM, speed, function) are configurable with a CV.
    • External emergency stop (configurable with CV36)
    • The time interval for power off in case of short curcuit is configurable with a CV. (default is 15ms for main and 40ms for programming track)
    • serial id (cv 39) added.
    • s88 timing configurable (cv 30); additionally, is turned off when dcc programming is active. The s88 task was broken down to bitlevel, not to block the dcc stack for a too long time if a long timing is selected.
    • Bugfix: If opendcc is heavily loaded with a lot of speed commands for other locos, it may happen that a old direction setting in one of the queues is used. This affects only locos, which got reversed recently and it happens only if the box is bombed with a lot of commands. Now the direction change is handled with high priority and can't be overtaken by normal speed commands.
    • Bugfix: Addressing error in bits for true turnout feedback. (only if was activated by compile-switch). Addtionally there are extra CVs for the size of the feedback array.
    • 17.04.08: bugfix: Baudrates 57600 and 115200 will not work; this is fixed but not yet in the release.
    • 18.07.08: bugfix: hex converter in p50xa doesn't work correct.
    • 10.08.08: Some optimisations and code changes (in preparation of Xpressnet) S88 task is now based on timer.
  • New hardware revision V1.4
      The first batch of PCB is sold and I took the chance to introduce some minor enhancements to OpenDCC. Changes from V1.3 to V1.4:
    • The RJ45 connectors for S88 now have a pinning according to the new standard S88-N.
    • This standard also supports RAILDATA transmission - in V1.4 the DCC output signal is fed by means of a single gate buffer (74AHC1G125) to these S88 lines.
    • To allow for further improvements (read back fo CVs on S88-N), the reset line can be tristated and read back. (R41 - R45)
    • The switch between USB and RS232 can simply be done by clearly marked pin head jumpers (JP5 and JP6).
    • A lot of copper marking and writing was made on the PCB to make fitting of components easier.
    • SJ4 now on component side.
  • V0.14, 20.10.2007
      Please update both Flash and EEPROM when upgrading to V0.14. (this applies also to V0.14beta testers).
    • new: true turnout feedback
    • Programming instructions will work in Lenz emulation - thanks to Rainer for the logfiles!
    • extension by P50Xa programming command stop and go (0x60 and/or 0x61 in the 6050 syntax). These instructions are used among others also by WinDigipet.
    • After programming the state before programming is resumed.
    • The default power-up mode in the Intellibox mode is now P50/P50X-Mixed (this was before P50X-only), now Rocrail is working. This has no effect on the interaction with TC.
    • Better allocation of the source code into modules, in order to be able to integrate future hardware platforms better.
    • There was no return string with the instruction XZzA1. This is now corrected.
    • During program operations on a decoder, the reading of the ACK input is weighted with a filter algorithm - this helps with some decoders. When OpenDCC waits for the ACK pulse, the yellow LED (PROG) is turned off for a short time - you can observe programming activity.
    • The timing for the programming algorithm can be made slower by eeprom configuration:
      - the number of the RESET packages before a read instruction can be increased.
      - the number of the read commands can be increased, thus the decoder has more time for the answer (see special options 18 and 19).
    • Simpler configuration by decoder programming instructions: If the GO tracer is pressed during power on, then decoder programming instructions are rerouted to the internal configuration variables. These parameters of OpenDCC are then read- and writeable by means of a programmer. Of course normal programming of locomotives is not possible in this mode. For Trainprogrammer there is provided a yrc file: OpenDCC.yrc
  • V0.13, 15.03.2007
      All optimizations of the V0.13 apply only to the IB mode!
    • Bug in the Programmer with Intellibox emulation fixed.
      Background: the programming module was implemented 'busy waiting' in the older versions and was adapted (due to the IB parser) to normal queue managment ('multi tasking'). Unfortunately the queue manager overwrote the repeatcounter of the programming instructions with 1. And that was not conform to NMRA ...
    • The ACK pulse is fed through a debounce routine with 500us delay. Please pay attention to hardware changes: C44 - 10nF, R19 - 2k2, R20 - 2k2
    • New feature: programming on the main - PoM Note: PoM is a write-only technique!
    • In case of OpenDCC is in programming mode, all commands (like locomotive commands, accessory and PoM) are redirected to the programming output (as long as there no ongoing programming operation). The commands are not cyclically repeated nor put down to the locomotive memory.
    • Acceleration of the DCC direct mode by a preceding test on bit ability. This ability of the decoder is remembered by OpenDCC for a short time (see #define TIME_REMEMBER_BIT_OP). With this trick the readout of a complete speed curve lasts only 20s, although the timing requirements of the NMRA are obied (contrary to a commercial available commmand station :-).
    • Error codes when programming are now conformal to the IB.
  • V0.12, 05.02.2007
    • EEPROM routines and several special options of the IB implemented.
      Background: Railware queries a lot of IB SO's - these are answered as good as possible.
    • change of the compiler to GCC 4.1.1 and AVR-Studio 4,13 (important).
  • V0.11, 28.01.2007
    • Bugfix in the interaction between IB mode and TC.
      Background: TC initialize with 2 stop bits. If OpenDCC operated with one stop bit, this may cause problems with some USB to serial adapters.
    • DCC Accessory repeat count is configurable in EEPROM.
    • Accessory Commands are inverted when using Lenz emulation.
      Background: IB and Lenz differ in their interpretation of DCC (!)
    • Bugfix if DMX is used
    • change in hardware: in order to avoid a too fast turn off of the output stage with capacitive loads, the recovery time of the output stage must be made smaller: R19 and R20 change from 10k to 2k2.
  • V0.10, 22.01.2007
      OpenDCC is running for the first time together with TC and IB emulation. I could drive a locomotive call functions and switch turnouts. Stop - Go was transmitted in both directions. Even the complicated initialization pattern "BABI" is working (inclusive inquiry of special options (e.g. baud rate)).

Seeking Assistance! PC-Tool for Configuration of OpenDCC

    PC control programs do not store the respective format of a locomotive (like DCC14, DCC28, etc..), they issue a query of the format to the command station.
    How can one specify thus the locomotive format? Since there no local control interface at OpenDCC, a tool is needed to configure these locos in OpenDCC (using the normal commands).
    In addition there are some options to control, like number of feedback modules a.s.o.
    Currently there is support from rocrail and a config file for use with Trainprogrammer.

Planned Extensions

    These are only ideas - no garantee! And it is open source - so your help is appreciated :-)
  • Configuration of OpenDCC over by means of an virtual locomotive decoder - implemented in V0.14
  • True turnout feedback together with OpenDecoder2 - implemented in V0.14.
  • POM - Programming on the main (in ASCII Mode)
  • Handheld controller (connected with an xpressnet adapter)

Märklin is a protected trade mark of Gebr. Märklin & Cie. GmbH, Göppingen , Deutschland.
Intellibox is a protected trade mark of Fa. Uhlenbrock
DiCoStation is a protected trade mark of Littfinski Daten Technik
Xpressnet and railcom are protected trade marks of Lenz