The Alpha Paging Entry Protocol
Talk to Motorola and they will probably say they invented it. It is known as the iXO protocol because of the iXO Company that used to make a little handheld keyboard device for entering alpha messages. Motorola likes to call it by their name PET for Personal Entry Terminal. After it was adopted by the Telocator Paging Association (now called the PCIA - Personal Communications Industry Association) they started calling it TAP for Telocator Alphanumeric Protocol. One company even called two different functions within their product by the separate names TAP and iXO. Actually all three names, TAP, iXO, and PET refer to the exact same protocol.

The following is an excerpt from e-mail, received on 3/18/02, which corrects the previous erroneous information, that had been on this site for a long time, about who invented this protocol.

My name is Mike Suchoff. I was the inventor if the iXO telecomputer. At the time, we (iXO) needed a market for our product — and paging input was a good match. The telecomputer already had the capability of automatically dialing and performing data transfers. That protocol was the basis for the original paging protocol.

At the time, I was called down to Texas by the paging manager at Motorola. His name escapes me, but I believe is was Bob something (I was to say "Bob please," or something like that). At that meeting were Motorola, me from iXO, and a representative from a 2nd terminal manufacturer (again, it escapes me, but I believe it was a terminal that was used by the deaf). The resulting protocol was based on the already existing iXO protocol, plus some changes so the other terminal could work.

Mike Suchoff
In Tune, Inc.
919-933-8495

After further discussion, Mike and I believe that the meeting was probably with Bob Scwendeman at a Motorola facility in Florida. The other alpha-entry terminal manufacturer in those days was Novation.

Off hook

Access DDD line

Await dial tone

Dial stored access number

Ring

Answer

(For automatic remote entry devices)

"<ESC> SST"

"<ESC>" signifies entry device intends to talk in automatic dump mode.

"SS" is a set of two alphanumeric characters signifying a type of service to be accessed.

(For a paging service where:

Field 1 = "Pager ID" and
Field 2 = "Message" (where applicable)

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 category 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).

"M<CR>"

Any manual operation is user defined after log-on. "M <CR>" can be replaced by any sequence ending in <CR> and not beginning with <ESC>.

or

"<Message sequence> <CR> <NAK> <CR>"

or

"<Message sequence> <CR> <ESC> <EOT> <CR>"

or

Requested again

or

Forced disconnect

A message sequence is defined as a series of short messages separated by <CR>'s. Message sequences are totally optional.

"<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>
FIELD <CR>
  |
  |
  |
FIELD #N <CR>
<ETX> <CHECKSUM> <CR>"

"<Message sequence> <CR> <ACK> <CR>"

or

"<Message sequence> <CR> <NAK> <CR>"

or

"<Message sequence> <CR> <RS> <CR>"

or

"<Message sequence> <CR> <ESC> <EOT> <CR>"

A "block" is up to 256 characters in length, 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 block 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&gt,, 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 regarding 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 connection.

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 resulting sum.

The checksum is transmitted as 3 printable ASCII characters having values between HEX 30 and HEX 3F (the characters 012345678 9:;<=>?). 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.

or

<NAK> <CR> = Checksum error, send latest block again.

or

<RS> <CR> = Abandon current transaction and go to next. RS may occur when the checksum is OK, but the current transaction violates a system rule. At the option of the system, it may occur in other cases.

<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 "PG" service will begin with the letters "ID" followed by the contents of field 1 for that transaction.

Optional message sequence before <ESC> <EOT> below denotes degree of acceptability of information in all transactions on this service.

<ESC> <EOT> = Begin disconnect.

Note: There is no revision number given because this is the original iXO protocol before it was known as TAP. This listing is from a handout sheet given to me many years ago at a Telocator Show by John McGovern who was the V.P. of sales at iXO. There have been several revisions to the TAP protocol over the years. This version should work fine on almost all systems -- it just doesn't have some of the newer enhancements. The latest official version of the TAP protocol (version 1.8) is available on the web -- complements of Motorola. You will be better off using the official version.

U.S. ASCII Table If you are implementing the TAP protocol, you may need to refer to the ASCII table. This table shows the decimal and hex equivalent for each ASCII character.

Help on the TAP checksum.