As far as I understand LCC is

As far as I understand LCC is the network standard for communication between the,physical hardware that is on the layout.  So for instance your detection system and your wired throttles would use LCC to connect to the command station.

So in the case of Digitrax it would be used for what currently LocoNet is used for.  Or Xpress Net on Lenz or whatever the proprietary system each current DCC system uses.  DCC is the communication protocol used between the command station and the Locomotives on the track.  This signal is usually repeated by each booster.  

LCC is a good concept that unfortunately may have came to late.  While it is theoretically possible to create a device that translates between LocoNet and LCC so that you could add LCC to a Digitrax layout the question is is it worth the cost and effort.    I know theoretically if you converted Loconet to LCC and LCC to Xpress Net/Xbuss you could use Lenz throttles on a Digitrax layout or Digitrax throttles Including the wireless ones) on a Lens layout.  But who is going to create these adaptors?

It is not necessarily in the best interests of a company to create an adaptor that converts from it's propriety system to the open LCC standard as that could allow a user to by another company's hardware and thus cost them the sale.  On top of this to truly take advantage of the speed and bandwidth of LCC you would most likely need to connect it directly to the command station or it would be bottlenecked by the existing network.  I could connect a fire hose to my garden hose but I can't get more water out of the fire hose then the garden hose can supply.

On top of this it actually could hurt the current DCC suppliers.  They had to create or adapt a standard network to connect there system together years ago something that they have figured out how to do and that they paid to do.  They have a large installed base of users that have spent a lot of money on said system.  Now in order to adapt LCC these companies will have to design the interface to connect there command station to LCC in effect they will have to design build and pay for something to do what they already designed built and paid for.  As to truly take advantage of LCC they will need to install it directly into the command station.  So they need to design or at least redesign there existing command station(s).  Once this work is done they will have to include both LCC and there existing system (or a perfectly working adaptor) as their existing users will not be happy if they have to replace everything that they already bought.  And the perception that they have been abandoned would not be good for business.  So the existing DCC suppliers will have to support two standards and that means increased costs.  As you can't support two systems as cheaply as one.

Any future throttles or other accessories will have to be designed twice or you are back to being perceived as abandoning your current system and users.  At least until practically all your current users replace there existing system.  But I know a ton of folks with system older than 15 years so I doubt folks change DCC systems like we change cell phones.  So that won't be any time soon.

The other downside to this is any NEW company just getting into DCC can just start up with LCC and thus have a faster network.  And they only have to support one standard.  So anything they design should be cheaper.  So the old company is now fighting harder because they have a,legacy system that they have to pay to support.  

So if an existing company jumps into LCC then they have taken on additional expenses and what do they get for this additional cost?  They get a system that someone else can get the profit selling accessories for.  Right now if your Digitrax throttle dies or you add an operator you have to buy a new throttle from Digitrax (ignoring smartphone options) if Digitrax puts out an LCC compatible system then it's owners can buy any LCC compatible throttle.   And just to add insult to injury Digitrax will have to help support company X brand throttles or face the backlash of bad reputation.  Because any compatibility issues between X brand throttles and Digitrax will fall on Digitrax just as much as XBrand.

So there is a TON,of down side to an existing DCC company jumping into the LCC playground.  And until LCC becomes the standard of most users there is little up side.

Like I said I would love to be able to have something like LCC for my layout but I think it will be a very long time coming if it ever really happens.  As the standard should have been rolled out years ago before each company went there own way. Now we are in the unfortunate position that the companies that supported DCC and made it a,success are actually in a position to get hurt by this new standard.  Not a good way to reward them for there effort.  So I guess I could understand someone not being happy about being asked if they will support LCC a system that opens them up to all sorts of potential issues.  Basically the existing companies are damned if they do and damned if they don't adapt LCC.

It is a shame as the concept is a good one  it just is to late.  No I think this ship has sailed on this.

The real question is, and I don't know the answer, but CAN someone legally design and sell something that adapts a proprietary system to LCC without the owners permission?  Assuming that Loconet is truly owned by Digitrax (for instance) as opposed to an open system that Digitrax adapted to there use.  Then can I sell Loconet compatible devices?  If so do I have to go through the reinvention of hardware and software like in the beginning of the IBM pc days?  If that is the case then I doubt we will see many adapters.  If you can sell these without having to get permission then you could argue that the Companies that have supplied us with DCC systems are potentially going to get screwed.  As they did the hard work of creating the system and getting folks to adopt it and now someone else can sell things for it.

