It is wired according to REVERSERS, left-hand entry for variant pins.
+
BOOSTER
=======
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.
+
+
+
+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
+
+ 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.
+
+
+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.
+
+*** 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
~ijackson / trains.git / commitdiff