Add ESU Car-Interior lighting strip with integrated Digital decoder #1724

Merged
merged 9 commits into from Aug 2, 2016

Conversation

Projects
None yet
3 participants
@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 1, 2016

Contributor

Not done yet = recreate decoder index.

Contributor

AlanUS commented Aug 1, 2016

Not done yet = recreate decoder index.

@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 1, 2016

Contributor

@AlanUS
Thanks for getting this going.

Since there are thousands of part numbers for ESU decoder variations (both connectors and sound projects numbers), none of which are identifiable from either the LokProgrammer software or JMRI, and because of the way I intend to handle this (and interaction with LokProgrammer) in future, I am reducing the models available in JMRI to only those distinguished by LokProgrammer software, and using exactly the same naming convention and identification technique (ProductID is read from the decoder and mapped directly to a single model name).

LokProgrammer recognises only one model "ESU digital interior light" with a Product ID of "16777316". ESU places this decoder in the category "Misc.", along with test coaches and smoke units. My recommended Family name would be either "ESU Miscellaneous" or "ESU Miscellaneous decoders".

I'll have a look at the rest of this a bit later.

Contributor

dheap commented Aug 1, 2016

@AlanUS
Thanks for getting this going.

Since there are thousands of part numbers for ESU decoder variations (both connectors and sound projects numbers), none of which are identifiable from either the LokProgrammer software or JMRI, and because of the way I intend to handle this (and interaction with LokProgrammer) in future, I am reducing the models available in JMRI to only those distinguished by LokProgrammer software, and using exactly the same naming convention and identification technique (ProductID is read from the decoder and mapped directly to a single model name).

LokProgrammer recognises only one model "ESU digital interior light" with a Product ID of "16777316". ESU places this decoder in the category "Misc.", along with test coaches and smoke units. My recommended Family name would be either "ESU Miscellaneous" or "ESU Miscellaneous decoders".

I'll have a look at the rest of this a bit later.

@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 1, 2016

Contributor

@AlanUS
The link below is the current model and ProductID listing, copied by me from the Tools->Supported Decoders menu item of LokProgrammer V4.4.23. This matches exactly the list available with the File->New project... Menu in LokProgrammer. I update this document as each new release comes out.
https://www.dropbox.com/s/a49jw81vjyr5p2b/ESU%20Data.xlsx?dl=0

Contributor

dheap commented Aug 1, 2016

@AlanUS
The link below is the current model and ProductID listing, copied by me from the Tools->Supported Decoders menu item of LokProgrammer V4.4.23. This matches exactly the list available with the File->New project... Menu in LokProgrammer. I update this document as each new release comes out.
https://www.dropbox.com/s/a49jw81vjyr5p2b/ESU%20Data.xlsx?dl=0

@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 2, 2016

Contributor

@AlanUS
I asked ESU whether multiple ProductIDs within a model mapped to different physical (e.g. connector type) or other user-significant features. I was told multiple ProductIDs simply designated minor hardware revisions throughout the production runs of a particular model.

Contributor

dheap commented Aug 2, 2016

@AlanUS
I asked ESU whether multiple ProductIDs within a model mapped to different physical (e.g. connector type) or other user-significant features. I was told multiple ProductIDs simply designated minor hardware revisions throughout the production runs of a particular model.

@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 2, 2016

Contributor

@dheap
OK will rename the family to "ESU Miscellaneous decoders".
So you would prefer one single entry for the 2 physical variants of the LED bar (warm-white and yellow) because there is a single SW product code for it?

I actually created two different entries with the same product code (ProductID), which is what we used to do e.g. for Digitrax decoders where a single SW release (in CV7 for Digitrax) corresponds to multiple form-factors. As a user I appreciate to have the exact reference of the decoder even if it cannot be discriminated by product or release (CV7) version, and therefore creating multiple hits with the identification function. In the present case, as ESU is offering a much more precise way to identify, the hit would be limited to 2 entries, which I think is perfectly manageable for any user. And there wouldn't be additional variants, as this is not a decoder where users can download their own projects.
So I think this case is slightly different than the sound decoders for which you cannot, at the time being, afford to add all possible projects' variants.

