@@ -23,7 +23,7 @@ CATS packets are created from raw information using the following flow. For rece
...
@@ -23,7 +23,7 @@ CATS packets are created from raw information using the following flow. For rece
\begin{tikzpicture}
\begin{tikzpicture}
\node [block, name=text1] {Raw data};
\node [block, name=text1] {Raw Data};
\node [block, right of=text1] (text2) {Whiskers};
\node [block, right of=text1] (text2) {Whiskers};
\node [block, right of=text2] (text3) {CRC};
\node [block, right of=text2] (text3) {CRC};
\node [block, right of=text3] (text4) {Whitener};
\node [block, right of=text3] (text4) {Whitener};
...
@@ -41,6 +41,25 @@ CATS packets are created from raw information using the following flow. For rece
...
@@ -41,6 +41,25 @@ CATS packets are created from raw information using the following flow. For rece
\draw [->] (text7) -- (text8);
\draw [->] (text7) -- (text8);
\end{tikzpicture}
\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.
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.