-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Programming of Accessory Decoder on Main & Controlling on Programming Track #301
Comments
We have to think if I don't think that
Can you explain the difference? What have you implemented? Pull requests or just a github location with code is always welcome. Harald. |
A Turnout Decoder is a Simple Accessory Decoder. The format for an Extended Accessory Decoder has three bytes. The third bytes allowes to handle up to 256 states. See RCN-213, chapter 2.3. Programming of an Simple Accessory Decoder is described in RCN-214, chapter 2. Instead of 'aw' a new single character command can be used as well. I can change that if somebody tells me which character I should use. The comment in line 99 in DCCEXParser.cpp is saying 'This is a JMRI command parser.' But I could not find any reference of the JMRI commands. For controlling and programming of extended accessory decoders new commands are necessary too. The 'a' command can't be used for extended accessory decoders too as the number of parameters would be the same when using Address and Subaddress for a simple accessory decoder and Linear Address and State for the extended accessory decoder. With <1 JOIN> the A is indeed obsolet, I wasn't aware of that feature. |
I forgot to mention, I have also added linear addresses 2045 - 2048. They will be mapped on address 0 subaddresses 0 - 3. See RCN-213, page 5. Actually there is much more to do to support accessory decoders. That's why I choose a two character code. The format for simple accessory decoders is 10AA-AAAA 1AAA-DAAR where R is the output (turnout, but could also be two light outputs) and D is Activate / Deactivate. The current documentation is misleading as the R bit is references as Activation. Most turnout decoders have a fixed or via CV configurable activation time, so sending a Deactiviation is in most cases not necessary. But a new command is required to control the two bits, e.g.
The a command should be renamed to
Next a command for extended accessory decoders is required. Format is 10AA-AAAA 0AAA-0AA1 DDDD-DDDD where DDDD-DDDD is in the range 0 - 255.
To make it even more complex this command can be used to set an activation time for simple accessory decoders. Format is 10AA-AAAA 0AAA-0AA1 RZZZ-ZZZZ. R is the output, ZZZ-ZZZZ is the time in 100 ms. 0 = off, 127 = permanently on
Then there are emergency off command for simple 1011-1111 1000-0110 and extended accessory decoders 1011-1111 0000-0111 0000-0000.
Next is a NOP command 10AA-AAAA 0AAA-1AAT
And now we have the progamming command. What I already did was programming of simple accessory decoders.
The same has to be done for extended accessory decoders:
And then we have for both decoder types programming of CV Bits and Checking of CV values and CV Bits (RCN-214, page 5). To reduce the number of commands I suggest to add the decoder type as parameter otherwise it all becomes very confusing. |
Beware <ac 1 2 3> parses to the same as <a 99 1 2 3> which could be a different meaning. |
Also, of you add these commands it would be normal to add rxrail macros to do the same. |
Problem/idea statement
For product testing of the new turnout decoders for Kato Unitrack from Proto Design Labs I needed the feature of programming accessory decoders on the Main Track. Therefore I extend the controlling command 'a' by a programming feature:
For programming on the programming track no accessory programming command is needed, that can be done by just using 'W'.
For testing the turnouts on the programing track after e.g. an address change I also added the command 'A':
Track power has to be on to operate a turnout.
I have done tests successfully with turnout decoders from Proto Design Labs and Decoderwerk.
What I haven't done yet is programming a decoder address either by ADDRESS SUBADDRESS or LINEARADDRESS. The reason for that is that RCN-255 list CV1 as LSB (6- or 8 bits) and CV9 as MSB (3 bits) with copies in CV17 and CV18. But Decoderwerk for example uses CV40 and CV41. I will try to get more information first to see what other manufacturers are doing. Any information on that would be very welcome.
One option could be:
for CV1 / CV9 and
to use non standard CVs for the address.
If the already implemented features are of general interest I can createa a pull request.
Best regards
Klaus Nahr
Alternatives or workarounds
Calculate address CV values by hand.
Additional context
No response
The text was updated successfully, but these errors were encountered: