Actually, when you program CV1, according to the NMRA Standards and Recommended Practices, the decoder is supposed to automatically reset CV 29 bit 5 (and clear the consist address if it is set). I can’t say with absolute certainty that they all do, but they are supposed to.
That has not been my experience.
In the QSI Quantum DCC Ref Manual, there is the following statement:
Remember to change bit 5 of CV 29 to “0” to enable the Primary Address.
QSI must have included that reminder for a reason.
Besides, what’s the harm in checking the value of CV 29?
Rich
The CC unit experiences intermittent failure to read CV values. It won’t read individual bit values for you. I’m pretty sure you need Lokprogrammer or Decoderpro to actually read bit values.
I am learning a bit more about how DCC addresses locomotives. Apparently ESU uses a sort of spoof system. Railcom assigns an ID number that is not the actual DCC address but a representative number starting at 1000 (this start number can be altered). When assigning a “real” DCC address to a non Railcom equipped decoder the display shows this address as a four digit number with two or three zeros preceding any two digit number even if the real address has no preceding zeros.
The DCC address menu item does not work with the QSI decoders including the BLI Paragon “versions” of QSI (it seems BLI now uses their “own” proprietary decoders which are as different to QSI decoders as it is possible for the lawyers to make them, without actually changing much).
Anyway, once the decoder is accepted by the CC everything is just hunkie dory. So, several of my old decoder equipped locomotives will retain just two digit addresses. The CC doesn’t find the locomotive using the address anyway, you just select the name you gave it and the CC locates whatever actual DCC address it assigned. You never need to know the actual address until you wish to program on the main. The address you use is whatever the CC says it is at the bottom left corner of the screen for that locomotive.
TCS decoders seem to play nice with the CC and so far my preference is to use decoders from ESU or TCS. So we’ll see how things go. I’m focussing on just laying track over the next few weeks.
I do appreciate the feedback and replies, for the most part. One post refers to the benefits of these “conversations” but at the same time expressed discontent with the way this thread (and others involving me) went. I refrained from replying at the time as,
OK, so if I understand you correctly, the ESU CC system will not tell you the value of CV 29. Since QSI reminds the user to set bit 5 to zero when using 2-digit primary addresses in CV 1, you could simply reduce the value of CV 29 by 32. But, maybe the system does not allow you to even do that.
I know that you are committed to the ESU Cab Control 50310, so I will spare you from reading my NCE recommendation for the third time. But, honestly, I really think that you have to be frustrated by what I consider the shortcomings of the ESU system. The ESU Cab Control 50310 seems to operating so differently from other manufacturers DCC systems, and not for the better IMHO.
Nothng, of course, and that would be the first thing to check if programming a primary address doesn’t work, that’s why I said “I can’t say with absolute certainty that they all do.” Maybe I didn’t word it clearly, but my point was that you should not have to program it manually, not necessarily that you would not have to.
That’s why I asked if ESU has a decoder setup like NCE does. I use that exclusively for initially addressing all my decoders. After that I go into CV29 and make sure that BEMF and 128 steps is enabled and DC (dual mode) is disabled.
Tom
C’mon. Talk about semantics!
The only reason that I raised CV 29 in the first place was to offer a suggestion to the OP as to the possibility of why he was getting those error messages. Maybe it was the CV 29 value, maybe it wasn’t. Who knows?
It wasn’t idle speculation on my part. It seemed logical that CV 29 could be the problem. I see no reason to delve into the ‘should not haves’ and would not haves’ of the issue. If the OP can read the value of CV 29, what is that value? One of those error messages does read “Address Conflict”.
[quote user=“richhotrain”]
Lastspikemike
Entered my newly acquired QSI equipped MP-15 DC today. Same weird inconsistent behaviour. Entered it as address 3 and it ran fine. Tried to change CV1 to 41 and got the weird voice confirmation “CV 1 41” and the “programming failed” message. Locomotive no longer responded to address 3 but clearly powered up. “Address conflict” oops. Went back and tried to change CV1 to 14 (open address slot) with no effect. Tried programming track and DCC address function. No success.
I am talking in Greek here because I am unfamiliar with the ESU unit, but what is the value of CV 2
For clarity I do know how to calculate and enter CV values from the decimal number components in look up tables. I dare say I could eventually figure out hexadecimal. I was an outstanding mathematics, physics and chemistry student before throwing all that talent away on my professional career. Mind you the 99% of lawyers who are not and never have been any good at science and maths get steam rollered when the case involves even a passing understanding of those areas of knowledge. It’s fun to surprise the accountants, engineers and scientists when they think they can buffalo their way through a cross examination. Not.
The Tech 6 allows you to change the value of any CV on any decoder I’ve run across but you can only tell it’s done so correctly by the performance of the locomotive.
The CC will also allow me to change CV values and read them which is handy. So far only QSI decoders present a challenge to the CC. I think even Lokprogrammer and Decoderpro aren’t fully QSI transparent but I’ve not acquired either of those. Under the circumstances it is highly amusing to hear the QSI decoder announce robotically the new value you just put into a CV concurrently with the CC informing you that the programming failed. The subsequent behaviour of the locomotive confirms that the programming in fact succeeded. Just not always with a QSI decoder.
I am very pleased with the CC. My troubles all originate with the inadequacies of DCC in general and older decoders specifically, as I’ve come to expect and complained about at some length here and elsewhere. It is obviously very difficult to create a decent and modern interface for DCC which is unfortunate but unsurprising.
I sure wish that the forum software had a white flag emoji. I would raise it at this point. Determining the proper value of CV 29 is about as fundamental to DCC as it gets. [*-)][%-)]
By the way, when I browse through the ESU Cab Control manual, on page 12, Section 10.2, Manual CV Programming, a screen is provided to read and write the values of CVs such as CV 29.
Yet I, along with many others have no troubles caused by these “inadequacies.”
There is a CV 29 calculator here:
http://www.2mm.org.uk/articles/cv29%20calculator.htm
All one has to do is click the desired boxes and read the answer.
Rich, you are a lot more patient than I. Reading around the edges of this thread, it appears that the OP is more interested in something else, and what that is seems to be currently undetermined.
maxman, I wondered the same thing. So, I went back and read each and every post made by the OP in this thread. It was then that I realized that he is not asking for suggestions, help or advice, not even once. Each post seems to be a stream of consciousness about what works and what doesn’t work with the ESU Cab Control 50310, the inadequacies of DCC and his dislike of QSI decoders. So, now, I wonder why I took the time to try to help him.
Rich
It might be instructive to remember what that ‘reducing the CV by 32’ means in context.
The CV is a binary number, but the system can use positional ‘bits’ as flags in a string, a binary 0 meaning one thing and a binary 1 something else. This completely different from the representation of a number as powers-of-2.
The binary string can certainly be converted to hexadecimal (which is just replacing every 4 binary digits by its hex numerical equivalent) or decimal… in so doing, losing the link with the flags. On the other hand, subtraction of a power of 2 flips the corresponding bit in the string… which if it were assigned as a flag position eould toggle just that value and no other. If you remember that binary 1 counts as a ‘power of two’ it will help you calculate the ‘decimal subtraction’ that flips a particular value without randomly resetting a buncha stuff ‘as if by magic’… which is what subtracting anything other than a power of 2 from the decimal version of one of that kind of CV would do.
Of course none of this should be necessary these days.
To operate a train in DC mode requires two wires and a throttle knob…
Then stay with DC. A number of well respected posters are DC and like it They have made a choice to stay with DC. DCC is great. DC is great. Just make a choice and stick with it. Move along. End this continuing soap opera of a topic and build your layout.
Spike, you are not the first person to complain about the poor DCC human interface or the limitations of the old technolgy it is built around. A very knowledgeable friend of mine in one of my other hobbies - the GRAVELY tractors - decided to take up model trains a few years back - he said the same things about DCC you are saying, and I have similar views.
But the facts I have already pointed out are not going to change. This hobby is too small, and most of those in this hobby will not spend money to replace systems they have spent years (or decades) installing and learning.
So don’t hold your breath for some better system.
I have watched the full developement of control systems in this hobby from 1968 to now, and studied many advanced DC systems that date back well into my childhood and before.
We each pick our poison based on a number of complex factors.
From my perspective, my DC advanced cab control is easier to use than DCC, with less to learn as a “user”. But it is considerably more complex to design, apply and build, unless you are doing signaling with your DCC, then it is likely a tie.
One BIG problem, that I have largely given up talking about on this forum, is that many modelers, especially those “newer” to the hobby, don’t really know what their operational goals for the hobby are.
My system is build around my goals. Goals that did not change when DCC was introduced, goals that did not change when sound was introduced (for the record, onboard sound came LONG before DCC) and goals that are not subject to whim because of what others are doing or new products that “pop up”.
For many DCC is perfect, and I expect it to remain the choice of most new modelers for t
You brought this upon yourself. If someone cannot figure out how to post a picture, there is no way they can figure out CV values.
I did get a good hearty chuckle from the self-ego stroking of courtroom genius in an electric train forum.
I might make that self-idolizing rant into my desktop background image.
[(-D]
-Kevin
It’s not.
This is the most sage advice on the entire thread, and exactly my sentiments. Stick with DC.
The OP has purchased a DCC system that he obviously does not know how to use, has no idea what DCC is all about or how it operates, and seems to have a preconceived bias against DCC in spite of the fact that he has purchased a DCC system.
Honestly, spike has had issues with DC as well. (See the Atlas Controller discussion) Maybe he needs to look into battery onboard w/ radio control.