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.
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,
On 2014-01-27 15:51:05 +0000, Wolf Kirchmeir said:
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.
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.
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,
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.
On Thursday, 30 January 2014 14:16:20 UTC+2, gareth wrote:
Do not feel bad, there is a steady progress with these efforts, which have
a large user and developer community.
JMRI has this page:
http://www.jmri.org/
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: http://www.jmri.org/help/en/manual/pdf/DP3_Man_3-4.pdf (the current
production version of JMRI is 3.6 )
The operations program has currently the manual in HTML form: http://www.jm
ri.org/help/en/manual/3-4_JMRI_OPS_UsersGuide/index.shtml
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: https://play.google.com/store/apps/details
?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: http://www.es
u.eu/fileadmin/download/brochures/2014/52937_Produktuebersicht_2014_ESU-KG_
DE_Auflage_I_eBook.pdf
SPROG has its own Web site: http://www.sprog-dcc.co.uk/
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.
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.
And check out
http://www.azatrax.com/usb/index.html
(Software that works with the Azatrax MDRs is available as a free download
from Deepwoods Software: http://www.deepsoft.com/modelrailroadsystem /.)
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
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 http://www.dcc4pc.co.uk/railcom_uses.html for some more
details.
Railcom is probably what you want to utilise for that.
Cheers,
N.F.
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.
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.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.