DCC debate: Railcom or Transponding? Loconet or XpressNet?

David Nebenzahl wrote in news:4773061f$0$16360$ snipped-for-privacy@news.adtechcomputers.com:

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

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).

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).

There's already Ethernet over AC power, so this can be done. Look at

a typical product. I wouldn't like to put 230 VAC on the rails, though, modulated or not

*grin* :-)

Cheers, N.F.

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.

On 12/27/2007 8:24 AM Nick Fotis spake thus:

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 ...)

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).

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.

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.

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?

I'm using the PIC18F4550 which comes in several formats including a 40pin 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.

I use bought decoders because I'm on N-scale. I'm happy to leave 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:

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.