Japanese t-trak ATC system

[kvp]

I wonder if it's the same atc circuit that the east penn traction guys adapted from someone in a big Japanese Ttrak group? Perhaps rich or rich can chirp in.

 

Jeff

Yes it is! We built our system in 2009 and will be using it on the Unitram layout at our East Penn Traction Club National Trolley Meet in Allentown, PA (USA) in May.

 

I spotted the little boxes in a picture on a now-defunct website for a Japanese group, figured out what they must be, and managed to inquire by email. The two creators of the system shared schematics and hexadecimal program code with us, but they put a copyright on it all, so I cannot pass it along.

 

The basic system uses PIC (programmable integrated circuit) chips. There is a PIC-based block control box for each track block, plus a throttle box which is also PIC-based. You have to download the hex code to the PIC chip in each box after you build them. The boxes get connected in a loop using standard ethernet network cables. Each block control box has a standard Kato blue/white wire pair coming out to connect to its block of the layout, T-Trak style. The throttle box gets its power from a "wall wart" power supply.

 

In operation, you have to insulate each block from its neighbors (both rails) with insulated Unijoiners. Being PIC-based, each block and the entire system is limited to 1 amp, I believe, but that works fine for model trams and trolleys. On our dogbone loop (made to look like double-track) we have 8 blocks so that we can run 4 cars at once comfortably, with minimum interference and stoppages since the block ahead of each car is typically empty or soon will be.

 

It's best to run cars that have the same basic speed profile, so we tend to run all Bachmann, or all Modemo, or all Tomytec, etc., at any one time. The PIC throttle (or the cars) makes a strange high-pitched whine, and it tends to exaggerate the speed differences in different brands. The quick Tomytec chassis must be run at the lowest throttle setting, and we have to crank the throttle way up for slower cars like Arnold Rapido Duewag trams. I tend not to trust that the system will not damage cars equipped with DCC or other fancy electronics.

 

Interestingly, if you throw the direction switch on the throttle box, not only does the flow of trolleys go in the other direction, but so does the detection of a car "ahead." When a block control detects that a car is running on the block "ahead," it slows its block gradually, down to a stop if necessary. When the block "ahead" clears, the box gradually accelerates its own block until the level set by the throttle dial is reached.

 

It's a neat system but has its issues, and I believe its developers do not believe it is ready for "prime time" or commercial use. At a public show, though, where we get talking to spectators, it is great to not have collisions because of distraction or inattention on our part

 

Rich K..

I created this topic for the discussion about this interesting ATC system and a possible reverse enineered, improved variant that could be designed to support long trains with multiple distributed motor cars. The current system has a few drawbacks, including the lack of support for the aforementioned emu/dmu sets, not supported precise station or signal stops and the speed spikes during block boundary transitions that is the result of unsynchronised pwm pulses.

 

The current system seems to use a binary block control system with stop and go signals for each block controlled by the occupancy of the next block. This means a current based block occupancy sensor must send info to its neighbours and receive info from its neighbours. The direction switch decides on the running direction and which incoming next block occupancy info is to use. The slowdown is gradual and triggered by having an active occupancy in the current and next blocks and cleared by having no occupancy in the next block. The drive signal is pwm, based on the speed set on the throttle and the slowdown value of the current block calculated above.

 

This could be improved in multiple ways, like having two neighbours sending info in both directions, which would allow 3 speed operation, with stop, slow and go (red, yellow, green) speed settings. It's also possible to drive 2 or 3 aspect block signals from the block state. (and even signal a block for both directions, with the unselected direction automatically falling to stop) The multiple speed option would allow the mixing of trains with different speed curves.

 

Station stops could be automated by adding an auto stop enable switch to the controls and a threadle type wheel detector to the stop position. The block would then automatically switch to slow mode and display a stop aspect, slowing the train as soon as it enters the station and stopping it precisely at the a wheel sensor. Departure could be controlled manually by turning the auto stop off (resuming normal atc operation depending on the next and next next block) or by a timer automatically doing the same until the station block is clear. (this would create a fully automatic ATO system)

 

In later posts, i will try to design a system that could support all of the above, first with a multiple speed synchronised pwm pulse ATC system, then adding the station ATO features if possible. I'll try to keep the physical format of the components and the connections the same as in the original system.

[kvp]

Required components for the system above:

 

PWM controller: for a chopped pwm controller, an easy solution is to use a pic microcontroller (for example a pic12f510 or pic16f506), connect an analog potmeter (10-20kohm) and an open collector driver ic (like an uln2003a). For reversing direction, add a double pole, double throw, center off switch, or make it a three pole one to be able to indicate which is the selected direction to the block control logic.

 

Block control logic: For an 8 wire utp cable, we have 4 wire pairs, able to carry 4 differential signals. One pair is needed as a railsync signal so all pwm controllers fire at the same time, allowing smooth transition between blocks. (this is the same with DCC boosters) One pair is needed to send out the status of the current block, which could be occupied (red), slow (yellow) or free (green). No signal should mean occupied, one polarity slow and the other free. (this is a trinary encoding) A similar wire pair could be used to receive the block status of the other block. Only one signal is used from the two incoming ones, depending on the selected direction of the block. The non selected direction is always indicated as occupied, preventing running into a block whose direction (track polarity) is set agaist the train. This requires two bipolar output drivers (like an L293d) and 2x2 optocouplers to decode the incoming trinary block signals. Extra signals are the selected running direction from the throttle and the outgoing slow and go signals to the throttle, which could be two wires or a single wire trinary signal, meaning a default VCC/2 level on the throttle input and pulling that either high or low. (if the throttle and the block logic is the same circuit, the last 3 signals could be handled fully in software and omitted) Another incoming signal is the local block occupancy detection of the block and from any threadle type (signal/platform) stop sensors and the stop mode selector bits (this could also be a trinary analog signal).

 

Power supplies: Each block could have it's own power supply or a daisy chained central supply could be used to power all controllers from a traction power bus or any combination of these two.

 

External connections in a list form:

Input: analog throttle position, block occupancy status (1), railsync (2), selected direction bits (2), left block status bits (2), right block status bits (2), [stop sensor bits (2), stop mode bits (2), analog platform stop time selection]

Output: pwm traction power control (1), block status left (2), block status right (2), [signal head left (3), signal head right (3)]

===

26 signals with at least 2 analog signals for stations and light signals

and 15 signals with 1 analog signal for line blocks a no signals

(the [] ones are needed only for stations with automatic stop and go system and for block/entry/exit signals)

 

This might seem complex, but i'm sure one or two small microcontrollers could handle it. I think i should draw a few diagrams later.

Edited March 28, 2017 by kvp

[kvp]

This is an example ATC setup with a block controller and a single signal, a station controller with a signal and an automatic platform stop (TASC/ATO) front wheel detector and in the bottom right the main pwm sync signal generator (only one is needed for the whole layout, even for multiple loops). Two boxes share the same power supply, while one is powered independently. If the pwm signal is changed to a smooth linear voltage regulator (fremo analog/kato style), the pwm synch system could be left out.

[Kiha66]

This looks pretty interesting KVP.  Keep sharing because I'd definitely like to use such a system for the t-trak modules I'm building! 

[POMU]

Interesting - have you tried it and does it work - or is it just theory?

 

This is an example ATC setup with a block controller and a single signal, a station controller with a signal and an automatic platform stop (TASC/ATO) front wheel detector and in the bottom right the main pwm sync signal generator (only one is needed for the whole layout, even for multiple loops). Two boxes share the same power supply, while one is powered independently. If the pwm signal is changed to a smooth linear voltage regulator (fremo analog/kato style), the pwm synch system could be left out.

[kvp]

Interesting - have you tried it and does it work - or is it just theory?

Just planning right now. The original system does work and i've built several pwm controllers in the past. The current loop block communication was tried at a fremo meet, but only with manual train control. The railsync system is something i pulled straight from the loconet and xpressnet protocols (actually this is the only part where they are compatible). So if anyone has an idea i'm open to it.

 

I do plan to try it at a ttrak meet, at least the ATC part, but it would be great if at least one station (my currently under construction Chuo dori) had full TASC support too. We are severly understaffed at exhibitons, so it seems like a must if we want to move more than one train on each loop.

[kvp]

I tried to reduce the part count, but without the optoisolators a single power source would be mandatory or isolating transformers have to be used instead of dc-dc (wallwart) power bricks which could get expensive and using ac is messy and needs too many parts.

 

So the i/o list so far looks to be 3 optoisolators, 2 full H drivers and 2 open collector motor/led drivers. I tried to simplify it but no success so far. This is without the 5V logic circuit supply parts and the logic mcu-s.

 

I'll post an internal block diagram as soon as i have a bit of time to draw one.

Edited April 2, 2017 by kvp

[Kiha66]

Thanks for the update KVP!  Sounds like you really know your stuff!

[kvp]

(the dashed blocks are only needed for an automatic platform stop system and for driving 3 aspect signals)

Edited April 4, 2017 by kvp