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.

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.

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:

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? 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:

 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

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

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

 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

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

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

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.

Note that the "socket" really only connects a few things, for downloading firmware/sound files, this is ok, and the Revolution and Titan use just the pins on J1 (left hand black sip socket)

The socket adapter was made by Aristo, and also several other aftermarket manufacturers. In addition the J1 connector has the 2 headlights. 

This is a good setup just to be compact, and carry to a site, and not do anything sophisticated.

Below is a more sophisticated setup, and was designed to accommodate the Titan.  It had the same basic socket, but DIP headers to screw into Titans, plus J2 and J3, plus one for J1 in case the Titan had their pins cut off. Notice also there are both speaker1 and speaker2 to confirm programming between them.

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

This setup was ok for basic programming and checking out "stereo", and some testing but had many issues.

Also, the orientation of the socket was rotated 180 degrees from what is shown in most documentation.

Inside, the programmer has been removed from it's housing to make a cleaner and more secure installation, but you could leave it in the housing and just cut a bigger hole in the cigar box.

The above unit was given to me by Josh Shedaker, and I used it for years for programming, but never verified the wiring to the ports until recently.

I found that a lot of things were not wired up missing connections and miswired connections.

In 2024 I started on a big project that would use all the ports and features of the Titan, and wires had been breaking off the headers to be screwed into the Titan, and there were ones not documented.

So I did a redesign and a rewire. My primary focus was ease of use of the Titan, and to have every output port monitored and more rugged connections to the decoder.

My first thought was to make an adapter to the existing socket, and provide the sockets for the Titan. This was based on the original sockets had been modified to have all pins connected (the stock Aristo adapter had no connections on J2) See the picture below:

But re-using the adapter had it's own issues: Below you can see the adapter wiring and see no wires on J2 (the bottom connector)

So, below is the idea: You can see that I was still trying to re-use the original headers into the screw terminals and additional wiring added to J2 on the bottom adapter.

Well, the short story is that this was a waste of time. So many wires not connected, miswired, and the pain of the adapter in the socket and the existing fragile dip pin headers for the screw terminals was a mess.

So I started all over, and made a proper socket with J1 and J2, AND added 3 sturdy dip headers to address the screw terminals. During this build I found that some of the connections on the Titan do NOT go to the pin that they should, and are ONLY available through the screw terminals.

 The blue perf board has traces on the other side that allowed multiple connections easily, i.e. you need up to 3 connections for any "pin" on the Titan:

• The connection to the socket
• The connection dip header for the screw terminal
• The connection to the actual output device, LED, motor, speaker, etc.

Here's a Titan in place:

Now finally, I had a solid platform, and rewired all the Titan Output Ports to the appropriate LED, 12 ports to 12 LEDS. In addition I hooked up the wires to the pushbuttons.

 But, don't open the box!!!! (yes I eventually will remove the tape and solder and heat shrink the wires ;-)

Installing and using Quantum Upgrade

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