DCC Decoders for Cab Cars/End Cars

[gavino200]

7 minutes ago, chadbag said:

From a discussion on the Digikeijs mail list regarding LCC it was claimed that command stations that actually support RailCom can use that to limit the amount of traffic sent out -- most command stations will repeat the commands X times or indefinitely so that dirty track or other electrical problems do not cause trains to miss commands.  Smart command stations with smart RailCom decoders can talk back and forth to avoid this.  I don't know more than was claimed.

 

 (DR5000 doesn't directly have RailCom but the Digikeijs block detection modules for RailCom do)

 

That's interesting. I need to read more about RailCom.

[Martijn Meerts]

I'm not sure if RailCom does an acknowledgement of commands, but theoretically it could. I've been a bit out of the loop on digital for a while since I've not been doing that much with the trains in general. 

 

Most of my decoders do have RailCom, but I like it mostly for the easier programming of especially function decoders. They can be read even with with just an LED attached to them, unlike non-RailCom decoders which need a much higher load in order to be successfully read. The newer decoders also have RailComPlus, which is the system where trains automatically register themselves, but this is another thing I've not tried, even though the newer LokPilot and ECoS should support this.

 

[chadbag]

IIRC the guy who was talking about RailCom equipped decoders being able to acknowledge commands (or something similar) seems to be involved with TCS and their command station under development.   There was a large discussion on "consisting" and he mentioned it multiple times as making it more efficient due to being able to remove acknowledged packets from the packet priority queue that many command stations implement to feed command changes out.  Anyway, I don't know what I am talking about here.  Above my pay grade.

 

[Madsing]

Very interesting comments. Thank you.

I will keep Railcom in mind but I don’t plan to do anything in that direction just now.

@chadbag mentioned LCC here and I am more interested. My Digikeijs feedback modules are connected to the Z21 using the ancient proprietary R-Bus (Roco Bus). I see above that @gavino200 uses Loconet, which is better but still old. LCC (https://dccwiki.com/Layout_Command_Control) is the future. It is based on the proven CAN bus used for years in the automation industry. The Z21 has a CAN port, but they don’t say anywhere if they support the LCC protocol. I could use it to control switches (turnouts), signals and maybe other devices, instead of DCC (and keep DCC for the trains only).

[gavino200]

1 hour ago, Madsing said:

@chadbag mentioned LCC here and I am more interested. My Digikeijs feedback modules are connected to the Z21 using the ancient proprietary R-Bus (Roco Bus). I see above that @gavino200 uses Loconet, which is better but still old. LCC (https://dccwiki.com/Layout_Command_Control) is the future. It is based on the proven CAN bus used for years in the automation industry. The Z21 has a CAN port, but they don’t say anywhere if they support the LCC protocol. I could use it to control switches (turnouts), signals and maybe other devices, instead of DCC (and keep DCC for the trains only).

 

Marc, I think this is super interesting. I've looking into LCC before. I'm seeing in iTrain that many elements can be controlled separately and simultaneously by different interfaces without going through the DCC command center. I especially like the idea of having a separate LED controller like what you have built. I may start a separate thread to discuss this as time goes forward.

[pbunter]

I asked the Roco Z21 people about LCC last May. Specifically: 

 

"Can you connect NMRA-compliant Layout Command Control (LCC) components to the Z21 Black CAN bus and will the Z21 understand the messages?"

 

Alas, their reply was in the negative:

 

"The specified components were not taken into account by our developers. This is also not planned for the future. The statement of the specialists in the exact wording: No, this will not work. We regret that we do not have any better news for you in this regard, for which we ask for your understanding."

 

I, too, am interested in LCC but find I am somewhat reluctant given that (pretty much) only RR-CirKits builds LCC components and if the owner, Dick Bronson, retires or loses an argument with a Mack truck, then what? One bright spot is LCC support in TCS's new command station and the hope that they and maybe others will start building LCC components...but the command station isn't released yet so me thinks it will be awhile yet before that hope is realized.

 

Does iTrain support LCC?

 

- - - Paul

[gavino200]

22 minutes ago, pbunter said:

I, too, am interested in LCC but find I am somewhat reluctant given that (pretty much) only RR-CirKits builds LCC components and if the owner, Dick Bronson, retires or loses an argument with a Mack truck, then what?

 

That would be a real problem for LCC.

 

22 minutes ago, pbunter said:

 

 

One bright spot is LCC support in TCS's new command station and the hope that they and maybe others will start building LCC components...but the command station isn't released yet so me thinks it will be awhile yet before that hope is realized.

 

TCS seem to have been talking about this for a long time. I wonder if it's ever going to happen.

 

22 minutes ago, pbunter said:

 

Does iTrain support LCC?

- - - Paul

 

I just had a look on the iTrain forum. It seems that the answer is also "no".

 

 

iTrain User: Am i correct to assume the Arduino uno dcc ++ system works well with I train ?

 

iTrain Developer: No, you are not. It is just another protocol that I would need to add to iTrain and there aren't enough request to justify it as it always takes up a lot of time that cannot be spent on other things from which everyone would benefit.

[chadbag]

1 hour ago, pbunter said:

I, too, am interested in LCC but find I am somewhat reluctant given that (pretty much) only RR-CirKits builds LCC components and if the owner, Dick Bronson, retires or loses an argument with a Mack truck, then what?

 

Hopefully not a lot. Besides TCS I expect there are others looking at it.  Unlike Loconet, LCC is an NMRA standard.

[Martijn Meerts]

LCC has been a thing for quite a while, but it seems there's not much going on development wise.

 

As for splitting things up, I pretty much only control my trains and turnouts using DCC. For occupancy detection I use a dedicated interface, and for lighting and signals I have another interface. iTrain supports all of that. It's not really needed for what I have now, but if I ever complete the big layout the ECoS would've been overloaded handling everything 🙂

 

[pbunter]

12 hours ago, gavino200 said:

TCS seem to have been talking about this for a long time. I wonder if it's ever going to happen.

 

TCS demonstrated their CS-105 command station at the Amherst train show last month. It is still a prototype but working sufficiently well for a demo. Of note, they had it connected to an RR-CirKits LCC-LocoNet Gateway module that then connected to a Digitrax throttle. 

https://www.youtube.com/watch?v=OOKjhMsIIM4&t=509s

 

[gavino200]

15 hours ago, Martijn Meerts said:

if I ever complete the big layout the ECoS would've been overloaded handling everything 🙂

 

 

Overloaded power-wise? Or in terms of computing power? If power, wouldn't you just add a booster?

 

5 hours ago, pbunter said:

 

TCS demonstrated their CS-105 command station at the Amherst train show last month. It is still a prototype but working sufficiently well for a demo. Of note, they had it connected to an RR-CirKits LCC-LocoNet Gateway module that then connected to a Digitrax throttle. 

https://www.youtube.com/watch?v=OOKjhMsIIM4&t=509s

 

 

Interesting video. The unit itself looks nice. Small and minimal. I'm guessing it doesn't have a couputer, graphical interface. My assumption is that if there was one they'd show it. The addition of that Digitrax cab makes me wonder if that's how everything is programmed and adjusted. I know lots of people who like that, but for me it's a deal breaker.

 

I spent a while looking into LCC before, but I've forgotten most of what I learned. Some of it is coming back to me. I had a while trying to understand just what it really was and what it could do that other systems can't . I think @inobu gave a description that made most sense. IIRC he described it as a non-proprietary alternative to Loconet.

 

It has potential advantages based on the fact that  it is a node network with no command center, so it's potentially faster. I also remember that the bandwidth "problem" that it was supposed to avoid was essentially a red-herring. I don't think I found anything that could only be done with LCC as opposed to Loconet/RailCom.

 

This was the previous discussion we had here about LCC.

 

 

[Martijn Meerts]

11 minutes ago, gavino200 said:

Overloaded power-wise? Or in terms of computing power? If power, wouldn't you just add a booster?

 

Computing power. ECoS has a standard S88 bus for occupancy detection, and if I remember correctly that's a polling setup. So the ECoS needs to ask the detectors if they're occupied, and then they respond. The detectors don't send signals by themselves. If you have a lot of detectors, this polling is pretty taxing on the system.

 

 

The first thing I get out of that video, is what happens when 2 people each with their own throttle start changing the speed of the same train? Which one is going to override the other, or are they going to try and continuously keep each other in sync? 🙂

 

[gavino200]

8 minutes ago, Martijn Meerts said:

 

Computing power. ECoS has a standard S88 bus for occupancy detection, and if I remember correctly that's a polling setup. So the ECoS needs to ask the detectors if they're occupied, and then they respond. The detectors don't send signals by themselves. If you have a lot of detectors, this polling is pretty taxing on the system.

 

Interesting. My detection is Loconet. I should find out what the limit is for detection using Digikeijs loconet detection. As far as I know the limit is quite high.

 

8 minutes ago, Martijn Meerts said:

 

The first thing I get out of that video, is what happens when 2 people each with their own throttle start changing the speed of the same train? Which one is going to override the other, or are they going to try and continuously keep each other in sync? 🙂

 

 

That's exactly what happens. You both control the train. At least that's what myself and my son think we remember. I remember there's also a "steal" command in Digitrax that allows you to take a loco from someone else's cab, so only you can use it.

[Martijn Meerts]

The documentation I read for the Lenz SDK, is that when you claim a loco, all other throttles that have that loco selected will lose control of it. I'm not sure if that's a recommended way of doing things when using regular DCC.

 

[chadbag]

36 minutes ago, Martijn Meerts said:

The documentation I read for the Lenz SDK, is that when you claim a loco, all other throttles that have that loco selected will lose control of it. I'm not sure if that's a recommended way of doing things when using regular DCC.

 

 

I think that is normal.  I should research it so that my SW throttle I am (slowly) working on works correctly.  I kind of remember my NCE talking about the same thing.

 

*my project is kind of on hiatus until our house project is done

 

 

[gavino200]

On 2/22/2022 at 10:51 AM, chadbag said:

IIRC the guy who was talking about RailCom equipped decoders being able to acknowledge commands (or something similar) seems to be involved with TCS and their command station under development.   There was a large discussion on "consisting" and he mentioned it multiple times as making it more efficient due to being able to remove acknowledged packets from the packet priority queue that many command stations implement to feed command changes out.  Anyway, I don't know what I am talking about here.  Above my pay grade.

 

 

Chad, I was reading the DCCwiki article on RailCom today and came across the following:

 

"Any commands which are received can be acknowledged by the decoder, increasing the operational reliability and bandwidth of the DCC System, since commands that have already been acknowledged will not require repetition."

 

I think that might explain what the TCS guy was talking about.

 

[chadbag]

14 minutes ago, gavino200 said:

 

Chad, I was reading the DCCwiki article on RailCom today and came across the following:

 

"Any commands which are received can be acknowledged by the decoder, increasing the operational reliability and bandwidth of the DCC System, since commands that have already been acknowledged will not require repetition."

 

I think that might explain what the TCS guy was talking about.

 

 

yeah exactly.  Potentially reduces clutter on the DCC command channels.

 

Also, with FL12 and difficulty in programming.  I don't have the Zimo version but I would bet that they have the same problem.  A cab car doesn't have the same current draw on the system so is an edge case for speaking with decoders.   Since the Zimo FL12-clone also doesn't have the motor and other things to draw current it should probably have the same issue.   I've had better success programming FL12 if I stick a locomotive on the programming as well.  (You could probably also get some sort of resistor setup to supply a load-- not being a EE I don't know the details of what you need).  I may get a beater locomotive I can use to program FL12s concurrently with.  One I don't chiech address it is getting.

 

[gavino200]

6 hours ago, chadbag said:

 

Also, with FL12 and difficulty in programming.  I don't have the Zimo version but I would bet that they have the same problem.  A cab car doesn't have the same current draw on the system so is an edge case for speaking with decoders.   Since the Zimo FL12-clone also doesn't have the motor and other things to draw current it should probably have the same issue.  

 

I was hoping that RailCom would make the difference as it should send back confirmation.

 

Quote

 

I've had better success programming FL12 if I stick a locomotive on the programming as well.  (You could probably also get some sort of resistor setup to supply a load-- not being a EE I don't know the details of what you need).  I may get a beater locomotive I can use to program FL12s concurrently with.  One I don't chiech address it is getting.

 

 

I've used the loco trick too. Either that or just programming it on main with everything else removed. Even then it can take multiple attempts. Removing all the other locos is not a problem for me now but a real hassle with a full layout. Usually I use the motor car that will have the same address anyway to register a current. I'm not sure how it would work with a different loco. I guess you could just sacrifice a beater like you say.

 

Edited February 26, 2022 by gavino200

[bc6]

Not sure if this is relevant but tonite I decided to add a couple of FL12's to my E353 end cars.

Pics are below or you could just follow the included instructions in the FL12 case lol.

 

 

 

 

 

Edited August 8, 2023 by bc6