No distinction is made between text and binary files. Either may be compressed, encoded using base numeric system encoding, or transmitted in original form. Information regarding compression, encoding or other file manipulation is contained within the data transmission and is not an inherent part of the protocol. In order to transmit files for remote reception, the minimum information needed is the name of the file and it's modification date-time, the method used for uncompressing the file (if compressed), the base encoding system (if used, ie: base-64 ...) and the data contained in the file. The combination of modification date-time and file name is sufficient to make each file transfer uniquely identifiable. Cycle Redundancy Checksum (CRC-16) values for each element of the protocol is used to ensure accuracy of reception. For subsequently storing missing data blocks, a block number is also necessary to indicate the data block sequence.
Any amateur radio transmission mode which supports the full ANSI character set may be used as the transport layer.
Since the transmission is to be done using commonly available systems, it is useful to further identify the information. Of course, as in all amateur communications, there is also the legal necessity of station identification, too.
The Amateur Multicast Protocol (AMP-2) version 3 consists of a sequence of elements described as follows.
Each protocol element consists of a keyword with character count and checksum enclosed in angle brackets (< >), followed by {hash} value and an optional block number and the specified data. Other information within the brackets may be included, but will be ignored by the receiving station. The optional text information may be useful for comments and other purposes. For readability, a carriage return (or anything else) may be sent following the data and it should be ignored by the receiver.
Keyword uniquely identifies the use of each Amp block
Byte-count. The byte count contains the number of bytes in the data block. For file names, descriptions, etc. it is the number of characters comprising the name or character string. For file content blocks, it represents the number of bytes transmitted in the data block, irregardless of how they might be handled by the client (receiver) software.
Checksum. The checksum is used by the receiving station to determine the accuracy of the received data. It is a 16 bit cycle redundancy check (Crc16) value. Crc16 C++ code is found in source file crc16.h associated with the application flamp. The CS value is always transmitted as a 4 character hex string.
HASH is
a 4 character
hexadecimal number that is the Crc16 value associated with a
concatenated string which consists of the date-time, colon, filename,
compression, base conversion, and block size ie:
Where the
date-time is the the system date-time stamp associated with the file's
last modification.
Developers
Note: The goal is to create a hash value based on the transmitted
file's configuration. The order of the fields can be varied and the
only requirement is they must be included in the CRC16 calculation.
Block-number. The block
number is only needed while sending file contents. For transmission,
the file is divided into convenient sized blocks (64 bytes is
recommended) and each block is numbered starting with 1 for the first
block sent, 2 for the second, etc. The use of a block number allows
the client software to keep track of what part of the file has been
correctly received and which parts are still incorrect, so that the
needed blocks can be received during a subsequent transmission.
<PROG # CS>{HASH}[name and version of software used to generate the Amp text stream].
<ID # CS>{HASH}callsign other info. Every transmission should begin with the station identification. In addition, at regular intervals (at least every 10 minutes and at the end of a communication in the US), there is the legal requirement for station identification. In order to separate the identification function from other data, the ID keyword should be used.
In many cases the receiver is free to ignore this keyword, unless needed for logging or other purposes. The main reason for including station identification as a separate keyword block is in order to separate identification data from file data in the middle of file transmission and reception.
Example: <ID 15 C2BC>(EA54}W1HKJ Toney, AL
<FILE # CS>{HASH}date-time:file-name, the modification date-time and name of the file to be transmitted is sent as data following this keyword.
Example: <FILE 29 2499>{EA54}20120915022802:jabberwock.txt
<SIZE # CS>{HASH}FSIZE NBLOCKS BLKSIZE. The size of the file, in bytes, the number of data blocks to be transmitted and the block size is sent as data following this keyword in normal ASCII decimal. The following example represents a file that is 200 bytes long and will be sent in 4 data blocks. Note that the 8 for character count indicates the length of the data, which is "332 6 64".
The data blocks will be 64, 64, 64 and 8 bytes long.
Example: <SIZE 15 F244>{2499}586 10 64
<DESC # CS>{HASH}textual description. An ASCII description of the file to be transmitted is sent as data following this keyword. This is an optional field.
<DATA # CS>{HASH:BlkNum}. The actual data contents of the file to be transmitted is sent as data following this keyword. File contents are usually sent in consecutive DATA blocks, each with a block number starting with 1, a character count (i.e. block size) and check sum. This a change from the original Amp protocol. The Block Number must be a part of the data line so that it is included in the Crc-16 checksum. Data transmissions may also consist of a partial list of DATA blocks.
Example1:
<DATA 72 240C>{2499:1}[b256:start]526
=LZMA:0:0:3-]:0:0:0:4:0=l=--(-t;=-h-zw-------a)-
Example2:
(Example 1 contains an embedded line feed character)
(Example 2 contains compressed, base256 encoded data; unprintable characters represented by '-' and '=')
<CNTL # CS>{HASH:control-word}. This keyword indicates that a transmission control word is the data load. The control word may be either EOF (end of file) or EOT (end of transmission).
Examples:
<CNTL 5 9016>{2499:EOF}
<CNTL 5 301A>{2499:EOT}
Several files may be transfered within a single Amp transmission. The protocol insures that each file and it's data blocks are uniquely identifiable so that an error free recreation of the file is possible at the transfer destination.
Transfer Examples:
Original text:
Compressed text data transfer:
The above file was compressed using the LZMA algorithm and then base encode using base-64 encoding. Base-64 insures that all characters in the transmission will be contained within the supported character set of most available amateur radio transport layers (digital modem types).
Additional header information
Programs using this protocol may add information both preceding and trailing the protocol blocks. For example: