MTC21 / NMRA / NEM decoders

This is an interesting subject, as the concept of "logic level" outputs on decoders is still relatively new to US users.

The impetus for this page is a friend, who is an installer, had questions about interfacing to a SoundTraxx decoder, and he said, "I hooked up lights to the AUX outputs, and they all went on and I could not turn them off. I responded that perhaps (since it was a 21 pin interface, which I know originated in Europe, they could be logic level outputs. What's that was the response, and the journey started.

Overview:

The history of this decoder interface goes way back. I don't feel like researching all the dates, but there was an interface called "Plus-X" with a dual row 21 pin connector, and it was related to an NMRA standard, which still exists, but has proven to be a Cul de Sac.... going nowhere.

Recently SoundTraxx started making decoders that met the NEM standard (European NMRA sort of) and as of about 2024, the standard has changed, and finally the NMRA standard is harmonized with the NEM standard. Unfortunately, many, no make that MOST decoder manufacturers just say "meets NEM standard". BAD!

So to be crystal clear, the NEM 660 standard, also called MTC21, is harmonized with the NMRA 9.3.1.1 standard.

Links:

NMRA 9.1.1.3 MTC21 https://www.nmra.org/sites/default/files/standards/sandrp/DCC/S/s-9.1.1.3_21mtc_decoder_interface_3.pdf

NEM 660: https://www.morop.org/images/NEM_register/NEM_E/nem660_en_2022.pdf

(I have omitted the PLUS-X NEM and NMRA standards, it seems that the newer standards "grew" from these)

New concepts:

For most people, the ability to "change" what a decoder pin does is not new, but note that this is becoming more prevalent, so note that as you review.

The biggest "new" thing is that many "outputs" are now "logic-level" that matches TTL computer logic voltages on digital logic chips.

Outputs:

First a little explanation: Decoder "outputs" are usually really an "input" from the sense of electrical conventions. In the old days (pre-digital logic), ON was the presence of positive voltage, and ground and minus were the same. So if you put a voltmeter on an "output", when you turn it on, you got voltage (as reference to ground).

But, when we started getting in gear with DCC decoders, all of a sudden things were reversed. You used the blue wire which was actually positive, hooked up your lamp, and the other end went to the decoder "output". To turn the lamp on, the decoder actually GROUNDS that input.

Why? A result of the process of making integrated circuits... turns out that it's cheaper and easier to make the open collector NPN transistor than the "positive switching" PNP transistor... actually pre-dates IC's, actually cheaper to make standalone transistors in NPN.

So all of our "outputs" are actually "inputs" that are grounded when active. So most people are used to this, know the blue wire is common, and some even realize it is positive voltage.

Enter logic-level "outputs":

So manufacturers realized early on that sometimes you connected something smarter than just a light bulb to a decoder. Probably the best first example was the SUSI bus, for sound units, when no motor decoders had sound in them... the SUSI bus allowed communication for configuration and data like motor speed or load to be communicated.

"logic level" signals were used, there were variations, but today it means "TTL signal levels", which are the dreaded 1's and 0's of digital communication. a zero is <=0.4 volts, and a one is >= 2.4 volts. So these outputs clearly do not supply "on and off" as a light bulb would see it.

Conversion of logic-level "outputs" to the familiar decoder outputs, a.k.a "amplified" outputs.

So since logic-level outputs are defined, there needed to be a term for "normal", connect to ground outputs, and the term is "amplified" outputs. It's really a misnomer, but since it does not belie the radically different characteristic of the output, but "amplified" it is.

