DCC Live
On WWW and CU-SeeMe
A project to bring a model railroad to you when and where you want it.
by John D. Balogh
Project Overview:
- Goal:
I wanted to enable other people on the 'net to be able to join in
the fun of operating model trains. Part of that fun is being able
to control and watch the trains, so I needed to implement a user
interface to the layout that gives video feedback as well.
It would also be nice to be able to demonstrate even some part of this
by the next NMRA National Convention.
- Limits:
The goal seemed like it could be implemented with a straightforward
series of tasks, but then I wanted to do it with limited cost or time
expenditures since I have a family that also makes demands on those
resources.
This limit meant using existing PC hardware I had at home and not
trying to learn how to set up a Unix environment complete with custom
real-time device driver I/O routines or special client software.
Selection of interface hardware and software would have to be reasonable
cost and "off the shelf".
- Hardware Resources:
I had begun to gather equipment which conformed to the NMRA S9.1 standard
for Digital Command Control (DCC). This enables a model locomotive
to be controlled with a series of commands formed as packets and
boosted to useable voltages and current capabilities on the rails.
Turnout (switch) controllers can also be connected to the rails and
can decode these signals thereby enabling the minimum essential tasks
required to route trains on a layout. This was the first part of the
hardware needed and functioned as the input to the layout.
The combination of these elements with a suitable controller interface and
PC platform could be used as the basis for selecting controlling software.
The second part of the hardware required was the feedback mechanism
from the layout to the user.
I wanted to be able to provide an overall as well as an "on-board"
view of the operations. This required some form of video capture
hardware and a camera looking over the layout as well as a camera
mounted INSIDE the train. The video capture board was dictated
by compatibility with available software and cost. The overall view
camera was a home video camera. The on-board camera required some
modification of the camera and an "Observation" car from a local
hobby shop. An additional offshoot of the
multiple viewpoint idea was the ability to electronically control
the selection of the video source to be digitized. This was accomplished
with a solenoid-driven video switch and a Turnout controller.
Future feedback will also include track mounted detectors and block
occupancy detectors (monitoring physical and electrical location of
the trains respectivly). This non-video method will enable users
to operate and monitor the trains without a minimum speed requirement
for their connection.
- Software Resources:
Various options were considered for the controlling user interface
(ref. the project timeline) but the solution of choice
appeared to be the WWW. I had not specified in the goal which
"people on the 'net" would be able or not able to run the layout,
so I attempted to accomidate as many flavors of Internet
connectivity as possible and WWW appeared to be the way to do that.
Given my limits and hardware resources, I needed a WWW server
that ran on a PC (similar functions are available in other packages
for the MacIntosh). Given the software I had at home, MS Windows 3.1
was the only pseudo-multitasking Operating System available so the
WWW server had to run in that environment. I investigated SERWEB
and HTTPD. SERWEB was a good learning tool, but did not support
the "forms" interface. HTTPD had the features required to implement
the software/hardware interface requirement and appeared to have
an easy learning curve, so it was chosen. The Windows interface for
HTTPD required a WinSock compliant stack, and I had that with
Trumpet WinSock. However, Netscape clients have the ability to
do multi-threading (which is supported by HTTPD) and to kill off a
download function, and that caused the old Trumpet stack to have problems.
Another vendor's PC/IP stack was chosen as a solution to the Netscape twist,
but it appears to have the same problem. Fortunatly Peter Tatum corrected
the problem in Trumpet WinSock V2.1c and then multi-threading worked fine.
Now I had an OS, IP stack, server software and customizable scripting
capability. That and some hours (many hours) of configuration would
accomplish the controlling side of the layout, but that was only
half of the goal.
The other interesting task was to provide the visual feedback to
the layout operator. The early winner (at least in cost and time
spent) was Cornell's CU-SeeMe software. This package enabled sending
a compressed video stream to other PC or MAC users on the Internet.
It also interfaced with the MBone, NV and VAT video applications.
This turned out to be the part of the development that required the
least effort and gave the most immediate functionality.
The first user interface to be implemented only requires
a forms-capable WWW browser but gives limited feedback.
Implementation details:
- DCC Components:
1
2
3
- Layout Components:
1
2
3
- Video Components:
1
2
3
- PC Hardware Components:
1
2
3
- PC Software Components:
1
2
3
User/Mentor Comments:
Many people have said "That's a neat idea." I agree. It also appears
to be a never-ending project, since the layout construction is not
done, and will OBVIOUSLY need to be upgraded for more challenging
operation and scenery concerns. When my Chief Financial Officer thinks
I can swing it, I may invest in more cameras and computer capabilities.
For now, I'm just nibbling away at the list of tasks, updating the
project timeline and coming up with more wild ideas to implement.
If you have an idea that you think would be fun to use, send me a note.
If you think I have missed something that would
save time or cost, PLEASE send me a note.
Even if you just want to ramble on about railroads, model trains
or internet connectivity, I'm still open to hear what you have to say.
Thanks!
JohnBalogh@psu.edu
Last updated: June 26, 1996.