Tehachapi Loop II

[ednadolski]

My planned operations are pretty basic, so I am not sure that I see much use of the yellow LEDs in actual practice, other than the Approach Diverging.   Are there any scenarios that I should be considering?

I am planning to wire all signal LEDs (including resistor) thru the RJ11/RJ45 connectors, so nothing will be left "hanging".  Even if I go with a low cost arduino board (like the Adafruit Trinket Pro 5V at only $10) there are still enough pins to drive all the LEDs.  All I would have to do then is update the programming to add the new behaviors.

Ed

[kc9jts]

My planned operations are pretty basic, so I am not sure that I see much use of the yellow LEDs in actual practice, other than the Approach Diverging.   Are there any scenarios that I should be considering?

Ed

If one of your control points is at stop (say the 56L or 54R signals) you would want the approach signal to be yellow and not green.  So your aspect progression could be:
Sig 52R = red, 54R = yellow, and 56R = green. The same could be true for the opposite direction.  Otherwise, you would have a clear signal (proceed at max authorized speed) into a stop signal if not using the yellow approach aspect.

[ednadolski]

So the logic would be, each CP would need to know the state of its adjacent CPs, and then restrict a clear indicator to yellow if the next signal in that direction were red.  To implement that I would need to add a wire in each direction between the arduinos (a pretty rudimentary Loco Net I suppose ).

One case where I think I will need that is an uphill (or downhill) train on the mainline thru Walong that has to stop at the east (or west)  Walong switch to let a downhill (or uphill) train clear into the siding.  In other cases tho, would the yellows typically be handled by the intermediates?  I don't think I see a downhill train into Woodford getting a yellow on the main, since the train would be headed into staging at that point and next signal would not actually be represented on the layout.

BTW the arduinos have daughtercards available that can handle various networking, including Ethernet WiFi, Bluetooth, and XBee.   For now I am not sure if I would need any of that, but it would be fun to tinker with. 

Ed

[kc9jts]

So the logic would be, each CP would need to know the state of its adjacent CPs, and then restrict a clear indicator to yellow if the next signal in that direction were red.  To implement that I would need to add a wire in each direction between the arduinos (a pretty rudimentary Loco Net I suppose ).

Yes

One case where I think I will need that is an uphill (or downhill) train on the mainline thru Walong that has to stop at the east (or west)  Walong switch to let a downhill (or uphill) train clear into the siding.  In other cases tho, would the yellows typically be handled by the intermediates?  I don't think I see a downhill train into Woodford getting a yellow on the main, since the train would be headed into staging at that point and next signal would not actually be represented on the layout.

BTW the arduinos have daughtercards available that can handle various networking, including Ethernet WiFi, Bluetooth, and XBee.   For now I am not sure if I would need any of that, but it would be fun to tinker with. 

Ed

Just about every mainline signal on Tehachapi pass had a yellow aspect for an approach indication; they would have been present at both the intermediates and control points.  I think the one exception may have been West/North Walong (CP SP351) which only had a red or green indication for the trailing signals northoung into the tunnel (this was discussed a bit on the Tehachapi prototype signal thread).  Whether or not you want to replicate this exactly logic is your call.  On one hand, you could have your signals that govern movement off the layout (to staging, signals 56L, and 52R on your diagram) show a green that they are cleared, or you could also give a yellow aspect of "be prepared to stop(in staging)".

[ednadolski]

Just about every mainline signal on Tehachapi pass had a yellow aspect for an approach indication; they would have been present at both the intermediates and control points.  I think the one exception may have been West/North Walong (CP SP351) which only had a red or green indication for the trailing signals northoung into the tunnel (this was discussed a bit on the Tehachapi prototype signal thread).  Whether or not you want to replicate this exactly logic is your call.  On one hand, you could have your signals that govern movement off the layout (to staging, signals 56L, and 52R on your diagram) show a green that they are cleared, or you could also give a yellow aspect of "be prepared to stop(in staging)"

With 52R/56L a train heading off the layout would pretty much always be stopping in staging anyways, so that would mean they would never see a green   (except perhaps for continuous running of a single train thru the staging).

With no yellows on the trailing signals on CPSP351 I presume that a dispatcher should never allow a train to proceed unless all the track up to CPSP350 were clear.

[kc9jts]

With 52R/56L a train heading off the layout would pretty much always be stopping in staging anyways, so that would mean they would never see a green   (except perhaps for continuous running of a single train thru the staging).

With no yellows on the trailing signals on CPSP351 I presume that a dispatcher should never allow a train to proceed unless all the track up to CPSP350 were clear.

In reality the dispatcher could request the signal at SP351 but with the double-blocked red to Woodford it would have depended on track conditions and opposing moves. In short though the trailing signals at SP351 would not clear unless the block to SP350 was clear.

[ednadolski]

I've been working on breadboarding a detection system using an LED bar graph display with the Arduino. Here is a video of what I have got working so far (note, be sure to have your computer's audio turned on for this little flick, and also please ignore the HO stuff -- I did't have any other convenient place to set this up):

This uses DCC current detection with one detection block corresponding to each segment on the LED bar graph display.  This demo track/circuit is using 4 blocks therefore only 4 segments of the bar graph.  The bar graph will ultimately be built into the CTC display panel.  A red LED represents a 'stop block' that will alert the operator when it is time to stop a hidden train.  (The 'stop block' in the video is where the train passes the handle of the screwdriver.)  The audio prompt is key, so that the operator does not need to continuously monitor the display panel to know when the train has reached a stop block.

The bar graph has 24 LED segments, which allows up to 24 detection blocks per staging track.   With four staging tracks, that's nearly 100 blocks, so it was important to reduce the cost of an individual detector.  After a bit of digging, I came up with a way to build a simple detector circuit that uses a transistor and a few other discrete components, all soldered together on a prototyping PCB.  The transformer coil is (I think, not 100% sure) the same part that NCE uses in the BD20A.  In quantity, these cost about $1.50 apiece, so with all the other parts the cost of a single detector works out to under $2 apiece.  (For comparison, a BD20A is about $12-$13, and other DCC detectors work out to about $8-$9 per detector).  For my prototyping work I made up a block of four detectors:



And my circuit is based upon a schematic at this link:

http://www.trainelectronics.com/DCC_Arduino/Current_Sense/index.htm
http://www.trainelectronics.com/DCC_Arduino/Current_Sense/images_current_sense/schematic.gif

Here is what the breadboarded system looks like:




The detectors are wired to the breadboard thru a CAT5 cable that is about 15' long.  For the audio prompt, I used an MP3 player 'shield' (arduino-speak for a daughtercard) that stacks onto the Arduino Uno and stores the .mp3 audio files on a micro SD card.  There is also a small single-channel audio amplifier to drive the speaker.  The Arduino itself is running a C program that I wrote to implement a simple state machine.  The code scans the GPIO input lines (one per block) and then sets the state of the bar graph LEDs and also plays the appropriate audio file whenever a stop block transitions from OFF state to ON state.  Once the program is downloaded into the board's flash, the whole thing runs independently without any other computer or network.

For the layout's hidden staging tracks, I am thinking to make the regular detection blocks about 40" - 48" long each, and the 'stop' blocks will be 12" long.  This arrangement provides relatively fine-grained resolution for monitoring trains in the hidden staging tracks, which should make it a lot easier to confidently run long trains even when they are out of sight from the operator.

Cheers,
Ed

[C855B]

That's some great engineering there, Ed. Mind if I copy?

Seriously, quite a solution.

[ednadolski]

Mind if I copy?

Sure, that's pretty much what I did anyway

Ed

[ednadolski]

A few more details on how I might implement this approach.   This pic shows the lengths and layout of the individual detection blocks in the staging sections:



Note that the detection blocks are different lengths for each staging track.  This in part is due to the helix, where the outer tracks are necessarily longer anyway.   This arrangement also reflects the intended train lengths that were previously discussed.

This pic shows how the bar graph LEDs would be placed on the CTC panel:



Each segment in the bar graph actually has two color LEDs, and thus can display either red, yellow, or green.  (Most other LED bar graphs have a single LED per segment, and thus only one fixed color.  With this bar graph I can even program the LEDs to change color on the fly if I wanted to.)  What I have done here is to use red for a stop block, yellow for the two blocks approaching a stop block, and green for the 'regular' blocks.   An unoccupied block will of course have its corresponding LED switched off.   So even with 100% hidden trains, there should be no chance of a collision as long as the operator keeps at least one unoccupied block between trains at all times.

The colors reflect that each staging track has an assigned direction, which is needed for serialization.  If I ever need to change the direction, I can update the software as needed.

Aesthetically, I am thinking of masking the LED displays so that they are no wider than the corresponding white lines. I'll probably make a mockup to see what looks best.

Ed

[jagged ben]

I'll say this Ed, you're not half-assed about anything you do.

[reinhardtjh]

That's very cool.  Where did you get the bar LED displays?

Are they these?  https://www.adafruit.com/products/1721

[reinhardtjh]

A few more details on how I might implement this approach.   This pic shows the lengths and layout of the individual detection blocks in the staging sections:



Note that the detection blocks are different lengths for each staging track.  This in part is due to the helix, where the outer tracks are necessarily longer anyway.   This arrangement also reflects the intended train lengths that were previously discussed.

This pic shows how the bar graph LEDs would be placed on the CTC panel:



Each segment in the bar graph actually has two color LEDs, and thus can display either red, yellow, or green.  (Most other LED bar graphs have a single LED per segment, and thus only one fixed color.  With this bar graph I can even program the LEDs to change color on the fly if I wanted to.)  What I have done here is to use red for a stop block, yellow for the two blocks approaching a stop block, and green for the 'regular' blocks.   An unoccupied block will of course have its corresponding LED switched off.   So even with 100% hidden trains, there should be no chance of a collision as long as the operator keeps at least one unoccupied block between trains at all times.

Ed

Do you want to consider having an additional  guard block after each stop block in the appropriate direction?  The way it's set up now you know when a train enters the stop block, but not if the stop block has been overrun and the train is fouling the switch.  You could have the guard block also show red and if an engineer goes to far then two red blocks show and he knows he's gone too far and either has to back up a bit or check to make sure he's still on the rails.

[ednadolski]

I'll say this Ed, you're not half-assed about anything you do.

Thanks   but I am just hoping to come up with something that will operate well enough so that I won't have to re-build too much of it later.       The block layout in the helix is pretty critical, since it would be very hard to change the gaps & wiring once the whole thing is built.

Speaking of wiring:  since the detection blocks are so short, this scheme lets me use a single feeder wire for each block without having to install an additional multi-feeder sub-bus for each block like I would need if the blocks were a lot longer (as discussed in this post.)    With four parallel tracks, that saves a considerable amount of (redundant) bus wire.

Are they these?  https://www.adafruit.com/products/1721

Yep, that's it.  They are pretty easy to put together, and they come with a controller chip that does most of the work of updating all the LEDs. The controller requires only two GPIO pins from the Arduino (way better than one GPIO per LED!) and there are solderable jumpers that let you address multiple display bars (up to 7 IIRC) in parallel. There is also a software library that makes the programming a lot simpler.  Not bad for a $10 product!   

I was really glad to find something that was software configurable.  All of the other multi-color LED bars that I could find were made for things like VU meters, so the colors in each element could not be changed.

Do you want to consider having an additional  guard block after each stop block in the appropriate direction?  The way it's set up now you know when a train enters the stop block, but not if the stop block has been overrun and the train is fouling the switch.

Good point.  The picture doesn't show it, but each adjacent track is also a control point with its own detection.  So when a train proceeds past the stop block, that will pick it up and display it on the panel.  The CPs and stop blocks will both have an extended timeout of about 10 seconds, which will continue to display the occupied state (ie, red light) for that additional time after the last detection element (ie., loco or resistor equipped car) has exited the block.   (On the demo, since the blocks are so short I set the stop block to remain on for only about 1 second after the train exits the block.)
 
Cheers,
Ed

[ednadolski]

In case anyone might be curious, here is what 120 detector coils look like:   



(Time to order up another roll of solder....  )

Ed