How to convert "logic level" to "amplified"? Simple, you use a transistor as a "power switch". This is actually what is already done in most decoders internally. The logic output is connected to the base of a transistor (that is the transistor's "control pin"), and the emitter and the collector are the 2 parts of the "switch", one goes to ground, the other is your new "output" pin.

In fact there are commercial products to do just this for your decoder with logic levels when you want to run a bulb, or LED or actually anything that needs power.

OK, OK, enough lecture, get to the meat!

The following chart shows a "translation" from the decoder pins to the actual function/description on the decoder:

Nmra pin	Nmra 9.1.1.3 def/NEM 21MTC 660	TCS	Soundtraxx def	Note
1	Sensor-input 1 Alt AUX7	CAM1 (chuff input)		“amplified” if not used as input. Should be used for input as chuff trigger
2	Sensor-input 2 Alt AUX8			“amplified” if not used as input.
3	AUX6	F6	FX8	“logic level”
4	AUX4	F4	FX6	“logic level”
5	Train bus clock alt AUX9			“logic level” for communication
6	Train bus data alt AUX10			“logic level” for communication
7	F0r	F0r	F0r	“amplified” normally rear headlight
8	F0f	F0f	F0f	“amplified” normally front headlight
9	Speaker A	Speaker +	Speaker	Impedance must be documented by mfg
10	Speaker B	Speaker -	Speaker
11				Index pin
12	Vcc (1.8-5.7v)			Reference voltage not mandatory
13	AUX3	F3	FX5	“logic level”
14	AUX2	F2	FX4	“amplified”
15	AUX1	F1	FX3	“amplified”
16	V+	Positive common	Positive common	Rectified track vltg
17	AUX5	F5	FX7	“logic level”
18	Motor 2 / -	Motor -	Motor 2 gry	For loco fwd
19	Motor 1 / +	Motor +	Motor 1 org	+ for loco fwd
20	GND	GND	Gnd	Actual minus
21	Track left	Left Rail	Track left
22	Track right	Right Rail	Track right

Converters / aids for logic-level conversion

Decoder Buddy

MX33 cabs

my firmware version: 01.01.0190

DCC Service Mode Tips

4 different official modes:

address mode - outdated, only updates CV1. For really old stuff, and if this mode is attempted on a newer decoder, it's possible that it does not update CV19 and/or CV29. Think original LGB stuff.

(physical) register mode - old stuff again, and old decoders had registers that corresponded to cvs 1,2,3,4,7,8,29. No long address support

page mode - extension of register mode. Uses register 6 as an index, and using 4 other register values, yielded 1024 cvs effectively... Often this has to be used for old decoders, or really dumb ones like switch machine controllers, or old weird stuff from europe

direct mode - what is mostly used today... the standard states 1024 cvs

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 and custom AML GP60 configuration

Note: updated & clarified manual:

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.

It is available in 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:

NOTE: I use my customized file for my GP60 as an example here

This page is to try to demystify the customization of the QSI Titan large scale 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 (the buttons on your throttle that ultimately execute a DCC function command)
OUTPUT (lighting) PORTS (the physical ports/connections on your decoder)
FEATURES (like ditch lights and various sounds)

Note well: NMRA Function key mapping is not supported in the QSI

The "standard" NMRA mapping allows mapping "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 (section 4 in the manual) - A reasonable idea when you basically had only maybe 6 outputs on the decoder.

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

Since you can (usually) only map up to 8 "things" to a Function Key, many other manufacturers besides QSI abandoned the NMRA standard function key mapping, as it was too restrictive in many modern decoders.

Updated QSI Terminology - Important

Features:

QSI calls the actual things "going on" FEATURES

You perform 2 different mappings, hook a FEATURE to a FUNCTION KEY, and hook a FEATURE to an OUTPUT PORT

Function key mapping:

In the original QSI manuals, the mappings for FUNCTION KEYS is called OUTPUT MAPPING (what a way to cause confusion!) Most people would associate OUTPUTS with the physical outputs. Really confusing.

In my revised manual, I call this FUNCTION KEY MAPPING TO FEATURES

Features:

There is also 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 and confusing again!

Resolution:

This conflict has been handled in my updated 5.3.x manuals. No more referring to the original document, so going forwards from here, you should be using my "corrected" manual.

Also many features are NOT documented in the original QSI manual.

OK, big mouth, how do I set up my decoder?

Do your "automatic" features first

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 single group.
Automatic Lighting Groups are is buried deep in the manual at section 5.7.28.

So, normal steps are:

Determine what other FEATURES are to be used, and map these to operate automatically (either individually or in a group) or not
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.
then you would normally assign certain FEATURES to a physical OUTPUT PORT (a.k.a. LED1 through LEDx)
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? No, sorry! you need the following notes:

FEATURES notes:

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 one in the original manual.

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:

There are also certain items that can have their initial state specified, mostly lighting. These start at section 5.7.8 (CV55.70.x)
I would suggest this be the last part of your customization, after explicit control, and directional control are "done"

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

OUTPUT PORTS notes:

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) as I find them
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.

FUNCTION KEY MAPPING notes:

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 (30-2 is 28)
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
(pi = primary index, CV49, si = secondary index, CV50, per standard QSI notation)

OK, finally we can start!

Note: From here on, this example uses my custom configuration for the AML GP60 installation.

Note the physical/electrical installation is detailed here: AML GP60 electronics

Sound set for this project:

from Quantum Upgrade, or CVManager about decoder:

Mfg ID: 113

Model: 1158 FX-LE EMD 710

Class: Diesel

Soundset: 1000

Version: 9.3.0

Build Date: 6/3/15

Last Modified: (varies, you can change it)

Hardware: 7022 (FX-LS)

Select and & map the features to the physical ports

So the following table shows what FEATURES are mapped to what PORTS (LED1 through LED12)

Review of QSI LED light ports on GP60 example for reference (and double check):

Port 1 - front headlight
Port 2 - rear headlight
Port 3 - front left ditch light
Port 4 - front right ditch light
Port 5 - reserved for front overhead beacon (1 of 4)
Port 6 - front number boards
Port 7 - reserved for front overhead beacon (2 of 4)
Port 8 - front cab light
Port 9 - smoke unit fan (using truck lights feature)
Port 10 - reserved for front overhead beacon (3 of 4)
Port 11 - reserved for front overhead beacon (4 of 4)
Port 12 - reserved for smoke unit heater (special high current port on QSI) (using step lights)

Note all 12 LED ports are mapped

Again, this is an actual screenshot of CVManager for my AML GP60 project

You see the indexed CV 115, and it's indexes as used.

The targets show the port number and (somewhat redundantly) the "L" number that matches the "LEDx" on the titan drawings, LED1 through LED12

Note this mapping matches the adapter on my GP60 pages:

gp60 feasture to port mapping

Notice that I programmed all ports: Ports 1-12 are indeed mapped in my GP60 with a LS Titan (see the GP60 page)

I built a double check" table, organized by port number, for what I am using on the GP60 at this time. I might add more notes later

port #	physical connection gp60	QSI Feature name mapping	notes
1	front headlamp	front headlight
2	rear headlamp	rear headlight
3	left ditch light	front left ditch light
4	right ditch light	front right ditch light
5		front mars light	not used at this time
6	number boards	front number boards
7		rear number boards	not used at this time
8	cab light	front cab light
9	may hook fan here	rear mars light
10		front marker lights	not used at this time
11			not used at this time
12	for smoke heater	rear cab light	high current output

Second: Map FUNCTION KEYS to FEATURES

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

This is an actual screen capture from CVManager.

Note you can map both lighting functions and sounds to a function key, this is why they are both under "FEATURES"

The output numbers go from 1 to 30, these are actually:

1 & 2 are F0 forwards and F0 reverse

3-30 are actually F1 (3) through F28 (30) (subtract 2 and you get the actual function key number)

The literal indexed CV is shown for either:

forwards and reverse (FWD/REV)
neutral (NeutralFromForwards or NeutralFromReverse) (no real distinction on how you "entered" neutral)

You also see the text description of the FEATURE, and the FEATURE INDEX

gp60 function key mapping

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 notice the 2 CVs for Initial state of some misc lights, sections 5.7.26, 5.7.27

Function	moving	neutral/stopped	Port	Notes:
F0 / lights	multiple lights 1	Multiple lights 1	L1/2	lights dim in reverse/neutral
F1	bell	bell
F2	horn	horn
F3	multiple lights 3 (smoke system)	multiple lights 3		smoke fan and heater here
F4	cooling fans	cooling fans		your can hear the actuator too
F5	dynamic brakes	dynamic brakes		only above 9 mph
F6	used for doppler on horn above ?? mph	startup sequence
F7	flange squeal & airbrakes (zero throttle)	front overhead beacon		ovbeac manual only, no auto
F8	mute	mute		respects mute volume set
F9	heavy load	3 phase shutdown
F10	grade crossing	change
F11	std/alt horn select	std/alt horn select
F12
F13	volume down	volume down		honks horn, will go to zero volume
F14	volume up	volume up		honks horn, will say "max" at max volume
F15		water loading
F16		motor rev up/test
F17		fuel loading
F18
F19
F20
F21
F22
F23
F24
F25
F26		fuel loading
F27		motor runup test
F28		check water level

Note:

Multiple automatic lights 1 fl(1), rl(2), flditch (3) frditch(4), front cab (8)

Multiple automatic lights 3 for smoke on off rear mars (9), rear cab (12)

User manual

Initial state:

Everything is off, sound and lights
Use F6 to power up (standard QSI startup)
if you use F9 (3 times) to shut down, then F6 has extended startup

Startup state:

Audio is at LAST volume before shutdown/power off
Headlights on (dim)
Ports headlights dim, cab light on, number boards on

Headlight notes:

Both off if loco stopped
Both can be turned on and off with NCE headlight button
Bright in current direction if moving, off otherwise
headlight button also turns off number board lights

Other light notes:

cab light comes on automatically when in neutral/stopped, goes off when starting to move after a delay
ditch lights come on with horn when loco is moving any speed

So on to the smoke control:

(not finished yet)

A tricky item: smoke unit control: (I drive the heater and fan separately)

Goals:

control smoke
have remote control of different smoke levels
modulate fan speed with load?
single on/off function key if possible

Givens:

smoke unit needs to be on L12 port, high current
try fan on port 9, seems to be intended on
try lighting group 3 to put both features on one key

Ideas:

