Not that sort of of bus - a layout control bus. DCC is really good for controlling trains, but is less suited for controlling points and signals and the like. A separate bus for operating accessories means that a short circuit on the track does not cause points and signals to change at random. The separate bus can also use systems that are more suited to train detection and route selection.
I initially joined Merg (Model Electronic Railway Group) in order to access their servo controller kits, for controlling points and signals. Having joined, I found out about their development of a layout control system based on the CBUS two-wire command bus. The CBUS protocol has been used in all new cars for a number of years, to reduce the complexity of the wiring loom, and increase the functionality. It is a fairly simple protocol, compared with TCP/IP as used by the Internet. The bus is used to join up various devices all over the car. It allows 'producer' devices (switches, or sensors for instance) to broadcast simple numbered 'event' messages over the bus. All the 'consumer' devices attached to the bus will see these 'event' messages, but certain devices will be setup to perform specific functions when specific events are seen. Thus a switch can broadcast an event which the windscreen wiper controller will act on to start the windscreen wiper motor. A rain sensor can be set up to broadcast the same event. It might also broadcast another event which would result in the headlight controller lighting the headlights. The CBUS is equally useful for controlling a layout. Control panel switches and train detectors can become 'producer' devices, and point motors, signal motors and mimic display panels can become 'consumers'. Because of the widespread use of CBUS in the automotive industry, the basic components required are readily available and low cost.
Last year, I purchased a couple of Merg kits, an eight input 'producer', and an eight output 'consumer'. I also picked up the experimenters kit, a small board with eight switches on that plugs onto the 'producer' kit, and a board with eight LEDs on that plugs into the 'consumer' kit. The Merg kits are designed to allow them to be 'programmed' using small switches that are part of the kits. The 'producer' can be told what events to broadcast for each switch operation, and the 'consumer' kit can be taught which events to listen for, and which LEDs to light or extinguish when the event is seen. The Merg kits were designed to use a 5VDC supply distributed from a power supply regulator on one of the kits, which required a 12-16V supply. I experimented with these modules, but did not get round to using them on Freshwater as deadlines approached, and a temporary 'traditional' control panel was built. I do intend to use CBUS eventually as it will allow simple route selection and some interlocking to be implemented.
The photo shows a 'producer' board on the left, with eight yellow switches on the experimenter board plugged on the end. On the right is a 'consumer' board, with eight red LEDs on the experimenter board plugged on its end. They are connected by the 2-wire bus (blue and white wires). The orange and black wires are the power supply lines. In the centre is a C-BUS connector board, and a power supply can plug into the lead coming down from the centre. I have modified these boards to run from a 12VDC supply instead of the 5VDC supply that the kits were originally designed for.
Over the last 12 months, more kits have become available, along with interfaces to a computer to simplify the programming of the modules. The computer interface also allows computer control of a layout, using suitable software like the freely available JMRI. The latest development from Merg is a DCC command unit and a hand-held controller. The CBUS is used for communication between the controller and the command unit. JMRI can also be used as a throttle connecting to the command unit via the CBUS.
So, to prepare for the DCC system, and use of the CBUS on Freshwater, I purchased the Merg kit for a CBUS to USB interface. This was initially built as per the instructions. It is designed to take a 5VDC supply. I therefore created a simple 5VDC regulator circuit on a small piece of veroboard, and mounted everything in a small black plastic case. A 4 way cable with an RJ22 type connector at the end that can plug into a Merg CBUS connector kit, comes from the box, connecting the two bus wires and the 12VDC supply into the box. A standard USB connector protrudes from the other end of the case.
Having a working USB interface, I set to building the DCC command station kit from Merg. This has been built as per its instructions. It is already designed to take an external 16VAC power supply, and can supply 12VDC to other devices on the bus.
The photo shows the USB interface box on the left, which connects to the USB port on a PC. It also plugs into the CBUS connector board and the bus then connects to the DCC command station board on the right, the red and black wires next to the bus wires have a socket for connecting the power supply. The red and black wires to the far right attach to the test track at the top of the photo. The white round object at the bottom right is a buzzer used as a short circuit warning. This setup now works, using a JMRI software throttle on the PC. I have also played with a Wi-throttle 'app' on an iPhone using a WiFi connection to the JMRI server on the PC.
Merg will very soon have a kit available for a hand held DCC controller that will plug directly into the CBUS connector board, and do away with the need for the USB interface and PC. Watch this space.
Sunday 10 July 2011
Subscribe to:
Post Comments (Atom)
4 comments:
When you say "The CBUS protocol has been used in all new cars for a number of years", you mean "The CAN protocol (on which CBUS is based) has been used in all new cars for a number of years".
The distinction is important.
Howard.
Howard, thanks for that clarification.
Also, in the same vein of clarity, about the car rain sensors explanation...
If the rain sensor was using the MERG CBUS bits, the sensor issues one event (as a producer).
Consumers are configured to respond to many events. So, the wiper switch sends one event, and the rain sensor a different event (important !). The windscreen wiper motor consumer responds to both the dashboard switch event and the rain sensor event. The headlamps respond to the rain sensor event (and no doubt to an event from a different dashboard switch).
- Nigel
Post a Comment