Search the Community
Showing results for tags 'semaphores'.
Found 1 result
-
[ full gallery] I have finally had a chance to photograph my semaphores. First off the signal bridge is modified version of a design I first saw by Jeramy Spurgeon. I have since seen this idea duplicated on several other layouts, but so far all of the examples I have seen have inactive signals. Sure, I had working LED signals, but then a few years back I started thinking about semaphores. There is just something nice about the changing position. So soon enough, I combined my semaphore idea with the signal bridge design. The MOC is tucked away in a dark corner of my layout and my camera batteries were dying, so I couldn't get any good video, but I was able to piece together this animated gif to give you an idea of how they look when operating. The mechanicals are fairly simple, a PF m-motor with a rubber band for a clutch. The one non-obvious feature is the two 1x1 plates just below the red and white semaphore arm. These are twisted ever so slightly to provide stopping points, the plate in back for the white and the plate in front for the red. I use an RCX to run the whole signal tower with a simple "break beam" train detector consisting of a PF LED pair in the middle shining on two light sensors, one for each track. I used a technic half pin to keep the emitted light beam tightly focused and a 1x1 plate sized hole in front of the sensor to keep as much ambient light out as possible. Because the whole setup is in a dark corner, the light for the sensor looks a lot brighter in the photos than it would normally look, e.g., I had the semaphores at one show and some of my club members were puzzling over how it sensed the trains. Given normal light levels it was a lot harder to see the light used for the sensor. The RCX is tucked away in a snug shed along the tracks, with cables coming out for the sensors, light, and motors. The program isn't complicated, but it does have a few clever tricks worked in, e.g., at startup it samples the background light level and stores that for a reference (instead of using a hardcoded value). It then does a loop to check if beam a has broken (saving the result in a variable), then if beam b has broken (again saving the result), then checks to see if it needs to change the state of either semaphore (either due to a newly broken beam or timing out since the last detection). Then loops back. Since most of the action is confined to the conditional statements, the program can complete the loop quickly and sample both tracks with a fairly frequency. I should also mention that I do not actually cut power to the track, so these are just for show. It should be fairly simple to modify this set up to control a single block on one track. [ full gallery]