Either way the situation is unfortunately a mess.  And one that could have and should have been avoided to begin with.

-Doug M

As I read the LCC description

As I read the LCC description on the NMRA web site, it very clearly says that the intention is for "non-locomotive" communication. It's intended for every thing else; turnouts, accessories, signals, etc.  The idea is to take all of that load away from the track bus, so as to leave more bandwidth for the locomotive commands.

I know there have been a couple of demonstrations that connect with throttles, but that really doesn't seem to be the primary, intention for LCC.

Frankly, if we don't see some significant "plug and play" products on the market in the next year or so, I'm not sure if it will be much more than a curiosity. 

The most generous estimates for DCC market penetration put it at 50%. That's after a couple of decades. And DCC is for the control of the most important thing on the layout. I applaud the guys that worked hard on the LCC spec. But it takes time and available products to turn it into something useful.

As the market stands today, I wouldn't think anyone but the largest clubs need to factor LCC into design decisions for the next few years.

I'm hoping we see this develop quickly, but product development doesn't happen over night, and the first generation of stuff is usually not optimal anyway. My guess is it will be a few years before we see enough variety of  product to even worry about it.

GS

Not sure how you could have missed the Huge LCC Signs

as you walked into the National Train show.  There was a demo layout on display for it.  As for LCC products, there are only a handful of manufacturer's at the moment, but actually ,when we look at the pace the DCC Standard was accepted and adopted by the various Model RR manufacturer's that dealt with command control, the LCC standard is farther ahead.  TCS is a major player though not as big as NCE or Digitrax.  I can see Digitrax not wanting to adopt the LCC standard because they already have their own independent Bus system for the non locomotive decoder electronics.  And NCE I have heard is rumored to have been developing it's own version of loconet, and if true, then it makes sense why they are not so found of the LCC standard.  But it's because it's designed to be a universal standard that I for one am a big supporter of it and am glad the NMRA has approved and adopted a new set of standards.  There are workarounds with connecting an NCE system with LCC though something such as the JMRI software, but I was hoping not to have to depend on another system to bridge  the two.  And hence the dilemma I face.  As I said before I was very disapppointed witht he rather curt response I received when I asked them about LCC.  Their claims of it's a solution in search of a problem totally ignores the fact that the NCE system relies on the same bus to handle all the traffic for both mobile decoders and stationary decoders and that their own AIU is actually (as the system uses it) is just another "CAB Throttle".  For a small switching layout, perhaps that is all that is needed, but anything that is bedroom sized or larger, having a separate bus for each I believe has superior advantages. 

Ken L.

yes I saw a HUGE

Ken ...yes I saw a HUGE sign that said LCC.  Big woop dee do.  What I didn't see was any manufacturers advertising anything at there booths that had anything to do with LCC. As for the display I was under the impression it was a display of hand/custom built components and not commercial devices that I can (or will) be able to buy.  Thus for someone not into building electronic devices it was at best a display of what theoretically LCC can do vs a display of components users can actually get.  Kind of like a display for a concept car that no one is building.  It looks cool but is of no practical use to someone looking to buy a new car any time soon.

I was standing in front of TCS booth listening to them talk about there decoder and never saw or heard anything about LCC or a new system for that matter.  I also looked at or talked with all most (all of them as far as I know but I could have missed one I suppose) of the companies selling electronic controls of any type from DCC to the folks with the modular control panel system.  And never saw or heard anything about LCC.  In fact I was looking for something along those lines as I am currently wiring my layout (just finished a ton of documentation for said wiring a couple months ago) and wanted to try and make my wiring forward compatible.  But no one had anything on display.

I spent a good amount of time talking with the nice and friendly folks at NCE about possibly change from Lenz to NCE and they gave me some great advice that would make my life simpler and make conversion cheaper for me that frankly did not help them.  But they were more interested in helping me then in selling me more products.

