> Thank you to Nate for the wonderfully full description!

> I disagree on the uses of the AC signal for powering the repeaters,
> as everything I have see has network power of up to 130V DC power
> on a separate pair of wires to the repeater.

I've also always seen the repeaters powered by 130-200VDC on the
wire.  This is partly why telco linemen will actually go to the
trouble of "protectoring" the pairs (putting the red plastic covers
on the punch-down positions) -- it does bad things to your test set
if you are looking for dialtone and clip onto a T1.  I also try to
not ground myself (i.e. leaning on a pipe) while probing a frame.

>>> Of course, the 56k calculation and bit about the phone companies
>>> throwing away the last bit for clocking purposes is out of a DSP book.

>> Unfortunately, it's dead wrong. Telcos have *never* used this method of
>> clocking data over digital lines at any rate.
>>
>> In North America and other countries using the T1 standard, each channel
>> really has 64 kbps of data (8 ksps x 8 bits per sample) devoted to it.

And such a 64kbps channel is a DS0 standard.  24 DS0s multiplexed
together make 1 DS1 (which is commonly carried on a T1 physical
interface).  [And 30 DS0s make a European E1 capacity circuit.]
30 DS1s make a DS3 which is usually carried on copper as a T3.

T1 speed of 1,544,000 bits/second is 24 * 64,000bps + 1 * 8000 bps
administrative overhead.

As Dave said, any digital equipment using a channel can only rely on
having 7 bits per sample (x 8000 samples/second = 56kbps) because of
low order bits "robbed" for in-band signalling.  It made no difference
when the telco used the digitized channels to carry voice -- people
just couldn't notice it.

If you need all 8 bits, you need to ensure your contract specifies
that the channel(s) is 8-bit clear (or similar).  It can be done,
but the telco frequently won't guarantee such service for free.

DS0s get reused a lot.  For example, ISDN uses DS0 for each of the
two B (bearer) channels plus 16,000bps for the D (data, signalling)
channel.  Thus ISDN's 144,000 bps raw on-wire data rate.


And since I've bothered to speak up...

> Why is each higher baud rate twice as fast until 14.4K which is
> only 1.5 times faster than 9600?
>
> 115,200
>  57,600
>  28,800
>  14,400
>     ?
>   9,600
>   4,800
>   2,400
>   1,200
>     600
>     300

You left out 19,200 and 38,400.  Both were commonly used on serial
links long before modems could go anywhere near that fast.  These
are even multiples of 9,600.

And I don't recall 14,400 or 28,800 as being serial link speeds.
They were modem speeds and had to do with the number of bits per
second that could be packed into the number of signal states per
second (i.e. baud) that were available on that link.  Telecomm life
really was simpler when 1 baud == 1 bit/second. :-)

Running the serial link faster than the modem rate because common
once sufficient compute power and buffer memory was available in the
modem to do transparent data compression "on the fly" -- even before
modem speeds exceeded 2400bps.  I recall Micom's MNP protocols to
do inter-modem compression.

Another old reason to run the serial link faster than the line speed
was synchronous modems.  A modem that, on a dedicated 1 or 2 analog
pair, cost about $1 per 1 bit/second (per modem).  Yes, boys & girls,
that was a couple thousand dollars per 2400 bps modem.

Synchronous modems usually used 8 bits per character (width varied,
but I'll assume 8 to simplify this discussion).  The modem provided
seperate data & clock signals on its serial interface.  Concentrator
handled framing, error correction, and (given the chronologic time)
was usually built with many PC boards stuffed with TTL.

The serial link from the concentrator/controller to end devices was
asynchronous at 10 bits/char.  If you ran the async and sync sides
at the same rate -- say 2400bps -- then the sync side had 300 char
per sec while the async side could only transfer 240 char/sec.  At
this time, buffer memory was very expensive.  This is why the link
protocols also provided flow control (usually as a side benefit).

                                                Lee Jones

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu