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)
Bob Jacobsen