At the time I was near the huge sign the person by it was busy so I didn't talk with them.  I didn't get a chance to return to the display because my father (85) was getting tired and I took him home.

So being as you are all fired up over LCC how about you tell us what they had other then a huge sign with the letters LCC on it?  Any other useful information would be nice like any components going into commercial production.  As I said I am all for LCC and would love to see it happen.  I have an old Lenz system that unfortunately is not getting supported with new devices so I expect I will have to replace it sooner or later so I am in a reasonably good place to take advantage of any new LCC system unlike most DCC users.  So it would be nice I just don't think it is good to happen.

As for the comment about LCC being for non train control (Not made by Ken)  that is true.  But if it is not going to replace the bus used for connecting various DCC components (such as Loconet) then why would the various DCC companies care about it?  If it runs independently of the DCC system then it really does not matter.  As far as that goes I could install a separate DCC system to control everything other than the trains.  Say a Loconet system keeping my Lenz system for the trains.  Or you could install two Digitrax systems and get close to the same results as you have removed all non train related commands from the network that controls your trains.

This does not however change my comments.  If an existing company wants to take advantage of the LCC standard they have to support both with the increased costs of doing so whereas a new company can just use LCC from the start.  Also there are good reasons for existing companies to not support LCC and very few reasons that they would want to support it.

Frankly I doubt that very many hobbyists have much of a need for LCC at this point so until that must have application comes around I doubt very many layouts would adapt it.  Signalling and Throttle connections being the only obvious uses that most folks might have for it at this point.  And companies such as Digitrax and Bruce Chubb have already invested a lot of time, effort and Money into non LCC versions of these things.  So it is going to be hard to convince them to change over as they would have to support both the legacy system and the new LCC versions.

NMRA LCC FAQ

Here's link to the  FAQ sheet from the NMRA web site - 

Two important quotes from page 1 -

"LCC stands for “Layout Command Control,” and it’s a system for controlling all the functions on your layout that don’t have to do with how fast the locomotive is moving -- things like signals, or sounds, or passenger car lighting. "

"LCC, or Layout Command Control, is designed to take some of the burden off the DCC bus by routing all the non-locomotive commands through a different pair of wires...the LCC bus. Only the locomotive control stays on the DCC bus"

I'm not trying to start an argument, I'm just working from available information. It seems to me that it won't make any difference what DCC system you use, and "LCC compatible" doesn't really mean much in relation to DCC.

Another quote "DCC and LCC are totally compatible....  no matter what brand of DCC system you currently use, LCC will work with it."

DCC and LCC are compatible in the sense that they can sit next to each other and work just fine. That's because they don't need to have anything to do with each other.

Read the whole FAQ sheet for more info.

Just for the record - I hope LCC is a big success. But I think it will take some time.  I think a lot of folks would love to have a Plug and Play signaling system or simple turnout control that didn't require a lot of configuration.  I think this would be healthy for the hobby and spur more growth.

gs

LCC's future

Is TCS considered 3rd Party?

I guess they could be? I just know that there was a prototype of their DCC/LCC Command Station, and it has me seriously considering switching over to TCS.  Though I don't know TCS Customer Service or Support so that could be an issue.  This is why I am very disappointed with how NCE is responding to the LCC Standard because I really like their system and though LCC can work along side with it, it would be nice that the Command Station was able to deal with both DCC and LCC. 

I would think the possibility of selling more of their products such as their throttles, would outweigh the potential loss of sales as everything becomes universal.  By NOT adopting LCC NCE and Digitrax may find themselves loosing because for example, even if I stay with NCE, I may not stay with their throttles and I certainly will not buy any of their accessory decoders or anything else from them, especially if I go with an LCC stand alone wireless throttle.  So NCE has just lost potential sales as I'm willing to wait for NCE to adopt LCC but not forever.

