开云体育

Jon,

You are correct, I missed the DN140 in the decoder list. This was certainly
operator error on my part, but that aside the sort order of the decoder list
is another thing I've been meaning to bring up. I think it should be
alphabetical within each mfr's block.

Robin

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 don't have any real ideas about how to better identify decoders. I agree it's a mess, and will be happy to implement whatever you guys think is best.

Mark Gurries made a suggestion a while back that I think would help with the user interface. He suggested that, instead of a single long list of decoders that's ordered by manufacturer, that we split it into three selection boxes:

(Mfg) (Family) (Model)

When you pick a particular item in the "Manufacturer" box on the left, that will restrict the other two to just that manufacturers families and models. If we auto-identify the manufacturer, that also does the restriction, so people just see the ones from that manufacturer.

The "Family" one would then be things like "LC Steam" for Soundtraxx, or "FX Decoders" for Digitrax. The idea is to have them be "so close together that they basically all program the same". Even if you're not sure of the particular model, and the program can't figure it out, you'll probably not get in trouble.

And then the "Model" box would get down to the specifics, including the number of output wires on a specific model, etc.

So if somebody knew that they had a "PQ197PJ", they could look for that in the "Model" column. If they don't see it, perhaps because nobodies ever made a file for it, but know that it's from "Wizzo Co", they could select that under manufacturer (or maybe decoder ID would do that), and look at the families. They they might realize that it's a "CoolChip" decoder, select that family, and be close enough to function.

Does this sound like it could help?

Bob

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

Bob,

I think I suggested a similar approach that was simpler. The dropdown
decoder list just shows manufacturers, but then there are flyout menus for
each manufacturer that list the models. If you like the family apprach,
you could flyout the family menu from the manufacturer instead, then have
the models flyout from the family. This advantage of this approach over
Mark's is that there is no need to enter data manually ahead of time for the
mfr or the family.

Robin

I'm still getting my DCC system up and running; so, I'm not (yet) a
JMRI user; but, I work in the software development industry, so I'll
jump in and offer up my $0.02.

Perhaps what is needed is a simple search facility; so, if a specific
decoder is not listed, you could search for decoders that have similar
attributes (as listed on the mfg web site and/or the product
information supplied with the decoder). These attributes could
include (but not limited to)

* Manufacturer
* Power rating (1A, 1.5A, 2A, etc.)
* # functions
* FX
* Back EMF
* speed steps
* supported CV's
* etc.

Jon

'Family' seems like a rather confusing category. Dividing the list by
manufacturer is a good idea. In other words, I agree with Robin.

Mike

Bob,

What about by Manufacturer, Scale, Model

Example:

Digitrax, N, DN142

or

North Coast Engineering, HO, D13SR

Al Silverstein

CV8 seems to be the most reliable data but I'm not sure what they do
when a decoder is subcontracted like say Digitrax makes a decoder for Atlas
or similar.
One of the very large problems I see with anything that is done is the
availability of programmers. We have very few and need to recruit
more<VBG>.
I see we have another Jon (I like that name<G>). Jon, as you work in
the software development industry do you fit in the above needed category?


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

Jon, as you work in the software development industry do you fit in

the above needed category?

Unfortunantly, I'm not a Java Developer. Actually, I don't get to
develop code much at all these days - I've evolved into more of a
"Professional Meeting Attendee" and "Creator of Pretty Charts and
Diagrams".

One thing I am interested in trying is to port JMRI over to the PalmOS
platform (using IBM VisualAge/Java Micro Edition); although, I don't
know how successful this kind of endeavor would be.

Jon Davis

At 9:54 AM -0700 5/31/02, Robin Becker wrote:

Bob,

Jim Hanna found that IDENT didn't work for NCE decoder. Checking into this,
I found that the NCE name is used differently in the decoderIndex and the
decoder files. In decoderIndex.xml, it is shown as "NCE Corp" but in the
NCE_D13SR.xml file is is "North Coast Engineering". Once Jim changed the
decoder file to read NCE Corp and then reindexed, IDENT "worked" fine.

Thanks for catching that! I've fixed the originals.

I put worked in quotes because every NCE decoder reports 32 for CV07! Jim
is going to call NCE and ask about this. Perhaps they use a different CV
for model info.

That's an example of a "family" of decoders. Jim Scorse uses the same micro-code for his line of "Silent Running" decoders. They all contain the same program, hence the same version number. The only thing that changes is the PC card, which can vary in shape/size, and have different numbers of function output transistors.

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

That's an example of a "family" of decoders. Jim Scorse uses the

same micro-code for his line of "Silent Running" decoders. They all
contain the same program, hence the same version number. The only
thing that changes is the PC card, which can vary in shape/size, and
have different numbers of function output transistors<

To my understand from John of TCS that's exactly what all TCS decoders
are, the same micro-code (except for additional functions in some). TCS
puts each change or fix in CV7 so their numbering goes 1,2,3, etc. I think
the latest version is 22 or 23.
Probably most all of the decoders manufactures do the same thing. I
know Digitrax did at one time, but then they made the DZ121 and all bets are
off<VBG>.

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

Digitrax is soon releasing the lower cost DCS050 and this unit has a
programming track. I am going to get one when they come out, probably June
or July. Depending on their specs. (it's not exactly known how they would
work with an EB) they might be a good combination with the EB which would
then give a programming track.

I've heard that it has a Chief-style programming track which can both read and write. That would be a really good alternative to the PR1, esp. if they can hit their price point. I'll be interesting in testing with one when they start to ship.

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

I've already ordered my Zephyr with the guy who did the obsolete
Digitrax list. He doesn't take CC's you need to send a check. I think this
is probably the best deal out there. Paste from his site below;



"Retail price $199.99. Litchfield Station???s price is $160 - POSTAGE PAID IN
THE USA! Until further notice, we will sweeten the pot with a FREE DH121
decoder with each Zephyr purchased. If you???d like another decoder, we???ll
allow $13 credit against our normal prices!"


My check went in a week or two ago! I plan to hook it up to a couple of
old (got a good buy) DB100a's for a secondary layout modules that are being
built for my new layout.

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

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet apps?
Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

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

My hunch is that this is an operating system rather than a hardware issue. PC
serial ports have been doing 56K for man years. I assume you're using
Windows. I know nothing about Windows so I can't help other than to suggest
looking at Windows rather than the laptop hardware. You might look at the
CMOS configuration too.

cheers,
Mike