DCC Misinformation Debunking

 This page is under construction and needs updating as the DCC Wiki has been seriously improved.

Typical misinformation:

• DCC is not AC but DC
• DCC is not bipolar
• DCC track voltage never goes to zero
• my $5 voltmeter reads DCC track voltage just fine.

DCC Wiki

My overall advice is that this is just like the Wikipedia, but worse. You have too many people putting information forth as facts, when they are often opinons.

Worse, while the Wikipedia almost always has lots of references, the DCC Wiki has none.

The intro is good, and a good page to read on basic concepts:https://dccwiki.com/Introduction_to_DCC

Note: previous incarnations of this Wiki were awful, it's been a lot improved.

Twisting track power wires

The DCC Wiki starts off well enough:

"This topic is fiercely debated on internet forums and DCC-related mailing lists, endlessly and without any real conclusions. This article tries to provide concise reasoning for either. "

https://dccwiki.com/Twisting_Power_Bus_Wires

But before getting to the reasoning, the BS starts:

This hell right away, stating:

"There is always a large debate on the twisting of track power bus wires. Keep in mind that DCC power buses are an 'Unbalanced Pair' - one wire (A) is held to ground while the other (B) is energized, then they flip when A carries a signal and B is held to ground. This is happening constantly and at a high rate. "

Complete crap. Spent several days arguing this with a person recently.

Yes, if you are INSIDE a DCC booster circuit board, you can typically measure from the internal ground to one of the 2 output connections, and you will see it go positive and negative, BUT THERE IS NO GROUND OUT ON THE LAYOUT, THE TWO RAILS ARE CONSTANT ALTERNATING IN POLARITY PLUS TO MINUS AND BACK AGAIN THIS IS THE VERY DEFINITION OF AC (ALTERNATING CURRENT).

Complete insanity. Not only is this a balanced pair, but this is WHY twisting wires helps reduce interference from outside sources and why twisted pair has been used from telephones to Ethernet wires for data.

I have only been able to determine that this idiocy has come as a necessary support for some other misinformation.

Look at the many examples of DCC waveforms on an oscilloscope, it's clearly a bipolar square wave.

Other than this BS, the DCC wiki does an OK job of identifying pro's and cons of twisting. They should have stopped there.

Back to twisting the wires:

Inductance

So a benefit given for twisting wires is that it reduces inductance.

(aside, having inductance in a DCC power circuit "rounds off" the sharp corners of the square wave, which is not the desired effect.  Additional inductance would normally reduce high frequency noise, if the right inductive value. In general you want to minimize inductance)

So, it is known that to minimize inductance is to place 2 wires of a balanced pair (we have established this is a balanced pair) closer together. So the basic "common wisdom" is that twisting together will keep the wires closer, and thus minimize inductance.

That is indeed true... but in general, twisted wires will increase inductance since twisting significantly uses more wire, so often the inductance INCREASES.

But, the "experts" then recommend just a few twists per foot, like 2 or 3. So, that is reasonable for HO trains. It probably does little harm at worst case, and MIGHT help installations where the 2 main DCC wires can get far apart.

Noise reduction:

An external magnetic field can induce voltage in a wire. Basic law of physics. How magnetism is generated in a motor. So a wire or other device close enough to your DCC wires can induce an unwanted voltage, and this is generally called "noise".

You see telephone wire, and more recently Ethernet cables made of twisted pairs. Any magnetic field that hits a twisted pair will induce a voltage in the wires, but since each wire is twisted in a different direction (one clockwise one counterclockwise) the voltage in each wire is equal in magnitude but OPPOSITE in polarity, and effectively cancel each other out. This is called common mode rejection.

All is well here, except that the number of twists needed is way more than the "common wisdom" Look at an Ethernet cable, open it and convince yourself.... don't listen to "experts". The people making these cables know what they are doing, since Ethernet works.

Bottom line:

I think the best way to approach this, is keep your wires close to each other and away from other stuff. If you have issues, you can try moderate twists, but I would reposition wires and look elsewhere first. At these frequencies, a cheap oscilloscope can be had for very little money. LOOK at the waveform yourself and you can stop guessing. You can see directly what the issue is from looking at the ACTUAL waveform.

For garden railroads, most people use twin lead landscaping wire, where the 2 wires are nice and close (and consistent) and will do perfectly fine. My wires are separate 10 gauge wire used for wiring 220v circuits in a house, but in conduit. Runs up to 60 feet. No issues!