It was their snobbish attitude that really put me off and for me tarnishes what has been an imbecile record when dealing with customers.  Though I was unable to speak with the owner himself, his staff certainly did nothing that sold me on the idea I shouldn't be concerned with LCC.  Statements such as "it's a solution looking for a problem"  proves nothing to mne, especially in light that the LCC Bus is far superior and faster than the DCC Bus.  ANd there are known issues with the DCC Bus on moderate to large layouts, especially with large number of throttles, as well as large number of accessory decoders, AIU's BD20s, and so forth. The CAB and DCC Bus are ill-equiped to handle that amount of traffic, and when I dig further and discover how the traffic is handled ()DCC vs LCC) though I can not specifically recall what was told to me because it is highly technical, I was left with the facts LCC handles packets much more efficiently.  The people at the NTS only scoffed at me when I brought those things up. I mean, if there are no "issues" with the way DCC handles things, why not explain them to me other than platitudes and hyperbole.  That is why I have a problem with NCE now and their service. 

My concern is just as when DCC was adopted by many manufacturers' there were those who didn't (CTC80 and Dynatrol come to mind) soon found themselves out of business.  And they used some of the same language and rhetoric how the standard is a bit too late, the "train has left the station", and yet, many manufactures DID adopt it, and it is the industry standard (even though there are some who ignore it such as Rail Pro) and only time will tell if the same is true for LCC, but here is my question.  If LCC is more or less "Universally Adopted" (with the occasional outlier of course) what happens to NCE? 

Ken L.

The question that begs to be

The question that begs to be answered is will / can someone make an interface that connects LCC directly to someone's DCC system?

 I think that they can connect the DCC system to a computer and then connect the LCC to the same computer and use the computer to communicate between them.  You should be able to do this because pretty much all the existing DCC systems sell a computer interface.

But can you legally build and sell an interface that connects a DCC system to LCC if the company does not want you to?  Is the code and hardware design protected by law?  I believe from what I have read that Loconet by Digitrax was developed by Digitrax and presumably it belongs to them.  I think Lenz started with an ieee standard so that may be public.  I think NCE started from Lenz but the two don't work together so I think they modified the standard enough that a company would have to reinvent the code.

Based on the difficulty companies had cloning the IBM pc back in the day I think someone could reinvent the code used and create an interface but if they have to go through the effort that the computer companies had to back in the day then it can't be worth the effort.

As for 3rd party I would say that anyone that doesn't make a DCC systems of their own is a 3rd party. So yes currently TCS is third party but if they release a command station then that would change.

As for TCS having a demo of a DCC system on display I guess I missed it.  Which is a sad commentary on the design of there display.  As I was looking for / at New DCC systems as I expect I will need to replace mine.  Admittedly I didn't look closely at TCS as I didn't expect them to have a DCC system on display as they were just a decoder supply company.  So I think they need to do a better job of getting the word out.  I talked with a couple folks I know that where at the show and they missed it two.  On top of that there is nothing on there web page as of yesterday.  So they are not exactly pushing it.

So as far as I know now the only company showing any hardware for LCC at the NTS was TCS with the prototype of a new DCC system.

As for companies adapting LCC I am sure if a large segment of DCC users start switching to or adding LCC to there layouts that the existing DCC system companies will jump on the bandwagon.  But until some must have application comes out for LCC I don't see it taking off.  Yes it should handle throttles better and it provides a standard for connecting multiple companies hardware together but that is not a must have it is simply an improvement.  If someone comes out with a $2 detection system that is easy to program or $5 switch machines or something that currently is to hard/ impossible to do without LCC then it will take off.

DCC was the first practical relatively affordable command control.  Older systems had huge issues (trust me I had OnBoard and a friend had Dynatrol and they where such a pain to use that we both went back to DC block control) so they had a must have application built in.  And even then it was not until Sound become common that DCC really took off for smaller layouts or to replace DCC on existing layouts.  And that is LCC problem.  Most folks in the hobby that are inclined to go with technology have existing DCC systems. A lot of them have existing detection systems and existing stationery decoders that would be expensive to replace or upgrade and why fix something that isn't broken in that case.  So LCC is limited in market to those that either are just starting and don't have these things or those that have the time and money to be able to toss out what they have now.  This cuts down the potential users.  On top of this you have things like the Raspberry Pi (or whatever they are called) to compete against.  And a lot of the more technology interested folks are playing with those and other things that eliminates the DCC system and just use a computer and WiFi.  Add in that most everyone is going with wireless throttles so the so called universal LCC throttles are not a big deal.  Yes LCC would allow my LCC receiver to plug into your LCC / DCC system it doesn't mean that my wireless throttles will work with your wireless receiver.  So we still will be stuck with one companies wireless system unless we buy multiple companies receivers.  And that ignores things like Benny's smartphones and the prototype diesel throttle that use WiFi

