开云体育

Did a DecoderPro install today for a friend, and he immediately ran into
confusion on Digitrax and Lenz decoder models. He had a factory installed
Digitrax DN146 decoder and a factory installed Lenz LE063. Neither of these
types is in the decoder list in the current version of DecoderPro. After
checking both mfrs websites tonight, I concluded that the DN146 has the
same functions as the DN142, and the LE063 has the same functions as the
LE062, both of which are included in DecoderPro.

You can see how confusing this would be to a new user though. I can't find
anything about the CV07 values on the mfrs websites, so I have no idea if
the ID for the DN146 is the same as the DN142. I was somewhat confused by
the explanation on the Digitrax site for the 5th character (3rd digit) in
the model number. They talked about series 1 and series 2, and then fx3
products, but then a DN141 seems to be the same as a DN142 so I don't know.
At least Lenz stated that decoder models that differ in number by 1 are the
same thing, just with different connectors.

I think at a minimum the decoder names in DecoderPro ought to be looked at.
Maybe LE062/3 or something? Not sure what would work for Digitrax -
DN142-DN146?


Robin Becker
Tucson, AZ

The DN-146A program wise is the same as a DN-140. The DN-142 has
transponding and back emf that the 146 and 140 do not have. Program wise
the DN-144K, 145K,146A,147A & 148K are like a DN-140. While the DN-149K2,
141K2 and 141E2 are like a DN-142. The -163 decoders are another set of CVs
to be programmed.

Programming wise the Lenz/Atlas LE-062 and LE-063 are the same.

Michael Mosher
Webmaster
Daylight Division PCR/NMRA www.trainweb.org/daylight
San Luis Obispo Model Railroad Club www.trainweb.org/slomrc
Personal www.ncinternet.net/~mmosher
Member
Golden Empire Model Railroad Club www.gemerc.homestead.com
Kern County Live Steamers www.trainweb.org/kernctyls

Michael,

Thanks. I don't see a DN140 in the DecoderPro set at this point.

For reference, can you point me to where on the Digitrax site this is all
spelled out?

Robin

Robin,
In my version I have a DN140 and a couple of DN142's. Looks like a
little housecleaning is in order<G>.

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

This just was posted on the Digitrax list, useful information!

Out of production Digitrax decoders are listed at



Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

Thanks Jon!

Ok, so how should the decoder name appear in the list when multiple decoders
have the same CV07 value?

My suggestion is that if the models have the same features, i.e. DN140,
DN144, DN145, DN146, DN147, DN148, then they should show up as _one_ entry
in the decoder list with some kind of generic name. Something like DN14X,
or DN140/144/145/146/147/148 or DN140/4/5/6/7/8 or ? This way when you use
IDENT the reported decoder type will at least include the number you expect.

If the models have different features but the same CV07 value, like all the
NCE decoders that report CV07-32, maybe their should be a flag in the
decoder file or the CV07 value should be omitted from the decoder file so
that IDENT can report the manufacturer name along with a message that the
model cannot be determined?

Robin Becker

Because with some manufactures CV7 isn't going to always tell much maybe
the DN14(x) concept would be good. The tabs (panes) for that group could
then be asterisked with the comment, "not all of this family has this
function". That way the user could at least get this information from the
data sheet. We must assume at least a little reading is required! This
would also work with the newer decoders, of the same family, that are going
to 5 or 6 functions.

CV07 value should be omitted from the decoder file so that IDENT can report

the manufacturer name along with a message that the model cannot be
determined?<
This seems to be a reasonable idea, at least something to think about.

I think there are several causes of confusion that are really different. Maybe it would help to think about them seperately?

a) "The Ident button picked the wrong decoder!"

Some of these are problems in the definition files, and we just have to fix that.

Some of these are due to the way that we present the results of the attempted identification. The result of the identify operation is a list of decoder types, sometimes a really long list. With the current user interface, only one shows unless you click that one to extend it. Some people don't know there are more values there, and get confused.