Back to the DCC Wiki on twisting wires:

Well they should have stopped there, with the pro's and con's.

But it continues with this:

DCC Issues... most make sense, but some seem nuts.

"Excessive track bus impedance can cause a multifunction decoder's PWM pulses to be superimposed onto the DCC signal, distorting the DCC waveform."

I'm going to research this.. seems nuts... how can the PWM get BACK from the H bridge, through the full wave bridge, back into the rails? Seems completely nuts, driving voltage backwards through a full wave bridge into the rails? How can that be?

They rest are fine, but I'm going to find the person who wrote this and ask him where he got his data.

Noise:

I think this is by far the bigger problem over the inductance in your wiring. Noise get in by a magnetic field. This can come from a nearby wire carrying heavy current (making a strong magnetic field) or possibly motors, or something putting high frequency noise IN THE DCC CIRCUIT. There are some possible outliers, like having an RF transmitter nearby and one of your wires is a "tuned length" for that frequency, but this is rare.

QSI Titan advanced function mapping

Note:

Even though I have years of experience in DCC, CVs, and even a degree in computer science, I found that I was copying information from the QSI 5.2.0 manual into this site, correcting it, clarifying it, and modifying it, and then re-publishing tons of information just too much work, and I was still left with a manual with problems.

So I decided to make my own update to the QSI 5.2.0 manual, and please request a copy of my current 5.3.x QSI manual. This manual is evolving, but errors corrected, confusion reduced, and I just cannot keep duplicating the old manual and then copying it into the web site, where it should be a reference document.

I'll add it to the files portion of the QSI-Solutions groups.io forum, and all are welcome to join. https://groups.io/g/QSI-Solutions You can also email me if you are not a "joiner", but the forum is a no-nonsense, non-commercial site.

For now, go by section numbers, since the page numbering will vary until I update the TOC and Index.

Overview:

This page is to try to demystify the customization of the Titan decoder. Most will apply to the other Titans, but they do have fewer lighting ports

The Titan allows very flexible mapping of these 3 main components:

• FUNCTION KEYS
• OUTPUT (lighting) PORTS
• FEATURES (like ditch lights and various sounds)

 Unfortunately, as with any system that has many options or flexibility, this can be complex.

NMRA Function key mapping not supported in the QSI - note well

The NMRA mapping allows mapping QSI "features" to a function key for F0 through F12. This table also allows mapping more than one item to a Function Key. Usually you can map up to 8 different items to that Function Key. This allowed a person to map for example the horn and ditch lights to a function key.

These are CVs 33 through 46 (page 66)

A reasonable idea when you basically had only maybe 6 outputs on the decoder.

When sound came around, manufacturers extended the use of the table to include sounds as well as the physical "function outputs" on the decoder.

Since you can (usually) map up to 8 "things" to a Function Key, that suffices for many situations.

Updated QSI Terminology - Important

In the original QSI manuals, the mappings for Function keys is called OUTPUT MAPPING, and never could this cause more confusion.

There is mapping of FEATURES to FUNCTION KEYS  (I call this FUNCTION KEY MAPPING TO FEATURES)

There is mapping of FEATURES to physical OUTPUT PORTS (I call this OUTPUT PORT MAPPING)

Unfortunately QSI calls FUNCTION KEY MAPPING: OUTPUT MAPPING in the manual. Too misleading!

This conflict has been handled in my updated 5.3.x manuals. No more referring to the original document.

How to customize your decoder, FUNCTION KEY mapping & more

The first thing that most people will want is the AUTOMATIC mappings of FEATURES, i.e. things that happen when the loco changes direction or stops.
Most of the lighting FEATURES (table in section 5.6.1) can be set to activate automatically when the loco is in reverse, forwards, or enters neutral.
These states are defined in section 1.5

In addition to mapping individual FEATURES, there also exists 3 "Automatic Lighting Groups" where multiple lighting FEATURES can be managed as a group.
Automatic Lighting Groups are is buried deep in the manual at section 5.7.28.

So, normal steps are:

1. Determine what other FEATURES are to be used, and map these to operate automatically (either individually or in a group) or not
2. put most, if not all "automatic" stuff in Multiple Automatic Lights #1, and also this is normally tied to the F0 function key also, so an overall "all lights on/off" is controllable.
3. then you would normally assign certain FEATURES to a physical OUTPUT PORT (a.k.a. LED1 through LEDx)
4. Optionally you would map a FEATURE to a FUNCTION KEY, things like cab lights, or perhaps a particular sound.

Note: FEATURES can include both lighting functions and sound functions.

In the end case, it's a very flexible system, but it does have some restrictions over other NMRA-TYPE mappings:

• when you want to mix automatic functions and also control/override with a function key.
• when you want to control some things automatically in a Automatic Lighting Group (the only groupings available) that is not allowed in the group
• There are some other restrictions on what FEATURES can be mapped to FUNCTION KEYS
• There are some other restrictions on what FEATURES are available in all "motion modes", i.e. moving or in neutral.

Can we get started now?

So the first thing is to look at all the FEATURES at your disposal. Again updated list of FEATURES is in section 5.6.1

Notice the directional states available, and the comments. It's quite a list, and my list is much more complete that the published one.

Notes on FEATURES:

• List of FEATURE ID numbers is section 5.6.1
• In the original document, not all FEATURES were in the original table, some more "sprinkled" through other QSI documents, often the user guide packaged with the decoder.
• notice that some automatic FEATURES also have an explicit "override" FEATURE too. Look at the first one: Headlight in automatic mode is FEATURE 70, but there is FEATURE 71 that can override it to allow the user to force it on and off.
• Note that the firebox flicker FEATURE 122 can be used to modulate a smoke unit fan to sync it in time with chuffs (look at the specific page on this site on how to set this up)
• Note FEATURE numbers are NOT the same as the Individual Sound Identifiers (section 5.5.1). The latter are used for setting individual volumes.
  

Notes on Automatic FEATURES:

• some features can also be automatic, i.e. will be controlled by directional state.
• also most of these automatic functions can be additionally explicitly be turned on and off

Notes on initial state control

Notes on FEATURES, specific to Multiple Automatic Lights groups

• Notice that the 3 different Multiple Automatic Lights groups, they each have a feature code (see table 5.6.1)
• Their feature codes are 136, 137, 138, details start in section 5.7.28
• Each group has a restricted list of possible features, i.e. cannot have all lighting functions possible, it's easiest to see which functions are possible in CVManager, or by looking them up directly in section 5.7.28.
• here's the features in Automatic lights #2 (#1 is usually for normal lights, and #3 is often already in use)
  • 96 - rear ohbl
  • 92 - ohbl
  • 88 - rear ditch lights
  • 84 - ditch lights
  • 80 - rear mars
  • 76 - mars
  • 73 - reverse light
  • 70 - headlight
  • 113 - step lights
  • 109 - truck lights
  • 106 - rear marker lights
  • 104 - front marker lights
  • 102 - rear number board lights
  • 100 - front number board lights
  • engine room 2 light
  • engine room light
  • 122 - firebox
  • 118 - rear cab lights
  • 116 - front cab lights

So for my GP60 project, I want a single function key to turn the fan and heater on and off,

therefore I need these 2 features to be in a group (so far so good)

but the 3 groups are only automatic, no way to turn the GROUP on and off with a singly function ke

therefore I need independent functions to at least turn both the fan and heater off...

I could perhaps turn the fan and heater on with an automatic group, as long as the 2 features in that group each have explicit on and off.

I also might be able to do something with initial state, perhaps turn both off for safety? or perhaps turn both on? (probably not a good idea, since turning on automatically without fluid is bad)

idea: what if I use rear ditch lights? might be able to turn the strobe off?

make the fan left rear ditch light, make heater right rear ditch light

bit 0 - 0 - no automatic ditch lights

bit 1 = 1 - explicit on off of ditch lights

bit 2 = 0 - don't dim ditch lights

bit 3 = 0 - don't strobe ditch lights (both on all the time

bit 4 0, no strobe with horn

bit 5 =0, no strobe with bell

bit 7 = 0, don't turn ditch lights off if the headlight goes off or dim

initial star

These are FEATURES that actually can be GROUPS of individual FEATURES.

It seems that groups 1 and 3 are often default, group 1 is to control the normally expected lights, group 3 is unusual in that it has the rear mars light, which I think may have been to turn smoke on and off... we'll see.

Notes on OUTPUT PORTS:

• OUTPUT PORT MAPPING is in section 7.1 (CV 115.PI.SI)
  
• not all CV115 FEATURE to PORT MAPPING was in the original table, I have updated the table in section 7.1 (CV 115.PI.SI)
• Port 12 seems to have a heavy duty transistor on it, so you can directly drive over an amp to run a smoke heating element directly.
• I'll add more limitations on current for the 12 ports (LS Titan)
• Note since, like all decoders, these PORTS are open collector, you can either use the on board 5v supply or the rectified track voltage, or even a separate supply (just make sure you connect it's ground to the decoder ground.
• You can see what physical connections are mapped to which ports on the pictures in the basic pages.

Notes on FUNCTION KEYs:

• FUNCTION KEY MAPPING is in section 5.6 (CV 53.PI.SI)
  
• Once I realized that in the software "output" numbers in the documentation are actually 2 added to the function key number, I was off exploring. (outputs 1 and 2 are FL(f) and FL(r) or as many people are used to, F0 for front and F0 for rear. (FUNCTION KEY mapping is in section 5.6)

Example:

• So, your F1 function is on output/index 3 (1+2=3), and F28 is output/index 30
• Note each "CV53" has 2 settings, one for when it is in FWD or REV, and the other for Neutral (NFF and NFR)
• So the primary index (cv49) is 1 through 30 for FUNCTION KEYS 0 through 28
• The secondary index (CV50) is either 0 or 1, 0 for fwd/rev, and 1 for neutral
• (the data below is from my GP60 project) (remember this is a diesel) and will be updated as I customize it.
• (pi = primary index, CV49, si = secondary index, CV50, per standard QSI notation)

So off to my example of programming form my GP60

The table below shows the FUNCTION KEY mapping to FEATURES in my GP60

Notes on my specific implementation:

• I noticed a lot of function keys are mapped to the short air let-off, instead of FEATURE ID 0, I guess that might help prove you pushed the key? I'd prefer to map them to FEATURE ID 0.
• may change grade crossing to work when stopped, fun to demo.
• if I want to enable fan and heater, maybe I should use multiple automatic lights group 2, need to look at why group 3 exists

Also mention the 2 CVs for Initial state of some misc lights, sections 5.7.26, 5.7.27

Examples for my GP60 project

So the following table shows what FEATURES are mapped to what PORTS

I've made a table for my own use here on the specific mappings for my GP60 project

 so all ports: 1-12 are indeed mapped in my GP60 with a LS Titan

double check table

map fan to port and mult auto lights

1. use rear number board lights for fan
2. map LED port 7 to rear number board lights (115.102.0 = 7)
3. assign rear number board lights to multiple lights #3 (55.138.1 = 2)

map smoke heater to port and mult auto lights

1. use rear cab light for smoke heater
2. map LED port 12 to rear cab light ( 115.118.0 = 12)
3. assign rear cab light to multiple lights #3 (55.138.2 = 2)

set these light features for explicit control

set multiple lights to F12, works in fwd/reverse/neutral

1. add multiple lights 3 to F12, CV53.14.0 = 138 (maps F12 (14-2) to feature 138 (multiple lights 3) for 0 (feature works in fwd and reverse)
2. do again for neutral CV53.14.1 = 138 (the secondary index of 1 is feature works in neutral)

tune fan settings for speed

Fan connections: rear number board lights are on port 7

• , (J3 pin3), connect fan minus here,
• other side to +5 volts

Heater connections:

• rear cab light on port 12, (j1-8 heater)
• I added a regulator so the +18v output goes through the regulator
• use ground

QSI programming fixtures

Programming hardware setup

Below is a simple setup with a motor and speaker and the socket. I'm holding a connector that lets me use the speaker plug on the Revolution (by the "I" in QSI on the programmer dongle) or change to a couple of wires that let me screw in to the Titan terminals. Al this is on a small board, the speaker is in the top of a spray paint can.

A more sophisticated setup below. This one has a socket and also DIP headers to screw into Titans that have had their pins cut off. Notice that I have both speakers there to confirm programming between them.

At the front you can see the jack for power and the usb socket.

Inside, I just removed the programmer from it's housing to make an easier installation into the box, but you could leave it in the housing and just cut a bigger hole in the cigar box.

Installing and using Quantum Upgrade

This page is all about installing the USB driver for the QSI programmer, and getting it working