TRAIN SET CIRCUITRY -*-text-*- ------------------- This README describes some of the circuitry connected to the train set PICs. It does NOT describe everything, and does NOT give pinouts. Refer to the relevant pinout diagrams for actual pin assignments. On the layout, PIC 0 is the `master' PIC: it controls the booster, serial port and other currently-implemented one-off peripherals. It is wired according to REVERSERS, left-hand entry for variant pins. BOOSTER ======= The `booster' generates the track voltage. It includes an overload protection feature. The PIC has direct control and responsibility for Turning the track voltage on and off Switching the track polarity according to the NMRA DCC spec Responding to overload (together with the hardware cutout) The relevant pins are Booster Shutdown (output) Booster Recent Overload (input) Booster Direction (output) User Fault Indicator (output) *** PROVISONAL *** If the following conditions are true, the track will be supplied with power: * Shutdown is L * The overcurrent cutout permits The polarity of the power is controlled by the Direction pin. There is no need to specify which polarity is which, as this is not meaningful in NMRA DCC. However, for debugging it is useful to know that for block sense to be effective on unreversed segments, the direction output from the PIC should be L. Booster Overload Cutout and Shutdown ------------------------------------ Initially, the Shutdown output should be Z. During normal operation, when the PIC wishes to supply power to the track, the Shutdown output should be L. (The PIC should allow the host to say whether the track should be provided with power.) The overload cutout compares the track current against a preset value. Excessive current (or excessive voltage drop on booster's power input) constitutes overload. If an overload occurs, the track power will be disconnected. (This may take anywhere between a few hundred ns and a few tens of us, depending on circumstances, and is not guaranteed not to involve multiple switchings.) With no track power, there will be no track current and the overload immediately disappears. So to prevent rapid oscillation, and as a backstop against PIC program failure, the overload circuit contains a retriggerable monostable: for the (approximately) 10ms following any overload, the cutout will still prevent the track power being restored. During this period, the Booster Recent Overload input will be H. Overload shutdown and decoders ------------------------------ However, following an overload-induced cutout it is in fact necessary to further delay the return of track power: firstly, a track power interruption of 10ms is not enough to ensure that a DCC decoder will not retain speed and similar information from before the outage, and secondly, the out-of-specification fluctuations on the track during overload and cutout can be misinterpreted by the decoder as an attempt to communicate via a different protocol or to drive it in DC mode. Therefore, following an overload, the PIC should arrange to keep the booster shut down (using the Shutdown output) for at least 100ms before trying again. Overload shutdown and the host ------------------------------ The host must be informed about overload cutouts, so that it can know that the trains have stopped and inform the user. Provision for this should be made in the PIC-to-host protocol. However, the host will not necessarily react to overload indications in a timely manner; in particular, it may continue to provide NMRA data which is only valid in the context of the state before the overload. The PIC must disregard such NMRA bitstrings, so there must be provision made in the protocol for the host to acknowledge the overload, and for NMRA data (and perhaps other instructions) to be processed only if they follow such an acknowledgement. (One way for the host to acknowledge would be to have the host reissue the `apply track power' instruction, or similar.) User Fault Indicator -------------------- The User Fault Indicator output controls, directly, the green segment of the `track power' tri-colour indicator LED. This segment should be lit by the PIC whenever an overload has been detected and the fault has not yet been rectified by the user. When a fault is present, the PIC should occasionally attempt to reapply track power, so that it can indicate to the user when the fault has been fixed. Output pin Green segment H off Z off L ON SERIAL PORT =========== The RS232 serial connection to the host arrives at PIC 0, on the pins indicated. PER-PIC LED =========== One pin of each PIC (the corresponding pin on each) drives the per-PIC LEDs, of which there are two per PIC: Output pin Orange LED Blue LED H off ON Z off off L ON off TRACK LAYOUT OBJECTS ==================== The physical relationship between track objects (detection segments, reversal segments, point motors, etc.) is not known to the PICs. The host protocol should name these objects by number in some representation convenient for the PICs. However, each PIC must be aware of which pin is connected to which kind of peripheral and must prevent the host from accessing one kind of peripheral as if it were another. Otherwise the host could send instructions which would cause the PIC to try to treat an output as an input, or do other things which might damage the PIC or circuitry. Therefore, each PIC must have configuration information (either stored in the PIC's ID locations along with its address, identity, etc., or compiled into the PICs' common firmware and indexed by its identity) which lets it know what peripherals are connected. README.protocol should specify how this information is to be provided by the build system to the PICs (eg, in a file on the host during the build? programmed into the PIC's ID locations?, and what the format should be. The first classification of PICs is into those on DETECTORS boards and those on REVERSERS boards. In the final plan there are 3 REVERSERS (including the master board with PIC 0) and 5 DETECTORS. POINTS AND CDU ============== Each point has two point motors, each controlled by one PIC pin. These two motors are treated as two separate objects by the PICs. Power for operating the point motors is supplied by the single CDU. While the CDU is enabled and no point motor is activated, the CDU charges up until it has enough energy to switch one point. This takes approximately 500ms. (The PIC program should be written so that this period can be adjusted fairly easily from around 200ms to 1000ms in relatively coarse steps.) When the CDU is charged, a point may be switched by activating the relevant output. The point motor output should be active for at least 100ms. After the point has moved, the relevant point motor output should be disabled again so that the CDU may recharge. The PICs should not attempt to activate more than point motor at once, nor to activate a point motor when there may be insufficient energy, since doing so leaves the point in an unknown state. The PICs should not assume that the CDU remains charged if it is disabled. There is no need to disable the CDU while switching a set of points. While the CDU is disabled, it gradually discharges. Point N pin Effect H Activated - point changes if CDU charged L Not activated Z Results not defined, do not use Point 0 pin Effect L Activated - point changes if CDU charged H Not activated Z Results not defined, do not use CDU Enable pin Effect H CDU is enabled (and charges up) Z CDU is disabled (and discharges) L CDU is disabled (and discharges) Suggested behaviour: the CDU could be enabled whenever track power is provided. The host will need control over the timing of point changes, so while the PICs should prevent the host from activating a point when the CDU is not ready, they should not delay the point change for this reason - instead, they should reject it. The host will also need to know when the point has been changed, and would probably also like to know when it can ask to change another. The currently envisaged PCBs can support up to 104 point motors. BLOCK SENSE =========== Each track section is equipped with a circuit for sensing the presence of current-drawing rolling stock. This circuit is only effective during one of the two track polarities (see Booster, above) - while the track current is the other way, the block sensor does not detect a train. Furthermore, due to intermittent poor contact, a train may `disappear' briefly - usually for a few ms, but exceptionally for a few tens of ms. This means that reporting every change in the set of detectable trains to the host would exceed the capacity of the serial link. The requirements are: * The host must be informed quickly if a train is spotted where the host has been told that there is no train. 10ms would be good; 100ms would be very marginal. * The host should be informed reasonably quickly if a train ceases to be perceptible. 100ms would be fine for this, although sooner would be better. * The currently envisaged PCBs can support up to 123 detection segments. The SENSE pins should always be configured as inputs (Z state); otherwise damage to the detection circuitry may occur. When a train is detected, the input will be L; otherwise it will be H. TRACK POLARITY ============== Some track sections have reversible polarity. The host needs to have timely control over the polarity of these sections, and needs to be able to switch several of them simultaneously (to avoid short circuits). The polarity states are Reverse pin Effect H segment polarity reversed L segment polarity not reversed Z undefined, do not apply track power Changing takes 1-10ms. The currently envisaged PCBs can support up to 18 reversible segments. *** PROVISIONAL: *** It may prove necessary to temporarily disable track power during certain polarity changes. FUTURE DIRECTIONS ================= In the future some PICs may be also asked to control the following: * Turntable: outputs to select stop, clockwise or anticlockwise; inputs: probably some binary optoreflective inputs which may need some decoding to establish the turntable's orientation * Uncoupler (probably a simple binary choice) * Tipper wagon actuator (probably a simple binary choice) * Signals (this may involve many more PICs) * Scenery lighting or displays - either one global item, or perhaps many outputs