Basics of POCSAG

POCSAG is a radio data protocol for sending messages to pagers. It was developed by the UK Post Office Codes and Standards Advisory Group (POCSAG), where it gets its name. On the air, it is a frequency shift keyed signal that carries serial data at 512, 1200 or 2400 bps. The deviation on the FSKis +/- 4.5 kHz, which is pretty wide. The resultant signal occupies 25 kHz of bandwidth.

Data is transmitted using 32 bit 'codewords', with the first bit indicating whether the codeword is an address (0) or data (1). Each codeword contains a 10 bit forward error correction code and a parity bit, so there are only 20 bits left to convey information. The astute among you will notice that 20 is not a multiple of 8. Originally, numeric data (i.e. phone numbers) was encoded as Binary Coded Decimal (BCD), which is 4 bits per digit, making 20 bits totally reasonable. Sending and receiving ASCII messages requires splitting the bytes into nibbles, and then packing five nibbles into each codeword.

(POCSAG frame structure and addressing, taken from US Patent Application 2003/0093167 A1)

Codewords are grouped into pairs to make a frame, and 8 frames are grouped into a batch. Each batch starts with a synchronisation codeword (0x7CD215D8) that effectively tells the receiver "Here is the start of a batch." You will find out why this is important in a moment. Empty codewords in a batch are filled with the value 0x7A89C197.

Addresses, which are known as Radio Identity Codes (RICs), are 18 bits long, which would suggest that there can only be 262,144 pagers; however, to save power, the pagers only listen to 1 in 8 frames, effectively increasing the address space to 21 bits and or 2,097,152 devices. The frame that the pager listens to is determined by modulus 8 of the RIC.

The best explanation that I've found so far on POCSAG is on the website of an anonymous Swede. He has gone to the trouble of creating some excellent diagrams that illustrate what is going on.

Fortunately, the transmitter that I acquired for this project does a lot of the legwork involved in grouping the data into codewords, frames and batches. I've included a short dit here to help anyone who might be trying to code the signal from scratch to use with a soft modem, TNC-Pi, etc.

RF DataTech ART Paging & Data Transmitter

The ART is a purpose-built device for encoding and transmitting messages to pagers. It is intended to be used in site-area paging systems, e.g. in hospitals, hotels, etc. It has a configurable power output of between 50 mW and 5 W, and the ART400 version covers 402-512 MHz, so it can be used on the 70 cm amateur band with an appropriate licence.

The transmitter is controlled over RS232 using a simple protocol. Commands to configure the transmitter are prefixed with ')', and data to be transmitted is prefixed with '/'. All commands finish in '\r'. Responses to commands are either values prefixed with '(', an acknowledgement or success '*', or an error number preceded by '!'. The full gamut of commands and responses can be found in the user manual.

To send a page, the address has to be calculated from the RIC and the function bits. Function bits are usually used to determine what the pager should do e.g. beep or display a message. Some pagers allow function bits to override their volume settings i.e. messages with certain function bits set will always produce an audible alert.  I mainly use this in Badger to annoy people.

To calculate the address, multiply the RIC by 4 and then add 0, 1, 2 or 3 depending on which function bits are set (00, 01, 10 and 11 respectively). Convert this value into ASCII-encoded hex and pad it so that it is exactly 3 bytes (6 ASCII characters) long. Data to be transmitted is usually in ASCII. Simply convert this straight into ASCII-encoded hex.

Send the data to the ART in the format of '/'.$address_hex.$data_hex.'\r' . If everything works, the ART will send '*' back after a short pause.