🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Ice Sat, 26 Sep 1992 20:50
How does PEP work?
#18
Author: Ice
Date: Sat, 26 Sep 1992 20:50
11 lines
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?
#23
Author: Geoffrey Welsh
Date: Mon, 28 Sep 1992 16:09
70 lines
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