PACSAT Broadcast Protocol
Harold E. Price, NK6K
Jeff Ward, G0/K8KA
ABSTRACT
The case for a broadcast protocol for use on PACSATs is made, and
a suitable protocol is proposed. In the proposed protocol, files
of general interest are chopped into <UI> frames and repeatedly
sent by the PACSAT in round-robin fashion or on request. Each
<UI> frame datagram contains enough information for groundstation
software to place the frame in the correct position in the appro-
priate file. Information indicating the type of file being re-
ceived is also included in each frame.
A protocol for groundstations to request retransmissions of spe-
cific frames is included.
1.0 Background
PACSAT is a generic term used to describe a digital store-and-forward satel-
lite mission in the Amateur Radio Service. Two of four Microsats and one of
two UoSATs launched in January 1990 will have PACSAT as a primary missions.
PACSATs will use the AX.25 frame as the basic link layer protocol, either in
the full AX.25 connected mode, or as unconnected <UI>-frame datagrams.
A PACSAT will have several types of data to send. Some of these are:
1) Forwarded mail messages. These are messages are not destined for PACSAT as
an endpoint, but are in transit between forwarding gateway stations.
2) Personal electronic mail messages. These are messages to and from individ-
uals who are using the satellite as a BBS; entered either directly by a human-
run connection, or by using a program that pre-formats messages for fast or
unattended transmission. These messages use PACSAT as an endpoint. It can be
argued that all mail should be forwarded mail, that no one use PACSAT as a
direct BBS. There are three counter arguments:
a) For access in remote areas without a terrestrial infrastructure in place.
b) For emergency access by minimal ground stations.
c) To permit large numbers of people to have a direct hands-on experience with
satellite communications.
3) Realtime Telemetry. These are current spacecraft telemetry values, such as
solar array power, internal temperature, etc.
4) Stored Telemetry. This is a file of one or more telemetry values stored
over time, for example, the output of the solar arrays once a second over the
last orbit. This is usually called ``Whole Orbit Data'' or ``WOD''.
5) Bulletins. These are items of general interest, orbit predictions, AMSAT
News, Gateway, etc.
6) Point-to-multipoint messages. These are messages which one PACSAT user
wishes to send to several other PACSAT end users. This may be implemented
using ``mail groups'' or ``CC'' lists.
Items 1) and 2) above are primarily point to pointoperations, either an indi-
vidual reading his own mail, or a gateway forwarding mail to be picked up by
another gateway.
Item 3) is a self-contained frame that needs no other frames to convey its
information.
The other items are germane to this discussion. Both are data types that
would be of interest to a large number satellite users people. Any time that
more than one user is interested in the same information, it will generally
make more sense to broadcast it (send it once for reception by many) rather
than send the information separately to each individual.
Current terrestrial packet radio use is highly inefficient. If 160 people in
southern California want to read the 20k byte ARRL Gateway newsletter, they
each log into a BBS and read it separately. This requires 3.2MB of data to be
sent. Because of packet overhead, collisions, acks, etc., the actual number
of bytes sent, and the total channel time, is much higher.
Assuming a very optimistic average throughput of 120 bytes/second, it takes
7.5 hours of channel time to allow 160 people to get a copy of the bi-weekly
Gateway. Taking the standard loaded aloha 18% of that figure, 42 hours of
channel time are required. Because there are 24 hours in a day, and there are
seven packet channels in use on 2 meters alone in southern California, it is
possible to accumulate 42 hours of channel time in less than a day. The
inefficiency of the system is masked by the large amount of time and RF spec-
trum available.
Now assume that one wished to distribute Gateway on a Microsat, an environment
where time and spectrum are at a premium. The Microsat is visible for about 14
minutes a pass, or about 60 minutes a day. It would then take 42 days to
accumulate 42 hours of channel time, since even though the Microsat has multi-
ple uplinks, it has only one downlink. UoSAT-3 (UO-14), with its 9600 baud
downlink, would require only 5 days to move the same data.
Even if we assume a very disciplined set of users who access the satellite one
at a time, we can move the efficiency from 18% to nearly 95%, enabling UO-14
to service the 160 users in 1.5 days, and Microsat in 8.5. This is assuming
all of the single downlink frequency was devoted to the activity of download-
ing Gateway to individual users.
There are several conclusions that can be drawn from this. One is that a
PACSAT is useless for dealing with a large number of individual users if they
all want individual copies of the same file. It would be far better to have a
gateway in the local area read a copy, then distribute it on the ground for
everyone else. This is, however, not much different than what we have now, and
we're looking to use the satellite to improve general conditions.
Another conclusion is that if there were a way to send a single copy of Gate-
way that could be seen by all 160 users at the same time, this would reduce
both the load on the satellite, and the load on the terrestrial network.
Since the satellite CAN see all 160 users in southern California at one time,
the solution is now clear.
A broadcast protocol for items of general interest is clearly desirable. A
strong case for one can be made in the terrestrial network as well, but the
multiplicity of frequencies and the 24 hour availability of VHF/UHF networks
makes the advantages harder to see. The single downlink of a PACSAT, and the
tyranny of orbital mechanics makes the need more evident in the satellite
environment. In a broadcast mode, UO-14 can transmit at least 3.2 million
bytes of data to a station in the mid latitudes in an average day, AO-16 and
LO-19 can each send at least 432,000. That is a lot of mail.
There is another advantage to a broadcast protocol, and again, it is more
telling in the satellite service. A broadcast protocol, being one way, does
not require a transmitter at the receiving site. The complexity of the ground
station is reduced as the 2 meter transmitter and its antenna are not required
to receive the broadcast.
Finally, the PACSAT environment gives another encouragement to broadcast
protocols: because the transmit and receive frequencies are on different
bands, it is inherently full-duplex. Since PACSAT will be the only transmit-
ting station on the downlink, a major source of data-loss, collisions with
other stations, is removed. When the link is good, there is no need for
retransmissions, making the broadcast protocol more efficient than the normal
ACK/timeout AX.25 protocol.
2.0 Attributes of a Broadcast Protocol
The AX.25 protocol, in its connected mode, makes the following guarantees:
1) All bytes are received once, in the order they were sent, with no gaps.
2) No bytes are received in error (within the limits of CRC16).
This means that the two stations can establish a connection, and then send a
file. When the expected number of bytes or an end of file marker is received
the receiving station can assume that it received the entire file (or message)
correctly.
The general philosophy is that the sending and receiving stations work togeth-
er to retransmit each frame (or small group of frames, 1-7) repeatedly until
it is received correctly, before moving on to the next frame.
The connected mode requires two-way point to point transmissions, and is not
suitable for a broadcast protocol.
The unconnected mode of AX.25 make these guarantees:
1) Byte order is maintained within a frame only.
2) No bytes in a frame are received in error (within the limits of CRC16).
One or more frames may be missing within a group of frames. Although some
TNCs allow you to receive frames with CRC errors, you can receive no reliable
indication that you have missed a frame. AX.25 does not provide frame se-
quence numbers in these frames. You can not know if the frame you have just
received immediately follows the previously received frame, or if you missed
some.
Although on average, the new PACSATs have the strongest amateur satellite
signals to date, the receiving station will still get occasional dropouts from
local conditions, polarity reversals due to the spacecraft's changing orienta-
tion, 70cm radar, etc. Loss of signal as the spacecraft goes over the horizon
will also cause a loss of frames.
All of this means that if you receive a file as a set of broadcast <UI>
frames, AX.25 itself does not provide enough information to allow you to tell
if the entire file has been received, or if it has gaps. A broadcast protocol
must provide this missing information. The broadcast protocol wouldride
inside a standard AX.25 <UI> frame.
Ideally, the broadcast protocol would have the following attributes:
1) Any frame, when received independently, can be placed in the proper loca-
tion within the file to which it belongs.
2) When the all frames have been received, the receive station can tell that
the file is complete.
3) For file types where it makes sense, partial files should be usable. For
example, if a data compression scheme is used, the file should be able to be
incrementally decompressed, e.g., a 20000 bytes of a 20256 byte file should
not be useless simply because the first 256 bytes are missing.
To carry this to full frame independence, this means that compression algo-
rithms should be such that the decompression of one frame does not depend on
the receipt of any other frame. This may require the use of a less-efficient
compression algorithm for files which are to be incrementally decompressed,
but partial files, and perhaps all of the information, can be extracted from a
smaller set of received frames.
Files that are not meant to be incrementally decompressed may use any compres-
sion scheme, the broadcast protocol maintains data transparency.
Four rules can be derived from the above desires:
1) Each frame must contain a file identifier
2) Each frame must contain something that identifies this frame's position in
the file.
3) The file must contain a special record that defines file attributes,
particularly file size. Other items of interest would be the actual file
name, creation date, etc.
4) If a partial file is to be usable, especially if compression is used, each
frame must contain enough information to allow use of a partial file.
2.0.1 Additional Error Protection
It is most likely that TNCs operating in KISS mode will be used to receive the
UI frames which make up PACSAT Broadcasts. The authors' experiments indicate
that the link between the KISS TNC and the user's personal computer may be
prone to errors caused by a lack of flow control. This is especially true
when using high radio data rates such as UoSAT-OSCAR-14's 9600 baud link.
Although the AX.25 CRC assures that only correctly received frames will be
passed on by the KISS TNC to the host computer, we are now not certain that
the frame reaching the host computer is error free. If we process incorrectly
received frames, even occasionally, files will be lost or corrupted. Thus, we
must add some error protection to the broadcast frame.
After experimentation, a 16-bit CRC was selected.
2.1 Frame Header Contents
The above rules define a frame structure that looks like this:
<flags><file_id><file_type><offset><data><crc>
Each field is discussed below.
2.1.1 file_id
At first glance, the simplest file id would be the actual name of the file.
Since the PACSAT file system permits 8 bytes of name and 3 bytes of extension,
this would lead to 11 bytes of overhead per frame, or 4%. This is somewhat
large. There is also the problem that the contents of a file named
``error.log'' may change, and so the file name is not truly a unique file
identifier.
To overcome this problem PACSAT assigns each created file a ``file number'',
which is 4-bytes long and will uniquely identify the file. This number is
used as the file_id in the Broadcast Protocol header.
The receiving station will not know the actual name of the file until the file
header record is received. This record could be transmitted more frequently
than other records, increasing the chances that it would be available in any
partially-received file.
2.1.2 offset
Each frame of broadcast data must contain the position in the file where the
data came from. Each frame, then, contains an offset field. The offset is
the byte number of the first byte in that frame, relative to the first byte in
the file. For PACSAT files, byte 0 is always the first byte of the PACSAT
File Header.
To place a received data frame into a file, one need only:
lseek((long) offset);
write(handle, data, frame_size);
While it is easy to insert the frame bytes into the file, it is much harder to
know when all the bytes have been received. There are several methods, one is
maintaining a list of holes in the file, much as some TCP/IP implementations
do when reassembling IP packets.
The size of the offset field is important, too small and the size of broadcast
files are limited, too large and the overhead for each file is increased.
We've chosen 24 bits as a compromise between efficiency and maximum file size.
This allows for files up to 16Mb.
2.1.3 Flags
The flag field is a byte which provides option bits. Two bits are currently
defined. ``Length'' says that an option length field is present in the frame
header. ``EOF'' says that this is the last frame of the associated file.
2.1.4 File_type
If a partial file, which could be just a single frame, is to be useful, some
information on the file type must be provided with each frame. Examples of
file types are:
ASCII text bulletins
Images from UoSAT-E CCD
Stored telemetry
Digitized voice
Machine-ready Keplerian element updates
Incrementally decompressable files
Non-decompressable files
The file_type can also inform the groundstation software that a file is incre-
mentally decompressable, or not compressed at all.
The file_type byte is the same byte which is found in the file header record
in the file. File types are assigned and defined in a separate document.
2.1.5 data
This part of the frame is the file data, compressed or uncompressed. The
file_type can be used to tell what type of data is present.
2.1.6 CRC
Reception errors in the AX.25 UI frame can be detected using the 16-bit CRC
which is part of the HDLC frame, and this low-level error detection would,
ideally, be enough to protect the Broadcast protocol frames. However, in
reality, the UI frames are usually received by a KISS TNC, and the link be-
tween the KISS tnc and the host computer may be unreliable (especially at high
speed) due to the lack of flow control in the KISS standard. For this reason,
we have chosen to append a 16-bit CRC to the broadcast frame WITHIN the AX.25
UI frame data field. This CRC will be calculated using the XMODEM CRC speci-
fication, which has been successfully and efficiently implemented on many
microcomputers.
2.1.7 File Header
Clearly, the 8-bit file_type and the 32-bit file_id cannot convey all of the
information which a groundstation needs to know about a file (e.g. time of
creation, complete file name, file size). This information is in a structure
at the beginning of each file. The file header may be of variable length, but
would contain an offset to the first user data byte. The header is always at
start of the file, with a byte offset of 0.
A proposal for a standard PACSAT File Header is provided in a separate docu-
ment.
2.2 Binary Data
For greatest efficiency, all header information is coded in binary. This is a
departure from previous amateur digital satellite philosophy.
Currently, UO-9, AO-10, UO-11, and AO-13 transmit telemetry and bulletins in
uncompressed Ascii. This was, in part, to make this information available to
the widest possible audience. The audience was a late 1970/early 1980 audi-
ence, and was assumed to have only the modem and a terminal, with little or no
computer assistance. Telemetry on all of the above satellites can be read in
Ascii and decoded with pencil and paper. The amount of telemetry generated is
small, and the broadcast data is bi-weekly bulletins.
PACSATs are being designed for a 1990s environment. A new piece of hardware
is required, either an external TNC, or an add-on card for your computer. In
almost all cases, a computer is present at the ground station. The number of
users who must deal directly with the raw data is reduced, perhaps to zero.
An increased emphasis on compressed data will lead to downlink which is mostly
binary anyway. Several ground station programs are planned or already avail-
able which will allow users to monitor the downlink and acquire the data. The
authors plan to make public domain source and shareware programs available for
the IBM PC, with proceeds going to AMSAT-NA and AMSAT-UK.
3.0 PACSAT Broadcast - How it works in practice
PACSAT command stations would upload files tagged with a broadcast rotation
priority and an expiration date. On-board programs would also be able to tag
or build files with this data. An onboard broadcast administrator task main-
tains a list of active broadcast files and assigns a file_id. Files would be
broadcast based on their rotation priority, i.e., files with low priority
would be sent less often that those with high priority. Files under some
threshold priority would only be sent during otherwise idle downlink time,
those above the threshold would be mixed in with whatever else is on the
downlink. Since parsing binary data (the header) in the standard monitor mode
of TNCs is non-trivial, we can assume that the KISS mode, or other host mode
will be used to implement the ground program. Therefore the PID byte in the
frame can easily be used to identify broadcast protocol frames. The exact
value is 0xbb.
Ground users would run a program that monitors the downlink for frames. This
program would probably use the KISS mode of the TNC. As each frame was re-
ceived, the file_id and offset field of the frames are used to build up an
image of the file. Duplicate frames are discarded. Several files can be
active at once.
A utility program is provided to convert the received files into a usable
form. It can decompress compressed files, and handle partial files if possi-
ble. It will display the contents of the PACSAT File Header record in re-
ceived files. It can also generate a hole list or bit map, as required, to
send to PACSAT and request retransmission of missing parts of the file.
4.0 Extensions
So far this discussion has assumed that all files on PACSAT can be divided
into two groups: broadcast files which are sent with the broadcast protocol,
and point-to-point files which are sent using AX.25 connected mode. There is
also a gray area: point-to-multipoint files, which are not of interest to all
PACSAT groundstations, but might be of interest to more than one station in
the same PACSAT footprint. For instance, a message to all TCP/IP users would
not warrant a continuous broadcast, but it might be downloaded by several
groundstations. One would like to arrange things so that when the first
groundstation downloads ``TCPIP.UPD'', other users in the broadcast-listen
mode would also receive and avoid downloading it themselves (if they're inter-
ested). There are two ways of achieving this: by using the broadcast mode
when the first groundstation requests the file, or by embedding broadcast mode
datagrams in the connected-mode frames.
Using the first method, the user would connect to PACSAT and request that a
file or files be put in the broadcast rotation. The user would then discon-
nect and use his broadcast-listen program to receive the desired files. (The
user could even avoid connecting in the first place by transmitting the file
request in a <UI> frame on the uplink.)
Files added to the broadcast list this way would be sent at a high priority
for the length of an average pass.
Users who do not receive the file completely while it is being broadcast can
send a description of the missed data (hole-list) to the PACSAT and those
blocks would placed in the broadcast rotation. Re-transmission requests for a
particular file can come from many stations, but by the nature of the round-
robin broadcast, requests are not likely to be synchronized and cause a mass
uplink collision.
Thus, we use the broadcast mode for all but explicitly point-to-point files.
The alternative is for the PACSAT to connect to one station and commence
standard AX.25 transfer, but embed enough information into the <I> frames to
allow ``eavesdropping'' stations to build up copies of the file being trans-
ferred. Thus, to every <I> frame PACSAT adds the standard broadcast mode
header, for the benefit of stations which may be listening in on the connec-
tion. Unfortunately, the connected mode user has no idea where each <I> frame
begins and ends, so his software cannot strip out the unwanted header informa-
tion. Thus, we set the L bit in the <flags> field and place frame length in
the <length> field. Now the connected mode user knows where each frame begins
and can strip out the header.
This may stick in the gullet of pure layered protocol designers. In defense
of the proposal we offer the facts that (1) the broadcast <UI> frame listener
already relies on knowing where the level-2 frames begin and end; and (2) we
can look on our frame format as a higher-level packet format, and it just so
happens that each packet fits in one frame (for the benefit of the ``eaves-
droppers'').
5.0 Incremental Decompression
Incremental decompression is the ability to decompress partial files. In the
most general case, any frame can be decompressed independently of any other
frame.
It should be noted that the desire for incremental decompression has several
deleterious effects. Primarily, it forces the use of non-optimal compression
techniques.
Some compression schemes, such as Huffman coding, require that a table be sent
along with the file that provides deciding information. The file is not
decodable without this table, so a partial file that did not include the table
would be useless. To allow use of Huffman-style coding, files would have to
be compressed with a small number of standard tables that can be encoded in
the file type.
Many compression methods, including Huffman coding, turn a file into tokens of
variable bit length. That is, a token will not necessarily be an integral
number of octets long, whereas an AX.25 frame must be an integral number of
octets long. An arbitrary frame can be decoded only if the start of the frame
is also the start of a token, and we know the number of meaningful bits in the
frame.
Also, the program doing the broadcast framing may not be the program that did
the compression. This would require, for instance, that PACSAT decompress the
file as it broadcasts it, so it could properly align frames and tokens.
Decompression of partial files is an area for further discussion. To allow
maximum flexibility in future implementation, the proposed standard includes
the possibility of variable length frames. If the length bit in the flag byte
is set, the two bytes following the standard frame header are the number of
valid bits in the block. This allows for bit tokens of a non-integer number
of octets.
It should be noted that the WO-18 image transmission format is a form of
broadcast with incremental decompression, allowing even a single frame of the
compressed image to be placed in it proper location on the display screen.
6.0 Broadcast Advantages
Receive-only stations with just an omni antenna and an eavesdrop program can
accumulate bulletins, telemetry, and other items of general interest just by
listening.
For transmit and receive stations, if one other station is interested in the
same file, then overhead is reduced by at least 100%. This should justify the
additional few percent overhead of the broadcast information.
7.0 Broadcast Disadvantages
Nearly everything broadcast from PACSAT would have several bytes of binary
data in the front of each frame. This would make it difficult to monitor with
just a TNC and terminal. Since the assumption is made that the data will also
be compressed, a computer and proper program would be required in any case, so
it is unlikely there will be any TNC-only stations. We also note that most of
current fleet of spacecraft are already transmitting telemetry in raw binary
form.
Due to the difficulty of parsing binary data from the standard monitor mode of
TNCs, only TNCs with the KISS protocol, or other host-mode protocol, will be
suitable. It may be possible, depending of the availability of true 8-bit
transparency, to use the monitor mode on some TNCs, since a known, fixed
string would precede each monitored frame, e.g., ``>QST-1:''.
8.0 Implementation Status
UO-14 has been broadcasting files using the protocol defined in Appendix A.
since mid summer. AO-16 and LO-19 should begin using this format by the end
of August.
9.0 Proposed Broadcast Protocol
The protocol specification is provided as Appendix A to this paper.
10.0 Correspondence
Address comments to:
Telemail: HPRICE or UOSAT
Compuserve: 71635,1174
Packet: NK6K @ WB6YMH
or G0K8KA @ GB2UP
Internet: 71635.1174
@COMPUSERVE.COM
Mail: Jeff Ward
UoSAT Unit
University of Surrey
Guildford, Surrey GU2 5XH
UK
Appendix A.
A.1 PACSAT Broadcast Protocol Description
This protocol describes a method where files can be sent from a PACSAT to an
unknown number of groundstations, using the unconnected <UI> frame mode of
AX.25. The protocol could also be used in purely terrestrial applications.
Each file that is to be broadcast is assigned a 32-bit file id. This number
must be unique among all other files broadcast by this station. A station
must be able to later match the file id with the file if the station is to
handle retransmission requests.
When a file is broadcast, it is broken down into frames. Each frame is iden-
tified with enough information so that the data can be placed in the proper
location and in the proper file by a receive-only groundstation. Each frame
is sent within an AX.25 <UI> frame, and is totally contained within that <UI>
frame.
Some files are automatically retransmitted enough times over several passes so
that the likelihood of a station receiving all parts of the file at least once
with no errors is high. A facility is also provided to allow a ground station
to request the transmission of certain frames to allow fills of missing data.
The PACSAT Broadcast Protocol has two elements, the File Transmission Frame,
use to send data; and the File Request Frame, used to request retransmission
of all or part of a file.
A.2 File Transmission frame format
A.2.1 Frame
A broadcast frame consists of a header, data and a CRC . The header is varia-
ble length, depending on bits in the flag byte. The data may also be of
variable length.
The broadcast frame is wholly contained within a standard AX.25 <UI> frame.
The total length of the broadcast frame may not exceed the length of a legal
AX.25 <UI> frame.
A <UI> frame containing a broadcast frame uses a PID of 0xbb.
A <UI> frame containing a broadcast frame uses a source address of the trans-
mitting station, and a destination address of QST-1.
A.2.1.1 Frame Header
Each frame contains a frame header, which occupies the first n bytes of the
frame. The structure of the frame header is as follows:
<flags><file_id><file_type><offset>[<length>]
This structure follows the PACSAT Data Specification Standards as regards
field size and byte order, which is defined in a separate document.
struct FRAME_HEADER {
unsigned char flags;
unsigned long file_id;
unsigned char file_type;
unsigned int offset;
unsigned char offset_msb;
};
or
struct FRAME_HEADER_EXT {
unsigned char flags;
unsigned long file_id;
unsigned char file_type;
unsigned int offset;
unsigned char offset_msb;
unsigned int length; /* only present if L bit set */
};
flags A bit field as follows:
7 6 5 4 3 2 1
/-------------------\
|* * 0 V V O L|
\-------------------/
L 1 length field is present
0 length field not present
E 1 Last byte of frame is the last byte of the file.
0 Not last.
VV Two bit version identifier. This version is 0.
0 Always 0.
* Reserved, must be 0.
file_id A number which identifies an active broadcast file. All
frames which are part of the same file are tagged with this number.
file_type The file_type byte from the file header. Provided so that
partial files received without the header can be decoded. File types are
defined in a separate document.
length If the L bit is set, this field is present it in the header.
It is the number of bits that are to be used in the data field. This field
has two intended uses: when variable length blocks are used with the broadcast
carried inside a higher level protocol (so that the frame length is lost), and
when a non-integer number of octets of data are used.
offset If the O bit is not set, this is the block number of the
block. If the O bit is set, this is the offset from the start of the file
for the first byte in this frame. This field is the lower 16 bits of a 24
bit integer.
offset_msb The high order 8 bits of the offset.
A.2.1.2 Data
If the block mode is used, the length of the data must be fixed. It may be
any length, but the following must be true:
file_offset_of_first_byte_in_frame = offset * this_frame_size
All frames in a particular transmission of a file should be the same length,
to avoid having the receiver resize his bit map too often.
If byte numbers rather than block numbers are used, the data may be any
length. If the length field is present, the data must contain only that
number of bits, rounded up to the next octet boundary.
A.2.1.3 CRC
A two-byte CRC as defined by the XMODEM protocol follows the data. The crc
covers all data bytes in the AX.25 UI frame, including the broadcast frame
header.
An inefficient definition routine for checking the XMODEM CRC when receiving a
frame is:
unsigned short crc; /* global crc register. */
crc = 0; /* clear crc register */
for (all received data bytes)
gen_crc(rx_byte); /* crc the incoming data bytes */
gen_crc(1st_crc_byte); /* crc the incoming first crc byte */
if(gen_crc(2nd_crc_byte)) /* crc the incoming second crc byte */
bad_crc(); /* non-zero crc reg. is an error */
else
good_crc(); /* zero crc is a good packet. */
/* Function to take a byte and run it into the XMODEM crc generator. */
/* Uses a global CRC register called ``crc''. */
gen_crc(data)
char data;
{
int y;
crc ^= data << 8;
for(y=0; y < 8; y++)
if( crc & 0x8000)
crc = crc << 1 ^ 0x1021;
else
crc <<= 1;
return crc;
}
Further information on generation of XMODEM CRC via more efficient byte-wise
methods can be found in BYTE Magazine, September 1986, pp. 115-124.
A.3 File Retransmission Request Format
Each request to retransmit portions of a file is sent in a retransmission
request frame. If more data is being requested than will fit in one request,
multiple requests may be sent.
This protocol is intended to service retransmissions of already-broadcast
files. The manner is which a file is first requested to be broadcast is a
more complex topic, including, presumably, the ability to request files based
on name, date, content, keywords, mail message copy list, etc.
A.3.1 Request Frame
A request frame consists of a header and data. The header is fixed length.
The data depends on the type field in the header, and can be of variable
length.
The request frame is wholly contained within a standard AX.25 <UI> frame. The
total length of the broadcast frame may not exceed the length of a legal AX.25
<UI> frame.
A <UI> frame containing a request frame uses the same PID as a broadcast
frame, 0xbb. The source address is the address of the transmitting station,
the destination address is the address of the station to which the request is
directed. Thus, if a frame has the PACSAT Broadcast Protocol PID , if the
destination is QST-1, it is a broadcast frame, otherwise it is a request
frame.
A.3.2 Request Format
A.3.2.1 Header
The format of request is:
<type><file_id><data>
struct REQUEST_HEADER {
char flags;
unsigned long file_id;
int block_size;
};
flags - A bit field as follows:
7 6 5 4 3 2 1
/-------------------\
|* * 1 V V C C|
\-------------------/
CC Two bit field as follows:
00 start sending file <file_id>
01 stop sending file <file_id>
10 Frame contains a hole list.
VV Two bit version identifier. This version is 0.
1 Always 1.
* Reserved, must be 0.
block_size Requests that the broadcast use this value as a maximum
size.
file_id File id of the requested file.
A.3.2.1 Data
If the CC field is 2, a hole list is present.
The format of the hole list is pairs of start addresses and lengths.
struct PAIR {
unsigned int offset;
unsigned char offset_msb;
unsigned int length;
};
The length of the hole list is determined by received frame size.
A.4 PROCEDURES
A.4.1 Identification of a broadcast protocol data frame.
The broadcast protocol will use a special PID 0xbb. Broadcast frames with be
sent with a source callsign of the station's call, and a destination callsign
of <QST-1>.
A.4.2 File transmission
Multiple broadcast files may be transmitted simultaneously, frames from one
file can be interleaved with another. Frames can be transmitted in any order
and repeated at any time.
A.4.3 File completion
The file header contains the total number of bytes in the file. Once the
ground station has received that number of bytes, the file is complete. The
file header also contains checksums which can be used to verify the correct
reception of the file.
Appendix B.
B. Legalities Within the Amateur Satellite Service
The use of the words ``broadcast'' and ``compression'' sometimes raise the
hackles of certain members of the amateur community. ``Broadcast'' is men-
tioned in the Amateur Rules (Part 97 of the FCC regulations), and compression
is sometimes equated with encryption.
B.1 Broadcast
To establish the bona-fides of a broadcast protocol:
97.113(d)(2) specifically permits information bulletins consisting solely of
subject matter relating to amateur radio.
The prohibited items are communications intended to be received directly by
the public (1200/4800/9600 baud PSK HDLC should take care of that), or for
newsgathering for broadcast purposes.
B.2 Compression
97.117 specifically permits the use of abbreviations or signals where the
intent is not to obscure the meaning but only to facilitate communications.
Compression using published algorithms to increase data throughput would thus
be permitted.
Ritorna a Software Radioamatoriale by
IW3FQG