Contributor

AlanUS commented Aug 2, 2016

@dheap
OK will rename the family to "ESU Miscellaneous decoders".
So you would prefer one single entry for the 2 physical variants of the LED bar (warm-white and yellow) because there is a single SW product code for it?

I actually created two different entries with the same product code (ProductID), which is what we used to do e.g. for Digitrax decoders where a single SW release (in CV7 for Digitrax) corresponds to multiple form-factors. As a user I appreciate to have the exact reference of the decoder even if it cannot be discriminated by product or release (CV7) version, and therefore creating multiple hits with the identification function. In the present case, as ESU is offering a much more precise way to identify, the hit would be limited to 2 entries, which I think is perfectly manageable for any user. And there wouldn't be additional variants, as this is not a decoder where users can download their own projects.
So I think this case is slightly different than the sound decoders for which you cannot, at the time being, afford to add all possible projects' variants.

AlanUS added some commits Aug 2, 2016

Update ESU Car-Interior lighting strip with integrated Digital decoder
- change family name to ESU Miscellaneous
@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 2, 2016

Contributor

@AlanUS
I took out all the form-factor related models in the range because we were getting complaints about multiple matches, with users being confused which one to pick, they are identical in all programming features and LokProgrammer software makes no such distinction.

I also took the decision to match the model names exactly to the ESU model names, not only for maintenance reasons but also to make the linkage between LokProgrammer and JMRI as seamless as possible, particularly on the LokSound users group, where it is advantageous to be able to give instructions applicable to both platforms.

ESU LCC USA is very supportive of JMRI and wants us to make things as seamless as possible, for support reasons.

Breaking the nexus on model names (and introducing artificial model name distinctions) gives no benefit to users, increases complexity and goes against what I have been seeking to do - make life easier and less confusing by reducing user decisions and matching ESU nomenclature, documentation and software.

Contributor

dheap commented Aug 2, 2016

@AlanUS
I took out all the form-factor related models in the range because we were getting complaints about multiple matches, with users being confused which one to pick, they are identical in all programming features and LokProgrammer software makes no such distinction.

I also took the decision to match the model names exactly to the ESU model names, not only for maintenance reasons but also to make the linkage between LokProgrammer and JMRI as seamless as possible, particularly on the LokSound users group, where it is advantageous to be able to give instructions applicable to both platforms.

ESU LCC USA is very supportive of JMRI and wants us to make things as seamless as possible, for support reasons.

Breaking the nexus on model names (and introducing artificial model name distinctions) gives no benefit to users, increases complexity and goes against what I have been seeking to do - make life easier and less confusing by reducing user decisions and matching ESU nomenclature, documentation and software.

AlanUS added some commits Aug 2, 2016

Update #2 ESU Car-Interior lighting strip with integrated Digital dec…
…oder

- one single mode for all references
@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 2, 2016

Contributor

@dheap
So let's stick to what you have implemented for other ESU decoders: only one model for both (current) references of the LED strip. Modification committed.
Model name "Car interior lighting" under family "ESU Miscellaneous decoders"
I don't have a LokProgrammer, so cannot check the naming convention. All CVs names are as per the existing documentation for this model (both in English and in German).

Contributor

AlanUS commented Aug 2, 2016

@dheap
So let's stick to what you have implemented for other ESU decoders: only one model for both (current) references of the LED strip. Modification committed.
Model name "Car interior lighting" under family "ESU Miscellaneous decoders"
I don't have a LokProgrammer, so cannot check the naming convention. All CVs names are as per the existing documentation for this model (both in English and in German).

@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 2, 2016

Contributor
Contributor

dheap commented Aug 2, 2016

@rhwood rhwood merged commit c4c4a48 into JMRI:master Aug 2, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@rhwood rhwood added the Enhancement label Aug 3, 2016

@rhwood rhwood added this to the 4.5.2 milestone Aug 3, 2016

@rhwood

This comment has been minimized.