So while I hope that LCC does well it has a lot against it.  And that ignores the issue that this standard should have been set years and years ago.  Frankly this kind of standard should have been part of DCC from the start.  Implementing it now just screws over the companies that supported the DCC standard years ago.  They invested time and money and now the NMRA has declared there systems to be non conforming.  And we now have hobbyists who are getting upset / unhappy with them because they have not adopted a standard that didn't exist until a year ago.  So they either have to spend more money to adapt LCC or they have to live with upsetting folks like Ken that want LCC.  This is not much of a reward for adapting a NMRA standard.  They supported the NMRA standard and the NMRA years later adds LCC decades after the fact.

So if you are thinking about adapting a new NMRA standard you have to consider the possibility that some new standard will be released in the future that will adversely affect you.    So I can easily understand how this is a sore subject for DCC system suppliers.  And I can easily understand them not being as friendly and cheerful as they ideally could be when the subject is brought up.  Expecting a company that most likely feels a bit betrayed to be happy when talking about something they either don't support or that will cost them money to support that they didn't have much of a say about is a bit unreasonable.  It like expecting someone in the middle of a nasty divorce where there spouse cheated on them and then got the house and most of there money to be happy talking about it.  Yes it would have been nice if they were all friendly and happy but truthfully you were not going to like there response no matter what as they where telling you something you didn't want to hear.  Laughing and joking and being really happy would not have changed the end result.  And that is the fact that you are not happy with them and they have by your own word lost future sales to you.  And the reason is beyond there control.  They followed the NMRA DCC standard to the letter.  The even used a derivative of the network that the creator of DCC (Lenz) used.  And here we are years later in a tough economic times and they are expected to either just suck it up and spend the money or get more folks like Ken who are going to take there money elsewhere.  No matter what they are getting screwed over just because they supported a standard that turned out to be incomplete.  And let's be honest if LCC makes sense today then the same logic holds true that there should have been a bus standard set back then.

-Doug M

TCS may be making a DCC

TCS may be making a DCC system? I'll be watching for that. 

Why LCC?

Assuming anything comes of it

Assuming anything comes of it anytime soon.  It doesn't look like NCE is doing anything with it.  I can't see Digitrax doing anything as Loconet has a ton of things.  And as you pointed out if Digitax adds LCC then a,lot of throttles will go to someone else.  So exactly why would they add LCC?  And there is the crux of the problem.  

It would be nice to use whatever components you want.  And to do everything with one network bus ran around the layout it would greatly simply wiring.  The key is availability and cost and easy of use.

Personally what I would prefer over simplified wiring and a unified standard is a better interface with the DCC system itself.  A computer with JMRI and decoder pro type software is a definite start in the right direction but it would be nice if the DCC system had a simple gui to set up and program things.  Presumably something like this could be possible if LCC is implemented but I think a lot would depend on how integrated LCC is into the DCC system.

And as for third-party that is a reasonable direction to go but to make it truly work it needs to interact directly with my DCC system and I am still not sure how that works if the DCC company does not want it.

And I think it is a crapy thing to do to the companies that supported the DCC standard.  It gives new companies a distinct advantage.  And yes DCC did the same.  But the systems it screwed over in general had less installed users, and generally didn't work very well.  And the big point.  They were not built in compliance with a NMRA standard.  The current DCC systems are built in compliance with the standard that the NMRA created and now years later the NMRA has created a new standard that fills a whole that the DCC left side open.  So the NMRA created a standard, left a whole in said standard, got a bunch of companies to spend time and money supporting that standard and creating proprietary patches for said whole, got a ton of hobbyists to buy into said standard and install/buy the "patch" and now twenty or so years later the NMRA finally creates a standard to fill said whole.  The end result being that everyone that has invested time or money be it the companies or the end users have now spent time and money that has theoretically been turned into a "dead end" 

This is not a very nice thing to do and doesn't encourage anyone to want to be one of the early adaptors or supporters of said standard.  

Note the concept of LCC is a good idea and it is to one degree or another needed.  But it is a bit unfair to decide this now.  And for those of you that may not have been in the hobby when DCC was created or that don't remember or that didn't participate in the discussions at the time.  There was a LOT of discussion about the DCC standard not having a standard for the control bus and many folks had issues with that part not being standardized.  But for various reasons it was decided by the NMRA that it was better to not create a standard for that.  Now obviously that has changed.  

Personally I think at the least the NMRA owes the existing DCC companies a letter of thanks and truthfully an apology for setting a standard 20 years late that to one degree or another screws them over.

Note I am not trying to turn this into an NMRA bashing post.  What the NMRA did with DCC was a great thing and the shining example of the single best reason for it's exciting made during my lifetime.  But I truly do think that if they could not get the existing DCC companies to sign off on LCC (and I don't think that was ever going to happen) then the NMRA should have just stayed out of it.  The NMRA made a decision two decades ago and now is having second thoughts.  I am not sure how you do that without getting the existing companies ticked off.  And personally the last thing I want is for the existing companies like NCE and Digitrax and CVP to get ticked off and take there toys and go home.  Remember this is the second time at least that CVP got hosed over and it may be for NCE also.

-Doug M

A Contrary View of LCC

While the "open standard" goals of LCC are laudable, we have yet to see much of any hardware developed and marketed.  Meanwhile, there IS a standard for computer interface--the C/MRI standard developed by Dr. Bruce Chubb.  This has a fairly large installed base (around 7000 as I recall) and now has additional vendors supplying components that use the C/MRI computer communication standard.  Even in our rapidly developing "high tech" world, there is much to be said for proven and installed systems.  Note that C/MRI now has (As of 2015) an official NMRA standard.

Important to both LCC and C/MRI, is that they are independent of the locomotive control system.  With "larger" layouts, that is an important move to get non throttle communication off the DCC bus.  

Bill Decker

@Beaver11

I was just getting ready to make the same point you did.

I agree that a standard already exists. To me this is a case of "re-inventing the wheel".

First the NMRA copied the Lenz standards for DCC when they adopted the "DCC Standards" now they basically want to copy C/MRI.

I wonder if the NMRA people ever had an original idea? Another reason in my "Con" column of whether to join or not.

Paul

Why the hate

Wires are still wires

In several cases on this forum, I have been amazed at the sheer amount of wire that is involved.  Even talking about the increase electron traffic that goes with all that people want to do, another bus system sounds old school. Wireless of some sort sounds more relevant.  It seems like limiting the head aches to specific modules in discrete locations would be better.  

As for the legality, if you can get JMRI on a computer to interface one system with another, a fixed stand alone plug in device to do the same thing.  Probably programmable, so it is device and to some degree technology independent.  

I think the aspect that may be as important, as some unique function, is simple, quick implementation that is easy to maintain.  How often are you chasing electrical issues along the current bus system.  Do you really want to add another set to maintain.    

The concept of standardizing the control of the way the potentially endless animation that can be in place is a good thing.  Including the transport means of this communication has to be limiting.  Who really knows what technology will bring in 5. 10, or even 15 years.  

To win, the system needs to be simple, easily renewed and adaptable for any control the modeler wants to implement. 

As I understand it, LCC is different

As I understand LCC, it is different from CMRI (and LocoNet).

LCC uses more of a mesh networking approach, and as such no central computer is required. Devices can self-discover and talk to each other. CMRI, on the other hand, is an old hub-and-spoke standard, and requires a central computer to function.

With LCC, each device on the network can act on its own, generating events and responding to events. Devices on LCC can automatically discover each other and send commands to each other. Event messages are free form and can be defined to operate however you need. Very state-of-the-art, fast, and flexible.

With LocoNet and CMRI, the events or messages sent have two parts, first an identifier number (address) and second the message type. The size of the command space and the protocol design limits the number of possible options to a predefined set. For example turnouts only have two options, normal and reverse. Have a three way turnout, sorry, you need to think of it as 2 different two position turnouts. Have a three color signal, sorry, you need to think of that as either three different on, off, messages, (CMRI) or else combine two different 2 position messages. (LocoNet)

