In a message on Sat, 04 Jun 2005 21:53:05 +1000, wrote :
J> My son and I have decided to scrap our modest N scale setup, salvage
J> what we can, and basically start again using DCC and computer control.
J> As we are both reasonably proficient at writing software and a bit less
J> so with electronics we'd like to build most of our own stuff ( probably
J> not the decoders) if possible. In that regard I've been looking for DCC
J> booster circuits and came across one from the NMRA that is directly
J> controlled from a PC serial port and looks ideal as it doesn't need a
J> separate controller. Its called NMRA Serial Booster rev 1.4.
J> So, my question is - has anyone here used this circuit? If so is it
J> OK, and what sort of software do you use to run it?
I've not looked closely at this particular circuit, but given my
(limited) understanding of DCC and given the need for continuous
message traffic (booster => decoder(s)), *I've*
decided to just get a
Lenz LZV100 (command station w/ built-in 5Amp booster) and use Lenz's
LI101F (serial port to XpressNet adapter) to connect a Linux box's
serial port to the XpressNet. Unless the Serial Booster circuit
contains an embedded processor (eg a PIC chip or some such), the I/O
demands will be rather large, given the continuous real-time nature of
the DCC system. A command station with some kind of computer interface
contains its own 'embedded processor' that talks care of the
track-level real-time I/O processing, leaving the main computer (your
PC) to deal with the higher level processing of the human-interface. I
have already written (not tested yet) the low-level software. I also
plan on using a RailDriver control stand and have written the (Linux)
software to talk to RailDriver unit. I already have tested and working
code for talking to a Bruce Chubb C/Mri system. The Bruce Chubb C/Mri
system uses a serial bus (RS485) that includes Micro-Processor based
The idea of distributing the processing is something I am
very much in favor of. The 'typical' desktop PC (even the new 3gighz+
machines) are just not suitable for low-level real-time processing.
And certainly none of the general-purpose O/Ss (not even Linux!) are
suitable for real-time programming. Unless you plan on using some SBC
system and writing an O/S from the ground up, you don't want to do this.
Using a older (cheaply available or even 'rescued from a dumpster')
desktop PC as a command-and-control system driving (via serial port(s))
low-level hardware-interface devices such as a DCC command station
(over XpressNet or LocoNet) or a Bruce Chubb C/Mri system is very sensible.
I'd recommend using Linux on such as system -- Linux 'comes with' all of
the development tools (compilers, etc.) and can be installed and will
work well on older hardware (no, not the resource-heavy desktop / office
automation stuff, but you don't need any of that for your MRR control
J> Many thanks for any replies,
Robert Heller ||InterNet: email@example.com
http://vis-www.cs.umass.edu/~heller || firstname.lastname@example.org
http://www.deepsoft.com /\FidoNet: 1:321/153