LCC, For Real
The first post-Standard LCC product is out, from RR-CirKits, and it’s quite impressive. I want to take this opportunity to share my first impressions, with the caveat that this is not a review. I only just bought my set earlier today, and haven’t even connected it to a computer yet. For all I know the pretty plastic boxes are full of sawdust. Mind you, I have had experience with RR-CirKits’ LocoNet interfaces over the years, and I’m fairly confident in the function of the new products matching their documentation.
This may read a bit like an ad, but that’s because I’m excited by this. I do want to note that, as usual, I only comment on things I’ve bought myself and that I have some interest in for my own purposes. In the case of LCC my interest is more curiosity than “likely to use on the railroad”, for now anyway, but I’m writing about it for my own reasons. Nobody gave me any incentives or influenced my comments here in any way. In fact, the folks I bought these from had no clue who I was (as if that would matter even if they did) and I paid the usual price, albeit at a show discount. Disclaimer done, on to the post:
Well, it didn’t take long. The first useful commercial products based on the LCC standards are out, and I have a set. While I may have some reservations about the state of the standards themselves (see my earlier series of posts), I’m very excited to see real products, and at fairly reasonable prices. Well, somewhat reasonable; I’ll have some comments on that.
I was at a train show Saturday (the big Springfield show in the Northeast) and tucked away in a corner was RR-CirKits (next to a JMRI/LCC booth) with a couple of brand new products, including a USB computer interface (LCC Buffer-USB US$70) and an LCC version of their TowerMan I/O module (Tower-LCC, US$70). They’re also selling a power supply (LCC Power-Point, US$25), which is required as the two units are bus-powered, so something needs to be putting voltage onto the LCC bus for them to use. At least for the show, they were packaging the computer interface and power supply, along with a pair of their bus terminators (LCC Terminator, US$14) as a “Starter Set” (along with a short Ethernet cable) at a show discount of US$85 (note: all prices rounded to nearest dollar), which was a good deal.
That’s what I bought up above (except for the green Ethernet cable, which is one of mine, only one Ethernet cable came in the set).
These are new enough that most of them aren’t appearing on their website yet; only the power supply and terminators are there as of today. I think the show was the intro for the computer interface and the Tower-LCC module. A google search does turn up a flyer (PDF) for the Tower-LCC though. This provides 16 lines, each of which can be an input or output, distributed via two ribbon cables (very similar to the wiring used in the LocoNet signal system if you’re familiar with that). They make a collection of devices you can connect via the ribbon cable (occupancy detectors, a four-aspect signal driver, and both stall-motor and capacitive-discharge coil turnout motors, and some others). So although the Tower-LCC is only one device, it’s really part of a system that is immediately useful for a wide variety of purposes.
Or rather, would be useful except that since I was completely ignorant of the TowerMan product line before this, I didn’t buy any of the other things. So my initial experiments with it will likely be done using switches and LEDs. Or maybe, given all the other things on my plate at present, I’ll just defer that until I can find time to buy some of the other modules.
In terms of the actual system, the USB adapter, like their earlier adapter for Loco-Net, is opto-isolated to protect the computer against any short-circuits in the layout wiring. I can’t stress how important a detail that is. Many cheap computer interfaces omit isolation, and in the chancy world of layout wiring, that’s a recipe for blowing your USB chip up. Frankly, I don’t begrudge a cent of the US$70 price for the adapter. That’s only $7 more than their LocoNet one currently lists for, and they’re both bargains (I should note that I’ve had several generations of the LocoNet one, and never had any problems with it).
I can’t really say the same for the other two items though. The power supply is a 1Amp 15 volt wall-wart with a box to connect it to the bus so it can supply 500 mA in each direction on the bus. The 500 mA limit is built into the design of LCC. A good-quality 1 Amp wall-wart goes for under US$10 (they sell theirs separately for US$11, reasonable considering the likely overhead). While I appreciate that this is a low-volume product and that there’s a custom circuit board involved, paying $25 for the power supply for my bus feels like too much. Of course, I could simply take my own wall-wart (or theirs) and splice its output directly into the bus wire if I wanted to be cheap, so I can’t complain too much. It would have been better if they built this function into the USB adapter and TowerMan (so you could plug a bus-power wall-wart into either, or neither) rather than having a separate power supply box.
I’d hope that maybe they put a resettable fuse or something inside the box to justify the price, but the card doesn’t mention one, and the flyer only mentions a rectifier that “prevents reverse polarity problems”. I think that’s marketing-speak for “we keep the + line higher than the ground line”; I suspect the purpose is in case someone plugs in the wrong wall-wart that has a reversed voltage output (or AC). Not bad, but at least in my mind it doesn’t justify the extra $14 they’re charging here.
The actual output of the supply is 15V (less a bit due to the rectifier, I presume), which places it safely within the 9 - 15V range allowed by LCC. And with 500 mA in each direction, it’s producing the maximum amount of power allowed by LCC (one of my issues with LCC is that there’s no description of how to support two power supplies on the bus if you need more juice). The computer adapter requires just 10 mA, and each Tower-LCC needs 20 mA (that does not include power supplied to attached devices), so you could wire up more of those than an LCC bus allows nodes without exhausting the power supplies (49 total, if you balance them on either side of the power supply and they aren’t actually doing anything).
The Tower-LCC, while a very flexible device, costs $70. Their existing serial-based TowerMan costs US$28. What they had to add were some chips that probably cost less than $10 in total when purchased bulk, a couple of Ethernet jacks, and some custom software development to interface their hardware to the standard LCC code (or perhaps they wrote their own LCC code). Now as a “version 1” device, they probably have to assume that they’re not going to sell many of them before changing the design, and that drives the cost up. And I’m not a manufacturer, so I have no idea of what the real costs are there. Still, doubling the cost just to add an LCC interface is more than I’d like to see. That said, $70 isn’t unreasonable for a device providing 16 I/O lines and there are 16-line DCC stationary decoders that sell for similar prices.
So, while I’d like to see the prices come down with volume (and I expect I will), I can’t really say the current ones are outrageous, even if the power supply and the Tower-LCC do seem a bit high-priced to me.
In terms of what these do, I’ve already mentioned that these basically use LCC to provide similar functionality to their existing serial-bus version, and that covers a wide range of functions. JMRI already has support for this (as of 4.2 or possibly 4.2.1 as the release notes describe some fixes). I haven’t tried that, although I do have 4.2 running on a Raspberry Pi, so I may give it a shot soon. But for now I can’t comment on the functionality from experience, but I will talk a little about what it claims to be able to do.
The Tower-LCC is equipped with the two Blue and Gold switches used for the simple two-button event programming method, so it can be programmed to respond to events like any other LCC device (not that there are any others yet). LCC events, as I mentioned in the earlier posts, are based off unique IDs by adding two more bytes (event IDs are 8 bytes, unique IDs are 6) so there are plenty to be used (and a node can use events other than those based off its ID). Each of its 16 lines can respond to up to 6 events as a consumer, or emit up to six events as a producer (one or the other, not both).
In LCC events represent changes, not conditions (e.g., “turn the light on” rather than “the light is on”). So, for example, you could hook up a set of pushbuttons on one Tower-LCC at a control panel that emitted one event per button to select a classification track in a yard, and have a second Tower-LCC at the yard controlling turnouts (one per each of the 16 output lines) where each turnout could respond appropriately to up to 6 different buttons (e.g., throwing left for the ladder for five of the buttons, and right for the classification track for “its” button).
Processing events requires storing the full event ID in memory, and 16 x 6 x 8 is 768 bytes, a lot of memory for the kind of microprocessor used in simple circuits like this, so that’s a reasonable limit even if in an ideal world it would be nice to have a given device respond to more than 6 events. And actually it can, although not more than the two per line, but it has more than just the 16 lines. It also has events associated with some internal logic “variables”.
One of the features it has is called “virtual track code lines”, designed for block signal management in a way that mimics CTC code lines (you can see how this would appeal to me based on my other current project). This appears to be very similar to the functionality in the serial TowerMan that can be used to produce ABS and APB signals, but with some added (I think) functionality based on LCC that makes it particularly appropriate for modular layouts. For some background on the original version, see the Towerman and Signalman manuals on their site. Presumably there will eventually be a Tower-LCC manual too.
The idea as used with LCC is to have a set of Tower-LCC nodes (one per module, although you could easily have more) and a way to use the two button programming to get them to learn a neighbor’s events and then use those to pass along information regarding signal aspects. This can be done for up to five tracks (labelled A through E). This uses some internal logic to generate different events for different signal aspects, of which they support 8 including a “track occupied” event. Layouts would map those eight events to specific aspects like “approach medium” that they wanted to display. I can’t say I really understand how this is supposed to work to generate aspects; the description is a bit too terse, as least on first reading. But it seems like a very useful capability, and I can see it being a big deal for modular clubs that want to add realistic signals.
What you’re basically doing is using events associated with a “track” between modules to mimic the function performed by a CTC “codeline” that sends signal aspects associated with a track. In a real CTC system, a code addressed to a signal causes the signal’s relays to process that code plus local data (like the state of track occupancy) to set the signal to an appropriate aspect, and to pass information along to the next signal so it can do its own processing.
Part of what’s used for this in the Tower-LCC is a set of 32 “logic conditionals” that can be associated with two different types of “groups”. These are used internally to set and evaluate some variables storing state, and appear to be how the events being sent down the line get processed. They and the logic that goes with them are performing the same function as trackside relays on a real railroad. It’s a very clever application of LCC events.
The first of these groups is the “mast group”, and when events for variables associated with it come in, they can modify those variables, and variables taken together can cause different events to be emitted “down the line” (every node actually sees all of them, but only pays attention to its two neighbors as per the usual LCC rules for only processing events a node has been configured for). This allows, for example, a module that has a turnout set to a diverging route to emit different events down the line based on whether the next block (on the next module) or the one beyond that are occupied, and its emitting different events than a module without a diverging turnout would emit (because diverging routes generally mean different signals).
Something I want to be clear on here is that an event such as “approach medium” for a track is not only different for each track in each direction, it’s a different event ID for each node emitting it. The numeric event ID is generated uniquely on each node based on that node’s unique ID, and when a node learns its neighbors events, it’s really learning a set of them so it knows what number that neighbor is using for “approach medium on track C”. Nodes emit their “approach medium on track C” when appropriate, but the actual event ID is the one they generated off their prefix (or possibly learned, but I think these are internally generated).
The other group of logic conditionals is the “ladder group”, and it’s used to allow more complex route setup to be done using the logic conditionals, so you can move beyond the simple “six events means six routes” approach I outlined above.
The Tower-LCC comes with a stapled set of pages describing it rather than a manual (complete with red-lettered additions; this is very much a work in progress). Google doesn’t turn up an online version of even this. The paper explains with more words (and colored flowcharts and lists of events) what I just outlined. But honestly, I couldn’t make any sense of it beyond what I just said (I couldn’t for the life of me say how it knows to generate an approach medium event, for example). Definitely something that’s going to take a few readings to sink in.
Still, this is incredibly impressive for a first LCC product.
The Tower-LCC has an LCC Unique ID assigned to it from the Manufacturer Specific set, written on a paper label as prefix 02 01 57. Which is exactly what I’d expect, as 57 is their manufacturer ID per NMRA S-9.2.2 in hexadecimal. The last six digits are assigned by them to the Tower-LCC (or anything else they make) at manufacturing time, and are effectively a serial number (I have 00 00 1F, serial number 31). I’ll have to power this up at some point to see what it actually emits, but I’m guessing that’s what it uses as a basis for its events.
In sum, I’m excited to see actual products for LCC, particularly from a company with the track record for solid hardware that RR-CirKits has (as I mentioned, I’ve used their LocoNet/Computer interface for years, going back to the original serial version). And with the LCC-Tower, they’ve instantly opened up a large range of useful things to do with it, as well as a very nice system for signaling that’s appropriate to modular layouts. That can only be good for LCC, and in the long run for all of us who want a standardized control bus.