PS3 BCR do they funtion the same in DCC mode?

No, When power is interrupted via dirty track a PS3 equipped loco will shut down. Most DCC decoders I've seen need a separate module that is usually a bank of supercaps to keep things "alive" when crossing dead track sections.

At my LHS ( 2 rail NCE dcc) they have a pair of PS3 gp35's that will not stay MU'd after several sessions. When i bring them home to my layout they perform flawlessly on my DCS layout single or MU. They need this MU for traction( grades and large freight consist). Any advice on improvement?

What does not stay MU'd mean?  Speed performance or all functions revert to individual engines?  Not addressable?  G

When the mu stops the NCE guy(he comes in twice a month) has to reload the values to reestablish the MU which will last a few sessions at best. When i get back to the LHS i get the usual it quit again and the engines are sitting on the bench. I am not sure if individual engines maintain settings . I will try to get together with the NCE tech with more data.The owner of the LHS wants the track cleaned once a day with a track cleaning car. I am thinking geez my track is lucky to get cleaned twice a year and usually due to traction issues(DCS 2 rail) and not signal issues. BTW i am DCC dumb

I would think.... that the MU is stored in the DCC remote? So if that was true, the remote or DCC system should be remembering it and not the individual engines.

 Maybe it's assigning a temporary address that isn't lasting?

NCE DCC Advanced Consisting data is split between two locations; the command station CMOS memory and in a DCC decoder register (CV19).  These two need to be kept “in sync” for advanced consisting to work properly.  In other words, if you take your locos from one layout to another, you should first kill the consist on layout A and then rebuild it on layout B – this is true even if both layouts have NCE DCC systems.  First off, Layout B has no idea of the consist that was built in the command station on Layout A so you have to rebuild it anyway on Layout B and if you were to then go back to layout A, where the consist was originally built (assuming you did not kill it), then CV19 in each of the loco decoders will more than likely have a different alias address inserted into it when it was built on Layout B, so always best to do proper housekeeping and delete DCC MU consists when going from one layout to another. 

Now as to the persistence of the storage in each of the two consist storage locations; DCC decoder itself and the command station.  DCC Decoder register CV19 contains alias address that each loco in the consist will respond to when operating as a common group. e.g. a consist or MU, since each loco will have its own unique address when operating individually.  Data in the decoder register CV19 does not need any power to remain set, the main DCC decoder chip uses flash memory - like an SD Card (like the one in your digital camera) or USB Key thumb drive to store CV - Configuration Variable data, like loco address, function mapping, etc..

Memory in the command station is battery backed (a little coin-style battery) and maintains command station CMOS-style memory when the command station is turned off – this battery needs to be replaced around every 3 years or so) depending on the ON time of the command station.  The longer the command station is left powered on, the longer the battery will last since the battery will not be drained while system is left powered up.  If this coin battery dies, then the data in the command station memory is lost once the command station power is turned off, this includes the command station consist information and all the command station configuration settings and so consists will have to be rebuilt each time you power it back up.

If the command station coin battery has not been replaced in a while, try replacing it and see if the consist info still disappears.  You can usually pick up one of these replacement coin batteries at any of the national pharmacy chains for less than $10. Remember to jot down the number printed on the battery in your command station since there will be a whole myriad of part numbers to choose from.  

Scott K.

Austin, TX

very useful information...adds to my DCC education and believe me i need it.

If you want a real brain scratcher read this straight from MTH about changing PS3 long & short addresses via a NCE DCC. More reason why the PS3 DCC hybrid decoder is a real PIA!

 http://mthtrains.com/using-nce...equipped-locomotives

E gadz....as you stated PIA

Okay, the original question about stay alive caps is a bit complex. As I mentioned before some manufacturers use an auxiliary capacitor board to keep engines alive while crossing dead track spots.

Here's how a friend of mine in Germany describes how a Lenz Gold Decoder can still operate with power interruptions...

 "The Lenz Gold decoders have something they call USP or Uninterrupted Signal Processing. I have visited Lenz when I was developing support for them on my app, and they gave my a demo on their test layout. A small two axle engine drove on to a piece of paper (A4/letter format) which was across the track. On that piece of paper, it stopped, reversed and back away from the paper. Very very convincing demo."

"There’s no magic to it. Bernd Lenz, the owner, is just applying math to the problem. When the wheels are separated from the track, the wheel/paper/track combo behaves like a capacitor. In that case, the edges of a normal DCC signal are electrical spikes, so in the decoder they detect the positive and negative spikes and reproduce a perfect DCC signal. Very clever."

Another issue to remember, is that some systems, command stations and decoders, do not handle "advanced consisting".    They only support "universal consisting" or "basic consisting".   

NCE handles advanced consisting as described above and does it very well.    Digitrax does not handle it well at all.    Depending on how MTH implemented their decoder software, it could be either or neither.    

The simplest solution is to give both  units the same address, then you can run them as a consist on either system.    Pick a standard like the lowest number address.    That way they would be compatible with both systems.  

Whatever your DCS system does, it will not be the same as NCE internally.    At home you are using  your proprietary DCS command station and decoder.   At the LHS, you are using the DCS decoder with a DCC command station.    MTH may not have implemented all the DCC standard control functions into their decoder.   MRC for example was guilty of that for years.    They called theirs DCC compatible, but they did not totally use DCC standards.

I remember that as I once sprung for a cheap MRC Prodigy 8 amp DCC system...and that was a mistake. It couldn't even read back most CV's on say a QSI Quantum Magnum decoder.

I see the new Lok Sound V4 DCC Decoders have stay alive caps mounted on them. I'd say they're top of the line and are rated something like 8 amp for total electrical load. 4 servo outputs gives me a few ideas. Zimo has top shelf decoders but cost like 50% more.

http://www.traintekllc.com/esu...ale-screw-terminals/

Sound decoders need a lot more power on the programming track to read back CVs.    I don't think any system will read back the CVs on most sound decoders without an auxilliary booster attached to the programming track.

I have found that Digitrax does not seem to read them back from QSI on the main, which does have a lot of power.

I have a "SPROG" programmer and it will read most of them.   You use it with your computer and you also need DecoderPro.    DecoderPro does not seem to have all the latest decoders in it files, so it cannot interpret some the QSI stuff in the Titan. 

So it is not your prodigy so much as what the decoder wants that is slowing you down.