Newer
Older
\section{Introduction}
\subsection{Features of CATS}
CATS has many exciting features over APRS:
\begin{itemize}
\item 2-FSK is used instead of FM-AFSK for a 7 dB modulation gain\footnote{See David Rowe's blog post ``FSK over FM'' at https://www.rowetel.com/wordpress/?p=3799}
\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 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
\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}
\subsection{The Pipeline}
CATS packets are created from raw information using the following flow. For reception, the pipeline is reversed. Note that all multi-byte fields are encoded little-endian unless otherwise indicated. \\
\begin{tikzpicture}
\node [block, right of=text1] (text2) {Whiskers};
\node [block, right of=text2] (text3) {CRC};
\node [block, right of=text3] (text4) {Whitener};
\node [block, below of=text4] (text5) {LDPC};
\node [block, below of=text3] (text6) {Interleaver};
\node [block, below of=text2] (text7) {Header};
\node [block, below of=text1] (text8) {RF};
\draw [->] (text1) -- (text2);
\draw [->] (text2) -- (text3);
\draw [->] (text3) -- (text4);
\draw [->] (text4) -- (text5);
\draw [->] (text5) -- (text6);
\draw [->] (text6) -- (text7);
\draw [->] (text7) -- (text8);
\end{tikzpicture}
\\\\
The pipeline ordering is important, as each step builds upon and adds value to the steps before it. To understand why this particular ordering makes sense, it helps to consider what is needed not to send, but to receive CATS data.
To receive any radio communications, an RF front-end is needed. No processing can happen before the over-the-air signals are received, so the RF stage goes first.
Once RF is converted to board level signals, a receiver needs to determine if the signals are actually a CATS packet. The Header provides a clear signature that the receiver can try and match incoming signals against. If the header was encoded in any manner, the receiver would need to continuously attempt to decode every bit of noise - a complicated and power-hungry operation to detect if there \textit{might} be a packet. Putting the Header stage right next to the RF stage keeps the CATS packet detection as simple and efficient as possible.
The FSK modulation is an asynchronously clocked transmission. To ensure the receiver can recover the original contents, especially for long CATS packets, it is helpful to have regular transitions in the data bits. The Whitener does not guaranty more transitions, but does increase their likelihood. We need data to target the whitening process, but there is no particular requirement for protection of the whitening process itself. By staging the Whitening before the LDPC stage, half as many bits need to be processed as would be needed after the LDPC stage, saving a small amount of processing time, and no adjustments need be made to support possible recovery strategies in the LDPC stage as another process-saving bonus.
While receiving a CATS packet, there may be some noise or interference in the signal. The receiver can recover the original data, despite some amount of noise, by decoding LDPC-encoded data. The LDPC decoding stage must come before any and all data that needs protection from corruption, but need not be the first decoding operation.
One type of error that the LDPC encoding cannot correct is if an entire LDPC chunk is corrupted. Putting the Interleaver stage before the LDPC stage spreads each LDPC chunk's data across time, reducing the chances of any single chunk becoming too corrupted to decode.
The receiver needs a way to verify that the data it receives is the same as the data that was sent. The CRC stage such a mechanism, providing a simple but effective way to check if the data is self-consistent. This stage should happen as late as possible in the decoding, so that any errors from any earlier stages will be caught. However, we must do the CRC check before we can interpret the data it is checking.
In order to use any received data, the receiver must be able to interpret the received data. The Whiskers stage provides a standardization and structure needed to do so. Putting the Whiskers decoding stage after the CRC and LDPC decoding stages provides several layers of protection that Whiskers do not have by themselves.
The receiver ultimately needs to be able to use the data it is sent. The receiver must convert the received Whiskers-formatted data into native formats. Once the data is in a native format, the receiver can do as it pleases, so that is the end stage of the CATS receiving pipeline.
Additional details about each of these pipeline stages are provided in subsequent sections of this document.
\subsection{Invalid CATS Packets}
The APRS standard is plagued by the existence of invalid packets. A good APRS parser not only handles valid packets --- it also handles slightly malformed ones. Different parsers may handle malformed packets differently, since by definition, they are not in a unified standard. This complicates new implementations and leads to fragmentation of the ecosystem.
CATS aims to avoid this problem. A packet that does not conform rigidly to the standard must have its contents discarded. Even if only one whisker is malformed, all whiskers must be ignored. It is considered an implementation bug if this does not occur. Note that unknown whisker types are not invalid. This allows for future whisker types to be added without breaking compatibility with existing implementations.