Digital train sets work by encoding a signal according to the DCC serial protocol and sending it to either a locomotive (mobile) or static (accessory) decoder. Each locomotive on the track carries a locomotive decoder to receive instructions from the controller. Static decoders sit alongside or hidden underneath the model railway layout and handle instructions relating to the layout itself, such as points, signaling, animation and scene lighting.
It is important not to confuse these hardware decoders with the 17 serial decoders that are built into the PicoScope 6 software. Although the techniques discussed here would not be possible without the PicoScope 6 DCC decoder, use of the word "decoder" in this application note relates to static and locomotive decoders.
The Hornby Elite is a fully featured advanced digital controller, capable of simultaneously running 64 locomotives on a single layout. You can set up each one of these possible locos via either of the two manual control channels. The Elite also supports control of points and other accessories, as well as full programming of locomotive and static decoders, both on the main and programming tracks. It connects to your PC via USB to allow firmware updates and interaction with model railway control software.
I connected a Pico Technology TA189 current probe to Channel B of the scope, when necessary, to measure a signal’s current at the same time as I measured its voltage on another channel.
The PicoScope 6 software has decoder support for a number of protocols, including DCC. When preparing this application note, I initially used the most recent beta version, then the stable version when it became available.
The Elite output connections are as follows:
|TRACK||The main DCC power output that connects to the main track of the model railway layout to drive the trains and digital accessories. Spring clamp terminals marked A and B help match DCC "polarity/phasing" across the layout.|
|PROG||The DCC programming output, which connects to a dedicated programming track. Unlike the TRACK output, this is an NMRA-recommended "low power – current limited" output, so it will not overload a locomotive or static decoder if you make an error in hard wiring, connection to the locomotive etc. This output connection is only live during active programming (pulses of 15 V AC). Like the TRACK output, PROG uses spring clamp terminals, again marked A and B.|
|XPRESSNET||These two sockets are of the 6-wire RJ12 type. You can use them to connect the Hornby DCC Select Walkabout controller, the Hornby DCC Power & Signal Booster, or any other equipment supporting the XpressNet protocol. The Walkabout uses pins 2 to 5, and the Hornby Booster uses pins 1 and 6, but this is a connection of convenience for Hornby and not part of the actual XpressNet protocol.|
|USB port||This port is for a standard USB male A to B cable, connecting the Elite to a computer. You can use this either to install downloadable firmware updates, or to use the Elite with computer-based DCC model railway control software such as Hornby RailMaster.|
|POWER INPUT||The power input socket is fed by a Hornby Digital 15 V 4 A Transformer. This power supply unit (PSU) is only suitable for connection to the 240 V 50 Hz mains voltage found in the UK. PSUs for other regions are available from Hornby.|
|BOOST||This output connection feeds a low-power version of the DCC track signal to drive one or more Hornby Booster units. The BOOST output connection offers greater flexibility than the alternative XpressNet connection described above, as no special cables are required. See the Hornby DCC Booster instruction manual and the connection diagrams below. This output uses spring clamp terminals marked A and B.|
|AUX OUTPUT||This is a 15 V DC auxiliary output that you can use to power layout lighting, signals etc. Note that the Elite controller deducts any current drawn from this output from the total available to the locomotives on the track. This output uses spring clamp terminals marked +15V DC–.|
Having installed the PicoScope 6 software and connected the PicoScope 2408B to the PC, I connected each of the four TA132 voltage probes supplied with the scope to a channel input and compensated them following the instructions in the probes’ user’s guide.
I used an ESU Decoder Tester to simulate a train on a track. This useful device allows you to install a locomotive or static decoder, check that it operates correctly, readdress it if necessary and add any custom settings before you install it in a locomotive or on to the layout. For this application note, I have only used a locomotive decoder.
I then attached breakout wires to the Elite’s various external circuits so that I could connect the TA132 voltage probes. For the TRACK, BOOST and PROG outputs, I used the supplied sprung hook probe tips to attach each probe to the wire coming from the A terminal of the output and clipped the probe grounds to the wire from the associated B terminal. Similarly, I attached breakout wires to RJ pins 1 and 6 to test the XpressNet outputs. This is contrary to the conventional scope connection of probe to signal source and clip to common ground, but as it correctly captured the peak-to-peak target signals and avoided the parallel ground path problem, I used this method throughout. It may be possible to ignore the ground clips and just probe on either output terminal instead.
I also installed a Hornby Sapphire Decoder in the ESU test rig as a working load. This is a more advanced model than the Digital Locomotive Decoder used in the DCC decoding video. A later application note will explore the full potential of the Sapphire decoder and look at the advanced packet DCC signals associated with its special features – see the Sapphire specification and the NMRA S-9.2.1 advanced packet definitions if you wish to read ahead.
For the sake of clarity, the basic equipment setup shown above uses only Channel A, with breakout wires for the probe attached to screw terminals on the ESU tester for the most reliable connection. I set up the other channels similarly, by way of breakout wires from each Elite output.
We are now ready to begin decoding the various DCC serial buses sent from the Elite controller.
As you saw in the DCC decoding video, serial decoding is controlled from the Tools menu in PicoScope 6. Simply click on Tools > Serial Decoding, click Create and select DCC to get started.
For all the tests in this application note, I set threshold to 0 V and hysteresis to 2 V. I also selected binary format for the serial data table.
We shall start by using Channel A to look at the DCC signal from the Elite’s TRACK output terminals, noting that although it is essentially similar to the unfiltered signal seen in the DCC decoding video, we now have extended data packets showing on the graph display for additional commands going to the Sapphire decoder, controlling functions such as switching directional lights.
The screenshot on the right was captured using the beta software. The upper part of the image is the graph display, where we can see Channel A (in blue) picking up the DCC packets and showing a typical DCC voltage of roughly ±15 V, and the TA189 current clamp on Channel B (red) picking up the Sapphire decoder running on load at around 0.2 A.
It is generally advisable to make sure your locomotive decoder can handle the loco’s stall current draw. I checked this by hand-stopping the motor, causing the current spike circled in the screenshot.
The lower part of the screenshot contains the table display, where by way of a link file, we are able to translate binary data to more easily digestible text, showing us the commands coming from the Elite. Further work is required to complete the translation from binary to text across all the columns of the link file.
Some ringing of the DCC signal is apparent in this screenshot as I had not set the lowpass filter correctly and there was only a light load on the track system—just the ESU decoder tester. Ringing is better damped when there are many locos on the track, even when they are at rest.
Note that, by default, static and locomotive decoders are always listening for several addresses: their own short or long addresses as set, a multiple locomotive consist address if allocated, and a broadcast address such as "Emergency – all stop" or programming instructions (a consist allows you to control multiple locomotives as one, such you might use for a heavy train or when negotiating a steep gradient with a banker engine).
In the colored data flow on the graph we can see the decoder responding after preamble to Address 0003, then taking action on given instructions and data, followed by error checking (just off the graph) and listening out again for further instructions. In reality the decoder does not action any commands until the error checking says they are good: if there is an error, the decoder ignores the commands and reverts to listening out.
We shall now use the stable version of the software to look at the output from the Elite’s BOOST terminals on Channel D and compare it with the TRACK output on Channel A. As noted in the list of the Elite’s connections above, the BOOST signal is a low-energy command repeater, sent to a Hornby Booster unit. The Booster receives the Elite DCC signal, amplifies it and passes it into a second electrically isolated power district, for which the Booster itself supplies full track power by way of its own PSU. See the connection diagrams in the XPRESSNET output section below.
I connected the Channel D probe and ground clip to the BOOST A and B terminals using the same method as for the TRACK terminals, but this produced an error message on the Elite screen, indicating mismatched polarity or a short circuit. To correct the error, I reversed the connections to probe and all was well, indicating some sort of problem within the Elite. Investigation showed there was an error in the design of the printed circuit board (PCB). Hornby will have allowed this into production as the external Hornby Booster automatically switches the polarity of the BOOST output without user intervention. I made a note to watch out in case of a possible similar problem when connecting to the XPRESSNET output later.
From the image above, we can see that the Channel A and Channel D waveforms are pretty well identical. There is no discernible lag: if there were, it would affect the transition of control of a locomotive from one power district to the other.
With the serial data table again set to binary, the Address field (left-hand box in the image above) shows a value of 00000011, which relates to decoder Address 0003; in the Instructions field (right-hand box in the image) we can see various speed steps applied. Some other instructions, which equate to whether the decoder is working to a limited V‑Max (restricted top speed) or on 128 speed steps (normal setting) are still displayed in binary, again reflecting the need for further work on the link file.
You can also connect a booster unit using the XpressNet RJ12 cable connection, as shown in Fig 1 in the image on the right. However, this method is not as good as the direct-wired methods as it is not an actual XpressNet data flow, merely convenient use of spare wire feeds on the RJ12 plug, and it can actually distort the XpressNet data used by a Walkabout controller. Fig 4 in the image is considered the most direct, and therefore the best, direct connection method for a booster.
For this test, I attached the breakout wires for the Channel C voltage probe to XpressNet RJ pins 1 (white, RailSync B) and 6 (blue, RailSync A). This time, no error message appeared on the Elite. The screenshot on the right shows that Channel C (green) is essentially a carbon copy of the Channel D (yellow) BOOST output, and they are both synchronized with the Channel A (blue) TRACK output. Note that there is some occasional matched ringing on all channels.
As before, with the table set to binary, the Address field (left-hand box in the screenshot) is awkward to read, but a number of entries in the Instructions field are in plain text where I have entered it in the link file. Here we can see that Functions 1 and 2 have been turned on in Packet 1038 and again in Packet 1045. Still in binary, we can also see the V‑Max and 128 speed step instructions in Packets 1034 and 1035 and again in Packets 1041 and 1042.
We shall now take a brief look at programming, which is too large a subject to cover fully here: we hope to discuss it in more depth in a future application note. There are two basic ways to program with the Elite, service mode and operational mode.
The short answer is decoder configuration variables (CVs). These are particular characteristics of static and locomotive decoders that we can change by writing in a range of values to alter the way that a decoder responds to DCC commands.
There are 1024 available CVs, each with eight bits, giving a range of possible decimal values from 0 to 255. Not all decoders allow all the CVs to be changed, and not all CVs use the full range of values.
Basic decoders have very few CVs that can be altered, but more advanced decoders such as the Sapphire and most sound decoders have many more CVs enabled by the manufacturer, and these can be changed. The user manuals for some sound decoders can be a daunting read!
In operational mode, programming commands are sent via the Elite’s TRACK output. This is possible even when multiple locomotives are on the main track, because programming commands are sent to a specified address, just as we saw with normal locomotive speed and direction instructions.
This is useful, as it allows you to make changes to a specific locomotive while it is running, with immediate effect. You can use operational mode to alter acceleration and/or deceleration rates, set the sound volume, command refueling, initiate flashing lights and more. In the next DCC application note, we will see how this system sends a specific static or locomotive decoder’s address followed by the programming instructions.
Programming is carried out on an isolated programming track under broadcast conditions. A "broadcast" signal is one that is sent without any specific address, so that any static or locomotive decoder in range will receive programming instructions issued in this way.
This mode also makes use of a clever feature called acknowledgement (ACK for short). When interrogated, a static or locomotive decoder will send an ACK if it agrees, usually by applying a short burst of power to the locomotive motor: the controller picks up this surge in current, then proceeds to its next task.
A digital decoder will only enter service mode upon receipt of a valid service mode instruction packet preceded by a reset packet.
Service mode is divided into three sub-modes:
Only eight registers are accessible in this mode, specified as follows:
|Register 1||the address of the static or locomotive decoder|
|Register 2||starting voltage|
|Register 3||acceleration rate|
|Register 4||deceleration rate|
|Register 5||the basic configuration of the static or locomotive decoder (e.g. speed steps, normal/reverse direction, ability to handle DC as well as DCC, long or short address etc.)|
|Register 6||reserved for use in paged mode programming|
|Register 7||the version number of the static or locomotive decoder|
|Register 8||the manufacturer's ID code|
This limited programming mode is not often used these days.
Paged mode expands on register mode up to the full range of 1024 CVs, which Register 6 then "pages" into groups of four CVs (so Page 1 = CVs 1 to 4, Page 2 = CVs 5 to 8, Page 3 = CVs 9 to 12, etc.). Many static and locomotive decoders do not support this method, but the DCC controller is usually smart enough to recognize which decoders can and which can’t.
This is the most commonly used method and is much faster. It allows access to all of the decoder’s CVs and allows you to quickly read or write to the individual eight bits defining the values of each CV from 0 to 255.
Earlier programming modes were very slow, as they required the controller to ask a decoder whether CV(n) was value 1, if not was it value 2, if not was it value 3, and so on, possibly through all 256 values. Direct mode interrogates the eight bits of each CV, and as each bit can only have a value of 0 or 1, the process simply asks whether bit 1 of CV(n) is value 1, then whether bit 2 is value 1, whether bit 3 is value 1 and so on. If a bit’s value is 1, the decoder will send an ACK, and if it is 0 it will not, so this method means the controller can still find the value of the CV and does so in a much shorter time. We will find out whether the serial data table can pick this up in the next application note.
I removed the ESU tester from the Elite’s TRACK terminals and connected it to the PROG terminals instead. This is another low-energy output, which the NMRA recommends using during programming to protect static and locomotive decoders from possible damage in the event of faulty wiring by the user. Using the ESU tester precludes this type of wiring error, but the decoder is still at risk if you go on to install it incorrectly.
I left the Channel A probe connected to the ESU breakout wires, as before. I also connected the Channel B probe to the Elite’s BOOST terminals, as there was an odd Elite characteristic I wanted to capture for later comment.
The sole reason for having a separate programming track on the Elite is that service mode signals are broadcast signals, with no specific address (see the screenshot above), and all static and locomotive decoders in range will be affected by any programming instructions issued in this way.
The screenshot above is a simple example of changing a decoder’s address in the direct sub-mode of service mode from its default of 0003 to a new number, by altering CV1. As usual, the table data is fairly incomprehensible, showing how important creating and populating a link file is to our understanding of the DCC signal.
Note how the programming signal ramps up and down as the Elite pulses the programming data, and how the BOOST data sharing the same output relay matches the pulse action.
With the Select controller, it is all too easy to program any or all locomotives on the main track by mistake, as it uses a dual-purpose DCC output that you can set to either track power or programming, so you have to remember to switch the wires from the main running track to a separate programming track to match the appropriate mode.
The Elite overcomes this problem with separate output terminals for each mode, thus allowing the controller to be permanently connected to the main operations track and to a separate programming track, avoiding both the need to swap connections and the risk of wrongly programming a whole fleet of locomotives by mistake. When the Elite invokes programming, it directs operational mode commands only to the specified static or locomotive decoder address on the main track, whereas it broadcasts service mode commands to anything listening on the programming track.
To improve on the low-energy programming recommendation defined by NMRA S-9.2.3, and in a further effort to safeguard static and locomotive decoders against damage due to poor installation wiring, the Elite also cuts power to the programming track whenever it is not actually sending any programming signals. This safeguard’s action is visible on the Elite as an internal relay clicks and an indicator LED flashes, and we can also see it in the trace above, which we will discuss more fully in the next application note.
We have seen from the traces across the various channels how the more advanced Elite controller can output into several external circuits simultaneously and how the DCC signal remains synchronized for effective control of a locomotive across isolated power districts.
We have confirmed some outputs are low energy, according to the NMRA’s recommended practices.
We can see how important the link file is, as the key to translating the data packet flow from the Elite as seen by the scope into something we can instantly read in a table or export to a file for in-depth analysis later.
We also found a problem with the polarity of the Elite’s BOOST output, and traced it back to a known error on the printed circuit board. In a customer’s hands this cross polarity is not a problem as the external Hornby Booster automatically detects and reverses any mismatched polarity found at the Elite’s output terminals.
We have briefly examined the difference in data packets between operational and service modes, and illustrated how, in service mode, the BOOST output is affected by an Elite hardware design feature.
In the next application note, we shall look more closely at programming static and locomotive decoders using the Elite to see if we can determine with the PicoScope software how the DCC signal changes when we are reading an existing CV value or writing a new value to it in both Operational and Service Modes.
One thing to note is that static and locomotive DCC decoders work in very much the same way as the PicoScope 6 software, using edge detection of the signal to better distinguish valid bits from any noise, so this detection point logic may be of importance in our future quest.
We shall also look at how advanced decoders such as the Hornby Sapphire and Twin Track Sound (TTS) decoders handle extended packet DCC signals traffic, and try to decode this on the PicoScope 6 traces.
Hornby Hobbies, Research and Development – particular thanks go to Ken Wards for his continuous support and permission to use extracts from Hornby’s website and manuals.