Thread View: kw.uucp
2 messages
2 total messages
Started by Ice
Sat, 26 Sep 1992 20:50
How does PEP work?
Author: Ice
Date: Sat, 26 Sep 1992 20:50
Date: Sat, 26 Sep 1992 20:50
11 lines
637 bytes
637 bytes
I am curious about how PEP works. Is there a document out there somewhere that explains how it works? Or maybe a mathematical explanationation? I assume it is some sort of run-length encoding which is capable of dynamically changing as a function of noise. Even better, does there exists an implementation in pseudocode/C? Ice()
Re: How does PEP work?
Author: Geoffrey Welsh
Date: Mon, 28 Sep 1992 16:09
Date: Mon, 28 Sep 1992 16:09
70 lines
4285 bytes
4285 bytes
ice@skynet.uucp (Ice) writes:
> I am curious about how PEP works.
I'll explain it. I'm going to assume that you know how all other modems
(Bell 103J FSK, Bell 212A DPSK, and V.32 Trellis Coded Modulation) work; if
this is not true, let me know and I'll restart from there.
> Is there a document out there somewhere that explains how it works?
I believe that there is, but I've never seen one single document which
includes everything I've learned from documents, talking to Telebit, and
working with Telebit modems. I've corrected a lot of misinformation, but I'm
bound to make some mistakes in trying to assemble the facts in one place.
> Or maybe a mathematical explanationation? I assume it is some sort of
> run-length encoding which is capable of dynamically changing as a function
> of noise.
It's far simpler than that, but there is a mathematical function involved:
the Fourier transform. More in a second...
> Even better, does there exists an implementation in pseudocode/C?
Strictly speaking, PEP is proprietary to Telebit. If you pay a significant
license fee, they *might* let you see the source. <grin>
PEP allocates 512 carrier frequencies, and codes a variable number of bits
per symbol on each, *independently*. The incoming data stream is spread over
the carriers, chopped according to the number of bits per symbol on each at
that time, and packetized. Since each symbol is encoded using QAM, which
translates a pattern of bits to an amplitude and a phase shift, what you have
is a table containing in each row a frequency, an amplitude, and a phase
shift... the normal output of a Fourier transform! So, the transmitting modem
applies a reverse Fourier transform to obtain a single waveform which contains
all components from the table and sends it on the phone line. The receiving
modem does a fast Fourier transform to turn the wave back into the table of
frequency, amplitude and phase values, which are then converted back into bit
patterns and assembled into the data stream at the other end.
Those who've done Fourier transforms know that the discrete implementation
is not a trivial operation, but PEP modems send these symbols only 7.8 times
per second (one of the advantages of sending up to 512 symbols at once!), so
the modem can take about an eighth of a second to perform it (ages compared to
the less than a millionth of a second it takes to do an add).
Carriers which are subject to errors are reduced in resolution until they
produce error-free transmission... even if that means shutting them off
entirely. A typical PEP connection will use only 420 carriers, with most of
the 'missing' ones near the top and the very bottom of the frequency spectrum
where poor response or distortion cause errors. Noises such as buzzing result
in 'holes' in the PEP frequency utilization, but allow it to work around the
problem while other modems might not be able to maintain a connection on the
same line.
PEP modems use a ping-pong scheme so that some data can trickle back; there
are normally three different lengths of time that one side may use to
transmit, and the 'ideal' for a unidirectional file transfer is for one side
to use the longest bursts while the other uses only the shortest. Any data
travelling one way obviously reduces the throughput potential in the other
direction, so protocol spoofing is implemented to eliminate the transmission
of ACK packets in the opposite direction and the accompanying drop in
throughput if the ACKs are delayed in any way.
Corrections invited.
Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
Coincidentally, most people who fight for "fairness" would be
significantly better off under the system they call "fair"...
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads