Home made DCC Booster Question

J> Hi, 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> 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 'nodes'.

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

J> J> Many thanks for any replies, J> J> Peter J>

\/ Robert Heller ||InterNet: snipped-for-privacy@cs.umass.edu

|| snipped-for-privacy@deepsoft.com /\FidoNet: 1:321/153

No need to scrap anything. The DCC "friendly" turnouts are just turnouts that are a bit less suseptical to short term shorting at the points and frog and if your turnouts don't do that then you really don't have to worry. Wire up the circuit and play with it. After all, it is nothing more than a fancy powerpack and you can provide a simple DPDT switch to switch between DC and DCC while playing with the DCC.

-- Why isn't there an Ozone Hole at the NORTH Pole?

Yes you could be right. Unfortunately the main thing I want to avoid at this point is a large outlay on something that I am not 100% sure we will continue with. I would much rather start with a simple and cheap system and see how it goes. Hence the serial port and booster. I was thinking that this circuit plus some software and a single decoder attached between the booster and track would allow us to experiment with DCC for probably under $60 - even if we could only run 1 unmodified engine.

Peter

Yes - well probably salvage most things. I really meant the layout - which basically sucked.

Peter

Have a look at Andrew's SPROG is reasonably cheap and can function as a controller as well as a programmer. Keith Make friends in the hobby. Visit Garratt photos for the big steam lovers.

Will do - thanks.

Peter

contains an embedded processor (eg a PIC chip or some such), the I/O demands will be rather large< A booster is just that a booster, or another name would be an amp. They contain no processors, that function is in the command station.