The Host to TNC protocol used over Serisl and Bluetooth links operates in two modes, Text or Hostmode. Text mode is primarily used for initialisation and testing, but can be used for simple interative QSO's using a standard ASCII terminal program. There is no error checking on the text interface. Hostmode is used for automatic operation, and provides error detection and recovery over the serial/Bluetooth line. ARDOP Hostmode is based on the SCS CRC Hostmode (as used in the PTC and Dragon Controllers) which is itself an extension of WA8DED Hostmode.
Either Protocol Mode can be used on one of two Operating Modes. ARDOP Native or PTC Emulation. The former supports the full ARDOP functionality, the latter enables ARDOP to be used with programs that support an SCS Pactor controllet, but don't have native ARDOP support.
ARDOP Native Mode is designed to be functionally similar to the TCP mode, to simplify host program and TNC support. Two DED Channels are assigned to the functions of the two TCP ports, Channel 32 for Control and Channel 33 for Data. A third channel (34) is used for debug information, as a standalone TNC doesn't usually have local storage for writing a debug log. The Protocol control channels (255 for polling, 254 for status and 253 for rig control) are used as defined by SCS.
This supports basic ARQ mode operation with software designed for Pactor. FEC operation isn't supported, but the Pactor Levels 1-4 are mapped to the ARDOP Bandwidths of 200 to 2000. Pactor Host Mode commands are converted to equivalent ARDOP commands, and ARDOP link status values mapped to equivalent Pactor values.
The protocol is polled master/slave, with a single bit sequence toggle to detect lost or duplicated frames.
The host program is the master and the TNC the slave. The polling frequency isn't defined, but a maximum interval of 100mS is recommended to minimise latency.
The link is considered Idle when the master has received an in-sequence response to its previous transmission.
The master can transmit at any time the link is idle. If it has data to send, it sends it, otherwise it sends a
General Poll message. The slave will respond with a list (possibly empty) of channels with data available. The master then polls each channel in the list.
If the master doesn't receive a valid response from the slave in a resonable time, it will repeat its last transmission. It it doesn't get a reponse after a reasonable number of retries it will report a link failure to
the higher lovel software, which will abort any transmission n progess, then try to reestablish the link.
If the master receives an out of sequence response following a timeout and retry it will assume a delayed response
from the slave, discard the respeat, and continue to wait for a valid frame. If it receives an out of sequence response at any other time it will assume a protocol error and reset and restart the link.
If the slave receives an out of sequence message it will assume that its previous response was lost, discard the message and resend the previous response unchanged.
All packets have a two byte header of 0xAAAA and a two byte CRC-16 checksum on end The top bit of the Opcode field is a sequence toggle. The basic packet format is: ----------------------------------------------- |Header|Chan|Opcode| Payload | CRC | ----------------------------------------------- |AA AA | XX | XX | XX XX XX .... XX |XX XX| ----------------------------------------------- Payload can have two formats, either a Null terminated ASCII string or a Byte Count of 0 to 255 followed by 1 to 256 bytes of data. There are two opcodes for Host to TNC packets, and eight for TNC to Host, though not all are used in ARDOP Native Mode. From Host to TNC Opcode 0 - Data Opcode 1 - Command From TNC to Host Opcode 0 - Response Success (no data follows) Opcode 1 - Response Success, followed by null terminated message Opcode 2 - Response Failure, followed by null terminated message Opcode 7 - Data, preceeded by (length-1) Channel 32 is used for Commands, Channel 33 for Data and Channel 34 for Debug information. Typical messages are shown below (control fields in Hex). Note that the Command format is used for hostmode protocol level commands. ARDOP commands (such as "ARQCALL") are sent as data on the Command channel. The Debug channel is for information to be written to a debug log. General Poll ---------------------------------- |Header|Chan|Opcode|Payload| CRC | ---------------------------------- |AA AA | FF | 01 | 00 47 |XX XX| ---------------------------------- Response is a null terminated list of channels with available data. Value is Channel plus 1 ---------------------------------- |AA AA | FF | 01 | 21 00 |XX XX| Channel 32 has data (0x21 = 32 + 1) ---------------------------------- Poll to TNC Command Channel ---------------------------------- |Header|Chan|Opcode|Payload| CRC | ---------------------------------- |AA AA | 20 | 01 | 00 47 |XX XX| ---------------------------------- Response is an async ARDOP response message -------------------------------------------------- |Header|Chan|Opcode| Payload | CRC | -------------------------------------------------- |AA AA | 20 | 07 |<0F>c:NEWSTATE ISS <0D>|XX XX| -------------------------------------------------- ARDOP Command to TNC ----------------------------------------------------- |Header|Chan|Opcode| Payload | CRC | ----------------------------------------------------- |AA AA | 20 | 00 |C:MYCALL G8BPQ <00> |XX XX| ---------------------------------------------------- response ----------------------------------------------------- |AA AA | 20 | 01 |c:MYCALL now G8BPQ <00> |XX XX| ----------------------------------------------------- Data to be transmitted ----------------------------------------------------- |Header|Chan|Opcode| Payload | CRC | ----------------------------------------------------- |AA AA | 21 | 00 |<12>D:(Len)Message to Send|XX XX| ----------------------------------------------------- response ----------------------------------------------------- |AA AA | 21 | 00 | |XX XX| ----------------------------------------------------- Received Data from TNC Data to be transmitted ----------------------------------------------------- |Header|Chan|Opcode| Payload | CRC | ----------------------------------------------------- |AA AA | 21 | 07 |<13>d:(Len)ARQMsg Received|XX XX| ----------------------------------------------------- This is no response to inbound frames, apart from the implied ACK of the next host frame having an inverted toggle.
SCS CRC Hostmode
See the PTC-IIIusb Manual Chapter 10 for details of CRC Hostmode .
WA8DED Packet Format
There are two data formats, null terminted or counted.
Byte 0 Channel Number
byte 1 Type Code (see table below)
byte 3-end Null Terminated string (max length 255)
or
byte 3 Info Length - 1
byte 4-end Info (length 1 to 256)
SCS CRC Hostmode adds two byte of 170 to the front and a crc-16 checksum to the end.
It also defines the top bit (bit 7) of the Type Code as a sequence toggle and next bit
(bit 6) as a sequence reset flag. Data transparency is ensured by adding a null byte
after any occurence of 170 in the message or crc.
Command Codes
Host to Tnc
-----------
CHANNEL CODE DESCRIPTION
------- ---- -----------
n 0 Information (preceeded by length-1)
n 1 Command (preceeded by length-1)
Tnc to Host
-----------
CHANNEL CODE DESCRIPTION
------- ---- -----------
n 0 Success (nothing follows)
n 1 Success (message follows, null terminated)
n 2 Failure (message follows, null terminated)
n 3 Link Status (null terminated)
n 4 Monitor Header (null terminated)
n 5 Monitor Header (null terminated)
n 6 Monitor Information (preceeded by length-1)
n 7 Connect Information (preceeded by length-1)