wording improv3ments

standard.tex

@@ -42,7 +42,7 @@
 \newpage
 
 \begin{abstract}
-  APRS, while an excellent tool, is over 20 years old, and is beginning to show its age. The protocol itself is overly complex and not particularly efficient. The modulation on which it rests --- AFSK over FM --- is also sub-optimal. The purpose of CATS is to design a modernized solution that overcomes these challenges by utilizing the latest technologies. CATS aims to deliver enhanced efficiency, simplicity in implementation, and improved performance compared to APRS.
+  APRS, while an excellent tool, is over 20 years old, and is beginning to show its age. The protocol itself is overly complex, and not particularly efficient. The modulation on which it rests --- AFSK over FM --- is also sub-optimal. The purpose of CATS is to design a modernized solution that overcomes these challenges by utilizing the latest technologies. CATS aims to deliver enhanced efficiency, simplicity in implementation, and improved performance compared to APRS.
 \end{abstract}
 
 \newpage
@@ -55,17 +55,17 @@
 
 \subsection{Features of CATS}
 
-CATS has many exciting features over legacy APRS:
+CATS has many exciting features over APRS:
 
 \begin{itemize}
-\item 2-FSK used instead of FM-AFSK for a 12dB coding gain
+\item 2-FSK is used instead of FM-AFSK for a 12 dB coding gain
 \item Forward Error Correction (LDPC), further improving the coding gain
 \item Bit-rate increased from 1200 bits/s to 9600 bits/s
 \item Maximum packet size 8191 bytes
 \item Data whitening used to prevent receiver desynchronization
-\item 70cm band is used instead of 2m by default
+\item The 70cm band is used instead of the 2m band by default
   \begin{itemize}
-  \item Since 2M is more common for voice, it makes it easy to add CATS to an existing setup while still being able to use 2M repeaters --- with full duplexing, so that CATS transmissions do not cause loss of reception on 2M
+  \item Since 2m is more common for voice, it makes it easy to add CATS to an existing setup while still being able to use 2m repeaters --- with full duplexing, so that CATS transmissions do not cause loss of reception on 2m
   \end{itemize}
 \item FELINET, which is the CATS equivalent of APRS-IS, will push and pull messages from APRS-IS to maintain some compatibility, at least initially. The eventual goal is to drop this link.
 \end{itemize}
@@ -156,7 +156,7 @@ A CRC checksum is used to distinguish when a CATS packet is corrupt. In this cas
 
 \subsection{Structure}
 
-The CRC algorithm used is 16-bit IBM SDLC.
+The CRC algorithm used is the 16-bit IBM SDLC CRC algorithm. \\
 
 \begin{tabular}{|l|l|l|}
   \hline
@@ -172,13 +172,13 @@ The CRC algorithm used is 16-bit IBM SDLC.
 
 \subsection{Overview}
 
-In APRS, a single flipped bit results in a ruined packet. In CATS, Forward Error Correction (FEC) is used to make the protocol tolerant of bit flips. LDPC has been chosen, as it's a mature standard which operates close to the Shannon Limit.
+In APRS, a single flipped bit results in a ruined packet. In CATS, Forward Error Correction (FEC) is used to make the protocol tolerant of bit flips. LDPC has been chosen, as it is a mature standard which operates close to the Shannon Limit.
 
 \subsection{Algorithm}
 
-Like APRS, CATS packets are variable-length. This is advantageous --- packets that contain small amounts of data don't need to be padded. This increases efficiency. However, LDPC encoding requires data to be of a constant width. The solution is to break our data into chunks, so that we can LDPC-encode each chunk individually.
+Like APRS, CATS packets are variable-length. This is advantageous as packets that contain small amounts of data don't need to be padded; this increases efficiency. However, LDPC encoding requires data to be of a constant width. The solution is to break our data into chunks, so that we can LDPC-encode each chunk individually.
 
-The structure of the data chunks isn't encoded in the packet. Instead, the data is broken into chunks deterministically. The same algorithm can be used by the receiver to break the chunks apart, decode them, and combine the resulting data together. The valid LDPC codes are TC128, TC256, TC512, TM2048, and TM8192, all with $r=1/2$. These codes are specified in detail in CCSDS document 231.1-0-1. The algorithm works as follows:
+The structure of the data chunks is not encoded in the packet. Instead, the data is broken into chunks deterministically. The same algorithm can be used by the receiver to break the chunks apart, decode them, and combine the resulting data together. The valid LDPC codes are TC128, TC256, TC512, TM2048, and TM8192, all with $r=1/2$. These codes are specified in detail in CCSDS document 231.1-0-1. The algorithm works as follows:
 
 \begin{enumerate}
 \item Pick the largest code with an input size $M \le N$
@@ -204,7 +204,7 @@ For example, imagine our data after adding the parity CRC is 2349 bytes long. Th
 \item Pad the remaining 5 bytes out to 8 bytes with 0xAA 0xAA 0xAA, then encode with TC128
 \end{enumerate}
 
-Note that the final packet length will be
+Note that the final packet length will be:
 \begin{align*}
   L &= 2 + N + (512 * 4) + (128 * 2) + 32 + (8 * 2)\\
   &= 4703
@@ -244,7 +244,7 @@ In CATS, each 16 bytes of data is XORed with the hex string ``e9cf 6720 191a 07d
 
 LDPC makes our CATS packet robust against single bit flips. However, it is not particularly robust against burst errors. This is because a burst will flip several bits in only one (or possibly two) of our LDPC chunks, while the rest remain untouched. If too many bits flip in a single chunk, it will not be possible to recover. Instead, it is better to split this burst across as many chunks as possible, to lower the likelihood that a chunk will be unrecoverable. The interleaver is responsible for reordering the CATS bits in such a way to be robust against bit flips.
 
-In CATS, a 32 bit block interleaver is used. For an bit string input $b_0 b_1 b_2 b_3 ... b_n$, the output from the interleaver is $b_0 b_{32} b_{64} ... b_1 b_{33} b_{65} ... b_3 b_{34} b_{66} ... b_n$. The receiver is responsible for de-interleaving the bit stream to get the original data.
+In CATS, a 32-bit block interleaver is used. For a bit-string input $b_0 b_1 b_2 b_3 ... b_n$, the output from the interleaver is $b_0 b_{32} b_{64} ... b_1 b_{33} b_{65} ... b_3 b_{34} b_{66} ... b_n$. The receiver is responsible for de-interleaving the bit stream to get the original data.
 
 \section{Header}
 
@@ -445,6 +445,8 @@ The destination whisker also allows requesting an acknowledgement from the stati
 
 The arbitrary whisker is a special type of whisker. Its content is intentionally not understood by the CATS standard. Instead, any content can be encoded. Most stations will ignore this content. This is also useful if the same packet is to be sent multiple times. To prevent de-duplication by receiving nodes, a different arbitrary whisker can be affixed to each one. \textbf{A valid CATS packet may contain zero or more arbitrary whiskers.}
 
+\subsubsection{Structure}
+
 \begin{tabular}{|l|l|l|l|}
   \hline
   \textbf{Byte offset} & \textbf{Length} & \textbf{Value} & \textbf{Description} \\
@@ -485,7 +487,7 @@ FELINET nodes communicate with each other via gRPC. A FELINET server implements
 
 \subsection{Filtering}
 
-When a FELINET node calls the $GetPackets$ method, it must specify a filter, which is used to limit what packets are sent to the node. This is done primarily for bandwidth reasons. As such, the filters are very coarse. It is the node's responsibility to filter more on the client-side if required. There are several types of packet filters. These filters cannot be mixed and matched --- only one can be used as a time. However, it's possible to call the $GetPackets$ method multiple times at once, though this is generally not recommended. The filter types are as follows:
+When a FELINET node calls the $GetPackets$ method, it must specify a filter, which is used to limit what packets are sent to the node from the server. This is done primarily for bandwidth reasons. As such, the filters are very coarse. It is the node's responsibility to filter more on the client-side if required. There are several types of packet filters. These filters cannot be mixed and matched --- only one can be used as a time. However, it is possible to call the $GetPackets$ method multiple times at once, although this is generally not recommended. The filter types are as follows:
 
 \begin{description}
 \item [All] No filter. All valid packets the server receives will be forwarded to the node.