Show comment
Hide comment
@rhwood

rhwood Aug 3, 2016

Contributor

@AlanUS Can you provide a comment for the release notes?

Contributor

rhwood commented Aug 3, 2016

@AlanUS Can you provide a comment for the release notes?

@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 3, 2016

Contributor

@rhwood
To use the exact terms of ESU website:
"Added ESU Digital LED lighting strip with integrated Digital decoder (Alain Le Marchand)"

Contributor

AlanUS commented Aug 3, 2016

@rhwood
To use the exact terms of ESU website:
"Added ESU Digital LED lighting strip with integrated Digital decoder (Alain Le Marchand)"

@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 3, 2016

Contributor

@dheap
I installed the LokProgrammer software and did what you suggested. Actually there are additional CVs for this decoder that are listed in LokProgrammer but not in documentation (CV13, 14 analog mode and CV21, 22 consist). Decoder version is 208 (and not 255).
RailCom CVs are not listed.
Shall we trust LokProgrammer or the documentation?

Contributor

AlanUS commented Aug 3, 2016

@dheap
I installed the LokProgrammer software and did what you suggested. Actually there are additional CVs for this decoder that are listed in LokProgrammer but not in documentation (CV13, 14 analog mode and CV21, 22 consist). Decoder version is 208 (and not 255).
RailCom CVs are not listed.
Shall we trust LokProgrammer or the documentation?

@dheap

This comment has been minimized.

Show comment
Hide comment
@dheap

dheap Aug 3, 2016

Contributor

@AlanUS

I installed the LokProgrammer software and did what you suggested. Actually there are additional CVs for this decoder that are listed in LokProgrammer but not in documentation (CV13, 14 analog mode and CV21, 22 consist).

Trust LokProgrammer.

(For new items, compare similar Panes side-by-side in both LokProgrammer and JMRI so we match pane location, listing order on pane and item names where practical. Makes user support advice easier.)

Decoder version is 208 (and not 255).

We'll need to find someone with an actual decoder to do either an "Extended Decoder Information" in LokProgrammer and send us the results or "Read Type from Decoder" in JMRI and copy the resulting line in JMRI system console to send to us. (I may also have to modify the Identify Decoder methods in the Java code.)

RailCom CVs are not listed.

If you are talking about the RailCom Setting Options, trust LokProgrammer.

If you are talking about the actual RailCom CVs page as per NMRA S9.3.2 (CV0.255.0-255), these are never shown explicitly in LokProgrammer (the information is shown in "Extended Decoder Information").

I'll see if I can get hold of an actual decoder.

Dave

Contributor

dheap commented Aug 3, 2016

@AlanUS

I installed the LokProgrammer software and did what you suggested. Actually there are additional CVs for this decoder that are listed in LokProgrammer but not in documentation (CV13, 14 analog mode and CV21, 22 consist).

Trust LokProgrammer.

(For new items, compare similar Panes side-by-side in both LokProgrammer and JMRI so we match pane location, listing order on pane and item names where practical. Makes user support advice easier.)

Decoder version is 208 (and not 255).

We'll need to find someone with an actual decoder to do either an "Extended Decoder Information" in LokProgrammer and send us the results or "Read Type from Decoder" in JMRI and copy the resulting line in JMRI system console to send to us. (I may also have to modify the Identify Decoder methods in the Java code.)

RailCom CVs are not listed.

If you are talking about the RailCom Setting Options, trust LokProgrammer.

If you are talking about the actual RailCom CVs page as per NMRA S9.3.2 (CV0.255.0-255), these are never shown explicitly in LokProgrammer (the information is shown in "Extended Decoder Information").

I'll see if I can get hold of an actual decoder.

Dave

@AlanUS

This comment has been minimized.

Show comment
Hide comment
@AlanUS

AlanUS Aug 5, 2016

Contributor

Alignment with LokProgrammer: see #1744

Contributor

AlanUS commented Aug 5, 2016

Alignment with LokProgrammer: see #1744

rhwood added a commit to JMRI/website that referenced this pull request Aug 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment