[lshort]

I have been using a Prodigy Advance with no problems for some time. Just recently I've been having a problem trying to change loco addresses using either the built in function, or CV1. It appears to be happening with sound decoder locos mostly. I've tried all the normal reset options. Any suggestions welcomed.

Les

 

[Brian Considine]

Make sure that the loco is is "110%" in contact with the programming track (the current available is limited, hence possibly the problem with sound equiped locomotives).

If that does not work remove every single locomotive from the running tracks & try using programming on the main as a last resort.

 

[Richard Johnson]

QUOTE (dbclass50 @ 1 Jan 2008, 15:12) <{POST_SNAPBACK}>Make sure that the loco is is "110%" in contact with the programming track (the current available is limited, hence possibly the problem with sound equiped locomotives).

If that does not work remove every single locomotive from the running tracks & try using programming on the main as a last resort.

*** You could also try adding a 100 ohm 1/2 watt resistor to one of the programming track leads. This will often let a units programming track output cope with the added load of a (mainly the higher current US types) sound decoder.

If its a QSI sound loco, disable verbal confirmation as it prevents programming because it adds a delay in the acknowedgement.

As long as the install is definately OK, then frankly POM is the easiest answer - many sound loco's actually can't be easily programmed on the programming track anyway.... MRC's horrid ones in particular (sorry - but they are nasty and best adjusted with a hammer).

Re programming on the main: The "danger of reprogramming everything" is actually a hobby myth!

---------------------------------------------------

Unlike programming track programming where the programming is simply broadcast to "whatever decoder is on the track", programming on the main is actually selective loco by loco.

paraphrasing programming track programming:

"whatever loco you are, change CV1 to 12"

---------------------------------------------------

