Bob,
We need a "Test for Decoder" window/Step/Button.
Here's the problem
When someone brings up Decoder Pro, one of the most common problems is
making sure the decoder is working on the programming track. People
start with simply putting the engine on the engine and start with the
ASSUMPTION everything is working. Many times during startup there are
problems especially with new decoder installations. The other is that
sometimes during programming,, the locomotive physically moves only to
die on me because of dirty track. But the user may not know that and
naturally move on. The other is the programming current may be to high
and programmer station reports a Fault. Anyway, after they place the
loco on the programming track, they start to figure out which button "ID
for loco" or "ID for Decoder" to use. Because the "ID for Loco" is the
TOP button, most people not knowing what to do try that button first.
Nothing wrong with that. But in this case the program does not find the
locomotive because the decoder is not working, but they do not know that
it is NOT working. Not getting results they thought they would get, they
next try "ID for Decoder" to see if that will work instead. Again no
results but the system says it cannot identify the decoder brand when in
fact it got no response. So the explanation is incorrect and starts
people down a confusing path. Some go ahead anyway since most people
have no idea what they should see and proceed not understanding the
values they are getting reported are completely bogus. Reading a value
of 255 is usually a good sign that a decoder is NOT there. The point is
that they get lost and the decoder does not get programmed leading to
frustration.
In other words, because the decoder is not working, people start going
off in other directions only to get lost. Most experience users figure
out very early on that there is something wrong with the engine and are
able to correct the problem since we have an idea of what we should see.
So here is what I propose. When the user "clicks on" open programmer
button from the splash screen, a new top floating screen is shown above
the normal ID screen that is shown. At the top of this floating screen
is the title "Looking for a working Decoder". At the bottom are three
buttons.
1) Quit. Exits and goes back to splash screen.
2) Retry. Redo the test assuming the locomotive has been fixed by the
user.
3) Proceed Anyway. This tell the programmer to ignore all errors. We
need this for those decoders that draw to much power but can be
programmed anyway. Choosing this option essentially defeats all this
decoder reading checking process until the current session is closed. In
fact I would think that the READ button would ALSO be disabled with this
option since reading will only generate more errors. Of course a note
will pop up telling the user the consequences of choosing this option.
Anyway...
The program automatically goes into what every programming mode is
necessary and reads the decoder Manufacture ID looking for any value
other than 0 or 255. This is done 3 times in a row. If you get a value
of 0 or 255 at any time, then the decoder is considered not working and
reports that to the uses then allowing him to go check the locomotive and
retest until a favorable report is received. Once a favorable report is
received, Decoder found statement is shown for a moment and the screen
automatically goes away and the normal ID screen is presented. If not,
then the user is asked to check that:
A) the locomotive is seated correctly on the track.
B) the locomotive wheels and Programming track are clean.
B) DCC mode is enabled (Some decoders have a DC or DCC mode jumper like
Atlas)
C) The decoder is actually connected properly. Check for lose open wires.
If the system reports a short, then the screen should say a short has
been detected.
A) Make sure all Function lights are off or disconnected if the run from
track power.
B) Any other electrical accessory (Smoke Generators) are disconnected if
the run from track power.
C) Check to see if the locomotive is seated correctly on the track.
D) There are no lose uninsulated or pinched wires inside the locomotive
You get the idea, but there is more
On every normal programming window pane, there is a new "DECODER STATUS:"
Status line. Possible sharing the same space as the Programming status
line. The status line has 4 values displayed
1) "OK" in green or white if no errors are recorded
2) "UNKNOWN" status in Yellow if any single CV values reports back as
255. If the next CV read is not 255, then it changes back to "OK"
3) "FAILURE" in Red if more than one CV reports 255 one after the other.
4) "IGNORE" in green or white. This appears ONLY if the "Proceed Anyway"
button is pressed on the "Looking for a working Decoder" window.
The CV checking process does not interfere with the current activities,
but does give the user confidence about what is going on. A watchful Eye
so to speak. With this report the user is now informed about the decoder
and has the option of going to the bottom of any window pane where they
can find a button called "Test Decoder". When a person suspects that
there is something wrong, clicking this button allows them to suspend the
current programming session and bring back up the "Looking for working
Decoder" test screen again. When operation is restored, the user goes
back to where they left off. In fact you may want to suggest that they
reread current window values to verify all is correct.
I really think this would be a big differentiating feature that make your
program even better. Be able to program in confidence addresses one of
the most intimidating things about DCC.
That the big Idea. I leave it up to you to figure out how to do it.
Different subject. We talked about a progress bar. I think a temporary
form of a progress bar would be in fact be a Elapse Timer instead. Every
time Decoder Pro is waiting for a response, the timer keeps counting up
the time in seconds starting from zero. When the response comes back, the
timer is reset. This also gives the user a sense of how well the
programming is going. Things that take longer then normal can sometimes
be a clue to something is wrong. An expansion on this timer function
would be a timer that keeps track of the elapsed time for the ALL READ
and ALL WRITE commands from start to finish. Sort of a bench-marking
capability indicating total system speed. It would also allow people to
see what effects a change, hardware or software, effected his system.
Best Regards,
Mark Gurries
Linear Technology
Power Supply & Battery charger Applications Engineer/Manager
---------------------------------------------------------
Model Railroad Club and NMRA DCC presentations are at:
--------------------------------------------------------
Audio Enthusiast (Love SAE equipment)
----------------------------------------------------------
