kopia lustrzana https://github.com/M17-Project/M17_spec
Wojciech Kaczmarski
GitHub
commit
6065fb7bf7
|
|
@ -148,9 +148,9 @@ again passed through the same XOR algorithm to obtain the original payload bits.
|
|||
|
||||
The pseudorandom sequence is composed of the 46 bytes (368 bits) found in the appendix ([Randomizer Sequence](../../appendix/randomizer-sequence)).
|
||||
|
||||
Before each bit of payload is converted to symbols for transmission, it is XORed with a bit from the pseudorandom sequence. The first payload bit is XORed with most significant bit (bit 7) of sequence byte 0 (0xD6), second payload bit with bit 6 of sequence byte 0, continuing to the eigth payload bit and bit 0 of sequence byte 0. The ninth payload bit is XORed with bit 7 of sequence byte 1 (0xB5), tenth payload bit with bit 6 of sequence byte 1, etc.
|
||||
Before each bit of payload is converted to symbols for transmission, it is XORed with a bit from the pseudorandom sequence. The first payload bit is XORed with most significant bit (bit 7) of sequence byte 0 (0xD6), second payload bit with bit 6 of sequence byte 0, continuing to the eighth payload bit and bit 0 of sequence byte 0. The ninth payload bit is XORed with bit 7 of sequence byte 1 (0xB5), tenth payload bit with bit 6 of sequence byte 1, etc.
|
||||
|
||||
When payload bits have XORed through sequence byte 45 (0xC3), the psuedorandom sequence is restarted at sequence byte 0 (0xD6)
|
||||
When payload bits have XORed through sequence byte 45 (0xC3), the pseudorandom sequence is restarted at sequence byte 0 (0xD6)
|
||||
|
||||
On the receive side, symbols are converted to randomized payload bits. Each randomized payload bit is converted back to a payload bit by once again XORing each randomized bit with the corresponding pseudorandom sequence bit.
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ graph LR
|
|||
<center><span style="font-weight:bold">Figure 7</span> Receive Payload to Contents</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
payload[Payoad] -- Type 4 bits --> fec[ECC/FEC Decode] -- Type 1 bits--> contents[Data Link Layer Contents]
|
||||
payload[Payload] -- Type 4 bits --> fec[ECC/FEC Decode] -- Type 1 bits--> contents[Data Link Layer Contents]
|
||||
style contents fill:#ffffffff,stroke:#ffffffff,stroke-width:0px
|
||||
style fec fill:#fff,stroke:#000,stroke-width:2px
|
||||
style payload fill:#ffffffff,stroke:#ffffffff,stroke-width:0px
|
||||
|
|
@ -93,7 +93,7 @@ Packet | None | 0x75 0xFF | +3, -3, +3, +3, -3, -3, -3, -3
|
|||
|
||||
### Link Setup Frame (LSF)
|
||||
|
||||
The LSF is the intial frame for both Stream and Packet Modes and contains information needed to establish a link.
|
||||
The LSF is the initial frame for both Stream and Packet Modes and contains information needed to establish a link.
|
||||
|
||||
<center><span style="font-weight:bold">Table 4</span> Link Setup Frame Contents</center>
|
||||
Field | Length | Description
|
||||
|
|
@ -236,7 +236,7 @@ Stream Frames are composed of frame signalling information contained within the
|
|||
|
||||
##### Link Information Channel (LICH)
|
||||
|
||||
The LICH allows for late listening and indepedent decoding to check destination address if the LSF for the current transmission was missed.
|
||||
The LICH allows for late listening and independent decoding to check destination address if the LSF for the current transmission was missed.
|
||||
|
||||
Each Stream Frame contains a 48-bit Link Information Channel (LICH). Each LICH within a Stream Frame includes a 40-bit chunk of the 240-bit LSF frame that was used to establish the stream. A 3-bit modulo 6 counter (LICH_CNT) is used to indicate which chunk of the LSF is present in the current Stream Frame. LICH_CNT starts at 0, increments to 5, then wraps back to 0.
|
||||
|
||||
|
|
@ -285,7 +285,7 @@ These bits are [\(P_2\) punctured](../../04.appendix/05.code-puncturing) to gene
|
|||
|
||||
##### Frame Combiner
|
||||
|
||||
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.
|
||||
The 96 Type 2 bits of the ECC/FEC LICH Contents are concatenated with 272 Type 3 bits of the ECC/FEC Stream Contents resulting in 368 of combined Type 2/3 bits.
|
||||
|
||||
<center><span style="font-weight:bold">Table 10</span> LICH and Stream Combined</center>
|
||||
Field | Length | Description
|
||||
|
|
@ -361,7 +361,7 @@ The CRC used here is the same as described in [LSF CRC](#lsf-crc).
|
|||
|
||||
Packet Mode shall always start with an LSF that has the LSF TYPE Packet/Stream indicator bit set to 0 (Packet Mode). Following the LSF, one to 32 Packet Frames may be sent.
|
||||
|
||||
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.
|
||||
Packet Mode achieves 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.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 12 </span><span>Packet Mode</span></caption>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ media_order: 'LFSR_8.svg,LFSR_16.svg,LFSR_24.svg'
|
|||
---
|
||||
### M17 Amateur Radio Voice Application
|
||||
|
||||
This section defines the application layer parameters for an audio stream containing low bit rate speech encoded using the open source [Codec 2](http://rowetel.com/codec2.html) codec. It is intended to be used over the air by amateur radio operators worldwide. Implementation details for M17 clients, repeaters, and gateways ensure that an M17 Amateur Radio Voice Application is legal under all licencing regimes.
|
||||
This section defines the application layer parameters for an audio stream containing low bit rate speech encoded using the open source [Codec 2](http://rowetel.com/codec2.html) codec. It is intended to be used over the air by amateur radio operators worldwide. Implementation details for M17 clients, repeaters, and gateways ensure that an M17 Amateur Radio Voice Application is legal under all licensing regimes.
|
||||
|
||||
Definitions
|
||||
- M17 Client - an end station that transmits and receives M17 voice
|
||||
|
|
@ -72,7 +72,7 @@ Bits | Meaning
|
|||
3..4 | Encryption type
|
||||
<nbsp> | $00_2$ = None
|
||||
<nbsp> | $01_2$ = Scrambling
|
||||
<nbps> | $10_2$ = AES
|
||||
<nbsp> | $10_2$ = AES
|
||||
5..6 | Encryption subtype
|
||||
7..10 | Channel Access Number (CAN)
|
||||
11..15 | Reserved (don’t care)
|
||||
|
|
@ -103,7 +103,7 @@ $11_2$ | Reserved
|
|||
|
||||
##### Text Data
|
||||
|
||||
The first byte of the Text Data is a Control Byte. To maintain backward compatability, a Control Byte of 0x00 indicates that no Text Data is included.
|
||||
The first byte of the Text Data is a Control Byte. To maintain backward compatibility, a Control Byte of 0x00 indicates that no Text Data is included.
|
||||
|
||||
Up to four Text Data blocks compose a complete message with a maximum length of 52 bytes. Each block may contain up to 13 bytes of UTF-8 encoded text, and is padded with space characters to fill any unused space at the end of the last used Text Data block.
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ Encryption type = $01_2$
|
|||
|
||||
Scrambling is an encryption by bit inversion using a bitwise exclusive-or (XOR) operation between the bit sequence of data and a pseudorandom bit sequence.
|
||||
|
||||
Pseudorandom bit sequence is generated using a Fibonacci-topology Linear-Feedback Shift Register (LFSR). Three different LFSR sizes are available: 8, 16 and 24-bit. Each shift register has an associated polynomial. The polynomials are listed in Table 7. The LFSR is initialised with a seed value of the same length as the shift register. The seed value acts as an encryption key for the scrambler algorithm. Figures 16 to 18 show block diagrams of the algorithm.
|
||||
Pseudorandom bit sequence is generated using a Fibonacci-topology Linear-Feedback Shift Register (LFSR). Three different LFSR sizes are available: 8, 16 and 24-bit. Each shift register has an associated polynomial. The polynomials are listed in Table 7. The LFSR is initialized with a seed value of the same length as the shift register. The seed value acts as an encryption key for the scrambler algorithm. Figures 16 to 18 show block diagrams of the algorithm.
|
||||
|
||||
<center><span style="font-weight:bold">Table 22</span> Scrambling</center>
|
||||
Encryption subtype | LFSR polynomial | Seed length | Sequence period
|
||||
|
|
@ -185,14 +185,14 @@ $01_2$ | $x^{16} + x^{15} + x^{13} + x^4 + 1$ | 16 bits | 65,535
|
|||
$10_2$ | $x^{24} + x^{23} + x^{22} + x^{17} + 1$ | 24 bits | 16,777,215
|
||||
|
||||
---
|
||||
<center><span style="font-weight:bold">Figure 16</span> 8-bit LSFR taps</center>
|
||||
|
||||
<center><span style="font-weight:bold">Figure 16</span> 8-bit LFSR taps</center>
|
||||
|
||||
---
|
||||
<center><span style="font-weight:bold">Figure 17</span> 16-bit LSFR taps</center>
|
||||
|
||||
<center><span style="font-weight:bold">Figure 17</span> 16-bit LFSR taps</center>
|
||||
|
||||
---
|
||||
<center><span style="font-weight:bold">Figure 18</span> 24-bit LSFR taps</center>
|
||||
|
||||
<center><span style="font-weight:bold">Figure 18</span> 24-bit LFSR taps</center>
|
||||
|
||||
|
||||
##### Advanced Encryption Standard (AES)
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ A Stream Mode Transmission begins with an [LSF](../04.data-link-layer/#link-setu
|
|||
|
||||
Packet superframes are composed of a 1..n byte data type specifier, 0..797 bytes of payload data. The data type specifier is encoded in the same way as UTF-8. It provides efficient coding of common data types. And it can be extended to include a very large number of distinct packet data type codes.
|
||||
|
||||
The data type specifier can also be used as a protocol specifier. For example, the following protocol identifers are reserved in the M17 packet spec:
|
||||
The data type specifier can also be used as a protocol specifier. For example, the following protocol identifiers are reserved in the M17 packet spec:
|
||||
|
||||
##### Reserved Protocols
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ Callsign Characters | Bits | Bytes
|
|||
12 | $log_2(37^{12})=62.51$ | 8
|
||||
13 | $log_2(37^{13})=67.72$ | 9
|
||||
|
||||
Of these, 9 characters into 6 bytes, or 12 charcters into 8 bytes are the most efficient. Given that 9 callsign characters and 6 bytes should be suitable for the majority of use cases, can the callsign alphabet be increased without using more than 6 bytes?
|
||||
Of these, 9 characters into 6 bytes, or 12 characters into 8 bytes are the most efficient. Given that 9 callsign characters and 6 bytes should be suitable for the majority of use cases, can the callsign alphabet be increased without using more than 6 bytes?
|
||||
|
||||
##### Alphabet Size vs. Bytes
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ taxonomy:
|
|||
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.
|
||||
to generate a pseudorandom binary sequence.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Traditional form LFSR</center>
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ The PRBS9 SHOULD be initialized with a state of 1.
|
|||
|
||||
The receiver detects the frame is a BERT Frame based on the Sync Burst
|
||||
received. If the PRBS9 generator is reset at this point, the sender and
|
||||
receiver should be synchonized at the start. This, however, is not common
|
||||
receiver should be synchronized at the start. This, however, is not common
|
||||
nor is it required. PRBS generators can be self-synchronizing.
|
||||
|
||||
##### Synchronization
|
||||
|
|
@ -67,7 +67,7 @@ with the LFSR taps. If the result of the XOR is a 1, it is an error (the
|
|||
expected feedback bit and the input do not match) and the sync count is
|
||||
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.
|
||||
the length of the LFSR), the stream is considered synchronized.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 4</span> M17 PRBS9 Synchronization</center>
|
||||
|
||||
|
|
@ -80,10 +80,10 @@ the overall bit error rate.
|
|||
...
|
||||
static constexpr uint8_t LOCK_COUNT = 18; // 18 consecutive good bits.
|
||||
...
|
||||
// PRBS Syncronizer. Returns 0 if the bit matches the PRBS, otherwise 1.
|
||||
// PRBS Synchronizer. Returns 0 if the bit matches the PRBS, otherwise 1.
|
||||
// When synchronizing the LFSR used in the PRBS, a single bad input bit
|
||||
// will result in 3 error bits being emitted, one for each tap in the LFSR.
|
||||
bool syncronize(bool bit)
|
||||
bool synchronize(bool bit)
|
||||
{
|
||||
bool result = (bit ^ (state >> TAP_1) ^ (state >> TAP_2)) & 1;
|
||||
state = ((state << 1) | bit) & MASK;
|
||||
|
|
|
|||
|
|
@ -174,7 +174,7 @@ The TNC must stop transmitting if the transmit buffers are empty. The TNC commun
|
|||
|
||||
TNC to host transfers are similar in that the TNC first sends the 30-byte link setup frame received to the host, followed by a stream of 26-byte data frames as described above. These are sent using **KISS port** 2.
|
||||
|
||||
The TNC must send the link setup frame first. This means that tne TNC must be able to decode LICH segments and assemble a valid link setup frame before it sends the first data frame. The TNC will only send a link setup frame with a valid CRC to the host. After the link setup frame is sent, the TNC ignores the CRC and sends all valid frames (those received after a valid sync word) to the host. If the stream is lost before seeing an end-of-stream flag, the TNC sends a 0-byte data frame to indicate loss of signal.
|
||||
The TNC must send the link setup frame first. This means that the TNC must be able to decode LICH segments and assemble a valid link setup frame before it sends the first data frame. The TNC will only send a link setup frame with a valid CRC to the host. After the link setup frame is sent, the TNC ignores the CRC and sends all valid frames (those received after a valid sync word) to the host. If the stream is lost before seeing an end-of-stream flag, the TNC sends a 0-byte data frame to indicate loss of signal.
|
||||
|
||||
The TNC must then re-acquire the signal by decoding a valid link setup frame from the LICH in order to resume sending to the host.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This appendix documents the file formats used for testing various M17 layers.
|
|||
### Glossary
|
||||
|
||||
#### Bit numbering, Bit order, Most significant bit (MSB), Least significant bit (LSB)
|
||||
[Bit numbering](https://en.wikipedia.org/wiki/Bit_numbering) is how bit positions are identified in a binary number. The least significant bit (LSB) is the bit position respresenting a value of 1. The most significant bit (MSB) is the bit position representing the highest value position. Bit order refers to the order in which bits are extracted from a binary number. This is important especially when sending binary values one bit at a time, or when constructing multiple-bit symbols. LSB first means the extraction happens from the least significant position first. MSB first means extraction happens from the most significant position first.
|
||||
[Bit numbering](https://en.wikipedia.org/wiki/Bit_numbering) is how bit positions are identified in a binary number. The least significant bit (LSB) is the bit position representing a value of 1. The most significant bit (MSB) is the bit position representing the highest value position. Bit order refers to the order in which bits are extracted from a binary number. This is important especially when sending binary values one bit at a time, or when constructing multiple-bit symbols. LSB first means the extraction happens from the least significant position first. MSB first means extraction happens from the most significant position first.
|
||||
|
||||
#### Deviation, Frequency Deviation
|
||||
In this context, deviation how far from the center frequency a carrier is shifted. This can be positive or negative. For M17, the frequency deviation of the four symbols are shown in [Physical Layer](https://spec.m17project.org/part-1/physical-layer) Table 1.
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue