Reliability in programming DCC decoders

With digital systems, and even more so with accessory decoders, it is essential that everything works perfectly. If an accessory does not switch, or a decoder does not work as intended, it can create serious repercussions for the ‘service’ in the train layout.

One of the key elements for this is a safe configuration of the decoder from a programming point of view.

For Helvest decoders, we have done our utmost to minimise this step, however, it is unavoidable to assign at least the address, connecting to the digital control unit and using the DCC protocol. In some cases, other parameters must also be assigned.

Example of connection of a decoder with DCC100-E module to the control unit for programming. Layout modules must not be installed.

The design principles of Helvest decoders.

Every manufacturer, when developing a product, faces very specific choices. We have based this on certain principles, which we believe are fundamental for you (and those have so far chosen our products have been satisfied with them):

Goal 1. they must be as easy to use as possible. This means reducing the amount of manuals to read and settings to perform.

Goal 2. Simplification must not involve compromise, i.e. simplicity must not be at the expense of reliability.

Goal 3. the user must always have the situation under control: i.e. the ability to know what he has programmed, on which board, and how to change it if necessary.

Goal 4. they must be reliable: certainty of operation over a long period of time and problem-free adaptation with any device that follows the same standard.

The ‘aches and pains’ of the DCC protocol

The most widely used digital system, DCC, has many merits. The main one is certainly that it is an open protocol (i.e. all manufacturers can use it), and this has undoubtedly favoured its spread.

The main flaw is its age: it was born in the 1980s, which for electronics corresponds to prehistory. At that time, networks were not very widespread, slower structures, and above all, it was unthinkable that they would have the possibilities of today in terms of network recognition and transmission: this is why programming with today’s eyes often appears cumbersome.

Some manufacturers have decided to modify ‘their’ version of DCC a little, to add functionality that was not originally planned, but this nullifies the advantage of having the standard, i.e. that all devices, from all manufacturers, can work together without problems.

Example of connection of a decoder with DCC100 module to the control unit for programming. Layout modules must not be installed.

Why you get programming security with Helvest.

Sometimes some users write to us, because they would prefer to have the possibility of programming Helvest decoders without having to connect them directly one by one to a control unit. In fact, other manufacturers have implemented programming procedures in which the decoders are programmed by ‘calling’ it with the control unit and pressing a button.

This, which certainly appears convenient, hides a major problem: the procedure as proposed by some other manufacturers is NOT provided for in the DCC standards. This method is therefore developed individually by each manufacturer without any uniformity, and gives no guarantee that it will work if products of different brands are combined. The decoder may not be programmed or even be programmed with a different address, due to technical factors relating to how the control units work, which it would take too long to explain here.

The other security aspect is the programming confirmation: Helvest devices are among the few accessory decoders that give confirmation to the control unit that the programming has been properly taken over. You thus obtain the security that the decoder is programmed as you want it to be.

If you have one of the rare control units that support POM mode, you can programme the decoder directly on the layout.

POM programming

DCC actually provides a way of programming over the network, without having to connect each individual decoder: this is called POM (Program On Main). Our decoders support this, of course: as explained, we support everything that is standard. The problem is that almost no control units programme in POM, because many manufacturers have preferred to implement a ‘do-it-yourself’ method that does not correspond to the standard.

In summary:

Goal 1. they must be as easy to use as possible. This means reducing the amount of manuals to read and settings to perform.

This is achieved through dedicated “Layout” modules, which are recognised automatically and reduce programming and your work to a minimum.

Goal 2. Simplification must not involve compromise, i.e. simplicity must not be at the expense of reliability.

In this sense, we comply and guarantee that all our products meet the DCC standard: we have not invented modes that could only work with some control units and not with others, deluding you with a simplification that would actually become a problem (as would be the case with button programming). What we can, we have simplified, but we do not introduce improvements that do not guarantee security.

Goal 3. the user must always have the situation under control: i.e. the ability to know what he has programmed, on which board, and how to change it if necessary.

You achieve this by always only connecting the card to be programmed to the control unit: it is a bit more time-consuming, but it gives you the guarantee of not making mistakes. Moreover, the control unit always gets confirmation that the programming went well.

Goal 4. they must be reliable: certainty of operation over a long period of time and problem-free adaptation with any device that follows the same standard.

If you change a control unit, if you participate in an event with a modular layout, in any context, and if the control unit meets the standard (!) you can be sure that you will have no compatibility problems.

MVnet will be a much more modern and advanced system, overcoming many programming limitations

Evolution

Of course, modern technology offers far greater possibilities, which is why we are developing MVnet. But our choice is to offer you a product other than DCC. Thus, those who prefer to use the previous system can still do so, and those who rely on the new one will appreciate the advantages with awareness.

Comments are closed.