DCC debate: Railcom or Transponding? Loconet or XpressNet?

Hello there,
I am planning to get a DCC command station (I expect to have my first decoder-equipped locomotives this winter), so I stumbled upon some
decisions to be made:
First one:
if I want two-way communication between decoder (locomotive) and central command, should I decide for Railcom (promoted by Lenz and slated to become an NMRA standard) or Transponding (promoted by Digitrax)?
I am not persuaded that Lenz's solution is the best (they offer Railcom only in their pricey 'Gold' decoders, the lighting in wagons needs modifications, etc.etc.).
Digitrax's solution (from a first read) seems to use the Loconet for sending the data from the decoder to the console, avoiding 'polluting' the signals on the rails with extraneous signals (but I may be wrong, I will have to re-read the documents).
Here is Digitrax's opinion: http://www.digitrax.com/faqtransponding.php
Here's Lenz opinion and information: http://www.lenz.com/techinfo/railcom.htm http://www.lenz.com/techinfo/railcomfaq.htm
Another idea would be to buy a booster and control everything from a laptop computer via JMRI in Java, but I get enough computers in my working hours already... :-)
Second question: Loconet or Xpressnet have better support and tools for expanding your system? Or it's a draw?
If the console can handle also Marklin/Motorola data/protocols, that would be nice.
What would you suggest for someone looking to start at a low cost into digital model railroad, with a view towards modular layout operation? (don't own any own layout, only the modules)
Here is a photo from our first public meeting, done last Sunday:
http://img221.imageshack.us/img221/2382/img0826smallpd1.jpg It's still a work in progress, but we hope to expand it.
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<snip>

become
IMHO, the real question is: do you really need or want two-way comms? Bi-Directional communication is really the bleeding edge of the hobby...and there's not too many people out there that acutally use it due to it's complexity and expense. Around 25% of US model railroaders use DCC (according to polls), and in most cases only large clubs, folks with large home layouts, and techo-geeks even have DCC block detection...say 5% of total DCC users? And then how many people of those that have DCC block detection have it connected to a computer, have signals, and then put Bi-D on top of that? This is sort of like the elite of the elite of the elite (not saying they're better, just really out on the leading edge of DCC technology). If you want to go there, great! But you probably won't find too many people out there in the wilderness with you (if you know what I mean). My club will eventually have Transponding, but we're still wiring up block detectors and haven't even started on signals, yet.

only
Supposedly, one will need to add an "inductor" to non-Bi-D decoders and accessories (like lighting, etc.).

sending
It's not really using the LocoNet...sort of. What it does is more of a low-grade form of Bi-D communications that sort of "echos" back through the track and rail buss to a receiver (RX8) mounted on the block detector (BDL168). This receiver (RX8) will then communicate with other LocoNet devices (as in computers, etc.) via the LocoNet. But really, it's still all going through the track originally. BTW, when I say "low grade", I mean that Transponding does not have as many features that 100% Bi-D will have someday. You can still get CV readback from decoders, and one can still do a lot with it, but there's apparently somethings that true Bi-D will do that Transponding cannot...I just don't know what that is because NMRA Bi-D is still not out yet (not that I've heard). Transponding, OTOH, has been out for years.

laptop
IIRC, to take full advantage of all the Bi-D comms offers, you still need a computer anyways. BTW, what do you mean using JMRI? You still need block detectors or other add-ons to read and use Bi-D decoders.

It's kind of interesting there. Lenz uses an open format (RS232?) for their communication buss, and there's a company out there called CVP that makes "EasyDCC". CVP's wireless throttles are compatible with Lenz systems...but CVP is about the only "third party" vendor for Lenz that I've heard of. Digitrax, OTOH, uses a closed format that is proprietary (LocoNet). One would think that proprietary systems would suffer no third party vendors because of it. However, Digitrax bascially charges peanuts for licensing, and uses the proprietary powers only to ensure that third party suppliers don't disrupt the LocoNet. There are currently a dozen third party vendors for LocoNet. http://www.digitrax.com/faqloconetq.php

AFAIK, Digitrax does handle Motorola Trinary protocols, but since that's not something I've ever much thought about (other than to say, what's that?), I really can't be 100% sure.

Well, these days there are no "bad" systems. There's nothing that comes to mind that would make one system or another better for modular layouts. Although, the Digitrax Zephyr might be good if only because the command station is lightweight, the power supply is a "wall wart" transformer (in the US, anyways), and it's relatively cheap ($160 US at Tony's: www.tonystrains.com). The Z also is a "throttle pack" design that allows it to be left in place. If you don't need to walk around with your train, the Z would be a good choice. Later on, of course, you could get more Digitrax throttles if need be...or even another Z.

Nice start...but geez, your meeting room is looking a little cramped! LOL
Paul A. Cutler III ************* Weather Or No Go New Haven *************
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pac Man wrote:

That's something I haven't given enough thought, but yes, this is a very valid question.
After all, we are just at our first stage, with a DC power supply and one locomotive running each time.
But in our next meeting, we expect to have DCC-equipped locomotives, and we wouldn't like to make an investment into a dead-end (and I understand that bi-directional DCC is a bit far into the future for us).
Regarding occupancy detection, I am trying to propose (read: persuade) to the other members the Free-mo SLO occupancy bus (it uses Ethernet Cat5 cable between modules, and it can 'see' two-blocks deep in each end of a signal). This was designed by Gregg Fuhriman, and it looks a very smart design to me. An introduction is at http://www.free-mo.org/node/94 , and there was an article in Railmodel Journal.

JMRI is a Java library that makes possible the existence of software that runs on Linux/Mac/Windows ('write once, run everywhere' is their motto).
Theoretically, with a serial or USB interface from your computer (Lokonet?) and a booster, you don't even need a command station anymore in order to control trains, only some throttles (or am I mistaken?). And I have already a second computer, so this idea is rather tempting to me...

There's also Roco in Germany that sells hardware compatible with XpressNet, like the LokMaus. http://www.lenz.com/xpressnet/xpressnetlist.htm has a list of XpressNet compatible hardware (probably not up to date).

This is the page that pointed me to JMRI...

I am asking about M?rklin support, because many Greek and European modelers use M?rklin rolling stock. These locomotives use center stub contacts ('pukos') between the tracks, and their data format is 'Motorola trinary' (a stupid marketing decision, if you ask me, that added unnecessary complexity in decoders and stations).
In fact, most European-built DCC command stations support both formats in the same time (so you can run M?rklin and DCC at the same time, but not the same tracks).

The problem is, that I haven't seen any Digitrax command station in Greece, so it's hard for me to buy based on specifications alone.
I have met consoles like Uhlenbrock's Intellibox and the eCoS from ESY, but these are rather pricey for my tastes (except if I catch one from Ebay?) And I have seen Tams (a small system with separate booster from the command station), nice and rather cheap - but it can only do double traction, not complete consisting as other stations.
And if you get a Digitrax or Lenz system (or something else), you are 'married' to it.
I am wondering, is there some comprehensive comparison between DCC command stations that is up-to-date, so I can select what suits our needs best?

Yeah, now that you mention it... :-) Next time, I am going to 'confiscate' the terrace of our house (80+ sq. meters should be enough, I guess :-) )
That's the good part of living in Athens, you have more days with warm enough weather for an outdoors meet. The flip side, of course, is that in the summer we get lots of days at 35+ degrees Celsius...
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I guess the next question is, what do you want Bi-D to do for you? Some of things, like reading loco's CV's on the mainline is more of a convenience. Others, like the ability to run out of fuel is, to me, more annoying than anything else. To me, the most critical thing about Bi-D is the ability to know (using a computer running CTC software) what train is where on the layout from a remote location. For you (or any modular layout), I think the ability to automatically stop trains when they pass a red signal would be the most important thing (provided you have a big enough layout to run more than one train per track). If you're just going to run one train per track, and you don't need CTC, and you can deal with putting your loco on a separate track to scan it, then why go through the expense and hassle of Bi-D?

we
From what I understand, the NMRA/Lenz Bi-D will not interfere with Transponding. Digitrax has also said that if there is a conflict that requires a software change, they will offer a chip upgrade for all Digitrax command stations. So if you go with Transponding or wait for NMRA/Lenz Bi-D, you really won't be trapped into a dead-end system. You may end up having to upgrade, but not a real "dead-end".

[shrug] I guess. I only know about Digitrax products for block detection these days, so I can't say if it's better or worse than another system. I don't even know if the above linked idea will work with DCC...

Oh, I'm familiar with JMRI. But AFAIK, the JMRI PanelPro merely displays data on the screen that is relayed to it by the various hardware detectors on the layout. By itself, it won't do much.

(Lokonet?)
I dunno about that. You need power, you need to be able to MU locos, throw switches, etc. and I don't think just a computer with JMRI will accomplish that (corrections welcome). With RR&Co.'s software suite, one still needs a DCC "brain" in order to talk to your locos. For example, the computer tells the brain to tell the decoder to move (or program or whatever). Without a "brain", it won't do much.

XpressNet,
Ah. Well, that would my ignorance showing about Lenz. BTW, I can't load that link. How many vendors are on it?

It was interesting to me because many anti-Digitrax internet talk focuses on the proprietary nature of LocoNet as if they were huge conglomerate trying to take over the hobby (or that they are Beta vs. Lenz' VHS, or that they are Apple vs. IBM, etc.), and yet Digitrax still has a dozen third party vendors.

modelers
Well, I think Digitrax handles it. What you have to do is "status edit" the address to be in trinary format. If you dig through their manuals (either the throttle or command station manuals) you should be able to find mention of it.

the
How does that work with that "third rail" of tie studs?

Greece,
That's tricky, alright. I like Digitrax products as they are a very forward thinking company that's pushing the edge of development, yet also maintains backwards compatibility. My club has had a Chief system for 9 years, and I've had the Z since it came out (5 years?). We love what it does for us. BTW, what's sort of amusing is that when we were checking out different systems, we actually tried Lenz and NCE, yet bought Digitrax based on nothing but the specs. of it.

but
command
"Double traction"? What's that?

Well...yes and no. You wouldn't have to change the decoders, and even the boosters are cross compatible (and the BDL168's can operate on non-Digitrax systems, too). You would have to swap out the "brain" and buy new throttles. But most if not everything else is compatible.

The only one I know of is at Tony's. www.tonystrains.com

We don't see too many outdoor HO layouts here in New England as we just got 20" (that's 50.8 cm) of snow in the past week. I was a little shocked to see your recent photo...and then I looked to see where you were posting from and I said, "Oh." :-)

35 C? Let's see that's...95 F. Yeah, that's not fun. I think it was only a couple years ago that we got a month-long heat wave (days of 90+) with high humidity. Right now, it's 1.4 C at just before midnight (thank goodness for digital thermometers...I didn't have to do the math!).
Paul A. Cutler III ************* Weather Or No Go New Haven *************
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pac Man wrote:

Hell, I don't even know what Bi-D is *capable* of doing! :-) (and I suspect many modelers aren't, yet, since NMRA hasn't finalized the standard yet).
Judging from your descriptions, it seems that ATP (automatic train protection) would be a nifty thing to have.
But, of course, this does mean I need to have occupancy detection first, etc.etc.
So, it seems that my question for Railcom vs. Transponding is 'a bit' premature...

They use it with DCC, since the occupancy detection is working on a separate bus. Then you overlay it with your signaling logic (2- or 3-aspect, etc.)
The core idea is to use three detectors per signal block: one infrared (optical) detector at begin and end of block (hidden between ties and pointing upwards), and one current detector per module that is included in the signal block.
As soon as at least one of the detectors catches sign of a train (even push-pull trains work with it), the particular block sends an 'occupied' signal (logical OR). The beauty of this is that it can work with push-pull trains (with locomotive pushing at the tail), and you do not need resistor equipped wheelsets for detection (hence avoiding a costly conversion process).
Since an Ethernet cable has 8 cables inside, you can transmit (due to some clever use of straight and crossover cables) occupation status of two signal blocks deep before and after each signal). You put detectors *only* on the mainline. If a switch is in a diverging position, this changes the status of the particular block as well.

My impression is that a DCC-speaking computer can substitute a command station completely.
The only things that seem to be needed are an interface (either USB-> Loconet/XpressNet or RS-232 -> Loconet/XpressNet) and a Loconet/XpressNet-compatible booster for powering the tracks (and throttles).

The page is out of date (2002), it lists Atlas, CVP and Roco besides Lenz in the products available. (I wonder, why isn't there a more up-to-date site for such a major DCC player?)

Fortunately, I am a relative newcomer to operation with DCC, so I wasn't involved in these holy wars of Digitrax vs. Lenz vs. whatever.

Strangely, Lenz (despite being a German company) doesn't seem to have Marklin support in their command stations (but I may be wrong). And Digitrax in their manual has only a terse 'support Motorola format' command. This is a bit thin, you know...

Well, the track rails have the same signal (the Marklin wheelsets aren't insulated, so they short the tracks), so you have again two connectors to connect power to.

'double heading' in American parlance. I mean, they cannot seem to have more than two locomotives in a train (I admit, it's very unusual for European practice to have 3+ locomotives on the point, but I want to be able to play USA-like scenarios).

I know about the decoder compatibility (thank God, or rather NMRA, for that!). Now, if NMRA had standardized the interface between the command station and throttles, things could be a little less chaotic.

Thanks for the pointer.
Unfortunately, this seems to be limited to USA-available systems (and I don't even see the newcomer Bachmann Dynamis, which is advertised in January Model Railroader).
Trying to clear=up the whole mess with command stations is going to be a challenge (especially when I add Marklin support in my requirements).
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Try finding a copy of the December 2003 "Model Railroader" (page 96). There's an article called "Third-generation DCC" that talks about what Bi-D can do.

In Digitrax, you'd need a BDL168, an SE8C, RX-8, RR&Co. or JMRI software, and a connection from the LocoNet to your computer. After you install all that, then you have to program all the logic into the software. It can get quite pricey and time consuming.

Well, it's good to know what you're aiming for at the start, so while it's a little premature, it's not like you went out and bought all this stuff when you don't have a layout (I've known people who stockpile for their future layout that they'll get around to...some day).

separate
Ah, it's got IR activation...that explains that.

I dunno about wheel detection being "costly". Sure, if you get Jay-Bee wheels, they're about $2 a pop, but there's nothing stopping anyone from installing their own resistors...and they are dirt cheap. One can either solder a surface mount resistor from the insulated wheel to the axle, or one can drill a small hole in the web of each wheel and insert a normal 1/4 watt or smaller resistor. BTW, shouldn't you have headlights or markers in your cab control cars in a "push-pull" anyways? That will light up the detector, too.

Well, if that was the case, then why would anyone who has a computer buy a command station? AFAIK, the JMRI or other software suites are very limited in what they can do without a command station. For example, I think they can only control one train at a time, etc.

Well, that might work with Digitrax because most boosters are also command stations (the DB150 is the Empire Builder starter set). I don't think that will work with anyone else's booster because they are just a booster, not a command station.

in
Atlas wasn't so much a third party "vendor" so much as they were a customer. All Atlas DCC (non-sound) locos and accessories were actually Lenz products with a different lable on them. In fact, if you look at the various Atlas circuit boards, they say "Lenz" right on them. Without Atlas, there's just CVP and Roco as third party support for Lenz? Ouch. So much for open architecture being so important... :-)

Oh, they are there just bubbling below the surface. Just wait, and you'll see 'em. 'Course, it's not as bad now, but 5 years ago it could get rather intense... lol

So thin as to be transparent, I agree. But then, I've been in the hobby (seriously) for 17 years...I go to 8 train shows a year including one of the largest in the world at Springfield, MA...I'm in a 60+ member RR club, and a member of a RR historical association...and I don't think I've ever seen Marklin trains in action with their system. I've *heard* of a couple guys that used to buy Marklin, but these people are rare. I mean, I've seen more TT (or live steam or On30) layouts that Marklin ones.

Ok. Yeah, in the US, four or 5 (or even 6) locos are not impossible.

and
The problem with making the command buss "standardized" is that it would have made everything just a Lenz knock-off. I like and appreciate my LocoNet too much to even consider having to use a Lenz command buss. If they had "standarized" the command buss, I think it would have caused more problems. Both Lenz and NCE constantly are upgrading their software, but can you imagine if each company was doing their own updates? Each time Lenz updates their software, NCE must as well, and vice versa. And if you don't update, your throttle woudn't work on your friend's layout, etc. Sounds like a mess to me.

Um, not for nothing, but I don't know what the "Dynamis" is, either.

That is totally true. Good luck!
Paul A. Cutler III ************* Weather Or No Go New Haven *************
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pac Man wrote:

Funny thing is, I am a subscriber of this magazine... *oops*
I suspect I overlooked this issue/article (I was so overwhelmed the latter year that some issues got never opened - and I guess Dec.2003 MR is one of these).

Oh no, I am not THAT much of a collector (only for Greek rolling stock, which is rare and it's "now or never" when buying). Before starting these modules, I was an 'armchair' modeler for more than a decade, until I got fed up with analysis/paralysis stage, and got help from another experienced module man.

It's not only in money, but in work and time.
And it's nice to be able to use a ready-to-run train/wagon without any modifications (many European modelers are leery of modifying a wagon or a locomotive, due to its high cost). Imagine having to modify (or, god forbid, paint) a 200-Euro locomotive. *That* would make many people nervous...

Well, there are also reverse moves (e.g. pushing back a freight train), so lighting/marker lights aren't always available when a locomotive pushes wagons into the mainline.

Well, here in Europe, things are *much* different regarding market share. The problem is, M?rklin does seem to target mostly the 'collector' market (somewhat like Leica camera owners).
There's (still) a big market of M?rklin users in Europe (that is much based in family tradition - these things just refuse to die :-), and grandfathers give these to younger generations, etc. )
And the 'concept' the M?rklin dealers seem to promote is 'loop or figure-eight layouts' and be done with it. There are VERY few M?rklin modelers who operate their trains, most of them are into the collecting (or, at most, the 'loop') stage.

In fact, I have even seen ATSF freights over Tehachapi with TEN (count'em, TEN!) locomotives at the point, in Steve Schmollinger's 'Tehachapi' book.
And there are these power moves (I remember seeing a dozen electric locomotives being moved in one of the mainlines in the Rhine valley as a single train - we speak about many thousand HPs on the move)

What kind of standard is this? To me, that's not exactly good engineering.

Well, it seems to be heavily promoted in both sides of the pond. For specs, look at this:
http://www.dynamisdcc.com/index.php

Thanks, I will need it.
And, unfortunately, the Greek market is still too small and not much beyond the limited 'digital starter kit' stage.
So, I have to ask about the experiences of international users, in order to avoid costly mistakes.
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
*snip*

As I understand it, it's thousands of potential HPs on the move. Chances are only one or two of those units is actually working, the others are just "big heavy boxcars." If you go digging through some railroad rule books, you'll see limits on how many axles a train can have online at one time. I think most of them limit it to 24. (That's 6 4-axle or 4 6- axle.)
Puckdropper
--
Marching to the beat of a different drum is great... unless you're in
marching band.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<snip>

Um, sorry, but you won't get much reaction from me. For example, I own a brass HO model of the New Haven "Comet" train (a 3-car high speed train set built in 1935 by Goodyear-Zeppelin...if you can believe it):
http://www.answers.com/topic/comet-train
This model cost about $1500US. When I got it, I opened it and ripped out all the interior lights, headlights, etc. and replaced them with new 12v bulbs. Then I installed two DCC decoders (one for each power car). I have also drilled out headlights on $400 brass steam engines, drilled out tenders for plugs for DCC, painted a brass 2-6-0, etc. I really have no qualms at all about modifying expensive (or cheap) trains to make them better.

True. At my club, we have a rule that the end of each train must have detection. Cabooses are great for that, as well as the FRED/EOT from Ring Engineering. It doesn't help with switching moves, but for mainline trains, it works out pretty nice.

based
grandfathers
If I had to guess, the lack of Marklin support is because Digitrax is an American company built for the US market (yet oddly enough, is owned by a New Zealander, A.J. Ireland). Perhaps the reason for Lenz not supporting Marklin has something to do with the fact that Bernard Lenz used to work for Marklin back in the 1980's. [shrug] It's pure speculation on my part.
<snip>

you
Ah, well that was a "what-if" scenario by me. My point is that right now, you *know* your Lenz throttle won't work on an NCE system. If they were cross compatible at the throttle level, and each company did their own upgrades, they might not be compatible...you'd have no way of knowing until you tried it. My other point is that if you confined DCC to the same control system, you'd wouldn't have the same kind of advancements that we see today. For example, Lenz still doesn't have a radio throttle, while Digitrax, NCE, and even MRC have radio throttles.

Oh, that thing. About the only thing I like about it is the alpha-numeric display possibilities. Everything else, I don't like. Infrared instead of radio? A throttle lever instead of a knob? A menu-driven interface instead of one-button = one-function? And the size of the thing...it's a two-hander by all appearances. How do you operate with it? Sigh. It's not a bad attempt at a better display, but the rest is just...ick.

beyond
to
You can also try the Model Railroader Forum and the Atlas Forum for more opinions and options. This newsgroup is really a shadow of it's former self. Heck, I'm suprised more people haven't jumped into this thread...
Paul A. Cutler III ************* Weather Or No Go New Haven *************
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pac Man wrote:

I suspect you are not a very typical modeler then :-)
Seriously, with a typical locomotive costing 200+ Euros ready-to-run, most people in Europe are afraid of experimenting with weathering or superdetailing (shades of 'collector syndrome' here).
At least, in the USA there were (or are still there?) cheap locomotives that you have no qualms of butchering up and kitbashing. When a mainline locomotive in Europe starts at 150+ Euros, most European hobbyists wouldn't dare touching it...

Hm, today most trains even in Greece are cabooseless, and demanding from others to modify their wheels isn't going to be very popular... :-) And there are passenger trains as well, without a thing like FRED but depending on signaling to keep them safe.
[ Regarding lack of Marklin support from major DCC manufacturers ]
From what I can understand, Marklin wants to keep an 'iron fist' around their customers, trying to keep every other company away.
They made a big 'Central Station' system, with lots of features, but this beast spits only Marklin/Motorola format (and they have also introduced all kinds of unusual ideas, like 'mfx' bidirectional data from their decoders etc. And, of course, they aren't very open (if at all) to other companies about the technical details.

Mine idea was a standardized control bus (or network, or something like that).
I have been disappointed with all this mess and incompatibilities, and seriously I would suggest everybody add an Ethernet adapter to their throttles (or something like that) and be done with it.

Well, there's even more. Let me introduce you to the current high-end of European digital command stations that support both DCC and Marklin, plus Selectrix and some other strange formats (e.g. LGB):
Uhlenbrock Intellibox:
The veteral of multiprotocol command stations, nearly 3 years old if I remember correctly. It can accept LocoNet and Roco/Marklin boosters and throttles as I can see.
At http://www.rjftrains.com/intellibox/intellibox.htm there are manuals/FAQ, etc.
ESU ECoS:
Short brochure: http://www.dccsupplies.com/documents/esu/ECoS%20overview%202006.pdf Full manual: http://www.loksound.de/download/anleitungen/ECoS/50000_ECoS_ESUKG_US_Betriebsanleitung_Auflage_I_eBook.pdf
Very impressive specifications, nice screens, looks well engineered, runs Linux with an ARM processor, very upgradeable. It has a different bus for expansion (based on some industrial specification), but with their 'sniffer' they can incorporate an existing system.
Viesmann Commander (probably the uber-high end, and the newest model of all): Full manual here, it can even cooperate with ready-made track panels for automagic operation and routing, if my reading is correct: http://www.viessmann-modell.com/pdf/Commander-GBS_InfoFlyer_112006_GB-monitor.pdf
Nearly every of these command stations supports the s88 bus for occupancy detection, besides various other protocols. Impressive machines, but the price is upwards of 500 Euros (most probably 650+ Euros for the Viesmann).

Really, I remember lots of lively discussions until nearly the time that 'Big John' Dalton left for the station high above... After his absence, things were ugly here for a looong time, and many old-timers have left for other places.
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Nick Fotis wrote:

Like Paul I have no qualms at all about taking soldering tweezers to a $1000.00 locomotive to change detail or make modifications. In fact I once disassembled an OMI F3A-B-B set and sent the shells off to a plating service and had them bright nickel plated. This was before OMI even offered them plated. The Locomotives I was modeling had stainless steel flanks and at the time there wasn't any other option.
Note: When I finally sold them I got a Kings Ransom for them. Modifications if done correctly and to match a prototype won't hurt the value of an object.
But I don't consider myself anything but a typical modeler either.

I have no doubt that the phenomenon that you describe is common. I have heard it referred to as the "Wash and Wear Crowd". Which is fine. For me, and most of those that I hang around with, we model a specific prototype. Doing so unfortunately means making changes to an existing model. Regardless of the cost.... If the starting point is *close enough* then your changes might be minimal. I actually own an Airbrush too... <lol> So dipping a $200.00 model into the stripper because the factory paint wasn't good enough might sound like heresy.

Again I'm not sure that this is a European thing or an American thing. Some people model ... some people run trains. They both get to do exactly as they like since it is their hobby.

I'm not sure that soldering a resistor across one wheelset is all that big a deal is it ? Or some resistance paint ?
[snip]

Heh .... Good luck with that ! <g>
Sadly there is a lot of room for improvements to be made with DCC and even DCC/Sound. Try and find the setup with least fleas and use that one.
Regards
Bill
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
William R. Mattil wrote:

Well, the strict modelers group is very small in numbers here in Greece, and they don't seem to be 'big spenders' (at least, that's my impression).
We will have to accommodate everybody (at least in the start, until we reach a 'critical mass', they specialize to DCC or Marklin Digital groups or something else).

Well, at least this hybrid method of occupancy detection seems the least intrusive to other people, who may say 'no way I am going to modify my standard locomotives/wagons in order to play with your modular layout'.
This could be called a 'least resistance' method (similar to my use of Marklin track, despite their code 100 rails and their center studs and their unrealistic appearance in general - I will go out of my way to accommodate everyone, up to a point).

If you look at the new breed of high-end of command stations I mentioned in my previous post, at least the ESU ECoS has already an Ethernet jack and runs Linux (already it includes a Web server, so you can access it with a Web browser via Ethernet). And the Viesmann has a USB 2.0 socket (OK, that's not suitable for a wired network, but I suppose there are Ethernet-USB adapters).
A dirt cheap Ethernet hub has 10 Mbps speed, can contain 24+ ports (which can be cascaded, with a switch at the root of the network), and the cables can go up to 90+ meters distance if I remember correctly (or it is for 100 Mbps?). Heck, a used Cisco Catalyst 24-port switch (not even an ancient hub) can be found at 50 dollars.
Or you could use a WiFi system for wireless connection of throttles and other peripherals to a command station. No messy radio controls, just simple WiFi that works everywhere in Europe and USA (as far as I know).
Or we could do away with command stations entirely, and load a personal computer (e.g. a notebook) with all the controlling logic, Ethernet interface. Nearly every notebook PC has a USB and an Ethernet connection, so you could use it as a 'router' between the booster and the throttles, and keep all the command station controls and logic inside the general purpose computer.

I heard there's again another connector (with 21-pins instead of 6- and 8-pins). At some time (now?), I feel there should be less fiddling and more standardization, in order to lower prices down via mass production.
Cheers, N.Fotis
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

As a personal preferance, I like seeing my locos clean. It's pure fantasy on my part for most of my locos, but I can go and weather them later. I'm not quite at the level of one of the RPM guys (those that can exactly copy a picture of a model), but I guess I'm working my way up to that.

that
Yeah, we still have Athearn (around $55 per loco), not to mention the el-cheapo Bachmann and Life-Like trainset types that are good for weathering practice if nothing else.

Well, at my club we're in the 1950's (even tho' we allow any era equipment), so cabooses are the norm. But for those that don't want cabooses, they have to use a FRED. All passenger cars must have detection, because any one of them could end up on the rear of a train. Fortunately, that's not a big deal because most US passenger car models can be lit fairly easily (if they aren't already).

all
Which might also go a ways to explain the lack of Marklin support from DCC manufacturers.

It's not as simple as that. The throttle buss (control buss, network buss, whatever you want to call it) is unique to each manufacturer. Lenz and LCE use RS232 polled buss, while Digitrax uses LocoNet (which is more LAN like in that it's peer-to-peer). I don't know what Zimo or MRC uses, but I imagine it's not compatible with anyone else, either. The info that travels over the network is different for each one. I don't think it's like getting an Apple to talk to an IBM via Ethernet, I think it's more like trying to get FORTRAN and QBASIC to talk to each other. IOW, LocoNet is a completly different "language" than Lenz...you'd need one heckuva translator.

From what I can figure from the FAQ, it appears that the UI is compatible at the track level, but not really at the command buss level (except in the "brain"). It appears that one has to have a seperate command buss for each different kind of throttle that you'd want to use. So wherever you plug in, you'd have a LocoNet jack plus a different jack for each other system in use. It's not a bad idea as the UI is the "translator", however it's not really like just sticking an Ethernet jack on each throttle.

http://www.viessmann-modell.com/pdf/Commander-GBS_InfoFlyer_112006_GB-monitor.pdf
But the question is, can any system handle every throttle via the same command buss? I don't think it's possible.

While Big John's journey to the roundhouse in the sky (RIP, Big John) was certainly a factor, IMHO r.m.r took the big nosedive after 9/11/01. Every mother's son and daughter suddenly wanted to talk politics here, and any resistance to that was met with, "There are more important things than model railroading!". While of course this is true, that doesn't mean that you post off-topic threads here just like you don't talk politics when you're at your kid's dance lessons. There's a time and place for everything, and some people come here to get away from worldly events.
Paul A. Cutler III ************* Weather Or No Go New Haven *************
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 12/26/2007 8:50 AM Pac Man spake thus:

Just a tiny note: it's "bus". A "buss" is a kiss.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pac Man wrote:

Problem is, in European (and Greek) practice you do not see often a FRED-like separate device (the prototype often uses axle counters or other kinds of track detection).
Now that I am thinking of it, many trains have a red light in their last wagon, but it won't be easy to fit such a thing inside a scale wagon. But all discussion is still a bit premature, since we haven't yet even a track power standard (DC at the moment, DCC in the near -I hope!- future).

Well, I was venting up my frustration. Surely it's not 'simple', but (at least in theory) would be doable to have a simple IP-like protocol over Ethernet serving the needs of bidirectional command_station <-> throttle communication.
After all, TCP and IP are more than capable of carrying every kind of data and you have a TCP/IP stack in most computer devices already (the ESU ECoS runs Linux inside and has an embedded Web server inside).
I know, 'loading' a throttle with a full TCP/IP stack sounds a bit crazy, but it can be done rather cheaply (if we speak about mass produced quantities). There are lots of smallish microcontroller boards that 'speak' TCP/IP and have an Ethernet interface.
Or we even could use WiFi for wireless throttles, and do away with radio frequencies, spectrum allocation and all that. Again, I simplify things a bit, but why reinvent the wheel when the computer communications people have already solved all these problems?
We accuse Marklin for trying to lock-up their customers, but in reality every DCC command station manufacturer tries to manage the same trick with their station-to-throttle interface.

Which, in my opinion, is not a good state of affairs. After nearly a decade of DCC use, we ought to know how to design a definite command_station <-> throttle (and other peripheral) bus.

Or we could add, say, a TCP/IP layer, then make the device 'look' to a LocoNet command station as a LocoNet peripheral, to a XpressNet like a XpressNet device (for an interim period). We could have a 'translator' box from TCP/IP to Loconet, another 'translator' box from TCP/IP to XpressNet and 'native' TCP/IP throttles with an Ethernet interface. [discussing Uhlenbrock Command station] Speaking from memory (always a tricky thing...), the Uhlenbrock IB has: Loconet socket, Roco Lokmaus socket, and can accept Marklin throttles via a Marklin command station. Not too bad, in my opinion. If they had also a full XpressNet socket, this could be called a 'universal command station'.
Now, we are seeing a new round of divergence in command station connections to throttles etc. The ESU ECoS has its CAN-based interface (and they have the 'ECoSniffer' for attaching an existing command station with its throttles as well). The Viessmann has yet another kind of interface, the Bachmann Dynamis yet another, ad nauseaum.

If we have an intermediate layer like TCP/IP, the problem becomes much more manageable, in my opinion.
Like the PBM image format: instead of writing, say a TIFF to JPEG converter and a TIFF to PNG converter (and their counterparts), you have a TIFF<->PBM and the PBM<->JPEG, PBM<->PNG converters (so, adding a new file format involves only a translator to/from the intermediate format). Else, you will have to write N! (= 1*2*3*....*N) converters, where N is the number of formats/protocols.
Of course, such a course of action would mean the manufacturers of command stations wouldn't have a grip anymore on the peripherals market... And then you could have general-purpose computers intermingling with boosters, command stations (or even replacing the latter altogether), and throttles or other peripherals over Ethernet.
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I like the idea of DCC over TCP/IP, it sounds like it'd be a great low- cost way to get in to DCC. You'd have to go all the way to having the network controlling trains, however, not just throttles talking to command stations.
There's a couple issues standing in the way, if you're talking about networking a whole layout. Network cables are difficult to terminate (I've done it several times), they tend to be sensitive to things like splices, and most current network topologies are star based. That means to add a new device, you have to run the cable back to the hub (switch).
There's also the issue of power. I haven't wired a DCC system myself, but it does occur to me that network is designed for communication only. If you have a network switch controller, how are you going to get power to throw the turnout?
Perhaps most importantly, TCP/IP and networking isn't easy. Yes, much of it can be simplified with DHCP, but you've still got to figure out what addresses you want your DHCP server to serve, how to secure your wireless network, viruses, and other such issues.
Like I said above, I do like the idea. I'm not attacking it, just pointing out a couple of the issues that will come up.
Puckdropper
--
Marching to the beat of a different drum is great... unless you're in
marching band.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Puckdropper wrote:

I was thinking about using the network (either Ethernet or WiFi or whatever - it's not even necessary to have an Ethernet switch) as an intermediate between command stations and throttles/peripherals.
Or, let me rephrase it, 'as a data transport between command stations and throttles/peripherals'. Or, even further, 'as a data transport between locomotives and controllers' (and we bypass command stations entirely? a little hard this one, since there is a need for power to go to the locomotives, hence the booster part is still necessary)

There are two options: either you put a central hub/switch at approximately the center of the layout, and probably 2-3 small hubs at close the ends of the layout (a 'star of stars' topology).
There are ready-made Cat5 cables, very cheap and run-of-the-mill, up to distances like 30 meters. How much more do you need? And you can use small/el cheapo hubs at nearly the ends, as a kind-of repeaters (if I remember correctly, you can cascade up to 3 Ethernet switches at 100 Mbps).
On the other hand, since you have TCP/IP as a base protocol, you can go the whole hog and do away even with Ethernet - you can use WiFi or WiMAX as a transport mechanism, with TCP/IP over it.

Turnouts and other paraphernalia get power (and commands) from either the track supply or the accessory bus. My idea is that you put 4 basic cables passing through all modules: two for track/DCC power, and two for accessory control/power (e.g. for turnouts or solenoids).

Well, we could have a very simplified protocol (sort like a client-server FTP-like protocol) for communicating between command station and throttles. A central software server (like an FTP service) would handle the communication with the throttles/peripherals. That is for native TCP/IP hardware, the LocoNet or XpressNet or whatever devices could get fooled that on the other side there's just another LocoNet/XpressNet box respectively.
WiFi and WiMAX have their ways of securing communication somewhat. Viruses are a problem if you are executing programs over the network (which is expected to be isolated from the Internet, probably with a firewall, or not even connected at all). If everything you run is only a protocol like FTP and you do not run programs off the network, things become rather secure, IMHO
An example of such communication would be: command_station_address:decoder_address:DCC_protocol_version:command:parameter1:parameter2 this could be transmitted as a data packet from the central command station to a decoder. The decoder could reply, say, as decoder_address:command_station_address:DCC_protocol_version:command:result_code
Decoder_Address and Command_Station_Address could be private IP addresses (like the ones starting from 192.168.xx.xx). Similarly, throttles would have their IP addresses (maybe these could communicate directly with the decoders, bypassing the central stations? Here we have the problem of supplying power to the trains, though, so we cannot sidestep the booster part).
If anybody implements this, remember you read it here first :-) I cannot wait for a day to 'ping' my locomotives from my PC :-)
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 12/26/2007 4:01 PM Nick Fotis spake thus:

Allow me to interject here, and please pardon any ignorance on my part of the topic under discussion.
I think I know enough about electroncs, data communication protocols, etc., to at least raise some interesting questions here.
The idea of using TCP/IP as a communication medium for DCC is intriguing, to say the least. Some comments:
o So far as using TCP/IP for communicating directly with locos goes, wouldn't the inherent noise pretty much rule this out? It's hard to imagine a clean-enough signal on model railroad track, with spikes being generated at random places and times by locomotives (and even rolling stock).
o The idea of using TCP/IP as an underlying protocol is compelling, but one is still left with the problem of what to use as the actual protocol, no? In other words, TCP/IP could be used as the low-level protocol, but one would still have to choose the high-level protocol (Locotrol, etc.) to use. But here's an idea:
o What about a smart, "adaptive" system that could recognize, and transmit, signals for *any* protocol? Here's what I have in mind:
If the data communication system used in our hypothetical command/control system was smart enough, in theory it could "listen" to commands being sent through the system, then figure out what protocol is being used for those commands. Then it could respond in kind, adapting to the protocol in use (conceiveably even switching dynamically between protocols). This would only require minimal code, far less, say, than what runs the average cell phone. DIYers could program it themselves.
I'm curious about what the actual protocol used to control/communicate with locos would look like. Would it be present-day DCC? some variant thereof?
For instance--and here, please excuse me for going pretty far out on a limb--couldn't you have a system where the power is always present on the tracks as low-frequency AC (say, 50/60 Hz), with the high-frequency signal superposed on top of it? Could you make such a system fairly noise-immune?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

You'd still have to get enough power to the locomotive, too. Cat 5 is usually #24 (or thereabouts) gauge wire, a far cry from the #12 gauge in the NTrak PowerPoles RP (the #12 bus is for DCCers concerned about voltage drop.)

That sounds great, but it might be a little difficult. We might be over "computering" model railroading. I, for one, would like to avoid the headache of what protocols your DCC system has installed. (If you have multiple protocols, you have to allow for alternate installs. Updates will be issued periodically, even HTTP has version 1.1.)

I like the idea of using present day DCC on the tracks. Your trackside accessories such as turnout machines and signals could use TCP/IP for control (and perhaps state?) and tap in to the power bus when they need power.

(I don't know, but I haven't snipped yet as I'm replying to the whole post, inline.)
Puckdropper
--
Marching to the beat of a different drum is great... unless you're in
marching band.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Puckdropper wrote:

Let's pause for a moment, and think the answer to the question: 'what are the problems with DCC on the rails? where does it stop us technically from achieving our goals?'
My argument is that using TCP/IP as a mechanism for communicating between command station/boosters and throttles or other accessories like fast clocks/speed meters/whatever, would permit freely intermixing throttles with a booster/computer combination.
The transport hardware would be plain Ethernet and/or WiFi (imagine a Starbucks hotspot used in a club layout :-) ). WiFi could be used as a way to let dozens of small wireless throttles or PDAs control locomotives on a layout.

Now, the turnout machines are powered off the DCC power on the tracks or from a separate power source? (e.g. 16VAC). And how do you send today commands to the stationary decoders? (I guess via the rails?)
The idea of 'plug-and-play' anything into an Ethernet switch or a WiFi hotspot sounds appealing, but I do not know if it's worth it. If we keep DCC boosters on the rails, these should be good enough (and standardized) for the task.
It's not very clear to me why a typical notebook PC with, say, a LocoNet or XpressNet adapter wouldn't be able to control a layout with a direct connection to a booster. I suppose there's more to DCC command stations than the standard logic of DCC data.
Cheers, N.F.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.