diff --git a/pages/02.part-1/04.data-link-layer/docs.md b/pages/02.part-1/04.data-link-layer/docs.md index 4186780..1d4380c 100644 --- a/pages/02.part-1/04.data-link-layer/docs.md +++ b/pages/02.part-1/04.data-link-layer/docs.md @@ -27,7 +27,7 @@ The Data Link Layer Contents of a specific frame are modified using various Erro Applying ECC/FEC may be a multi-step process. To distinguish data bits at the various stages of the process, Bit Types are defined as shown in the following table. It is important to note that not all ECC/FEC processes utilize both Type 2 and Type 3 bits. Prior to decoding Data Link Layer contents, a receiver would need to convert incoming bits from Type 4 back to Type 1 bits, which may also include conversion through Type 3 and/or Type 2 bits. The exact ECC/FEC methods and Bit Types utilized will be indicated for each frame type. -
Table 1 Bit Types
+
Table 2 Bit Types
Type | Description ---- | ----------- Type 1 | Data link layer content bits @@ -35,7 +35,7 @@ Type 2 | Bits after appropriate encoding Type 3 | Bits after puncturing Type 4 | Interleaved (re-ordered) bits -
Figure 1 Transmit Contents to Payload
+
Figure 6 Transmit Contents to Payload
[mermaid] graph LR contents[Data Link Layer Contents] -- Type 1 bits --> fec[ECC/FEC Encode] -- Type 4 bits--> payload[Payload] @@ -44,7 +44,7 @@ graph LR style payload fill:#ffffffff,stroke:#ffffffff,stroke-width:0px [/mermaid] -
Figure 2 Receive Payload to Contents
+
Figure 7 Receive Payload to Contents
[mermaid] graph LR payload[Payoad] -- Type 4 bits --> fec[ECC/FEC Decode] -- Type 1 bits--> contents[Data Link Layer Contents] @@ -83,7 +83,7 @@ BERT Sync Bursts, if present, may only follow the Preamble or other BERT frames. Multiple Stream or Packet Sync Bursts may be present during a Transmission, depending on the mode. -
Table 2 Frame Specific Sync Bursts
+
Table 3 Frame Specific Sync Bursts
Frame Type | Preamble | Sync Burst Bytes | Sync Burst Symbols ---------- | -------- | ---------------- | ------------------ LSF | +3, -3 | 0x55 0xF7 | +3, +3, +3, +3, -3, -3, +3, -3 @@ -95,7 +95,7 @@ Packet | None | 0x75 0xFF | +3, -3, +3, +3, -3, -3, -3, -3 The LSF is the intial frame for both Stream and Packet Modes and contains information needed to establish a link. -
Table 3 Link Setup Frame Contents
+
Table 4 Link Setup Frame Contents
Field | Length | Description ----- | ------ | ----------- DST | 48 bits | Destination address - Encoded callsign or a special number (eg. a group) @@ -114,7 +114,7 @@ Destination and source addresses may be encoded amateur radio callsigns, or spec The TYPE field contains information about the frames to follow LSF. The Packet/Stream indicator bit determines which mode (Packet or Stream) will be used during the transmission. The remaining field meanings are defined by the specific mode and application. -
Table 4 LSF TYPE definition
+
Table 5 LSF TYPE definition
Bits | Meaning ---- | ------- 0 | Packet/Stream indicator, 0=Packet Mode, 1=Stream Mode @@ -138,7 +138,7 @@ The input to the CRC algorithm consists of DST, SRC (each 48 bits), 16 bits of T The test vectors in the following table are calculated by feeding the given message and then 16 zero bits to the CRC algorithm. -
Table 5 CRC Test Vectors
+
Table 6 CRC Test Vectors
Message | CRC Output ------- | ---------- (empty string) | 0xFFFF @@ -156,6 +156,7 @@ Type 3 bits are computed by [\(P_1\) puncturing](../../04.appendix/05.code-punct Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit LSF Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms). +
Figure 8 LSF Construction
[mermaid] graph TD @@ -188,7 +189,7 @@ In Stream Mode, an *indefinite* amount of data is sent continuously without brea Following the LSF, one or more Stream Frames may be sent. - + @@ -241,7 +242,7 @@ The 48-bit LICH Contents is partitioned into 4 12-bit parts and encoded using [G ##### Stream Contents -
Table 6 Stream Contents
+
Table 9 Stream Contents
Field | Length | Description ----- | ------ | ----------- FN | 16 bits | Frame Number @@ -262,7 +263,7 @@ These bits are [\(P_2\) punctured](../../04.appendix/05.code-puncturing) to gene The 96 Type 2 bits of the ECC/FEC LICH Contents are concatenated with 272 Type 3 bits of the ECC/FEC Stream Contents resuting in 368 of combined Type 2/3 bits. -
Table N LICH and Stream Combined
+
Table 10 LICH and Stream Combined
Field | Length | Description ------ | ------ | ----------- LICH | 96 bits | ECC/FEC LICH Contents Type 2 bits @@ -273,6 +274,7 @@ Total: 368 Type 2/3 bits Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit Stream Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms). +
Figure 10 Stream Frame Construction
[mermaid] graph TD @@ -317,14 +319,14 @@ end Stream Frames are grouped into Stream Superframes, which is the group of 6 frames that contain everything needed to rebuild the original LSF packet, so that the user who starts listening in the middle of a stream (late-joiner) is eventually able to reconstruct the LSF message and understand how to receive the in-progress stream. -
Figure 6 Stream Superframes
+
Figure 11 Stream Superframes
![M17_stream](M17_stream.png?classes=caption "Stream consisting of one superframe") ### Packet Mode In Packet Mode, a Single Packet with up to 798 bytes of Application Packet Data along with an appended two byte CRC may be sent over the physical layer during one Transmission. -
Table 9 Single Packet
+
Table 11 Single Packet
Bytes | Meaning ----- | ------- 1..798 | Application Packet Data @@ -338,7 +340,7 @@ Packet Mode shall always start with an LSF that has the LSF TYPE Packet/Stream i Packet Mode acheives a base throughput of 5 kbps, a net throughput of approximately 4.7 kbps for the largest data payload, and over 3 kbps for 100-byte payloads. Net throughput takes into account preamble and link setup overhead.
Figure 3 Stream ModeFigure 9 Stream Mode
PREAMBLE
- + @@ -360,7 +362,7 @@ Packet Frames contain Packet Contents after ECC/FEC is applied. #### Packet Contents -
Table 10 Packet Contents
+
Table 12 Packet Contents
Bits | Meaning ---- | ------- 0..199 | 200-bit chunk of Single Packet @@ -378,7 +380,7 @@ When there are no bytes remaining in the Single Packet after removing a 25-byte
-
Table 11 Metadata Field with EOF = 0
+
Table 13 Metadata Field with EOF = 0
Bits | Meaning ---- | ------- 0 | Set to 0, Not end of frame @@ -386,7 +388,7 @@ Bits | Meaning
-
Table 12 Metadata Field with EOF = 1
+
Table 14 Metadata Field with EOF = 1
Bits | Meaning ---- | ------- 0 | Set to 1, End of frame @@ -402,6 +404,7 @@ These bits are [\(P_3\) punctured](../../04.appendix/05.code-puncturing) to gene Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit Packet Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms). +
Figure 13 Packet Frame Construction
[mermaid] graph TD @@ -447,7 +450,7 @@ interoperability testing across M17 hardware and software implementations, and t configuration and tuning of ad hoc communications equipment common in amateur radio.
Figure 3 Packet ModeFigure 12 Packet Mode
PREAMBLE
- + @@ -475,7 +478,7 @@ frames even with a PRBS generator with a relatively short period. See the Appendix for [BERT generation and reception details](../../04.appendix/07.bert-details). -
Table X BERT Contents
+
Table 15 BERT Contents
Bits | Meaning ---- | ------- 0-196 | BERT PRBS9 Payload @@ -493,6 +496,7 @@ This provides the same error ECC/FEC used for Stream Frames. Within the Physical Layer, the 368 Type 4 bits are randomized and combined with the 16-bit BERT Sync Burst, which results in a complete frame of 384 bits (384 bits / 9600bps = 40 ms). +
Figure 15 BERT Frame Construction
[mermaid] graph TD @@ -522,5 +526,5 @@ end ### Issues to address... * Stream FN rollover - allowed or not? -* + diff --git a/pages/04.appendix/01.address-encoding/docs.md b/pages/04.appendix/01.address-encoding/docs.md index 0f63122..870b584 100644 --- a/pages/04.appendix/01.address-encoding/docs.md +++ b/pages/04.appendix/01.address-encoding/docs.md @@ -14,6 +14,7 @@ M17 uses 48-bit (6-byte) addresses. Callsigns and special purpose addresses are ### Address Scheme +
Table 1 M17 Addresses
Address Range (base-16) | Category | Number of Addresses | Remarks ------------- | -------- | ------------------- | ------- 0x000000000000 | RESERVED | 1 | For future use @@ -25,6 +26,7 @@ Address Range (base-16) | Category | Number of Addresses | Remarks 9 characters from an alphabet of 40 possible characters can be encoded into 48 bits (6 bytes). The base-40 alphabet is: +
Table 2 M17 Callsign Alphabet
Value (base-10) | Character | Note --------------- | --------- | ---- 0 | ' ' | A space, ASCII 32 (0x20). Invalid characters will be replaced with this. @@ -124,6 +126,7 @@ Secondary operating suffixes are often added to callsign to indicate temporary c The minimum number of allowed callsign characters in the callsign alphabet is 37 ('A' through 'Z', '0' through '9', and '/'). The following table shows how many bytes are required to encoded a callsign using an alphabet size of 37. +
Table 3 Storage required for number of callsign characters
Callsign Characters | Bits | Bytes ------------------- | ---- | ----- 7 | $log_2(37^7)=36.47$ | 5 @@ -140,6 +143,7 @@ Of these, 9 characters into 6 bytes, or 12 charcters into 8 bytes are the most e The following table shows how many bytes are required to encode a 9 character callsign using callsign alphabet sizes of 37 through 41. +
Table 4 Storage required for alphabet size
Alphabet Size | Bits | Bytes ------------- | ---- | ----- 37 | $log_2(37^9)=46.89$ | 6 diff --git a/pages/04.appendix/02.randomizer-sequence/docs.md b/pages/04.appendix/02.randomizer-sequence/docs.md index 054e8ce..39b0deb 100644 --- a/pages/04.appendix/02.randomizer-sequence/docs.md +++ b/pages/04.appendix/02.randomizer-sequence/docs.md @@ -5,6 +5,7 @@ taxonomy: - docs --- +
Table 1 Randomizer values
Seq. number | Value | Seq. number | Value ----------- | ----- | ----------- | ----- 00 | 0xD6 | 23 | 0x6E diff --git a/pages/04.appendix/03.convolutional-encoder/docs.md b/pages/04.appendix/03.convolutional-encoder/docs.md index 5936da5..0f67905 100644 --- a/pages/04.appendix/03.convolutional-encoder/docs.md +++ b/pages/04.appendix/03.convolutional-encoder/docs.md @@ -16,6 +16,7 @@ The convolutional code shall encode the input bit sequence after appending 4 tai The output from the encoder must be read alternately. +
Figure 1 Convolutional encoder
![convolutional](convolutional.svg?classes=caption "Convolutional coder diagram") ### Issues to address... diff --git a/pages/04.appendix/04.golay-encoder/docs.md b/pages/04.appendix/04.golay-encoder/docs.md index b4e8710..6d52ecd 100644 --- a/pages/04.appendix/04.golay-encoder/docs.md +++ b/pages/04.appendix/04.golay-encoder/docs.md @@ -48,7 +48,8 @@ This is equivalent to 0xC75 in hexadecimal notation. Both the generating matrix \) The output of the Golay encoder is shown in the table below. - + +
Table 1 Golay encoder details
Field | Data | Check bits | Parity ----- | ---- | ---------- | ------ Position | 23..12 | 11..1 | 0 (LSB) diff --git a/pages/04.appendix/06.interleaving/docs.md b/pages/04.appendix/06.interleaving/docs.md index 7c2204a..70eb2c7 100644 --- a/pages/04.appendix/06.interleaving/docs.md +++ b/pages/04.appendix/06.interleaving/docs.md @@ -7,7 +7,7 @@ taxonomy: For interleaving a Quadratic Permutation Polynomial (QPP) is used. The polynomial \(\pi(x)=(45x+92x^2)\mod 368\) is used for a 368 bit interleaving pattern QPP. - +
Table 1 Interleaver mapping
input index | output index | input index | output index | input index | output index | input index | output index ----------- | ------------ | ----------- | ------------ | ----------- | ------------ | ----------- | ------------ 0 | 0 | 92 | 92 | 184 | 184 | 276 | 276 diff --git a/pages/04.appendix/07.bert-details/docs.md b/pages/04.appendix/07.bert-details/docs.md index d16dcfd..bc25e5e 100644 --- a/pages/04.appendix/07.bert-details/docs.md +++ b/pages/04.appendix/07.bert-details/docs.md @@ -12,13 +12,13 @@ The PRBS uses the ITU standard PRBS9 polynomial : \(x^{9}+x^{5}+1\) This is the traditional form for a linear feedback shift register (LFSR) used to generate a psuedorandom binary sequence. -
Figure X Traditional form LFSR
+
Figure 1 Traditional form LFSR
![Traditional_LFSR](m17-traditional-lfsr.png?classes=caption "Traditional LFSR") However, the M17 LFSR is a slightly different. The M17 PRBS9 uses the generated bit as the output bit rather than the high-bit before the shift. -
Figure X M17 LFSR
+
Figure 2 M17 LFSR
![M17_LFSR](m17-prbs9.png?classes=caption "M17 LFSR") This will result in the same sequence, just shifted by nine bits. @@ -29,7 +29,7 @@ The reason for this is that it allows for easier synchronization. This is equivalent to a multiplicative scrambler (a self-synchronizing scrambler) fed with a stream of 0s. -
Figure X M17 PRBS9 Generator
+
Figure 3 M17 PRBS9 Generator
![M17_PRBS9_Generator](m17-equivalent-scrambler.png?classes=caption "M17 PRBS9 Generator") ``` @@ -69,7 +69,7 @@ reset. The received bit is then also shifted into the LFSR state register. Once a sequence of eighteen (18) consecutive good bits are recovered (twice the length of the LFSR), the stream is considered syncronized. -
Figure X M17 PRBS9 Synchronization
+
Figure 4 M17 PRBS9 Synchronization
![M17_PRBS9_Sync](m17-prbs9-sync.png?classes=caption "M17 PRBS9 Sync") During synchronization, bits received and bit errors are not counted towards @@ -107,7 +107,7 @@ After synchronization, BERT mode switches to error-counting mode, where the received bits are compared to a free-running PRBS9 generator. Each bit that does not match the output of the free-running LFSR is counted as a bit error. -
Figure X M17 PRBS9 Validation
+
Figure 5 M17 PRBS9 Validation
![M17_PRBS9_Validation](m17-prbs9-validation.png?classes=caption "M17 PRBS9 Validation") ``` diff --git a/pages/04.appendix/08.kiss-protocol/docs.md b/pages/04.appendix/08.kiss-protocol/docs.md index 3f375d3..ab35d55 100644 --- a/pages/04.appendix/08.kiss-protocol/docs.md +++ b/pages/04.appendix/08.kiss-protocol/docs.md @@ -131,8 +131,9 @@ The streaming protocol is fairly trivial to describe. It is used by sending firs #### Stream Format -##### M17 Kiss Stream Protocol +##### M17 KISS Stream Protocol +
Table 1 KISS Stream
Frame Size | Contents ---------- | -------- 30 | Link Setup Frame @@ -153,6 +154,7 @@ The data frames contain a 6-byte (48-bit) LICH segment followed by a 20 byte pay ##### KISS Stream Data Frame +
Table 2 KISS Stream Data
Frame Size | Contents ---------- | -------- 6 | LICH (48 bits) diff --git a/pages/04.appendix/09.file-formats/docs.md b/pages/04.appendix/09.file-formats/docs.md index 3cc039f..a981a44 100644 --- a/pages/04.appendix/09.file-formats/docs.md +++ b/pages/04.appendix/09.file-formats/docs.md @@ -43,6 +43,7 @@ The rate at which new symbols are generated. For M17, this is 4800 symbols per ### File Extensions Multiple files are used when testing the different elements of the M17 protocol. File extensions (the three characters after a period in a complete file name) are defined to standardize formats and usage. +
Table 1 File extensions
Extension | Description | Data Format | Data Rate --------- | ----------- | ----------- | --------- aud | Mono audio | Signed 16-bit LE | 8000 samples per second
Figure X BERT ModeFigure 14 BERT Mode
PREAMBLE