The following summary describes the coding used on POCSAG pager
signals and may be of interest to those curious about what those ear-splitting
beeps and buzzes mean and how they encode data.   This summary is
based on a very old text of the standard from my files; the current
text of the POCSAG standard is available as CCIR Radiopaging Format 1.

        Note that some current POCSAG signals (so called Super-POCSAG)
transmit paging at 1200 or 2400 baud instead of the 512 baud I refer to
here, but use essentially a similar coding standard.

        The interested USA reader is reminded that willfully intercepting
other than tone only paging is a violation of the ECPA with similar
penalties and criminal status to willfully intercepting cellular phone calls.

        The interested reader is advised that at least two of Universal
Shortwave's RTTY reading devices (the M8000 and the new C-400) are
capable of reading at least the older 512 baud version of POCSAG paging,
so commercial devices for this purpose are currently being sold in
the USA.

        And finally, much alphanumeric paging - particularly that installed
some time ago, uses a proprietary Motorola encoding format called
GOLAY which is quite different from POCSAG.  The two can be told apart
by their baud rates - GOLAY is 600 baud.


                POCSAG


        First POCSAG stands for Post Office Code Standarization Advisory
Group.   Post office in this context is the British Post Office
which used to be the supplier of all telecommunications services in
England before privatization.

        POCSAG as defined in the standard, (original POCSAG) is 512 bits
per second direct FSK (not AFSK) of the carrier wave with +- 4.5 khz shift
(less deviation than that is used in some US systems).  Data is
NRZ coded with the higher frequency representing 0 (space) and the
lower one representing 1 (mark).

        The basic unit of data in a POCSAG message is the codeword which
is always a 32 bit long entity.  The most significant bit of a codeword
is transmitted first followed immediately by the next most significant
bit and so forth.  The data is NRZ, so that mark and space values (plus
and minus voltages) as sampled on the output of the receiver
discriminator at a 512 hz rate corrospond directly to bits in the
codeword starting with the MSB.   (Note that the audio output circuitry
following the discriminator in a typical voice scanner may considerably
distort this square wave pattern of bits, so it is best to take the
signal directly off the discriminator before the audio filtering).

        The first (msb) bit of every POCSAG codeword (bit 31) indicates
whether the codeword is an address codeword (pager address) (bit 31 = 0)
or a message codeword (bit 31 = 1).  The two codeword types have
have different internal structure.

        Message codewords (bit 31 = 1) use the 20 bits starting at bit
30 (bit 30-11) as message data.  Address codewords (bit 31 = 0) use 18
bits starting at bit 30 as address (bits 30-13) and bits 12 and 11 as
function bits which indicate the type and format of the page.  Bits 10 through
1 of both types of codewords are the bits of a BCH (31,21) block ECC
code computed over the first 31 bits of the codeword, and bit 0
of both codeword types is an even parity bit.

        The BCH ECC code used provides a 6 bit hamming distance between
all valid codewords in the possible set (that is every valid 32 bit
codeword differs from ever other one in at least 6 bits).  This makes
one or two bit error correction of codewords possible, and provides
a robust error detection capability (very low chance of false pages).
The generating polynomial for the (31,21) BCH code is x**10 + x**9
+ x**8 + x**6 + x**5 + x**3 + 1.

        Codewords are transmitted in groups of 16 (called batches), and
each batch is preceeded by a special 17th codeword which contains a
fixed frame synchronization pattern.  At least as of the date of the
spec I have, this sync magic word was 0x7CD215D8.

        Batches of codewords in a transmission are preceeded by a start
of transmission preamble of reversals (10101010101 pattern) which must
be at least 576 bits long.  Thus a transmission (paging burst) consists
of carrier turnon during which it is modulated with 512 baud reversals
(the preamble pattern) followed by at least 576/512 seconds worth of
actual preamble, and then a sync codeword (0x7CD215D8), followed by 16
data/address codewords, another sync codeword, 16 more data/address
codewords and so forth until the traffic is completely transmitted.  As
far I am aware there is no specified postamble.  I beleive that all 16
of the last codewords of a transmission are always sent before the
carrier is shut off, and if there is no message to be sent in them the
idle codeword (0x7A89C197) is sent.  Later versions of the standard may
have modified this however.

        In order to save on battery power and not require that a pager