POM isn't a "broadcast" type thing as people think Brian - To do any programming you always have to first tell the command station which loco to programme, and this also applies with address changes... other wise programming on the main would always tell every loco the same thing, and it doesn't. (there are many DCC users who do 99% of their programming of everything on the main one they've checked the correctness of the install on the programming track).

paraphrasing programming on the main:

step one "attention loco number 3"
step two "change CV1 to 12"

etc etc.... So youc cannot change all loco's at once unless they all have the same address to start with!!!!!

MOST competent systems will happily change all CV's on the main including address...If in doubt, check the manual for your own system.

Richard
DCCconcepts

 

[Brian Considine]

QUOTE (Richard Johnson @ 1 Jan 2008, 08:03) <{POST_SNAPBACK}>Re programming on the main: The "danger of reprogramming everything" is actually a hobby myth!

Ah yes, but if you change CV1 with PoM you can end up with everything with the same address code - not something I've done, but a couple of our customers have managed it ! (somehow).

 

[neil_s_wood]

QUOTE (dbclass50 @ 2 Jan 2008, 03:18) <{POST_SNAPBACK}>Ah yes, but if you change CV1 with PoM you can end up with everything with the same address code - not something I've done, but a couple of our customers have managed it ! (somehow).
I managed this with my Lokmaus 2 a while ago.

 

[Richard Johnson]

QUOTE (neil_s_wood @ 2 Jan 2008, 09:13) <{POST_SNAPBACK}>I managed this with my Lokmaus 2 a while ago.

**When programming on the main or when using the main as a programming track??? There's a difference. If you put the unit into what is effectively "programming track" mode then yes, this can happen, but true POM actually cannot do that in a compliant or conformant product..

Richard

 

[neil_s_wood]

QUOTE (Richard Johnson @ 2 Jan 2008, 12:18) <{POST_SNAPBACK}>**When programming on the main or when using the main as a programming track??? There's a difference. If you put the unit into what is effectively "programming track" mode then yes, this can happen, but true POM actually cannot do that in a compliant or conformant product..

Richard
The Lokmaus2 doesn't have a programming track extension so it's pretty much all on the main. I forgot to remove a couple of locos from the track before changing the address (CV1) on a new loco. They all ended up with the new address.

 

[Richard Johnson]

QUOTE (neil_s_wood @ 2 Jan 2008, 12:39) <{POST_SNAPBACK}>The Lokmaus2 doesn't have a programming track extension so it's pretty much all on the main. I forgot to remove a couple of locos from the track before changing the address (CV1) on a new loco. They all ended up with the new address.

**Then its not really 'programming on the main" as defined by DCC at all - it is simply using a standard programming mode without the option of POM existing. This is confirmed by my reading of the manual... ROCO like several others in fact only support a form of direct programming, which I agree can cause a problem. The problem with units that feature a simplified programming support is two fold - they generally cannot support readback in any programming format and are easier to make mistakes with, which is just what new DCC people do NOT need.

In that case, the track power should be routed as follows:

from DCC unit output to the centre terminals of a DPDT
From one side of DPDT to isolated programming track
From other side of DPDT to running track

Always switch to isolated programme to programme.

True POM is as used by quality brands such as NCE, Digitrax, Lenz, ESU etc - these are designed to allow programming on the main without affecting all decoders, which is why it requires a specific decoder to be addressed first. Some but not all can access address basic CV1 settings in this mode.

(For example NCE can - both PowerCab and Powerhouse Pro, ESU cannot).

To me, when features of DCC are thought through properly, the real benefit of one Vs the other really stands out in these areas which are never even considered by many - once the real "win" of having these things properly available is undrestood, then value of one Vs the other becomes self evident - which is why while I like some things about amny systems, I generally end up back at NCE every time as "the best and most useful and easy to use system of them all"

....and why I'd never consider recommending many of the brands that are available.

Richard
DCCconcepts

DCCconcepts

 

[neil_s_wood]

QUOTE (Richard Johnson @ 2 Jan 2008, 16:29) <{POST_SNAPBACK}>True POM is as used by quality brands such as NCE, Digitrax, Lenz, ESU etc - these are designed to allow programming on the main without affecting all decoders, which is why it requires a specific decoder to be addressed first. Some but not all can access address basic CV1 settings in this mode.

(For example NCE can - both PowerCab and Powerhouse Pro, ESU cannot).

Richard
DCCconcepts

DCCconcepts
Was this not meant to be one of the benefits of RailCom?

 

[Richard Johnson]

QUOTE (neil_s_wood @ 2 Jan 2008, 14:40) <{POST_SNAPBACK}>Was this not meant to be one of the benefits of RailCom?

***Not really Neil - its a by-product perhaps but not the main thrust. Most competent systems can already read a standard decoders CV's.

Railcom was really conceived to add interactive bi-di communication for some new features such as fuel etc - which begs the question: reading the standards and RP's these are to be places in the higher CV areas (CV900+) and be programmable.

Which When you think about it, begs the question: Some supposedly Railcom compatible systems can't even come close to interacting with CVs in the higher areas - so what wil lthey really deliver benefit wise in the end??

None of this of course helps those with entry level gear - and the sad thing is they'll never know what they are missing!

Richard

 

[Gary]

To programme on the main three things are required.

The console must support "operations mode" programming and the decoder must support "operations mode" programming.

And thirdly the human interface must select "operations mode" on the console!

Any other set of circumunstances and this is NOT programming on the main.

Dynamis and Elite both support "operations mode" programming.

"Operations mode" programming does have limitations. Not 100% on this but is there a 2 digit short address limitation?

For unlimited programming and read back "direct mode" is normally used. If using the mainline as a programming track in "direct mode" then all locomotives with the exception of the one being programmed must be removed.

Elite supports read back. Dynamis supports read back when used with a Pro unit.

Getting back to the original Prodigy Advance qestion and the sound decoder I note the use of CV1. This is is used for short two digit addressing. I am wondering if the decoder is set up for extended addressing mode and 4 digit addressing. If it is using CV1 will not work! I too have experienced this issue when using the wrong addressing mode.

Happy modelling
Gary

 

[SPROGman]

QUOTE (Gary @ 2 Jan 2008, 13:23) <{POST_SNAPBACK}>"Operations mode" programming does have limitations. Not 100% on this but is there a 2 digit short address limitation?

There are no limitation other than those imposed by some manufacturers for their own reasons, e.g., some do not allow the address to be changed in ops mode.

Andrew

 

[lshort]

Makes no difference whether it's Program or Main - it doesn't work. However, I have more data: this seems to be happening only with Soundtraxx Tsunami decoders. Also, I can change other CVs no problem. Example, I changed the bell volume, and the loco inches forward to indicate it accepted the programming (and it did), but this does not happen with CV1. Weird!

Les

 

[Gary]

CV1 is used for the address.

Make sure CV29 is set up for short addressing if you are trying to set CV1.

Happy modelling
Gary