Finally, LCC uses a standard CAN bus, meaning all the interface chips between the bus and the various devices are all off the shelf components manufactured in the millions (read: cheap). CMRI and LocoNet are proprietary and require custom-designed circuits and firmware.

The LCC standard is designed using the latest thinking on networked devices and maximum flexibilty, while allowing for cheap manufacture from common electronic components. So there IS a difference.

LCC is nothng like C/MRI

I love people who hate the NMRA make up facts as they go along.  All I will say is the LCC Standard is nothing like the c/mri set up, for one thing, a computer is not required to run it.

Oh, and as for the comment about the NMRA copying Lenz, that is not what happened.  Lenz agreed to sell the NMRA it's patents so that the DCC standard would be open to ANYONE AND EVERYONE FOR FREE so there were no royalty fees involved.  The committee involved with the DCC standards tweaked things a little, but the Lenz system had at the time one of the better protocols and the fact Lenz was willing to give over the patents was a siginificant in the NMRA's decision to use them. 

People who speak about things who have no clue what they are talking about especially when its attempting to slander an organization shouldn't speak at all!

Ken L.

Give it a rest

L.C.C. not for me

LCC

If I've gotten the gist right, LCC is just a stand alone system designed to handle the non-locomotive/train bits of the layout.  I can't see how this can be anything but a good thing.  Open source, anyone can use it and the consumer wins as they will have more options available to them.  Doubtless, Digitrax and NCC may be lurkers for a while, but they would likely be able to increase their customer base by offering LCC compatible versions of their more popular products.

As far as the "technology" is concerned ... I think both DCC and LCC are WAY behind the times.  So much more could be done with what is available today.  Seeing some of it with the Arduino and RaspberryPi  based micro controllers.

Interesting

Hi Joe, I think your use of Mesh Network terminology is incorrect. While it may look like the nodes are cooperating in the network in a mesh like fashion, under the hood the CAN bus is just a linear bus topology (you can't set the nodes up in a star or a ring).  Also, the nodes don't participate actively in the network, they use Carrier Sense Multiple Access (CSMA) like Ethernet to determine when to transmit (they are polite – they listen before speaking). 

Some interesting stuff:

Data Rate 125Kbits per sec using the CAN frame protocol

Max Buss Length: 500 m

Uses 4 pair (Ethernet) Cable, 1 pair for the can bus, 1 pair for power, 1 pair for shield and ground, I pair unused)

Unique Node ID’s burned in at the factory (like the MAC address on your network card)

Looks like JMRI has support as well on the computer side as well.

You could encapsulate the CAN protocol using a CAN-TCPIP device and run it over Ethernet to a PC or Arduino (or even just bridge it back to another CAN-TCPIP device.)

Andrew

That's why I said as I understand it

That's why I said as I understand it. I've never really sat through any LCC clinics yet, I've only read through some docs and stood around on the periphery of LCC conversations.

So anything that clarifies how it really works more accurately is fine with me.

Things I would use LCC for ...

Building remote panels for signal indications, or pushbutton inputs to control turnouts (or route selection).

While I can do the same thing with JMRI and a tablet mounted on the fascia, there may be a reason to want something else (size of icons and my near vision with glasses, viewing angle, fat fingers, or a whole host of other reasons)

Following along with Dr. Geoff Bunza's Arduino projects, I had already thought of setting up 1 Arduino to read the pushbuttons and send a DCC command to the servo turnout Arduino.  A second Arduino would also be connected to this DCC bus and would be programmed to respond to the same command, but instead of controlling a servo, it would be lighting LED indicators on the panel.  As many panels as needed could be built as needed (for our Freemo modules, controls need to be accessible on both sides of the modules) and distributed around as needed.  The wiring would be very simple - 2 wires for the DCC and 2 wires for power and ground.  The project could even be expanded to include signaling if I wanted to add another Arduino to drive that.  There is no reason that this little control panel local DCC bus would need to be connected to the track DCC bus, but it could be. 

This is the type of application where LCC could be a real benefit to people who are not hardcore "roll your own" hardware hackers.  Just like ready to run rolling stock, if I could get ready to install modules that were easily configured by connecting them to a PC and filling in the fields, I would jump on it.  Less soldering, no learning a programming environment, nobody else's code or libraries to figure out, no errors with missing "#include" statements!

That is the vision of where LCC wants to be.  

I don't think anyone debated

I don't think anyone debated the fact that LCC is new faster and better then the various control bus / networks of various DCC systems. It is after all created many years later.  The main goal of LCC as I understand it was to remove the work load from the DCC bus that the creators of DCC did not seem to intend it for.  The secondary goal appears to be to create a universal standard. The fact that this network is faster or better then existing options is simply the result of newer technology because it is 15 to 25 years down the road.    

The problem is that various systems are in place to do this already.  Be it CMRI, Loconet or what have you (those two probably being the best known).  This automatically creates an issue in that the companies that are in the best place to implement,LCC have a vested interest in other systems.  

As for the argument about cost.  If you assume that the LCC components cost $10 to add to a system then the distributor will increase the cost to $15 or $20 or so and the retailer will increase it to between $30 and $40. Doesn't sound like much but it is not negligible.

Also we have to add in the time to learn how LCC software and hardware work. design new hardware (including boards, connections, power supplies and cases to name just a few), create new code, test everything revise as needed per testing (repeat until flawless), create documentation, train tech support, write user manuals, get new packaging,  revise advertising.  Update the website, absorb any existing hardware that has not been shipped.  And that just gets us,to the day we sell the first revised system.

Once the system is for sale we have to support both systems, continue to test for compatibility with nearly released hardware sold by the competition (this includes buying said hardware,testing it in all manner of ways on multiple configurations of network nd layout design,) provide support for connecting other companies hardware to your system (in documentation, online and over the phone) revise existing hardware or software as needed because of any compatibility issues that may be encountered.  Design new /replacement hardware for anything that someone else has a better version of (such as throttles) going through the same process as above for the new hardware.  And of course to keep are existing users happy we have to design two versions of our new hardware and support both.  (Thus increasing ur design costs and support costs yet again) and let's just hope that or existing system will support all the bells and whistles we can make LCC do or we will have issues with the legacy compatible versions of the new hardware.  As it will look bad compared to the LCC version.

And let's not forget that we will tick off at least some of out owners/users and our supply chain because they ordered/ brought the old non LCC system two days before the new system was announced.  Note this will happen no matter how much notice we give as someone has to be the last person to buy the old system.  Also the longer notice we give the longer we won't sell anything as who is going to buy the old system once the new new is announced?  And if we don't give a long notice the we will just get folks even more upset with us so we are damned if we do and damned if we don't.  We will also have to deal with users that don't understand why there buddies system can do something there system doesn't and good luck explaining that he has LCC and the caller dose not.  This may sound minor until the guy goes online and gives you bad press because his non LCC system won't do what the new LCC system does.

So there are a ton of issues and expenses involved with going to LCC and I can see why some companies are not supporting it and are not happy about it and don't really want to discuss it.

As,for the idea that JMRI can connect to most (all?) DCC systems and thus it is possible (and presumably legal) to create a hardware connection.  The two are not necessarily the same.  As far as I know all the DCC systems have there own computer interface (hardware and software) to build an LCC connection means creating hardware and software that "speaks" and physically connects with the DCC system.  Unless you plan on using the computer interface all the time.  And while that should work to one degree or another it is not as seamless or useful as being able to directly connect or even better have LCC support built into the system.

Note I like the idea of DCC and I hope it succeeds but it has a long way to go and it has an uphill battle against the installed DCC systems and the companies that makes them.  If a good solid DCC/LCC system comes out by the time I want to replace my Lenz system I will give t a good look and it having LCC will be in the plus column (thus giving the existing DCC companies one more thing to be unhappy about) as I will do what is best for me.  And if LCC takes off I will get on the bandwagon.  But I don't think the standard should have been set or it should have been set years and years ago for various reasons.  As such I fully understand some folks not being happy with it.  I also think that it will not become very common anytime soon.  As of right now I know of one company working on something and a couple companies that don't plan on supporting it.  So good luck.  I could really use it.  As right now I am considering going with a,Loconet system to handle detection and such.  And I would love a simple to install network that has multiple vendors supporting it.

-Doug