receive all the bits of an entire transmission (allowing the receiver
to be turned off most of the time, even when a message is being transmitted
on the channel) a convention for addressing has been incorperated which
splits the pager population into 8 groups.  Members of each group
only pay attention to the two address code words following the synch
codeword of a block that corrospond to their group.  This means that
as far as addressing is concerned, the 16 codewords in a batch are
divided into 8 frames of two codewords apiece and any given pager
pays attention only to the two in the frame to which it assigned.

        A message to a pager consists of an address codeword in the
proper two codeword frame within the batch to match the recipients frame
assignment (based on the low three bits of the recipient's 21 bit
effective address), and between 0 and n of the immediately following
code words which contain the message text.  A message is terminated by
either another address code word or an idle codeword.  Idle codewords
have the special hex value of 0x7A89C197.  A message with a long text
may potentially spill over between two or more 17 codeword batches.

        Space in a batch between the end of a message in a transmission and
either the end of the batch or the start of the next message (which of
course can only start in the two correct two codeword frame assigned to
the recipient) is filled with idle codewords.  A long message which
spills between two or more batches does not disrupt the batch structure
(sync codeword and 16 data/address code words - sync code word and
16 data/address codewords and so forth) so it is possible for a pager
not being addressed to predict when to next listen for its address and
only turn on it's receiver then.

        The early standard text I have available to me specifies a 21 bit
address format for a pager (I beleive this has been extended since)
with the upper 18 bits of a pager's address mapping into bits
30-13 of the address codeword and the lower 3 bits specifiying which
codewords within a 17 codeword batch to look at for possible messages.
The address space is further subdivided into 4 different message classes
as specified by the function bits (bits 12 and 11 of a codeword).  These
address classes corrospond to different message types (for example
bits 12 and 11 both zero indicate a numeric message encoded in 4 bit BCD,
whilst bits 12 and 11 both set to 1 indicate an alpha message encoded
in 7 bit ASCII).  It was apparently envisioned that a given pager could
have different addresses for different message types.


        There are two message coding formats defined for the text of messages,
BCD and 7 bit ASCII.   BCD encoding packs 4 bit BCD symbols 5 to a codeword
into bits 30-11.  The most significant nibble (bits 30,29,28,27) is the
leftmost (or most significant) of a BCD coded numeric datum.  Values beyond 9
in each nibble (ie 0xA through 0xF) are encoded as follows:

        0xA     Reserved (probably used for something now - address extension ?)
        0xB     Character U (for urgency)
        0xC     " ", Space (blank)
        0xD     "-", Hyphen (or dash)
        0xE     ")", Left bracket
        0xF     "(", Right bracket

        BCD messages are space padded with trailing 0xC's to fill the codeword.
As far as I know there is no POCSAG specified restriction on length but
particular pagers of course have a fixed number of characters in their
display.

        Alphanumeric messages are encoded in 7 bit ASCII characters packed
into the 20 bit data area of a message codeword (bits 30-11).  Since four
seven bit characters are 21 rather than 20 bits and the designers of the
standard did not want to waste transmission time, they chose to pack the
first 20 bits of an ASCII message into the first code word, the next
20 bits of a message into the next codeword and so forth.  This means
that a 7 bit ASCII character of a message that falls on a boundary can
and will be split between two code words, and that the alignment of character
boundaries in a particular alpha message code word depends on which code
word it is of a message.   Within a codeword 7 bit characters are packed
from left to right (MSB to LSB).   The LSB of an ASCII character is sent
first (is the MSB in the codeword) as per standard ASCII transmission
conventions, so viewed as bits inside a codeword the characters are
bit reversed.

        ASCII messages are terminated with ETX, or EOT (my documentation
on this is vague) and the remainder of the last message codeword is
padded to the right with zeros (which looks like some number of NULL
characters with the last one possibly partial (less than 7 bits)).

        The documentation I have does not specify how long a ASCII
message may be, but I suspect that subsequent standards have probably
addressed the issue and perhaps defined a higher level message protocol
for partitioning messages into pieces.   The POCSAG standard clearly
does seem to allow for the notion of encoding messages as mixed
strings of 7 bit alpha encoded text and 4 bit BCD numerics, and it
is at least possible that some pagers and paging systems use this
to reduce message transmission time (probably by using some character
other than ETX to delimit a partial ASCII message fragment).


Brett Miller N7OLQ                  brett_miller@ccm.hf.intel.com
Intel Corp.
American Fork, UT                   DoD#1461

-----------------------------------------------------------------------------