The Alpha Paging Entry Protocol: Talk to Motorola and they will probably say they invented it. Talk to IXO and they will probably take credit for it too. It is known as the "IXO" protocol because the IXO Company used to make a little hand-held keyboard de vice for entering alpha messages. Motorola likes to call it "PET" for Personal Entry Terminal. After it was adopted by the Telocator Paging Association (now called PCS) they started calling it "TAP" for Telocator Alpha-entry Protocol.
The truth -- like many things in life -- is not so well known. It was actually written at the direction of my good friend Bob Edwards, the paging industry pioneer. Bob owned Radiofone Corp. (Empire Paging in New York) which was one of the largest carriers in the USA. One of Bob's technical people (Doug Morrison) wrote the code because Bob had the vision to get into Alphanumeric Paging before anyone else thought it was a good idea.
He also had the first Numeric Display Pager manufactured when everyone else in the industry thought voice pagers was the only way to go. Of course, the Numeric Display Pager became the most successful pager ever made, and it continues to lead the world m arket by a large margin. Alphanumeric paging is gaining share of market in the US and is clearly the dominant offering in Latin America with over 90% of the market.
| Step | Remote entry device does | Paging central does | Comments |
| 1 | Off hook Access DDD line Await dial tone Dial stored access number |
Ring Answer |
|
| 2 | Carrier up | Carrier up | |
| 3 | "<CR>" | "<CR>" is repeated at two second intervals until paging central responds with "ID=" at correct baud rate or until 3 transmissions have bee n completed. (This step exists to allow for possible future baud rate recognition). (All quotation marks or the symbols shown are used for notation in this document and are not transmitted). | |
| 4 | "ID=" | Request for ID returned within one second of receipt of <CR>. | |
| 5A | (For automatic remote entry devices) "<ESC> SST" |
"<ESC>" signifies entry device intends to talk in automatic
dump mode. "SS" is a set of two alphanumberic characters signifying a type of service to be accessed. (For a paging service where:
Field 1 = "Pager ID" and SS will be sent as "PG".) Where T is a single alphanumeric character relating to the type of terminal or device attempting to send the message. T = "1" is a catagory of entry devices using the same protocol. The IXO and Novation devices are members of this category. T = 7, 9, 9 are reserved for wild card terminal or devices which may relate to a specific user's system. 6 alphanumeric character password (PPPPPP) here from automatic terminals. (Password is optional and may be different lengths in some systems). |
|
| 5M | (For manual remote entry.)
"M<CR>" |
Lack of <ESC> at beginning of response to "ID" signifies
manual operation where applicable.
Any manual operation is user defined after logon. <"M CR"> can be replaced by any sequence ending in <CR> and not beginning with <ESC>. |
|
| 6 | "<Message sequence> <CR> <ACK> <CR>"
|
Logon accepted or Requested again
|
|
| 7 | "<ESC> [p <CR>" | Message go ahead is sent when paging central is ready for new information. Note: the "p" is in lower case. | |
| 8 BLOCK #1 BLOCK #2 BLOCK #3 BLOCK #4 LAST BLOCK |
TRANSACTION #1 "<STX> FIELD #1 <CR> FIELD #2 <CR> | | FIELD #N <CR> <ETX><CHECKSUM><CR>" TRANSACTION #2 "<STX> FIELD #1 <CR> | | | FIELD #J <CR> <ETB><CHECKSUM><CR>" "<STX> FIELD #J + 1 <CR> | | | FIELD #L <CR> <ETB><CHECKSUM><CR>" "<STX> FIELD #L + 1 <CR> | | | FIELD #N <CR> <ETX><CHECKSUM><CR>" LAST TRANSACTION
"<STX> |
"<Message sequence> <CR> <ACK> <CR>"
"<Message sequence> <CR> <RS> <CR>"
"<Message sequence> <CR> <ESC> <EOT> <CR>" |
A "block" is up to 256 characters in lentgth, with up to 250
characters of info, plus 3 control characters and a 3 character checksum.
The block carries one transaction (one set of all fields 1 through N) or
a portion of a transaction. A bl ock always carries an integral number of
fields with their associated <CR>'s. It may be less than 256 characters
to accommodate short transactions or the integral number of fields rule.
A field, with its associated <CR>, may not exceed 250 characters. The <CR> field delimiter suggests <CR> may not be used within a field. The <ETX> is used if a given transaction (Fields 1 through N) ends within the block currently being transmitted. The <ETB> is used if the transaction is continued into the next block. No limit is established within the protocol itself regardin g the number of transactions or the number of blocks or fields or blocks per transaction; however, a particular user system may have limits on either or both. Some systems may be limited to one block per transaction and one transaction per phone connectio n. Each checksum is computed by performing the simple arithmetic sum of the 7-bit values of all characters preceding it in that block. (This means that STX and ETB/ETX are included in the sum). The checksum is then the least significant 12 bits of this resul ting sum. The checksum is transmitted as 3 printable ASCII characters having values between HEX 30 and HEX 3F (the characters 0123456789:;<=>?). The most significant 4 bits of the sum are encoded as the 4 LSB of the second character and the least significant 4 bits of the sum are encoded as the 4 LSB of the third character. (See example in following table.) A normal paging system will have 2 fields only: Field 1 = Pager ID (normally up to 8 digits. May include function and check digit). Field 2 = Message. When a page is tone only, Field 2 will be empty. (Field 2 will typically be up to 80 alphanumeric or up to 24 numeric characters). The response to each block is one of four: <ACK><CR> = OK, send next block.
<ESC><EOT><CR> = Begin disconnect. Any of the responses may have an optional message sequence before them, although the system designer should understand the consequences to the user with all planned entry devices. It is expected that many systems will save their message sequence responses until immediately before disconnect. For some entry devices, it may also be desirable that messages describing non-checksum errors associated with a particular transaction in a "P G" service will begin with the letters "ID" followed by the contents of field 1 for that transaction. |
| 9 | "<EOT><CR>" | After reception of an <ACK> or <RS> for the last transaction in a given service, the entry device sends <EOT><CR > meaning there are no more transactions remaining in this service. | |
| 10 | "<Message sequence> <CR> <ESC> <EOT> <CR>" followed by dropping of carrier and hang up. | Optional message sequence before <ESC> <EOT> below
denotes degree of acceptabiloity of info rmation in all transactions on this
service
<ESC><EOT> = Begin disconnect. |
|
| 11 | Drops carrier and hangs up. |
| The standard protocol will be ASCII with X ON, X OFF either
direction using a 10 bit code (1 start, 7 data, 1 parity, 1 stop) with even
parity.
In the case of delays, the paging central shall wait at lease four seconds (eight seconds in Steps 3 and 4) before disconnecting the remote entry device; the remote entry device shall wait at least 10 seconds for a character from the central before hangin g up. For initial use of the protocol, the paging central shall be equipped to receive full duplex using a Bell 103 compatible modem at 300 baud. Optionally, certain inputs may be capable of receiving 110 baud Bell 103 full duplex, 300/1200 baud Bell 212 full duplex, or 1200 baud Bell 202 half duplex. No echo shall be employed in full duplex mode. Any attempts at automatic baud rate determination shall be within the restraints of the specified protocol. |
| STX | 000 | 0010 | |
| 1 | 011 | 0001 | |
| 2 | 011 | 0010 | |
| 3 | 011 | 0011 | |
| CR | 000 | 1101 | |
| A | 100 | 0001 | |
| B | 100 | 0010 | |
| C | 100 | 0011 | |
| CR | 000 | 1101 | |
| ETX | 000 | 0011 | |
| ------------------ | ----------------- | ||
| 1 0111 | 10111 | ||
| Sum: | 1 7 | ; | Checksum = 17 ; |
"<STS> 123 <CR> ABC <CR> <ETX> 17; <CR>" |
Note: I hope there aren't any typos in this information. Let me know if you
find any. I checked it carefully against the original. Good luck! Let's keep
those beepers beeping with new applications.