This page is not a summary of the FLEX protocol. Instead, for a nice introductory page explaining how information is transmitted using multiple phases, please look at this Instead, some general paging and FLEX information can be found here; that site has a nice explanation of how FLEX information is transmitted using multiple phases. For more technical information, look at the datasheet for the Motorola's MC68175 Flex paging decoder chip, which can be found here or for more of an overview look here . That datasheet contains a nice but at times vague description of the FLEX protocol (the intent seems to be to give a design engineer a grasp on how FLEX works without burdening him/her with excessive details). Even better, US patent #5555183 covers the flex protocol (thank you to the kind soul who pointed this out to me).
The rest of the information on this page is the nitty-gritty information that you must know in order to decode the FLEX protocol, but which I could not track down on the internet or at the local library. This information is mostly the result of guesswork based on data collected from actual FLEX transmissions.
| MODE | BAUD RATE | PHASES | SYNC SEQUENCE |
| FLEX | 1600 (2 level FSK @ 1600 SPS) | A | 870C A6C6 AAAA 78F3 |
| FLEX | 3200 (4 level FSK @ 1600 SPS) | A & B | B068 A6C6 AAAA 4F97 |
| FLEX | 3200 (2 level FSK @ 3200 SPS) | A & C | UNKNOWN (*) |
| FLEX | 6400 (4 level FSK @ 3200 SPS) | A,B,C & D | DEA0 A6C6 AAAA 215F |
| REFLEX 25 | 1600 (2 level FSK @ 1600 SPS) | A | UNKNOWN (*) |
| REFLEX 25 | 3200 (4 level FSK @ 1600 SPS) | A & B | UNKNOWN (*) |
| REFLEX 25 | 3200 (2 level FSK @ 3200 SPS) | A & C | UNKNOWN (*) |
| REFLEX 25 | 6400 (4 level FSK @ 3200 SPS) | A,B,C & D | 4C7C A6C6 AAAA B383 |
(*) NOTE: Program should be able to handle these modes once their sync sequences are found.
The first step in decoding a FLEX (or ReFLEX) tranmission is figuring out exactly when a frame starts and what tranmission will mode is used to tranmsit data in that frame. The program does this by looking for one of the synchronization sequences shown above (No matter what transmission mode is used inside the data frame, the sync is always transmitted at 1600SPS 2 level FSK).
As you can see, there are four modes that are currently not recognized by the program. I could not determine their synchronization sequences because these modes are not used in my local area. It is apparent from the above table that the two center words should be "A6C6 AAAA" and that the two other words should XOR together to give "FFFF". Any unrecognized sync headers fitting this pattern will be shown on the screen as "UNKNOWN SYNC HEADER: xxxx xxxx xxxx xxxx" message. If you keep seeing that message, you have most likely found either a 3200 Baud 2 level FSK transmission or one of the lower speed ReFLEX modes. It would then be a simple matter to modify the program to recognize this mode (if this happens to you please send me the information).
After the sync sequence is detected, tranmission continues at 1600 baud for another 88 characters or so. The program basically ignores this information except for the Frame Information Word (FIW) which is sent during this time. This 32 word uses the same bit fields (21 data, 10 BCH, 1 parity) and error correction/detection as POCSAG. The FIW determines the cycle and frame numbers which are displayed on the status line. Although this information is used by real pagers to determine when to go to sleep, the program processes this information only to make the status line look more impressive.
Finally, transmission of the actual frame takes place (transmission speed is changed at this point if necessary). The program splits the transmitted data up into the appropriate phases (the number of active phases is determined by which synchronization sequence is used). Each transmitted phase is a completely independent data stream consisting of 11 blocks. Each block consists of eight 32bit words that have been interleaved. Each 32 bit word has the same bit field structure and error detection/correction code that is used in POCSAG. So, by the end of the frame the program will have collected 88 words of information per active phase. The program switches back to 1600 baud 2 level FSK in order to start looking for the next sync header.
Brief aside: you will notice that FLEX/ReFLEX words use the same error dection and correcting codes that are used in POCSAG. It was therefore a relatively simple to add the capability to decode POCSAG pages.
Up until this point FLEX and ReFLEX 25 data is processed in the same manner. At this point, a ReFLEX message will be spread out over all active phases (e.g. the message words could be Ph.A/Wd17; Ph.B./Wd17; Ph.C./Wd17; Ph.D./Wd17; Ph.A./Wd18; Ph.B./Wd18; et cetera). Since I did not find any further details on ReFLEX, the program displays all successive non-idle words onto the screen in ReFLEX mode; the result is a pretty ugly display but you most certainly will be able to read the ReFLEX message traffic (that's better than not supporting ReFLEX at all). Since I found a lot more information about FLEX message structure I was able to format the received messages much more intelligently. The next table shows the possible FLEX word types transmitted during each phase and how they are currently processed.
| Word Type | Bits | Interpretation |
| FIW - FRAME INFORMATION WORD | 4-7 | 4 Minute cycle number [0-E] |
| 8-13 | Frame Number [0-7F] | |
| BIW - BLOCK INFORMATION WORD | 10-15 | First vector word number |
| 8-9 | First address word number minus 1 | |
| VECTOR FIELD - Hex/Binary/Alpha/Secure | 4-6 | Message Type |
| 7-13 | First Message word number | |
| 14-20 | Length of Message in words | |
| VECTOR FIELD - Numeric message types | 4-6 | Message Type |
| 7-13 | First Message word number | |
| 14-16 | Length of Message in words | |
| ADDRESS FIELD | 0-20 | Whole field shown on screen in hex |
| MESSAGE FIELD | 0-20 | Except for header bits, the complete message is shown on screen |
You can see that the program processes just enough of the information in the FLEX data stream to display a pager's address, the message type, and the complete message itself. It does not do any of the other functions a pager must do such as reassembling fragmented messages, check the error correction checksum in the message header, or decoding the time & date or pager address regrouping instructions. Because of this, don't be too suprised when the program occasionally runs off into the weeds and spits out mangled messages onto the screen.
For short addresses, simply convert the number to decimal and subtract 32768. You'll end up with a 7 digit number.
For long addresses, invert the second 21 bit word (the second half of the 12 digit hex number shown on screen), multiply by 32768, add 2067456, and then add in the first word (converted to decimal). The resulting number is displayed in 9 digit format with leadin zeroes.
Technically, a FLEX capcode also includes phase, frame, and battery save information. Still, you should be able to find transmissions to your particular FLEX pager by matching up the 7 or 9 digit number shown by pocflex with that used on your pager.
To sum up:
I hope the information on this page
(along with the references given at the top)
helps you sort out the intimate details of the FLEX protocol.