DCC?

Well, you asked for it, so here's my opinion. ;-)
In no particular order: NCE, Digitrax, Soundtraxx, Model Rectifier Corp, Lenz, ESU, .... All conform to NMRA standards and (most) NMRA RPs (recommended practices). Prices don't vary much, the market is very competitive. All offer pretty much the same functions. All, from my limited "let's give it a try" POV, are about equal in ease of use (with a surprisingly steep learning curve beyond stop/go/reverse). I'm sure there are some people who are committed to one brand over another, and you'll hear from them.
As for rolling your own: I can't assess your level of expertise, but keep in mind that all DCC is packaged with custom-designed chips. I suspect that access to reliable custom chip makers is more important than designing the system itself, which most MRRs can do quite easily when relaxing after an operating session. ;-).
OTOH, if you really wanna do it, start by checking the NMRA website for specs, etc. Any system you devise should conform to the standards, else it won't sell enough for you to recover your development costs. Eg, MTH has installed its own version of DCC on its models, but the system is also compatible with NMRA. The main issue with DCC is that there is still no standard assignment of CVs (control variables). NMRA left most of them unassigned, and the mfrs use different CVs for the same functions. Stoopid, IMO.
Have a good one,

Thanks for your input again (previosuly in the UK group).
I'm not intending to attack the on-train stuff, only the controller.
but provide your own monitor, keyboard mouse) could form the basis of the computing end, with then only the H-Bridge that powers the track or layout to be the knife-and-fork bit of electronics to add.
(That is not yet a solution to the on-train engines replying to data requests on the programming track)
Any experience with the MERG track circuits? My experience of working with Train Describers (signalling manufacturer here in Brit) couls come in useful there.

There's also the Roco/Fleischmann Z21 box, which is somewhat different to the above as it uses your tablet or phone as the controller. Arguably easier and better, but certainly an alternative.

"gareth" wrote in news:lc63ad$s2h$ snipped-for-privacy@news.albasani.net:
I would consider developing an app for a cheap Android 7" tablet driving the DCC through the USB port or (better) possibly via wifi. Much more portable than having a monitor mouse.
I think it would be neat to use the computer graphics to make turnout throwing easy to visualize and automate. The tablet can be a neat enhanced controller. Expect a lot of programming to just match the capabilities of present controllers as well add-ons such as frog juicers, etc.

Ah yes, that's a different prop. Could be a nice DIY project for the geeks among us. ;-)
No, I'm not a hands-on electronic geek no more, nor more, nor more, no m-o-o-ore... Oops. ;-)
I did build a couple of transistorised controllers a while back, still use one; and a filtered DC power supply for track testing engines; still use that, too. And I've put together the bits and pieces needed for three functional computers, too, but I won't do that again, it's cheaper in time to buy them ready built. Time is more valuable than money now.
Have fun,

There are many different products.
Personally, I started with a Roco Multimaus (included in a starter set - Roco has very nice digital starter sets, especially if you like European trains)
The Multimaus is a surprisingly useful system, and you can add multiple throttles via the 'Slave' connector (in our club we have operated easily with four throttles attached to the amplifier, and it can accept more via an RJ12 plug). The whole intelligence is in the red controller, and the amplifier that came with the starter kit could put 3.2A on the rails (the transformer included was 50VA), but more recent packages have replaced the transformer with a smaller one. It supports 4-digit addresses and CV programming. Note, though, that it cannot read back parameters stored in a decoder. This capability is reserved for more high-end systems.
We tried the Bachmann Dynamis. The infrared controller is nice, if you can point your throttle to the correct position in order to be visible by the sensors. And it cannot read back the decoder configuration (you need additional equipment, if I am not mistaken). We were not happy with it, since it didn't offer much above the Roco Multimaus we already had, and ergonomics were rather mediocre.
Now, we are progressing to a computer-controlled system using JMRI software (written in Java) and the USB-connected SPROG 3 interface. The latter is a tiny box that connects to a USB port of the computer and transmits data to the layout (and power up to 2.5A - for more power, you use boosters). Since we have already computers and tablets/smartphones (the latter are used through WiFi for controlling our trains), this has been deemed the most low-cost approach for a wireless layout. The reliable Roco Multimaus will be kept as a reserve.
The Roco Z21 is nice (and it permits the use of Multimaus as throttles in parallel with tablets etc). But the cost is steep, compared with the freely-downloaded JMRI and the rather cheap SPROG (and you need a computer with Z21 anyway, if you want to extract enough of its capabilities). Roco has a trimmed-down version (named z21, in lowercase) included in starter sets.
Cheers, N.F.

Thanks for the heads-up.
Looks like I have been pipped at the post!

