TUCoPS :: Phreaking General Information :: flex.txt

Motorola FLEX Paging


                                FLEX Paging

  I located some technical data on FLEX which I do not see on the
Motorola website (www.motorola.com), so I will post it here.  This
information is from an 8/93 Motorola introductory manual titled "An
Introduction to FLEX(tm)".  A brief restatement of the contents
follows.

  FLEX can start at 1600 BPS bippolar FSK, and then upgrade to
higher speeds when system upgrades permit.  FLEX pagers can accept
1600, 3200 and 6400 BPS speeds without changes.  FLEX systems can
dynamically change data speed during times of peak demand, the
optimum speed being the lowest which meets traffic demand.  FLEX
has a binary message mode which permits message encryption.
(I have never examined this encryption feature.)

  The document says FLEX is compatible with existing protocols, but
APOC was not known when it was published.  (Most probably there are
ways to combine them on a channel if necessary.)  FLEX pagers must
see FLEX sync at least once per minute, and channel sharing must be
synchronized.

  Increased data speed requires more transmitters for comparable
coverage.  Compared to 1200 BPS POCSAG, 1600 BPS FLEX requires
about 1.2 times as many transmitters, 2400 BPS POCSAG requires
about 1.4 times as many transmitters, 3200 BPS FLEX requires about
1.8 times as many transmitters, and 6400 BPS FLEX requires about
twice as many transmitters.

  FLEX operates on a 4-minute overall cycle.  During this 4
minutes, there are 128 frames of 1.875 second each.  Each of these
frames contains a 1600 BPS sync header, followed by 10 data blocks.
At 1600 BPS, these blocks are 256 bits in size.  At 3200 BPS, they
are 512 bits in size, and at 6400 BPS they are 1024 bits in size.

  The blocks contain information arranged as 1, 2 or 4 groups of
eight 32-bit BCH codewords each.  Motorola refers to the coding as
(32,21)BCH code.  Each 32-bit codeword contains 21 bits of data
and 11 bits of error correction data.  The groups of eight
codewords are stacked in rows but transmitted by columns, which
interleaves the data.

  At 1600 BPS, each block consists of eight 32-bit codewords, or
256 bits, and these bits are transmitted as 1600 BPS bipolar FSK.
At 3200 BPS, each block consists of 512 bits from two multiplexed
eight-codeword groups, and these bits are transmitted as 4-FSK at
1600 symbols per second.  At 6400 BPS, each block consists of 1024
bits from four multiplexed eight-codeword groups, and these bits
are transmitted as 4-FSK at 3200 symbols per second.  At the
receiving end, the data is demuxed and de-interleaved into the
original groups of eight codewords and then BCH checked; up to 2
errors in each 32-bit codeword can be corrected.

  The breaking up of data into interleaved blocks is done for error
management purposes only.  The 10 groups of 8 codewords following
the sync header carry a block information word, an address field, a
vector field, a message data field, and any leftover space.  These
words and fields are contained in every frame following the sync
header, but they do not necessarily align with the codeword-group
boundaries.  Addresses are carried first in each field, so pagers
can "sleep" for the rest of the field if they are not being
addressed.

  There can be unused leftover space after the message data field
because the message lengths are variable and not all addresses
require vectors, yet the 10 blocks must remain at their fixed sizes for
synchronicity.  Motorola says the leftover space is filled with idle
codes.

  And at 3200 and 6400 BPS where two or four sub-frames are
multiplexed into each transmitted frame, the block information
words, the address, vector and data fields and the leftover space
of each sub-frame are of independent sizes.

  The pagers can be programmed to monitor only some of the frames.
The paging systems must of course be correspondingly programmed.
By monitoring fewer frames, the pager can "sleep" more, increasing
battery life where slower paging response can be tolerated.  For
example, if the pager monitors only every 32nd frame, there can be
up to 60 seconds of additional delay (32 times 1.875 seconds per
frame), but with substantial battery savings.  If instead the pager
monitors every fourth frame, the extra delay drops to 7.5 seconds
(4 times 1.875 seconds per frame), but with less battery savings.
Battery savings from 4 frame, 8 frame, 16 frame and 32 frame
programmings are shown in the document.

DISCLAIMER

  Not employed by or representing Motorola, not a shareholder of
Motorola, etc.

  This post is for information purposes only; I am not promoting
FLEX or any other format, although I am in favor the modern high
speed formats because they permit better use of congested radio
channels, and because they also offer improved battery life.

  More information on FLEX is available from Motorola at
www.motorola.com.

  Bob Bruhns, WA3WDR, bbruhns@li.net

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH