DCC debate: Railcom or Transponding? Loconet or XpressNet?
Nick Fotis
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.
Pac Man
"Nick Fotis" <nfo...@otenet.gr> wrote in message
news:fk9cej$s8p$1...@ulysses.noc.ntua.gr...
<snip>
> 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)?
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.
> 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.).
Supposedly, one will need to add an "inductor" to non-Bi-D decoders and
accessories (like lighting, 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).
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.
> 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... :-)
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.
> Second question: Loconet or Xpressnet have better support and tools for
> expanding your system? Or it's a draw?
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
> If the console can handle also Marklin/Motorola data/protocols, that would
> be nice.
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.
> 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)
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.
> 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.
Nice start...but geez, your meeting room is looking a little cramped!
LOL
Paul A. Cutler III
*************
Weather Or No Go New Haven
*************
Nick Fotis
> "Nick Fotis" <nfo...@otenet.gr> wrote in message
> news:fk9cej$s8p$1...@ulysses.noc.ntua.gr...
> IMHO, the real question is: do you really need or want two-way comms?
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.
>> 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... :-)
>
> 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.
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...
>> Second question: Loconet or Xpressnet have better support and tools for
>> expanding your system? Or it's a draw?
>
> 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.
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).
> Digitrax, OTOH, uses a closed format that is proprietary (LocoNet).
> for LocoNet. http://www.digitrax.com/faqloconetq.php
This is the page that pointed me to JMRI...
>> If the console can handle also Marklin/Motorola data/protocols, that
>> would be nice.
>
> 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.
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).
> 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.
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?
>> 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.
>
> Nice start...but geez, your meeting room is looking a little cramped!
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.
Pac Man
>
> That's something I haven't given enough thought, but yes, this is a very
> valid question.
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?
> 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).
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".
> 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.
[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...
> 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).
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.
> 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...
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.
> 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).
Ah. Well, that would my ignorance showing about Lenz. BTW, I can't
load that link. How many vendors are on it?
> > Digitrax, OTOH, uses a closed format that is proprietary (LocoNet).
> > for LocoNet. http://www.digitrax.com/faqloconetq.php
>
> This is the page that pointed me to JMRI...
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.
> 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).
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.
> 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).
How does that work with that "third rail" of tie studs?
> 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.
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.
> 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.
"Double traction"? What's that?
> And if you get a Digitrax or Lenz system (or something else), you are
> 'married' to it.
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.
> 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?
The only one I know of is at Tony's. www.tonystrains.com
> 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 :-) )
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." :-)
> 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...
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!).
William R. Mattil
>
> 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.
Hi Nick,
In another thread did I hear you refer to that as the Feather River ? As
in Western Pacific ?
Regards
Bill
Nick Fotis
> Hi Nick,
>
> In another thread did I hear you refer to that as the Feather River ? As
> in Western Pacific ?
Hey, you misunderstood me. I meant that the 'Centennial' locomotives plied
the Feather River Route in the *prototype* (see Steve Schmollinger's
'Feather River Canyon: Union Pacific's heart of stone' hardcover book, with
some impressive photos from regular freight trains besides Feather River).
In my (freelanced) modules I want to make some dramatic mountain/river
landscapes, like the ones in Greece, but no Keddie Wye (yet :-) )
Cheers,
N.F.
Nick Fotis
> "Nick Fotis" <nfo...@otenet.gr> wrote in message
> news:fkbfgg$gpa$1...@ulysses.noc.ntua.gr...
>>
>> That's something I haven't given enough thought, but yes, this is a very
>> valid question.
>
> I guess the next question is, what do you want Bi-D to do for you?
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...
>> An introduction is at http://www.free-mo.org/node/94 , and there was an
>> article in Railmodel Journal.
>
> [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...
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.
> 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).
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).
> Ah. Well, that would my ignorance showing about Lenz. BTW, I can't
> load that link. How many vendors are on it?
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?)
> It was interesting to me because many anti-Digitrax internet talk
> focuses on the proprietary nature of LocoNet as if they were huge
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.
> 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.
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...
>> 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).
>
> How does that work with that "third rail" of tie studs?
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.
>> 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.
>
> "Double traction"? What's that?
'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).
>> And if you get a Digitrax or Lenz system (or something else), you are
>> 'married' to it.
>
> 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.
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.
>> 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?
>
> The only one I know of is at Tony's. www.tonystrains.com
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.
William R. Mattil
>
> Hey, you misunderstood me. I meant that the 'Centennial' locomotives plied
> the Feather River Route in the *prototype* (see Steve Schmollinger's
> 'Feather River Canyon: Union Pacific's heart of stone' hardcover book, with
> some impressive photos from regular freight trains besides Feather River).
Nick, if you found that book good reading see if you can locate a copy
of Ted Bensons "Echoes Down the Canyon". Pretty darn spectacular with
some excellent description of UP's power shortages and the result
invasion of the Canyon by "Big Jacks". Tons of photos too.
BTW - it would not be too hard to create a passable DD40X from an
Athearn DD40 shell and a widecab.
>
> In my (freelanced) modules I want to make some dramatic mountain/river
> landscapes, like the ones in Greece, but no Keddie Wye (yet :-) )
Best Regards
Bill
Pac Man
>
> 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).
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.
> 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.
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.
> So, it seems that my question for Railcom vs. Transponding is 'a bit'
> premature...
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).
> 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.
Ah, it's got IR activation...that explains that.
> 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).
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.
> My impression is that a DCC-speaking computer can substitute a command
> station completely.
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.
> 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).
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.
> 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?)
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... :-)
> 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.
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
> 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...
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.
> '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).
Ok. Yeah, in the US, four or 5 (or even 6) locos are not impossible.
> 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.
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.
> 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).
Um, not for nothing, but I don't know what the "Dynamis" is, either.
> 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).
That is totally true. Good luck!
Nick Fotis
> "Nick Fotis" <nfo...@otenet.gr> wrote in message
> news:fkev3a$11rp$1...@ulysses.noc.ntua.gr...
> 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.
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).
> 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).
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.
>> 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).
>
> I dunno about wheel detection being "costly".
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...
> 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, 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.
> 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.
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.
> Ok. Yeah, in the US, four or 5 (or even 6) locos are not impossible.
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)
> 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.
What kind of standard is this?
To me, that's not exactly good engineering.
>> 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).
>
> Um, not for nothing, but I don't know what the "Dynamis" is, either.
Well, it seems to be heavily promoted in both sides of the pond.
For specs, look at this:
http://www.dynamisdcc.com/index.php
>> 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).
>
> That is totally true. Good luck!
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.
Puckdropper
*snip*
>
> 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)
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.
To email me directly, send a message to puckdropper (at) fastmail.fm
Pac Man
<snip>
> 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...
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.
> 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.
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.
> 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.
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>
> > 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.
>
> What kind of standard is this?
> To me, that's not exactly good engineering.
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.
> Well, it seems to be heavily promoted in both sides of the pond.
> For specs, look at this:
>
> http://www.dynamisdcc.com/index.php
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.
> 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.
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...
Nick Fotis
> 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.
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...
> 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.
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.
> 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.
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, it seems to be heavily promoted in both sides of the pond.
>> For specs, look at this:
>>
>> http://www.dynamisdcc.com/index.php
>
> 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.
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).
> 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...
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.
William R. Mattil
>
> I suspect you are not a very typical modeler then :-)
>
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.
> 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).
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.
> 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...
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.
> 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.
I'm not sure that soldering a resistor across one wheelset is all that
big a deal is it ? Or some resistance paint ?
[snip]
> 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.
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
Nick Fotis
> Nick Fotis wrote:
>> 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...
>
> 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.
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).
>> 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.
>
> I'm not sure that soldering a resistor across one wheelset is all that
> big a deal is it ? Or some resistance paint ?
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).
>> 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.
>
> Heh .... Good luck with that ! <g>
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.
> 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.
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
Pac Man
>
> 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).
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.
> 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...
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.
> 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.
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).
> 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.
Which might also go a ways to explain the lack of Marklin support from
DCC manufacturers.
> 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.
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.
> 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:
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.
> 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).
But the question is, can any system handle every throttle via the same
command buss? I don't think it's possible.
> 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.
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.
Nick Fotis
>> 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.
>
> 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).
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).
>> 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.
>
> It's not as simple as that.
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.
> The throttle buss (control buss, network
> buss, whatever you want to call it) is unique to each manufacturer.
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.
> 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.
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.
> But the question is, can any system handle every throttle via the same
> command buss? I don't think it's possible.
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.
David Nebenzahl
> 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.
Just a tiny note: it's "bus". A "buss" is a kiss.
Puckdropper
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.
Nick Fotis
> 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.
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'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 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.
> 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?
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).
> 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.
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.
David Nebenzahl
> Puckdropper wrote:
>
>> 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.
>
> 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.
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?
Puckdropper
news:4773061f$0$16360$8226...@news.adtechcomputers.com:
> On 12/26/2007 4:01 PM Nick Fotis spake thus:
>
>> Puckdropper wrote:
>>
>>> 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.
>>
>> 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.
>
> 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).
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.)
> 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.
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'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?
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.
> 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?
(I don't know, but I haven't snipped yet as I'm replying to the whole
post, inline.)
Nick Fotis
> 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).
The noise-suppression (and error-correction) can be handled by TCP/IP
(remember, when they invented packet-switching the best they had was analog
modems - remember SLIP/PPP?).
That is, if you want to put TCP/IP data modulated on top of low-voltage AC
power (much like DCC does already, but in higher frequencies, if you want
enough bandwidth).
But there would be lots of overhead and possibility of errors in
transmission in such a scheme (a CSMA/CD scheme like the original 3-10 Mbps
Ethernet could cope with such a case, I think).
> 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:
Now you raise another problem:
how do you communicate with locomotives and stationary decoders, while
providing these with power at the same time?
To me, DCC on rails looks like an ingenious solution (adding information on
a low-frequency square wave carrier that server as power is a smart idea,
in my humble opinion). Don't know about the 'clutter' by various decoders
responding back to the command station in a BiDi scheme (probably they are
using a coaxial Ethernet-like scheme?)
If you want to transfer whole TCP/IP packets, you will need probably higher
bandwidth (don't know what the DCC data bandwidth is on the rails, but I
wouldn't be surprised to hear it isn't much higher than an RS-232 serial
connection). And TCP/IP have significant overhead per data packet (in order
to have routing and fault-tolerance).
> 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?
There's already Ethernet over AC power, so this can be done.
Look at
http://www.ietechsmart.com/shop/cart.php?target=product&product_id=1024&category_id=134
for a typical product.
I wouldn't like to put 230 VAC on the rails, though, modulated or not
*grin* :-)
Cheers,
N.F.
Nick Fotis
> David Nebenzahl <nob...@but.us.chickens> wrote in
> news:4773061f$0$16360$8226...@news.adtechcomputers.com:
>> 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:
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.
>> 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?
>
> 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.
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.
David Nebenzahl
> David Nebenzahl wrote:
>
>> 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?
>
> There's already Ethernet over AC power, so this can be done.
> Look at
> http://www.ietechsmart.com/shop/cart.php?target=product&product_id=1024&category_id=134
> for a typical product.
So I'm not completely nuts; good. This would seem to me to be the best
scheme; one that supplies both power and data on two conductors, and
does it in a reliable way. (I'm not convinced that DCC is so hot; all
those square waves, generating all those harmonics, seems like a perfect
way to generate errors ...)
> I wouldn't like to put 230 VAC on the rails, though, modulated or not
> *grin* :-)
Of course not; we here in the U.S. wouldn't want to see 120 VAC there
either. We're talking the same voltage range as DCC (< 20 VAC).
Eric Mayo
>
> 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).
> (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.
> 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...
> lighting/marker lights aren't always available when a locomotive pushes
> wagons into the mainline.
> 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.
> 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)
> To me, that's not exactly good engineering.
> For specs, look at this:
> http://www.dynamisdcc.com/index.php
> 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.
priced electronics that do very little so I began looked into the
technology recently. I wound up designing & building a DCC decoder using
PIC Microcontroller. It handles base line and extended packet format
which seems to be the latest NMRA standards for about $5 in parts;
comapred to the $49 and $100 range for commercial ones that are buggy.
MRC decoders are the worst I've run into.
Also, I have a background in programming and electronics and am an
embedded engineer by day.
I want to be able to have my decoders programmable so I looked at the
ACKing that is needed and even that appears to have some disagreements
with NMRA pushing Lenz/Railcom and Digitrax off doing their own thing.
As for Transponding/Digitrax vs. Lenz/Railcom - the Digitrax concept is
more appealing as it does not require a power interruption on the rails
like the Railcom design requires. With the Railcom, a break, as they call
it, is where they "short" the rails together (kid you not, read the
spec.). It's not really a short or else nothing would be able to
communicate. Anyway, they stop applying DCC signal between packets and
long enough for a Railcom decoder long enough to respond with track pulses
similar to RS232. The problem with this design is that the decoder needs
a hefty capacitor to give it enough power during the dead time to power
the microcontroller and its support circuitry. Probably not a huge deal
but it's extra cost and complexity in the decoder electronics.
With the Digitrax/Transponding concept/system, the decoder pulses the
motor or basically draws current after a DCC packet during what I think is
the stretch bit period of normal DCC (not 100% sure on that part) but the
point is this concept doesn't require a power interruption like the
Railcom. A stretch bit is a long 0 and during this time the DCC command
station or BDL16 listens for these pulses and counts them to relay back
over Loconet. The BDL16 acts as a proxy. With Digitrax/Transponding,
this IDEA would work over other network buses like Xpressnet or CAN too.
All this just seems stupid to me. I can't understand why something like
CAN (like what is used in automotive) can't be used to just replace DCC.
CAN has been around for years and is bidirectional with bus arbitration
capabilities and most microcontroller families already have CAN
capabilities built into the silicon.
And while on my soap box, I just have a real problem with a standards
organization like the NMRA who doesn't seem very competent. The Railcom
solution is not as good as Transponding and their own web site is
problematic. None of their email contacts work, they have misspellings,
the RPs have contradictory language and the whole outfit just seems very
unprofessional and lacking because of these things. How did they come to
power anyway? This hobby needs current technology to intervene and I'm
not convinced the NMRA in in a position to drive this forward.
Go with Digitrax/Transponding. They have a better solution,
technologically speaking, and they have a track record of their products
being upgradeable through out long life times.
--
posted from
http://www.polytechforum.com/trains/dcc-debate-railcom-or-transponding-loconet-or-xpressnet-55816-.htm
using PolytechForum's Web, RSS and Social Media Interface to
rec.models.railroad and other engineering groups
Larry Blanchard
> All this just seems stupid to me. I can't understand why something like
> CAN (like what is used in automotive) can't be used to just replace DCC.
> CAN has been around for years and is bidirectional with bus arbitration
> capabilities and most microcontroller families already have CAN
> capabilities built into the silicon.
playing with an Arduino to control turnouts - input from toggles and
outputs to servos.
I had thought of trying to build a DCC throttle using an Arduino, but I
thought that even the Nano was a bit large for a decoder. How big is the
PIC?
Eric Mayo
>
> That sounds interesting. I'm a software guy myself and have just started
> playing with an Arduino to control turnouts - input from toggles and
> outputs to servos.
> I had thought of trying to build a DCC throttle using an Arduino, but I
> thought that even the Nano was a bit large for a decoder. How big is the
> PIC?
DIP package that I use on solderless breadboard and it comes in a QFP
(about the size of a postage stamp) if you want to miniaturize it.
I have all the decoding done in hardware meaning I am using the PIC's CCP
with IRQ (no polling) and I also have UART Tx and Rx working for
diagnostics. I originally built this as a learning project and wanted to
have some basic serial output.
I originally did it without the external oscillator option and running at
8MHz, I was able to pull it all off. I later added external oscillator
and now run the decoder at 48MHz which gives way more overhead to,
perhaps, add Loconet to the same chip or some sort of DCC diagnostic UI.
Ian Jackson
>I recently got back into this hobby and a bit miffed by what seems over
>priced electronics that do very little so I began looked into the
>technology recently. I wound up designing & building a DCC decoder using
>PIC Microcontroller. It handles base line and extended packet format
>which seems to be the latest NMRA standards for about $5 in parts;
>comapred to the $49 and $100 range for commercial ones that are buggy.
>MRC decoders are the worst I've run into.
designing, building and debugging that kind of tiny SMD device to the
market. I've had very good results with Lenz decoders.
My controller (and booster) is entirely homebuilt. I don't have the
schematics online - I did them on pencil and paper - but all the
machine-readable stuff including firmware for the trackside systems,
and the computer control system, is here:
http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=trains;a=tree
I don't bother with any kind of back-channel from the trains; I've
never seen the need. (My trackside system has block occupancy
detection based on current draw, and is capable of detecting even a
totally-idle decoder.)
Of course the whole thing is a work in progress.
--
Ian Jackson personal email: <ijac...@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/