A 60-year love affair: Model Railroading, Hackers and Free Software
Paw Prints: Writings of the maddog
It was a love affair that started over sixty years ago between technology and model railroading.
In 1946 a group of students at MIT banded together to form the “Tech Model Railroad Club” (TMRC) in a gigantic old “temporary” building which itself became famous for the large number of projects started there, “Building 20”.
For TMRC, model railroading was more than just paper-mache scenery and tin-plate tracks. The real challenge was to develop the control circuitry and programming to run the trains, switch the switches and capture the realism of railroading.
Computers were just being invented. At places like Harvard, just down the street from MIT, the Mark I was donated by IBM on August 7th, 1944. The Mark I was made of relays, gears and had a “drive shaft” to sequence it. It could not store its program in memory, instead relying on a paper tape to tell it the sequence of instructions. Many of the computers like the Mark I and the Colossus (the computer at Bletchley Park in England that helped to break the Germany Enigma codes during World War II) were made of components used in telephone switching. While these components were not inexpensive, they were available and relatively reliable.
The advisor to the TMRC was an Electrical Engineering professor named Carlton E. Tucker, who had both a passion for telephony and connections in the field of telephony, so excess equipment often "found its way" to the TMRC to start building their control mechanisms. This eventually led the way to using computers for some of the more sophisticated control work both from the MIT Lincoln Labs and Digital Equipment Corporation in the late 1950s and early 1960s.
Sometimes getting these controls to do what you needed was tricky. A lot of thought had to go into the problem, and even then the answer might be a little less than “elegant”, but admired all the same. That particular type of solution was called a “hack”, and people that did this a lot were called “hackers”. Many people credit the application of this term for computers to the TMRC, and the TMRC was immortalized in the first two chapters of Steven Levey's book “Hackers”.
I have had a love affair with trains and model railroading since early childhood. I would visit railroad museums and seek out steam-powered (my favorite) engines for train rides.
My own model railroad was built, first with trains like A.C. Gilbert's American Flyer, then with HO gauge trains, but later I became distracted by other electronics and (later still) computers, and my love of model railroading was relegated to seeing other people's displays and attending model railroading events.
Back in my childhood model railroaders had a simple power supply/controller hooked up to a section of track and you could basically run one train on that one section. For large layouts you would isolate sections of track from each other, creating “control blocks”, and each “block” would have its own power supply/controller, allowing you to move your train from one block to the next block.
Some of the first attempts at control circuitry were “simply” to have relays automatically disconnect a controller from the block that the engine was leaving and connect the controller to the block the engine was entering. For small layouts and a few active trains this was “simple”. As the model railroad got larger with more active trains, the control circuitry became very complex.
As control circuitry improved and got cheaper, people tried to produce layouts where multiple trains could be running at the same time and the control circuitry would automatically keep them from crashing into one another. Signals were made to operate the same as on “real” railroads, and this required even more relays and wiring.
Even with a lot of “hacking”, using relays to do control logic was very expensive, both in the actual cost of the relay and the time it took to unwire and re-wire for changes to the logic. About 1977 I was teaching at a small, two-year technical college. The KIM-1 computer had been out for a couple of years, and it was selling for about 200 dollars. I stopped at a model shop, and they had just completed a small, stand-alone display of a model railroad, complete with switch yard, turn table and round-house, all controlled by relay logic.
As I stared under the display at the massive numbers of relays that controlled the display, I asked how much the relays had cost. “Three thousand dollars,” came the reply (probably the equivalent of nine thousand dollars today). I told them that they probably could have put all of that logic into the two hundred dollar KIM-1, and made it a lot easier to change. They were not happy with that observation.
Even if you had relays controlling each block problems would occur when trying to run your train very slow, or having trains “coast” and realistically come to a stop, and these were solved over the years by having special circuitry put into the power supply to simulate these activities. Still, some issues remained, as lights in trains would be very bright when the train was running fast, and dim or out when the train was running slow or stopped. Not very realistic.
Eventually the “temporary” Building 20 met its fate, and in 1997 the TMRC had to move to a new building, N52. At the same time the members decided that the second control system they had built over the years from relays (“System 2”) was both hard to expand and hard to change, so they decided to re-design the control mechanism and use computers to control the functions. As you might imagine, most of the “logic” became software, although a lot of difficult interfacing issues still existed.
In the meantime, an organization called the National Model Railroad Association (NMRA), which had been working on standards in Model Railroading since 1935, decided in the late 1980s to try and bring together one standard for sending signals over the tracks. These signals would allow multiple trains to be running on the same track and also allow the controller to send separate signals to the lights, switches and other decoders that might be found in or around a model railroad. They called this standard “Digital Command Control”.
Like a lot of other standards committees, they did not want to “reinvent the wheel”, so they put out a call for various existing control mechanisms, picked one and expanded it to meet the future needs that they could envision. As such, up to 10,000 “devices” can be controlled in one layout, whether it be engines, switches, signals, and even hooking up engines as “doubleheaders”, with two engines working together.
Today you can buy different controllers from different manufacturers, and you can buy different “decoders” for different engines that have different capabilities, but they can all create and read the same signals sent over the rails and wires due to the standard created by the NMRA. You can even buy engines with the decoders already installed, complete with sounds made by that engine when it runs “in real life”.
Of course this is a blog about Linux and Free Software, so you would assume that there is some type of connection.
While DCC is a standard of the NMRA, it is a published standard, and so there is also an “OpenDCC” project where decoders and controllers are designed as “open” hardware, with parts lists and PCB layouts made available.
Likewise there is an entire Model Railroad Control System called RocRail that is licensed under the GPL and runs on Linux, Mac OS X and Windows of various flavors. It is wrtten in “C” and C++, in a client/server manner, with the server able to be on a different machine than the clients, and there was even a browser based client and an iPhone based client.
The software allows you to define your model railroad, complete with switches, turntables, track sections and other devices. Afterwards you can use your definition to attach to a server and either run the trains “manually” or in “automatic” mode.
Both of these projects have active communities and forums, with people that have downloaded the projects, built the controllers and reported back their successes and improvements. I will warn you, however, that the learning curve may be a little greater than it was in the mid-1960s with my HO trains and Atlas “Snap-Track”.
This is the type of electronics that intrigues , and continues to intrigue the hackers of the TMRC, and so on April 24th, 2010 the TMRC will be having an Open House for people to see their latest layout and control systems.
The "Home of Hackers” for 60 years lives on. Perhaps I will see you there.
Don't forget JMRIYou don't mention JMRI (written in Java, so runs on almost any OS), yet this has was around long before RocRail, is also (now) under a GNU license, and should be mentioned for the recent settlement of the court case involving Open Source licensing that had implications for the whole open source community.
Don't forget srcpdhttp://sourceforge.net/blog...-over-the-internet-with-srcpd/
VMware bids for a stake in the container industry with a bold effort to integrate containers with its classic virtualization system.
3ROS attack tool lowers the technical bar so anyone can be an intruder.
Mozilla's latest browser offers powerful new privacy feature
If attackers are on your system, saving your passwords in a password vault is no protection.
Faulty hash algorithm persists, despite efforts by experts to raise awareness.
Powerful man-in-the-middle attack is now targeting online shopping.
Another high-profile coder says the kernel team needs a kinder, gentler culture.
Bug database has a bug of its own that could allow an intruder to create an unauthorized account.
Report focuses federal resources on achieving universal Internet access.
Leading browser makers say “no” to porous encryption algorithm