regulate the unregulated DC output with a regulator (fed from unregulated power) for the heater
there is explicit control of bright/dim on mars light, could that be high/low smoke power?
could put smoke and fan in a single lighting group, like group three, then use feature 138 to turn group on and off, but realize you need the features on the group to be "explicit" also, which normally means always on in any state

Issues:

feature code of mult lights 3 is 138??

function key 3 (output 5) was coupler sounds for both moving and neutral, try mult lights 3 for both (138)

port programming: put fan (port 9) on truck lights
and heater (port 12) on step lights

function key programming (output map): put 138/ mult lights 3 on output 5 (function key 3)
mult lights 3 programming (feature config): put truck and step lights in group 3
turn off initial state for truck and step lights (misc lights 55.134.0)

this did not work, they always came on at startup.. but F3 controlled them after

try 2 other features:

try rear number and rear marker

mult lights 3... set
initial state rear number initial state
initial state rear marker

came on at startup, but F3 had no control

try on mult lights 2, no difference... back to mult lights 3 and truck and step lights

now it works !!!!! WTF???

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 state

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.

map fan to port and mult auto lights

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

map smoke heater to port and mult auto lights

use rear cab light for smoke heater
map LED port 12 to rear cab light ( 115.118.0 = 12)
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

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)
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

Notes on my "TEST" file:

Doing the GP60 was a bit of a daunting task at first, finding omissions, errors, and just discovering how stuff works.

I built a "TEST" programming file to use in a titan for debugging. This was designed to let you individually and explicitly turn all 12 LED ports on and off with function keys.

Also I mapped the FUNCTION KEY directly to the same numbered QSI LED Port. so F3 turns on QSI LED output 3.

Contact me and I'll be happy to share this file with you so you can use the QSI CVManager to load it into your decoder in one shot!

test build
mult lights 1 is headlight
mult lights 2 is rear headlight

f key port # out# feature
1 1 3 136 mul lights 1 (front headlight) j1-4
2 2 4 137 mul lights 2 (rear headlight j1-9
3 3 5 117 front cab j2-8
4 4 6 105 front marker j2-12
5 5 7 101 front number j3-1
6 6 8 77 mars light j3-2
7 7 9 107 rear marker j3-3
8 8 10 103 rear number j3-4
9 9 11 109 truck lights j2-10
10 10 12 113 step lights j2-11
11 11 13 119 rear cab lights j3-8
12 12 14 81 rear mars j1-8

13 vol down
14 vol up
15 shutdown
16 startup

26 horn
27 bell
28 status (can also startup)

QSI Test box:

(picture)

describe connectors

don't use j2 pins, only one connected is pin 1 maybe

Weirdness in QSI QCV files.

The QCV file has a list of the CVs and their values.

Unfortunately, even if not specified in the file, CVManager will try to program "undefined" CV's

the following list is my notes...

not in file, but system insists on trying to program anyway

52.14
52.26

55.21.0

56.50.0
56.50.1
56.50.2
56.50.3
56.50.4
56.50.7
56.50.8
56.50.9
56.50.10
56.50.11
56.50.12
56.50.13
56.50.14
56.50.15
56.50.16
56.50.17
56.50.20
56.50.21
56.50.22
56.50.23
56.50.24
56.50.25
56.50.26
56.50.27
56.50.28
56.50.29
56.50.30
56.50.40
56.50.41
56.50.42
56.50.43
56.50.44
56.50.45
56.50.46
56.50.47
56.50.48

56.50.128
56.50.129

116.14
116.26

117.0.1
117.8.1
117.10.1
117.16.1
117.19.1
117.28.1
117.40.1

Sidebar

Main Menu

Overview:

New concepts:

Outputs:

Enter logic-level "outputs":

Conversion of logic-level "outputs" to the familiar decoder outputs, a.k.a "amplified" outputs.

OK, OK, enough lecture, get to the meat!

Converters / aids for logic-level conversion

DCC Wiki

Twisting track power wires

But before getting to the reasoning, the BS starts:

Back to twisting the wires:

Back to the DCC Wiki on twisting wires:

Note: updated & clarified manual:

Overview:

Note well: NMRA Function key mapping is not supported in the QSI

Updated QSI Terminology - Important

OK, big mouth, how do I set up my decoder?

Do your "automatic" features first

So, normal steps are:

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

Can we get started now? No, sorry! you need the following notes:

FEATURES notes:

OUTPUT PORTS notes:

FUNCTION KEY MAPPING notes:

OK, finally we can start!

Note: From here on, this example uses my custom configuration for the AML GP60 installation.

Select and & map the features to the physical ports

Review of QSI LED light ports on GP60 example for reference (and double check):

Second: Map FUNCTION KEYS to FEATURES

User manual

Initial state:

Startup state:

Headlight notes:

Other light notes:

So on to the smoke control:

QSI Test box:

More Articles …