One way to solve this is to show the results in a more verbose widget. Maybe a scrollable list of decoder names, with up to 10 showing? That would make it clear that there are multiple choices, because you could see the alternatives. The scroll bars would make it clear what to do to see the rest of them if the list is too long. You'd select one by highlighting it.

b) "My decoder isn't on the list!"

That's really two cases, which I think it important to separate:

b1) "My decoder isn't on the list! And you identified this other one instead!"

That's a lot like case (a) above. The happens when the manufacturer has a lot of similar models, and uses the same CV version number to identify several, and we haven't added the specific decoder model to the definition file.

Generally, you can still program successfully if you just tell the program to use the similar decoder that has the largest number of outputs. This is where the idea of the "family" comes in. Digitrax has a number of "FX decoders" that differ in size/shape, current capacity, number of outputs, etc. But the CVs are really the same (except for those that don't matter when certain outputs are not present).

If the user knows the basic type ("Oh, this is an NCE Silent Running decoder, that will do!") and has a way to select that, things will go OK. We don't have to have any confusing "family" terminology appear, we just need to give them a way to understand that their decoder will probably program OK.

So I suggest that the top entry in the list of identified models be something like "General <name here> decoder", e.g. "General Digitrax FX decoder", "General Lenz BEMF decoder", "General SoundTraxx DSD Steam decoder", etc. That would then be what's selected when the list pops up after an identify. The user can look for a more specific model number, and if it's not found just go with the general one. (Maybe somebody can think of a better word than "general"? "Generic" sounds too medical, "Basic" might give the wrong impression, and those were the only ideas I had)

That would also allow us to make the entries in the decoder list alphabetical (within manufacturer). Right now, I put the "most general", usually the one with the most outputs, at the top of the list, and I agree that's confusing.

b2) "My decoder isn't on the list! In fact, you didn't identify any model at all!"

This means that we really don't know much about this decoder, as the CVs didn't match any file. And I'm not sure what to do here. The user might want to try the standard NMRA CVs, or another decoder from this manufacturer.

In this case, I'd like to gather some information from them. I think it would be useful to know what the CV7/CV8 values are, and what (if anything) the user knows about this decoder. So it might be fun to pop a little window that requests permission to send an email with the CV values, and gives the user a little box to enter what they know about the decoder. We could send the mail to a sourceforge alias that accumulates them so we know what decoders are missing, and gather the CV values to make things work better.


c) "It didn't find anything at all!" This can happen if there's a problem reading, in which case wierd stuff happens. That's something that I just have to make more robust in the code. Mark suggested a button above the two Ident buttons called "Check loco connection" or similar that reads CV3 to make sure we _can_ read CVs. If a value of 255 or 0 is found, or the command station reports an error, it's clear that Bad Stuff Has Happened, and we can prompt them through some troubleshooting steps...


Are there other cases?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

One way to solve this is to show the results in a more verbose

widget. Maybe a scrollable list of decoder names, with up to 10
showing? That would make it clear that there are multiple choices,
because you could see the alternatives. The scroll bars would make
it clear what to do to see the rest of them if the list is too long.
You'd select one by highlighting it.<

Sometimes these problems can be solved with instructions and/or
training. As I think my clinic proved just a little time with DecoderPro
and it becomes very easy to use. The concept between trying to identify
what is in the engine vs just selecting the decoder doesn't become a large
problem. Of course if you just bought an engine and want to know what's in
it then that becomes a different matter.
The problem of the famous 255 reading (and other happenings) is not
unique to DecoderPro even throttles will do that. I think instructions or
text can work here. Of course I'm like everyone and don't read stuff
either<VBG>.
The small group that was at my house quickly adapted to which list to
pull down. Maybe I'm getting a little political here but it seems to me
that the time needs to be spent on areas that tend (and here is where IMHO
comes in) to need a lot of help. Having DecoderPro work with the MS100,
which I think is probably not an easy job. Getting more decoders in the
list. Tying the decoder listings to families.
Now I'm sounding like a ***! Seriously though, thoughts
on this. It's ok to tell me to go back to my cage!

Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS

Bob:

Would "Typical" work for "General"?

Jim Hanna