You stated Ops mode programming is locked out on the Tsunamis (“…Soundtraxx apparently decided it best to protect the end user from themselves by locking out the ability to program Tsunami on the mainline…”). It is not. Where is my misunderstanding of plain English?
I can understanding you thinking it is after having trouble; however, after you made a similar statment in your previous thread, I explained to you that it was not.
I’m not big on jargon and prefer plain English to the extent possible in technical discussions. But to say you’re “locked out” as arto is using it here demonstrates confusion – for himself and for others. Why?
Because you actually CAN lock a decoder and it has nothing to do with how Arto is using the term. Check CV 15 and CV 16. They should both be zero. If not, then the decoder is locked by this pair of codes. That is what “locking” a decoder is about. To refer to something else as being locked tends to confuse things for everybody. YMMV, but just suggesting we not be bull-headed about this for everyone’s understanding, whether needing to help or helping someone else.
People may quibble with Soundtraxx’s approach to this, but all it takes is one fried decoder to more than pay for the PTB-100 (NOT including your labor to R&R, plus aggravation, etc). Maybe there was another way this could have been done, but it wasn’t. Not point in doing anything but understanding how it works. It is what it is. As Dave noted, a PowerCab has no problem dealing with this, as do other command stations some have mentioned. Not all do, though, so check this if it matters to you.
But if locked using the decoder lock settings, even a PTB-100 won’t save you. The only good news is that there are only 255 possible options, and there’s no permanent lockout like a computer or smartphone after too many invalid tries.
–Randy
[(-D]
Randy,
That is true, a PTB-100 won’t help at all with a key to the lock.
To avoid guessing, can’t DecoderPro just read those values? Mine reads them as 0 and 0. Or can’t they be read on a programming track, where you do get read back from the decoder? Might take less than 255 tries that way, but I don’t bother with the darn things myself, so don’t know for sure.
Never tried. They might be readable. The idea is to prevent accidental programming, not literally lock the decoder, so it’s not like it tries to hide the secret combination to the cookie jar. I guess though if the problem is your system can’t read the decoder onthe program track, you’d have to blind test the possible combinations on the main.
–Randy
Arto,
I can understand your frustration with DCC (especially if computers frustrate you.)
The problem you are experiencing with reprogramming a 4 digit address on the main isn’t a limitation of tsunami but one of the DCC standard.
When you send commands to change a variable in a decoder on the main, you have to address it to a certain decoder. That way the train knows the command was meant for it and not the other trains on the track.
The command structure kind of looks like this
Decoder Address we are broasting to, CV #, Value
Well your 4 digit address is based on CV17, and CV18. So this is a two step programming process.
So lets say you want to change your loco from address 1234 to 4567
Well your commands would look like
Decoder Address, CV, Value
1234, CV17, 209
1234, CV18, 215
But the second command won’t take. Why? Because when you executed the first command, you reprogrammed half the address. Your train is no longer 1234, and it’s not 4567 either. (And unless you are good with hex math, you won’t know what address your train is between those two steps)
There are two work arounds for this.
Workaround #1:
Switch CV29 to use the short address.
Reprogram CV17, and CV18 using the short address
Switch CV29 to use the long address again.
Workaround #2:
Take off all locomotives on the track except one being programmed
Set address to 0
try programming CV17, CV18
The second work around may or may not work for certain brand decoders. It is not gaurenteed.
That said, your booster is NOT a bad purchase. It will mak
I don’t know who “Mr. DCC” is, but he is wrong about the problem being Digitrax’s program track not conforming to NMRA recommended practices. You can’t really say that either the decoder or the command staion didn’t comply, because initially there was some ambiguity in the specs - the NMRA recommended “limited energy” for service mode programming, but did not specify what qualified as limited energy (they have since upgraded the spec to define limited energy). The fact is, however, when Tsunamis were first introduced, several command stations would not program them on the program track(certainly not just Digitrax), so I feel the fault is with the Soundtraxx because they apparently did not test them with a variety of command stations.