Copper Mountain's pre-activation sequence consists of a pulse train sent
unidirectionally by the STU-C before dropping into the standard HTU-C startup
sequence.  During pulse transmission the bitpump is operated at 80 kHz symbol
clock and pulses are generated by turning the transmitter on and off for a set
number of symbol periods (using the bitpump's general purpose timer 3).

The pulse train has the following structure:

1. A single 300 ms pulse is followed by a 150 ms pause.  It is the only pulse
   of this duration, hence the STU-R knows to start counting when it detects
   this pulse.

2. A number of 150 ms pulses separated by 150 ms pauses.  The number of 150 ms
   pulses encodes the data rate as follows:

   0 =  160 kbps
   1 =  208 kbps
   2 =  320 kbps
   3 =  416 kbps
   4 =  392 kbps
   5 =  784 kbps
   6 = 1040 kbps
   7 = 1568 kbps
   8 = 2320 kbps

3. One final pulse of 600 ms duration.  It is the only pulse of this duration,
   hence when the STU-R detects it, it looks at the number of pulses counted so
   far and determines the operational data rate based on that.  (NOTE: our
   previous version of this document said that the duration of this pulse was
   300 ms - that was an error on our part.)

4. Final pause: 100 ms of silence.

5. The bitpump clock is switched to the operational symbol rate and the
   standard HTU-C startup sequence begins.

We have implemented this pre-activation sequence in our SDCORE shared library
in the STU-C role exactly as described above, and it links up with standard CM
CPE devices.  We have also implemented the detection and counting of these
pulses and automatic data rate configuration in the STU-R role by having copied
the logic from disassembly of CM's own CPE code, and our SDCORE STU-R
implementation has been tested and proven to work against the real CE200 DSLAM.

The fact that it works successfully in both roles (STU-R links up with the real
DSLAM with data rate autodetection and STU-C emulates a CM DSLAM well enough to
satisfy CM's own CPE devices) is good evidence that our understanding of the
pre-activation sequence and its implementation is now correct.  See the source
code for the details (currently in the hackorocket tree, soon to be moved to
the OSDCU).