I'm writing this because of the many many posts of people asking for help, and the difficulty to help them, even from "experts".
Out of courtesy, I would hope the moderators will keep the smart-ass "just use battery" comments off this thread.
It is indeed about helping people, not about thumping your chest that your way is the best way.
First, many many issues result from confusion on configuring the system and the decoder(s) in the loco.
Many many threads are "I cannot change this CV" or "I cannot read CVs" etc.
As an engineer, I learned the meaning of RTFM early on, "Read The Friggin Manual". I learned about the different modes of programming decoders and the use of individual bits in an 8 bit "word" to set features was a no-brainer as I also am a computer engineer, indeed I had to program some early computers in binary, a row of switches representing 1 or 0.
So, I did indeed have these advantages. Using different systems was simple, once I learned what command to enter the programming modes I wanted. I did indeed use a calculator create the decimal number for certain CVs, like the all importand CV29 and the long address CVs.
All was good in DCC land.
But clearly I was an exception, I did not throw a conniption fit when I was told to toggle a bit in a CV, but new users really had issues if they did not want to learn binary, and learn the programming modes.
It is completely natural that DCC manufacturers wanted to make things simpler for people with a user interface more like: "tell me the address you want for the loco", and then it would do whatever it needed to do. The concept is simple AS LONG AS YOU FOLLOW THE "RULES" FOR YOUR SYSTEM.
Now things get nasty when stuff does not work, because the user has no idea if they are programming on the main (during normal DCC operations and voltage) or the specialized "service mode" where the decoder is the only connection the the command station, and a different voltage, current, and programming interface is used.
A recent snafu on this forum proves this, an experienced installer had no idea that the DCC system was switching between Operations Mode and Service Mode while programming, actually using BOTH modes in the simple operation of writing and reading a CV.
Why is this a problem? because when things go wrong, without understanding the eccentricities of the particular DCC system, debugging problems may be impossible. This is made a mess by the fact that the DCC manufacturer, in the understandable effort to keep things simple does not tell you what it is doing. Some people term this information "irrelevant" because THEIR system works fine, so yours should too apparently.
Tell this to the guy with the problem.
Back to the problem: if you do everything exactly the way the manufacturer tells you, yes you don't need to know what goes on behind the scenes. But to debug the problem, without knowing, you have to have SOMEONE ELSE SOLVE IT FOR YOU.
I guess it is back to the user expectations. If you are OK that if it does not work as expected, you just throw money and/or time at the problem to solve it (ask the manufacturer and wait, or endless conjecture on the forums) or you can at least note how the "magic" in your system happens.
I guess there is not a good answer for everyone. For me I would rather expend the energy to learn a bit to solve the issue than just be handed the answer. For others, "just give me the answer" is what they want, and to depend on others.
I can understand that, but in my personal life, I give my friends just so many "free passes", and then insist they learn at least some of the basics. If they don't I tell them helping someone else with a new problem is a priority over helping them solve the SAME problem a 3rd time.
I guess there is not good answer for everyone, my mode has to be limiting, for my time and sanity, and I have to learn to not get frustrated with people with bad or incomplete information who refuse learn. It's their right, and you cannot help everyone.
End of rant, but still looking to help others, as I do every day.
Greg
Out of courtesy, I would hope the moderators will keep the smart-ass "just use battery" comments off this thread.
It is indeed about helping people, not about thumping your chest that your way is the best way.
First, many many issues result from confusion on configuring the system and the decoder(s) in the loco.
Many many threads are "I cannot change this CV" or "I cannot read CVs" etc.
As an engineer, I learned the meaning of RTFM early on, "Read The Friggin Manual". I learned about the different modes of programming decoders and the use of individual bits in an 8 bit "word" to set features was a no-brainer as I also am a computer engineer, indeed I had to program some early computers in binary, a row of switches representing 1 or 0.
So, I did indeed have these advantages. Using different systems was simple, once I learned what command to enter the programming modes I wanted. I did indeed use a calculator create the decimal number for certain CVs, like the all importand CV29 and the long address CVs.
All was good in DCC land.
But clearly I was an exception, I did not throw a conniption fit when I was told to toggle a bit in a CV, but new users really had issues if they did not want to learn binary, and learn the programming modes.
It is completely natural that DCC manufacturers wanted to make things simpler for people with a user interface more like: "tell me the address you want for the loco", and then it would do whatever it needed to do. The concept is simple AS LONG AS YOU FOLLOW THE "RULES" FOR YOUR SYSTEM.
Now things get nasty when stuff does not work, because the user has no idea if they are programming on the main (during normal DCC operations and voltage) or the specialized "service mode" where the decoder is the only connection the the command station, and a different voltage, current, and programming interface is used.
A recent snafu on this forum proves this, an experienced installer had no idea that the DCC system was switching between Operations Mode and Service Mode while programming, actually using BOTH modes in the simple operation of writing and reading a CV.
Why is this a problem? because when things go wrong, without understanding the eccentricities of the particular DCC system, debugging problems may be impossible. This is made a mess by the fact that the DCC manufacturer, in the understandable effort to keep things simple does not tell you what it is doing. Some people term this information "irrelevant" because THEIR system works fine, so yours should too apparently.
Tell this to the guy with the problem.
Back to the problem: if you do everything exactly the way the manufacturer tells you, yes you don't need to know what goes on behind the scenes. But to debug the problem, without knowing, you have to have SOMEONE ELSE SOLVE IT FOR YOU.
I guess it is back to the user expectations. If you are OK that if it does not work as expected, you just throw money and/or time at the problem to solve it (ask the manufacturer and wait, or endless conjecture on the forums) or you can at least note how the "magic" in your system happens.
I guess there is not a good answer for everyone. For me I would rather expend the energy to learn a bit to solve the issue than just be handed the answer. For others, "just give me the answer" is what they want, and to depend on others.
I can understand that, but in my personal life, I give my friends just so many "free passes", and then insist they learn at least some of the basics. If they don't I tell them helping someone else with a new problem is a priority over helping them solve the SAME problem a 3rd time.
I guess there is not good answer for everyone, my mode has to be limiting, for my time and sanity, and I have to learn to not get frustrated with people with bad or incomplete information who refuse learn. It's their right, and you cannot help everyone.
End of rant, but still looking to help others, as I do every day.
Greg
-
4
-
1
- Show all
