• pocsag

    From LU9DCE@21:5/101 to BBSRT on Mon Jul 1 13:40:06 2019

    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

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



    --- Mystic BBS v1.12 A43 (Linux/32)
    * Origin: HAMRADIO telnet lu9dce.dynu.com (21:5/101)