Bachman vs Gaugemaster decoders

[Free At Last]

There are only 10 types of people in the world: those who understand binary and those who don't.

[Nigelcliffe]

Right so instead of needing some other device to program CV29 I just add an 8 digit number e.g. 0000 0001,

Oh and yes you were right when reading CV29 it did = 6, however if the above is right then I would expect to see 0000 0006 or perhaps some variation other than 7 zero's

I shall go away and play with CV29=3

From the above, I am thinking you're not proficient with binary numbers or binary to decimal conversions.

In which case, just stick to what the CV29 calculator webpage gives as results for the features wanted and don't worry about binary.

 

The Prodigy handset appears to only show you decimal values, which is fine, but means for a few things (notably CV29) a binary to decimal calculating tool is required.  That can be a bit of paper, or a computer tool. 

 

If wanting to know how binary conversions work, you can see from the 2mm webpage tool how the value is calculated. If you add the decimal numbers in the 2nd column of every ticked item, it will equal the decimal total. This works for any binary to decimal number conversion.

 

 

 

 

- Nigel

[Izzy]

 

Hi Stuart,

 

As Nigel says I have a PA2 system but don't generally use it to program decoders much finding my sprog+JMRI/Decoder pro much easier/simpler/better. I haven't used the prog track output for some years as a result but do use the prog on main at times for odd tasks like acc/dec adjustments and changing decoder addresses.

 

As such I believe the system auomatically uses the right mode to program decoders (there is no way to change it I know of) and I can't recall having any issues changing the address on any make of decoder using it in the POM mode. I can't tonight but tomorrow I'll dig out some locos and try changing the address just to confirm - they are mostly CT/ZIMO these days.

 

Izzy

[Izzy]

I have now carried out a small series of tests with my PA2 and (Farish) CT decoder fitted locos. A small circular test track I have was set up with both program track and main track connections, only one of which can be connected at any one time to prevent me blowing the program track outputs again(!), which I did when I first got the unit by connecting them both at the same time. Some lessons you learn the hard way. Thankfully Gaugemaster repaired it FOC.

 

Anyway, I have tried changing the CT decoder addresses using different combinations, both 2 digit to 2 digit, 3 digit to 3 digit, and four digit to four digit, and between them as well, 2 to 4, 3 to 2 etc, using both the program track output, and Program on main. I have encountered no issues whatsoever. When the address was changed using the program track I should state that I turned the base station off while I changed connections (which is using 5-din plugs and sockets) before the loco was run using the new address on the main track connection. The base station was left on when POM was used, i.e. I didn't turn it off between changing the address and then trying to run the loco using the new address, which they always did. (Often when I have re-set a decoder via POM - I have tried it with different makes on occasion - then there is a need to turn off/on the system before the re-set decoder will be recognised).

 

As these tests would seem to confirm my memories that I hadn't had any issues with the CT decoders I have when programmed using my PA2 in any mode I am just wondering whether the issues Stuart has encountered are to do with either the particular CT decoders he has obtained, or the locos they are being used in since I have had no light direction problems either.

 

Izzy

[StuartM]

Thanks Izzy, for taking the time to test and report back.

My GF locos ran fine as DC locos

When I first converted them to DCC I used a Bachman EZ controller and CT DCX76D/N decoders

The loco ran ok but the lights would operate in the opposite direction to travel

 

I have since replaced the EZ controller with the Prodigy 2 and thanks to everyone's help I've managed to program the chips with new addresses so the P2 can now operate the locos, but the lighting issue still persists.

I've taken Nigel's suggestion of changing CV29 to both 3 and 6 and in fact every other number between 1-6 but still the lights either work in the opposite direction to travel, or the the lights work at one end only, or they slowly flash? 

 

It has been suggested that perhaps I try a factory reset and Gaugemaster have suggested while programming, when presented with the CV# option to key in 1, press enter and then address the loco address and then enter.

Both of which I will try later tonight.

[Nigelcliffe]

Stuart,

 

semi-randomly changing CV29 will produce odd results.  Use the calculator mentioned earlier to understand the values that are being set. 

For example, on many decoders, setting things to 14 steps, but issuing 28/128 step instructions from the command station will result in lights on/off with alternating speed steps (I could explain why, its to do with the structure of 14 step and 28 step DCC packets). 

 

The lights not working correctly is weird.  However, I wonder what else has been changed in the decoder (you've already mentioned CV49) with the experiments.  If various semi-random things have been changed, a factory reset on a CT decoder is CV1=0, this is different to many other decoders.  It will set the decoder back to address 3, and also set all other values back to the factory default.

 

If changing CV29 isn't correcting the lights, then the next step is to experiment with the function mapping.  This starts in CV's 33 and 34. 

 

Say if you want some detailed instructions as to what to change in what order. 

 

 

- Nigel

[StuartM]

Coastal DCC from whom I bought the decoder from suggested resetting the decoder from CV1=0

Gaugemaster tech support suggested that I address the loco from CV1=loco address

 

So I did both in that order,and it does address the loco from that cv

I did notice that if I programmed CV29 afterwards to either 3 or 6, then this became the address

But if I programmed CV29 first and then programmed CV1, then the address remained what I had entered.

 

I got 4 CT DCX76D/N decoders which I put into the following locos

GF class 20

Dapol class 22

GF class 37

GF class 47

 

The class 20 works fine

The class 22 works but no lights so swapped into GF 37 and works fine both address and lights

The class 37 works fine

The class 47 works but lights only work in one direction, which happens to be the opposite direction of travel

 

To make sure it wasn't the loco at fault, I swapped the decoders in the 37 and the 47 round

The 47 then worked perfectly including lights, whereas the 37 displayed the same issue as the 47, proving the problem lies with the decoder and not the loco

I tried doing a factory reset and then re programming CV29 to 3 and then re-addressing the decoder to 37, it runs but still has the same problem with the lights only working in one direction which would lead me to think the decoder may be faulty.

Does this make sense?

[Nigelcliffe]

Your conclusion does point to the decoder.   It could be a faulty decoder output.  Or a programming error (which should clear with a reset).  Or, it could be a bad connection between decoder pin and the decoder socket, though I think this unlikely in two locomotives. 

 

Your programming observations around address and CV29 does not make sense.  Something wrong there.  If that is happening with all the decoders, then the problem needs sorting out.  It should not happen that way if you are actually accessing the CV values (ie. skipping the first menu options on the Gaugemaster until you reach the actual CV entry point). 

 

If you want to investigate the problem decoder further, try to read back CV33 and CV34.   I would expect CV33=1 and CV34=2.   That should result in lights working in each direction of travel. 

 

Or, send the problem CT back to Kevin at Coastal.  He'll be able to check it.   (And if you tell him you've talked to me, then he can blame me !). 

[StuartM]

Hi Nigel,

I've posted the decoder back to Kevin this morning, but I'm interested to know more of these CV33-3X settings that you speak of

[Nigelcliffe]

Stuart,
CV33,34 (and a few more) are "function mapping".   They are an optional part of the DCC standard, which most decoders implement.   Those that don't are usually high-end models, because the DCC standard is actually quite restricting in what can be done, so the high-end models either provide ways to extend things (eg. Zimo), or just invent their own highly flexible method (eg. ESU).
 
Function mapping defines which Function Keys on a handset control the Outputs on the decoder.    Note that the DCC standard defines Headlight Key-Forwards as different to Headlight Key-Backwards, and these are also called Function Key Zero.  Other function keys (F1 to F28) within the DCC standard are not directional (though many decoder makers add CV's to make directional behaviour possible with these higher keys, CT do offer this with further CV's ). 
 
CV33 is the CV for Function Key Zero (Headlamp) in Forward direction.   It defines which output(s) come on when that key is active. 
CV34 is the CV for Function Key Zero (Headlamp) in Backwards direction. It defines which output(s) come on when that key is active.

CV35 is the CV for Function Key 1 (in either direction).  Defining the output(s) which come on when that key is active.

The outputs are labelled in different ways by different makers, but I'll stick with Front Light (white) and Rear Light (yellow).   The colours being the usual default on a decoder with wires.  There can be many more than two outputs.   Each output acts as a binary switch (like CV29).   So, Front Light takes value "1",  Rear light value "2" and the next output (usually green wire) would be "4", and so on.   Add the numbers of the outputs required for the value of the CV.

 

So,  the default arrangement for CV33=1, means when Function Key Zero, in Forwards, is active, the Front Light wire is active.

And, CV34=2 means when Function Key Zero, in Reverse, is active, the Rear Light wire is active. 

 

 

Internally in a typical N diesel loco, there are two lighting circuits.  The A-end (front) of the loco front lights which are also connected to the B-end (back) loco rear lights  (these connect to the "front light" wire).   And the opposite B-end front light connected to the A-end rear light (these connect to the "rear light" wire).    

 

If you didn't want the Function Key Zero to control the lights, you could change CV33 and CV34 to be both zero.  And, then alter values in CV35 to make Function Key 1 control the lights (eg. CV35=1 would mean the Function Key 1 would control the "front light wire"), or CV36 for Function Key 2,  and CV37 for Function Key 3.       At Function Key 4 things change because the DCC specification has a jump in how things work, so according to the specification, the first three outputs have to be controlled by Function Keys 0 to 3 - this is one reason the advanced decoders (Zimo, ESU, etc.) have ways to do their own thing.   

 

In answer to "why would you change the function mapping for the 'front light wire'" ? - for a decoder and model with two "normal" light circuits its hard to come up with a good reason, though some locos might have unusual lights.   It is possible to use the function output for other things.   In some of my models, the front light output wire on the decoder operates my uncoupler coils.   So, I will have mapped that output to a key which I use for uncoupling, often Function Key 1 or Function Key 3.  (I've never fully standardised my models, perhaps I should!). 

 

 

Additionally, for CT decoders (other makers might do something similar), there is a pseudo function output called "Rangiergang", which is a control to allow reduction in acceleration and running speed.   So, that allows a Function Key to turn off the acceleration/deceleration values, and optionally reduce the running speed for shunting.    It requires both mapping to a function key,  and additional settings to say how the function will behave. 

 

 

Though I know what's going on, I prefer to use a computer software tool to do all this sort of thing.  It is possible to do it by keying on a DCC handset, but its hard work, and quite a lot to keep track of with a bit of paper.  So, I prefer to have a computer running JMRI hooked up to my DCC system to make and record such changes. 

 

 

 

-  Nigel

[StuartM]

Thanks for the comprehensive answer Nigel,

so much to learn, perhaps I ought to buy a book on the subject

[StuartM]

Another question

How do I assign a function to a function key

For instance, say I wanted to be able to switch the red tail light on a loco off or on, how would I assign that function to a function key eg:F1?

[Nigelcliffe]

Another question

How do I assign a function to a function key

For instance, say I wanted to be able to switch the red tail light on a loco off or on, how would I assign that function to a function key eg:F1?

Short version answer - with most N gauge diesels, you can't. Unless you are willing to rewire the loco. This is because the makers have connected the Front White to the Back Red on a single wire. The makers have also connected the Back White and Front Red on a single wire. So, to operate the Red alone (at either end) would require rewiring of the loco to split the lights into four independent lights.  Then you need a decoder with four function outputs  (these do exist on CT DCX76's, but two are solder pads on the decoder).

 

Longer answer starts in the post above about Function Mapping and CV33/34/35.   Function Mapping is how you assign the behaviour (lights etc.) to Function Keys.