1 TRAIN SET CIRCUITRY -*-text-*-
4 This README describes some of the circuitry connected to the train set
5 PICs. It does NOT describe everything, and does NOT give pinouts.
6 Refer to the relevant pinout diagrams for actual pin assignments.
8 On the layout, PIC 0 is the `master' PIC: it controls the booster,
9 serial port and other currently-implemented one-off peripherals.
10 It is wired according to REVERSERS, left-hand entry for variant pins.
17 The `booster' generates the track voltage. It includes an overload
20 The PIC has direct control and responsibility for
21 Turning the track voltage on and off
22 Switching the track polarity according to the NMRA DCC spec
23 Responding to overload (together with the hardware cutout)
26 Booster Shutdown (output)
27 Booster Recent Overload (input)
28 Booster Direction (output)
29 User Fault Indicator (output) *** PROVISONAL ***
31 If the following conditions are true, the track will be
34 * The overcurrent cutout permits
36 The polarity of the power is controlled by the Direction pin. There
37 is no need to specify which polarity is which, as this is not
38 meaningful in NMRA DCC. However, for debugging it is useful to know
39 that for block sense to be effective on unreversed segments, the
40 direction output from the PIC should be L.
42 Booster Overload Cutout and Shutdown
43 ------------------------------------
45 Initially, the Shutdown output should be Z.
47 During normal operation, when the PIC wishes to supply power to the
48 track, the Shutdown output should be L. (The PIC should allow the
49 host to say whether the track should be provided with power.)
51 The overload cutout compares the track current against a preset value.
52 Excessive current (or excessive voltage drop on booster's power input)
53 constitutes overload. If an overload occurs, the track power will be
54 disconnected. (This may take anywhere between a few hundred ns and a
55 few tens of us, depending on circumstances, and is not guaranteed not
56 to involve multiple switchings.)
58 With no track power, there will be no track current and the overload
59 immediately disappears. So to prevent rapid oscillation, and as a
60 backstop against PIC program failure, the overload circuit contains a
61 retriggerable monostable: for the (approximately) 10ms following any
62 overload, the cutout will still prevent the track power being
63 restored. During this period, the Booster Recent Overload input will
66 Overload shutdown and decoders
67 ------------------------------
69 However, following an overload-induced cutout it is in fact necessary
70 to further delay the return of track power: firstly, a track power
71 interruption of 10ms is not enough to ensure that a DCC decoder will
72 not retain speed and similar information from before the outage, and
73 secondly, the out-of-specification fluctuations on the track during
74 overload and cutout can be misinterpreted by the decoder as an attempt
75 to communicate via a different protocol or to drive it in DC mode.
77 Therefore, following an overload, the PIC should arrange to keep the
78 booster shut down (using the Shutdown output) for at least 100ms
81 Overload shutdown and the host
82 ------------------------------
84 The host must be informed about overload cutouts, so that it can know
85 that the trains have stopped and inform the user. Provision for this
86 should be made in the PIC-to-host protocol.
88 However, the host will not necessarily react to overload indications
89 in a timely manner; in particular, it may continue to provide NMRA
90 data which is only valid in the context of the state before the
91 overload. The PIC must disregard such NMRA bitstrings, so there must
92 be provision made in the protocol for the host to acknowledge the
93 overload, and for NMRA data (and perhaps other instructions) to be
94 processed only if they follow such an acknowledgement.
96 (One way for the host to acknowledge would be to have the host reissue
97 the `apply track power' instruction, or similar.)
102 The User Fault Indicator output controls, directly, the green segment
103 of the `track power' tri-colour indicator LED. This segment should be
104 lit by the PIC whenever an overload has been detected and the fault
105 has not yet been rectified by the user.
107 When a fault is present, the PIC should occasionally attempt to
108 reapply track power, so that it can indicate to the user when the
109 fault has been fixed.
111 Output pin Green segment
120 The RS232 serial connection to the host arrives at PIC 0, on the pins
128 One pin of each PIC (the corresponding pin on each) drives the per-PIC
129 LEDs, of which there are two per PIC:
131 Output pin Orange LED Blue LED
140 The physical relationship between track objects (detection segments,
141 reversal segments, point motors, etc.) is not known to the PICs. The
142 host protocol should name these objects by number in some
143 representation convenient for the PICs.
145 However, each PIC must be aware of which pin is connected to which
146 kind of peripheral and must prevent the host from accessing one kind
147 of peripheral as if it were another. Otherwise the host could send
148 instructions which would cause the PIC to try to treat an output as an
149 input, or do other things which might damage the PIC or circuitry.
151 Therefore, each PIC must have configuration information (either stored
152 in the PIC's ID locations along with its address, identity, etc., or
153 compiled into the PICs' common firmware and indexed by its identity)
154 which lets it know what peripherals are connected.
156 README.protocol should specify how this information is to be provided
157 by the build system to the PICs (eg, in a file on the host during the
158 build? programmed into the PIC's ID locations?, and what the format
161 The first classification of PICs is into those on DETECTORS boards and
162 those on REVERSERS boards. In the final plan there are 3 REVERSERS
163 (including the master board with PIC 0) and 5 DETECTORS.
170 Each point has two point motors, each controlled by one PIC pin.
171 These two motors are treated as two separate objects by the PICs.
172 Power for operating the point motors is supplied by the single CDU.
174 While the CDU is enabled and no point motor is activated, the CDU
175 charges up until it has enough energy to switch one point. This takes
176 approximately 500ms. (The PIC program should be written so that this
177 period can be adjusted fairly easily from around 200ms to 1000ms in
178 relatively coarse steps.)
180 When the CDU is charged, a point may be switched by activating the
181 relevant output. The point motor output should be active for at least
182 100ms. After the point has moved, the relevant point motor output
183 should be disabled again so that the CDU may recharge.
185 The PICs should not attempt to activate more than point motor at once,
186 nor to activate a point motor when there may be insufficient energy,
187 since doing so leaves the point in an unknown state. The PICs should
188 not assume that the CDU remains charged if it is disabled.
190 There is no need to disable the CDU while switching a set of points.
191 While the CDU is disabled, it gradually discharges.
194 H Activated - point changes if CDU charged
196 Z Results not defined, do not use
199 L Activated - point changes if CDU charged
201 Z Results not defined, do not use
203 CDU Enable pin Effect
204 H CDU is enabled (and charges up)
205 Z CDU is disabled (and discharges)
206 L CDU is disabled (and discharges)
208 Suggested behaviour: the CDU could be enabled whenever track power is
209 provided. The host will need control over the timing of point
210 changes, so while the PICs should prevent the host from activating a
211 point when the CDU is not ready, they should not delay the point
212 change for this reason - instead, they should reject it. The host
213 will also need to know when the point has been changed, and would
214 probably also like to know when it can ask to change another.
216 The currently envisaged PCBs can support up to 104 point motors.
222 Each track section is equipped with a circuit for sensing the presence
223 of current-drawing rolling stock. This circuit is only effective
224 during one of the two track polarities (see Booster, above) - while
225 the track current is the other way, the block sensor does not detect a
228 Furthermore, due to intermittent poor contact, a train may `disappear'
229 briefly - usually for a few ms, but exceptionally for a few tens of
230 ms. This means that reporting every change in the set of detectable
231 trains to the host would exceed the capacity of the serial link.
233 The requirements are:
235 * The host must be informed quickly if a train is spotted where the
236 host has been told that there is no train. 10ms would be good;
237 100ms would be very marginal.
239 * The host should be informed reasonably quickly if a train ceases
240 to be perceptible. 100ms would be fine for this, although sooner
243 * The currently envisaged PCBs can support up to 123 detection
246 The SENSE pins should always be configured as inputs (Z state);
247 otherwise damage to the detection circuitry may occur. When a train
248 is detected, the input will be L; otherwise it will be H.
254 Some track sections have reversible polarity. The host needs to have
255 timely control over the polarity of these sections, and needs to be
256 able to switch several of them simultaneously (to avoid short
259 The polarity states are
262 H segment polarity reversed
263 L segment polarity not reversed
264 Z undefined, do not apply track power
266 Changing takes 1-10ms.
268 The currently envisaged PCBs can support up to 18 reversible segments.
272 It may prove necessary to temporarily disable track power during
273 certain polarity changes.
280 In the future some PICs may be also asked to control the following:
282 * Turntable: outputs to select stop, clockwise or anticlockwise;
283 inputs: probably some binary optoreflective inputs which may
284 need some decoding to establish the turntable's orientation
286 * Uncoupler (probably a simple binary choice)
288 * Tipper wagon actuator (probably a simple binary choice)
290 * Signals (this may involve many more PICs)
292 * Scenery lighting or displays - either one global item, or perhaps