The January Railroad Model Craftsman has article about a 1ft x 4 ft shunting layout. The builder uses a modified Arduino micro-controller to operate it. IMO articles about using Arduino and Raspberry Pi for MRRs would be very welcome. Kits would find real albeit small market, too, esp. if any printed circuit work is required.
Just a thought,

Do not feel bad, there is a steady progress with these efforts, which have a large user and developer community. JMRI has this page:
It has two major parts: DecoderPro and PanelPro. The first is dedicated to decoder programming and locomotive tuning, and yo u include your trains into a roster (you can add photos of your train as we ll), while the second is dedicated to the operation of the layout, and incl udes both software and hardware throttle support.
DecoderPro has a manual which should give you a good idea about its capabil ities: (the current production version of JMRI is 3.6 ) The operations program has currently the manual in HTML form:
When the operations program starts, we start up the WiThrottle server on th e PC (works in Windows XP and Linux, at least), and we use that Android app lication for running our trains: ?id=jmri.enginedriver (I think that there is an equivalent iOS application as well).
The only problem with these touch screens is the lack of physical feedback (potentiometers, etc.), but I have seen ESU promoting such a device in the current Nuremberg fair and on the cover of their new catalog: DE_Auflage_I_eBook.pdf
SPROG has its own Web site: Also, SPROG and JMRI have their own Yahoo groups, which are very focused an d helpful.
If you want to see the combination in operation, search in Youtube with wor ds such as SPROG, WiThrottle, JMRI and Engine Driver.
Note that JMRI, SPROG and Engine Driver do not negate the usefulness of tra ckside equipment (occupation sensors, signaling, etc.) - quite the opposite !
Regards, N.F.

maintain the timings of the output waveform, and then the H-Bridge to couple the power to the track.
As to PCB, google for "Manhattan Style" or "Dead Bug" construction as favoured these days by we who are radio amateurs / radio hams.
And then a (notionally) zero-cost option to provide separate hand controllers consisting of forward/notch up/reverse and regulator based upon another PIC with 10 A2D converters.

Thanks for a full and informative response.
I am particularly interested in what occupation sensors are around, because of my involvement with Train Describers in a local-to-me company 25 years ago, in order to create a fully automatic layout.
What I envisage is that there would be two occupation sensors per signal.
One on the approach to the signal would instruct the train to decelerate (The Train Describer knows which train is where!) and then at the berth itself, the train would be instructed to stop. Obviosuly, there would need to be characterisation of each engines's deceleration profile.

Forgot to add that Raspberry Pi has not enough compute power to run the JMRI stack (as far as I know), but it is perfectly usable with other tasks (e.g. automating, signaling, sensors, etc.). JMRI has its own group in Yahoo! Groups, with enough traffic.
If you want to run JMRI on a budget, a used laptop is more than enough (we used my ancient IBM T60 Thinkpad as a JMRI system and server in the test, and it was up to the task)
N.F.

And you can run it on Linux, which is very ancient-hardware-friendly. ;-)

Check out
Specifically:

And check out

(Software that works with the Azatrax MDRs is available as a free download from Deepwoods Software:

That depends greatly on distribution and user interface selected.
A recent version of Ubunty Linux was so heavy that was nearly useless on a dual-core desktop computer with 2 GBytes of RAM I had on a contract job 1.5 years ago (I think it was a Core 2 Duo processor, probably 8200?). I had to throw away the default user interface and use XFCE desktop instead in order to have a usable machine.
Comparatively speaking, my T60 with Windows XP feels still snappy enough (I have upgraded it to the maximum 3 GB RAM, changed the hard disk with a WD Scorpio Black 500 GB and last of all exchanged the 2.6 GHz CPU with a 2 GHz T7200 - not too surprisingly, the latter made the least difference to me)
N.F.

You can use a large amount of sensors, both electronic and optical, with a DCC-controlled layout.
For example, you could put an optical occupancy sensor between sleepers (this avoids the need to wire axles with resistors for visiting trains), and add infrared detectors at entrance and exit for block occupancy. And there is Railcom, where your system can query the locomotive for data such as speed, direction, etc. (most DCC decoders sold today support this), so you could use one braking sensor and make each train respond accordingly.
Software like JMRI has support for these things (read especially the documentation about PanelPro in it). Note that JMRI is continuously updated with more capabilities by its users and developers, so you could have a future Railcom controller with it.
Look also at for some more details.
Railcom is probably what you want to utilise for that.
Cheers, N.F.

Ops, I meant "exchanged the 1.6 GHz CPU for a 2.0 GHz T7200 CPU".
N.F.

Since I mentioned Railcom, here is a demonstration of automatic braking using Railcom:
Regards, N.F.