kopia lustrzana https://github.com/M17-Project/M17_spec
update to TeX
kc1awv
rodzic
616146e5e3
commit
9395ec2002
|
|
@ -1,29 +0,0 @@
|
|||
name: Docs to PDF
|
||||
# This workflow is triggered on pushes to the repository.
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
# Paths can be used to only trigger actions when you have edited certain files, such as a file within the /pages directory
|
||||
paths:
|
||||
- 'pages/**'
|
||||
|
||||
jobs:
|
||||
converttopdf:
|
||||
name: Build PDF
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: baileyjm02/markdown-to-pdf@v1
|
||||
with:
|
||||
input_dir: pages
|
||||
output_dir: pdfs
|
||||
images_dir: pages
|
||||
# for example <img src="./images/file-name.png">
|
||||
# image_import: ./images
|
||||
# Default is true, can set to false to only get PDF files
|
||||
build_html: false
|
||||
- uses: actions/upload-artifact@v1
|
||||
with:
|
||||
name: pages
|
||||
path: pdfs
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
*.acn
|
||||
*.acr
|
||||
*.alg
|
||||
*.aux
|
||||
*.bak
|
||||
*.bbl
|
||||
*.bcf
|
||||
*.blg
|
||||
*.brf
|
||||
*.bst
|
||||
*.dvi
|
||||
*.fdb_latexmk
|
||||
*.fls
|
||||
*.glg
|
||||
*.glo
|
||||
*.gls
|
||||
*.idx
|
||||
*.ilg
|
||||
*.ind
|
||||
*.ist
|
||||
*.lof
|
||||
*.log
|
||||
*.lol
|
||||
*.lot
|
||||
*.maf
|
||||
*.mtc
|
||||
*.mtc1
|
||||
*.nav
|
||||
*.nlo
|
||||
*.nls
|
||||
*.out
|
||||
*.pyg
|
||||
*.run.xml
|
||||
*.snm
|
||||
*.synctex.gz
|
||||
*.tex.backup
|
||||
*.tex~
|
||||
*.thm
|
||||
*.toc
|
||||
*.vrb
|
||||
*.xdy
|
||||
*.xml
|
||||
*blx.bib
|
||||
.bak
|
||||
.mtc
|
||||
build/
|
||||
_site/
|
||||
.sass-cache/
|
||||
.jekyll-cache/
|
||||
.jekyll-metadata
|
||||
# Ignore folders generated by Bundler
|
||||
.bundle/
|
||||
vendor/
|
||||
Plik binarny nie jest wyświetlany.
Plik diff jest za duży
Load Diff
|
|
@ -1 +0,0 @@
|
|||
theme: jekyll-theme-slate
|
||||
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 28 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 22 KiB Po Szerokość: | Wysokość: | Rozmiar: 22 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 28 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 20 KiB Po Szerokość: | Wysokość: | Rozmiar: 20 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 37 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 18 KiB Po Szerokość: | Wysokość: | Rozmiar: 18 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 59 KiB Po Szerokość: | Wysokość: | Rozmiar: 59 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 20 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 20 KiB Po Szerokość: | Wysokość: | Rozmiar: 20 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 19 KiB Po Szerokość: | Wysokość: | Rozmiar: 19 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 17 KiB Po Szerokość: | Wysokość: | Rozmiar: 17 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 17 KiB Po Szerokość: | Wysokość: | Rozmiar: 17 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 14 KiB Po Szerokość: | Wysokość: | Rozmiar: 14 KiB |
|
Przed Szerokość: | Wysokość: | Rozmiar: 12 KiB Po Szerokość: | Wysokość: | Rozmiar: 12 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 42 KiB |
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
title: Welcome
|
||||
---
|
||||
|
||||
## Part I - Air Interface
|
||||
* [M17 RF Protocol: Summary](/part-1/m17-rf-protocol-summary)
|
||||
* [Glossary](/part-1/glossary)
|
||||
* [Physical Layer](/part-1/physical-layer)
|
||||
* [4FSK generation](/part-1/physical-layer#4fsk-generation)
|
||||
* [Preamble](/part-1/physical-layer#preamble)
|
||||
* [Bit types](/part-1/physical-layer#bit-types)
|
||||
* [Error correction coding schemes and bit type conversion](/part-1/physical-layer#error-correction-coding-schemes-and-bit-type-conversion)
|
||||
* [Data Link Layer](/part-1/data-link-layer)
|
||||
* [Stream Mode](/part-1/data-link-layer#stream-mode)
|
||||
* [Packet Mode](/part-1/data-link-layer#packet-mode)
|
||||
* [BERT Mode](/part-1/data-link-layer#bert-mode)
|
||||
* [Application Layer](/part-1/application-layer)
|
||||
* [Amateur Radio Voice Application](/part-1/application-layer#m17-amateur-radio-voice-application)
|
||||
* [Packet Application](/part-1/application-layer#packet-application)
|
||||
|
||||
## Part II - Internet Interface
|
||||
* [M17 Internet Protocol (IP) Networking](/part-2/ip-networking)
|
||||
* [Standard IP Framing](/part-2/ip-networking#standard-ip-framing)
|
||||
* [Control Packets](/part-2/ip-networking#control-packets)
|
||||
|
||||
## Appendix
|
||||
* [Address Encoding](/appendix/address-encoding)
|
||||
* [Callsign Encoding: base40](/appendix/address-encoding#callsign-encoding-base40)
|
||||
* [Callsign Formats](/appendix/address-encoding#callsign-formats)
|
||||
* [Randomizer sequence](/appendix/randomizer-sequence)
|
||||
* [Convolutional Encoder](/appendix/convolutional-encoder)
|
||||
* [Golay Encoder](/appendix/golay-encoder)
|
||||
* [Code Puncturing](/appendix/code-puncturing)
|
||||
* [Interleaving](/appendix/interleaving)
|
||||
* [BERT Details](/appendix/bert-details)
|
||||
* [KISS Protocol](/appendix/kiss-protocol)
|
||||
* [References](/appendix/kiss-protocol#references)
|
||||
* [Glossary](/appendix/kiss-protocol#glossary)
|
||||
* [M17 Protocols](/appendix/kiss-protocol#m17-protocols)
|
||||
* [KISS Basics](/appendix/kiss-protocol#kiss-basics)
|
||||
* [Packet Protocols](/appendix/kiss-protocol#packet-protocols)
|
||||
* [Stream Protocol](/appendix/kiss-protocol#stream-protocol)
|
||||
* [Mixing Modes](/appendix/kiss-protocol#mixing-modes)
|
||||
* [Implementation Details](/appendix/kiss-protocol#implementation-details)
|
||||
* [File Formats](/appendix/file-formats)
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
title: 'M17 RF Protocol: Summary'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
M17 is an RF protocol that is:
|
||||
|
||||
* Completely open: open specification, open source code, open source hardware, open algorithms. Anyone must be able to build an M17 radio and interoperate with other M17 radios without having to pay anyone else for the right to do so.
|
||||
* Optimized for amateur radio use.
|
||||
* Simple to understand and implement.
|
||||
* Capable of doing the things hams expect their digital protocols to do:
|
||||
|
||||
* Voice (eg: DMR, D-Star, etc)
|
||||
* Point to point data (eg: Packet, D-Star, etc)
|
||||
* Broadcast telemetry (eg: APRS, etc)
|
||||
* Extensible, so more capabilities can be added over time.
|
||||
|
||||
To do this, the M17 protocol is broken down into three protocol layers, like a network:
|
||||
|
||||
1. Physical Layer: How to encode 1s and 0s into RF. Specifies RF modulation, symbol rates, bits per symbol, etc.
|
||||
2. Data Link Layer: How to packetize those 1s and 0s into usable data. Packet vs Stream modes, headers, addressing, etc.
|
||||
3. Application Layer: Accomplishing activities. Voice and data streams, control packets, beacons, etc.
|
||||
|
||||
This document attempts to document these layers.
|
||||
|
||||
.. [TETRA] Dunlop, John; Girma, Demessie; Irvine, James "Digital
|
||||
Mobile Communications and the TETRA System" Wiley 1999,
|
||||
ISBN: 9780471987925
|
||||
|
||||
.. [DMR] ETSI TS 102 361-1 V2.2.1 (2013-02): "Electromagnetic
|
||||
compatibility and Radio spectrum Matters (ERM); Digital
|
||||
Mobile Radio (DMR) Systems; Part 1: DMR Air Interface (AI)
|
||||
protocol"
|
||||
https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/02.02.01_60/ts_10236101v020201p.pdf
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: Glossary
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
### ECC
|
||||
Error Correcting Code
|
||||
|
||||
### FEC
|
||||
Forward Error Correction
|
||||
|
||||
### Frame
|
||||
The individual components of a stream, each of which contains payload data interleaved with frame signalling.
|
||||
|
||||
### Link Setup Frame
|
||||
The first frame of any transmission. It contains full link information data.
|
||||
|
||||
### LICH
|
||||
Link Information Channel. The LICH contains all information needed to establish an M17 link. The first frame of a transmission contains full LICH data, and subsequent frames each contain one sixth of the LICH data so that late-joiners can obtain the LICH.
|
||||
|
||||
### Packet
|
||||
A single burst of transmitted data containing 100s to 1000s of bytes, after which the physical layer stops sending data.
|
||||
|
||||
### Superframe
|
||||
A set of six consecutive frames which collectively contain full LICH data are grouped into a superframe.
|
||||
|
|
@ -1,197 +0,0 @@
|
|||
---
|
||||
title: 'Physical Layer'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
simple-responsive-tables:
|
||||
active: true
|
||||
media_order:
|
||||
---
|
||||
|
||||
This section describes the M17 standard radio physical layer suitable for use where a transmission bandwidth of 9 KHz is permitted.
|
||||
|
||||
### 4-level Frequency-shift Keying Modulation (4FSK)
|
||||
|
||||
The M17 standard uses 4FSK at 4800 symbols/s (9600
|
||||
bits/s) with a deviation index h=1/3 for transmission in a 9 kHz
|
||||
channel bandwidth. Minimum channel spacing is 12.5 kHz.
|
||||
|
||||
#### Dibit, Symbol, and Frequency-shift
|
||||
|
||||
Each of the 4-level frequency-shifts can be represented by dibits (2-bit values) or symbols, as shown in Table 1 below.
|
||||
|
||||
In the case of dibits, the most significant bit is sent first. When four dibits are grouped into a byte, the most significant dibit of the byte is sent first. For example, the four dibits contained in the byte 0xB4 (0b 10 11 01 00) would be sent as the symbols (-1, -3, +3, +1).
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Table 1 </span><span>Dibit symbol mapping to 4FSK deviation</span></caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th colspan="2" style="text-align:center;">Dibit</th>
|
||||
<th rowspan="2" style="text-align:center;">Symbol</th>
|
||||
<th rowspan="2" style="text-align:center;">4FSK deviation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th style="text-align:center;">MSB</th>
|
||||
<th style="text-align:center;">LSB</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody style="text-align:center;">
|
||||
<tr>
|
||||
<td>0</td>
|
||||
<td>1</td>
|
||||
<td>+3</td>
|
||||
<td>+2.4 kHz</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>0</td>
|
||||
<td>0</td>
|
||||
<td>+1</td>
|
||||
<td>+0.8 kHz</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
<td>-1</td>
|
||||
<td>-0.8 kHz</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>-3</td>
|
||||
<td>-2.4 kHz</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### 4FSK Generation
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Dibit to 4FSK Generation</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
id1[Dibit Input] --> sym[Dibit to Symbol] --> id2[Upsampler] --> id3[RRC Filter] --> id4[Frequency Modulation] --> id5[4FSK Output]
|
||||
style id1 fill:#ffffffff,stroke:#ffffffff,stroke-width:0px
|
||||
style sym fill:#fff,stroke:#000,stroke-width:2px
|
||||
style id2 fill:#fff,stroke:#000,stroke-width:2px
|
||||
style id3 fill:#fff,stroke:#000,stroke-width:2px
|
||||
style id4 fill:#fff,stroke:#000,stroke-width:2px
|
||||
style id5 fill:#ffffffff,stroke:#ffffffff,stroke-width:0px
|
||||
[/mermaid]
|
||||
|
||||
Dibits are converted to symbols. The symbol stream is upsampled to a series of impulses which pass through a
|
||||
root-raised-cosine (alpha=0.5) shaping filter before frequency modulation
|
||||
at the transmitter and again after frequency demodulation at the
|
||||
receiver.
|
||||
|
||||
Upsampling by a factor of 10 is recommended (48000 samples/s).
|
||||
|
||||
The root-raised-cosine filter should span at least 8 symbols (81 taps at the recommended upsample rate).
|
||||
|
||||
### Transmission
|
||||
|
||||
A complete transmission shall consist of a [Preamble](#preamble), a [Synchronization Burst](#synchronization-burst-sync-burst), [Payload](#payload), and an [End of Transmission](#end-of-transmission-marker-eot) marker.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 2 </span><span>Physical Layer Transmission</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
<td style="border:3px solid black;">SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PAYLOAD</td>
|
||||
<td style="border:3px solid black;">EoT</td>
|
||||
</tr>
|
||||
<tr style="color:black;border-left:hidden;border-right:hidden;border-bottom:hidden;">
|
||||
<td style="border-left:hidden;border-right:hidden;">40ms<br/>(192 symbols)</td>
|
||||
<td style="border-left:hidden;border-right:hidden;">16 bits<br/>(8 symbols)</td>
|
||||
<td style="border-left:hidden;border-right:hidden;">Multiples of 2 bits<br/>(Multiples of 1 symbol)</td>
|
||||
<td style="border-left:hidden;border-right:hidden;">40ms<br/>(192 symbols)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Transmissions may include more than one synchronization burst followed by a payload.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 3 </span><span>Physical Layer Transmission with Multiple Synchronization Bursts</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
<td style="border:3px solid black;">SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PAYLOAD</td>
|
||||
<td style="border:3px solid black;">SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PAYLOAD</td>
|
||||
<td style="border:3px dashed black;">•••</td>
|
||||
<td style="border:3px solid black;">SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PAYLOAD</td>
|
||||
<td style="border:3px solid black;">EoT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Preamble
|
||||
|
||||
Every transmission shall start with a preamble, which shall consist of 40 ms (192 symbols) of alternating outer symbols (+3, -3) or (-3, +3). To ensure a zero crossing prior to a synchronization burst, the last symbol transmitted within the preamble shall be opposite the first symbol transmitted in the synchronization burst.
|
||||
|
||||
### Synchronization Burst (Sync Burst)
|
||||
|
||||
A sync burst of 16 bits (8 symbols) shall be sent immediately after the preamble. The sync burst is constructed using only outer symbols, with
|
||||
codings based on [Barker codes](https://en.wikipedia.org/wiki/Barker_code). Properly chosen sync burst coding assists in symbol clocking and alignment.
|
||||
Different sync burst codes may also be used by the [Data Link Layer](../data-link-layer#synchronization-burst-sync-burst) to identify the type of payload to follow.
|
||||
|
||||
### Payload
|
||||
|
||||
Payload shall be transmitted in multiples of 2 bits (1 symbol).
|
||||
|
||||
### Randomizer
|
||||
|
||||
To avoid transmitting long sequences of constant symbols (e.g. +3, +3, +3, ...), a simple randomizing algorithm is used. At the transmitter, all payload bits shall be XORed with a pseudorandom predefined sequence before being converted to symbols. At the receiver, the randomized payload symbols are converted to bits and are
|
||||
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 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 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.
|
||||
|
||||
### End of Transmission marker (EoT)
|
||||
|
||||
Every transmission ends with a distinct symbol stream, which shall consist of 40 ms (192 symbols) of a repeating 0x55 0x5D (+3, +3, +3, +3, +3, +3, -3, +3) pattern.
|
||||
|
||||
### Carrier-sense Multiple Access (CSMA)
|
||||
|
||||
CSMA may be used to minimize collisions on a shared radio frequency by having the sender ensure the frequency is clear before transmitting. Higher layers (Data Link and Application) may require the use of CSMA, and may specify parameters other than the defaults.
|
||||
|
||||
[P-persistent](https://en.wikipedia.org/wiki/Carrier-sense_multiple_access) access is used with a default probability of p = 0.25 and default slot time of 40 ms.
|
||||
|
||||
### Physical Layer Flow Summary
|
||||
|
||||
<center><span style="font-weight:bold">Figure 4</span> Physical Layer Flow</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
payload["Payload"]
|
||||
phy_randomizer["randomizer"]
|
||||
phy_sync["prepend SYNC BURST"]
|
||||
phy_chunk_dibit["chunk dibit"]
|
||||
phy_dibit_to_symbol["dibit to symbol"]
|
||||
phy_upsampler["upsampler"]
|
||||
phy_filter["rrc filter"]
|
||||
phy_frequency_modulation["frequency modulation"]
|
||||
phy_rf["4FSK RF"]
|
||||
|
||||
classDef default fill:#fff,stroke:#000,stroke-width:2px
|
||||
|
||||
payload --> phy_randomizer
|
||||
Preamble --> phy_chunk_dibit
|
||||
phy_chunk_dibit --> phy_dibit_to_symbol --> phy_upsampler --> phy_filter --> phy_frequency_modulation --> phy_rf
|
||||
phy_randomizer --> phy_sync --> phy_chunk_dibit
|
||||
EoT --> phy_chunk_dibit
|
||||
[/mermaid]
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* Time limits for RF carrier and no symbol generation before the preamble and after the EoT.
|
||||
* Nothing to consistently address loss of signal/fades/missing EoT
|
||||
* No limit on transmission duration
|
||||
|
||||
File diff suppressed because one or more lines are too long
|
Przed Szerokość: | Wysokość: | Rozmiar: 50 KiB |
|
|
@ -1,207 +0,0 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 26.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="svg8" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 1154.7 63.5" style="enable-background:new 0 0 1154.7 63.5;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:none;stroke:#000000;stroke-width:1.4173;stroke-miterlimit:11.3386;}
|
||||
.st1{fill:none;stroke:#000000;stroke-width:1.4184;stroke-miterlimit:11.3386;}
|
||||
.st2{fill:none;stroke:#000000;stroke-width:1.4184;stroke-miterlimit:11.3386;stroke-dasharray:12.8844,12.8844;}
|
||||
</style>
|
||||
<g>
|
||||
<path d="M36.1,40.2V27.3H41c0.7,0,1.3,0,2,0.1c0.6,0.1,1.1,0.3,1.6,0.6c0.4,0.3,0.8,0.7,1,1.2c0.7,1.5,0.4,3.3-0.7,4.5
|
||||
c-0.7,0.8-2,1.1-3.8,1.1h-3.3v5.2H36.1z M37.8,33.4h3.3c0.8,0.1,1.7-0.1,2.3-0.6c0.5-0.4,0.7-1.1,0.7-1.7c0-0.5-0.1-1-0.4-1.4
|
||||
c-0.3-0.4-0.6-0.6-1.1-0.8c-0.5-0.1-1.1-0.1-1.6-0.1h-3.3V33.4z"/>
|
||||
<path d="M48.1,40.2V27.3h5.7c0.9,0,1.8,0.1,2.6,0.3c0.6,0.2,1.1,0.7,1.4,1.2c0.4,0.6,0.5,1.3,0.5,1.9c0,0.9-0.3,1.7-0.9,2.3
|
||||
c-0.8,0.7-1.7,1.1-2.7,1.2c0.4,0.2,0.7,0.4,1,0.6c0.5,0.5,1,1.1,1.4,1.7l2.2,3.5h-2.1l-1.7-2.7c-0.5-0.8-0.9-1.4-1.2-1.8
|
||||
c-0.2-0.3-0.5-0.6-0.9-0.9c-0.2-0.2-0.5-0.3-0.8-0.3c-0.3,0-0.6-0.1-0.9-0.1h-2v5.7H48.1z M49.8,33h3.7c0.6,0,1.2-0.1,1.8-0.2
|
||||
c0.4-0.1,0.8-0.4,1-0.8c0.2-0.3,0.3-0.7,0.3-1.2c0-0.6-0.2-1.1-0.7-1.5c-0.6-0.4-1.3-0.7-2.1-0.6h-4.1V33z"/>
|
||||
<path d="M61.1,40.2V27.3h9.3v1.5h-7.6v3.9H70v1.5h-7.1v4.4h7.9v1.5L61.1,40.2z"/>
|
||||
<path d="M71.7,40.2l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H71.7z M75.4,34.9h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L75.4,34.9z"/>
|
||||
<path d="M85.1,40.2V27.3h2.6l3.1,9.1c0.3,0.8,0.5,1.5,0.6,1.9c0.1-0.5,0.4-1.2,0.7-2.1l3.1-9h2.3v12.9h-1.6V29.4L92,40.2h-1.5
|
||||
l-3.7-11v11H85.1z"/>
|
||||
<path d="M100,40.2V27.3h4.8c0.8,0,1.6,0.1,2.4,0.4c0.6,0.2,1.1,0.7,1.4,1.2c0.3,0.5,0.5,1.1,0.5,1.7c0,0.6-0.2,1.1-0.4,1.6
|
||||
c-0.3,0.5-0.8,0.9-1.4,1.2c0.7,0.2,1.3,0.6,1.8,1.2c0.4,0.6,0.6,1.2,0.6,2c0,0.6-0.1,1.2-0.4,1.7c-0.2,0.5-0.5,0.9-0.9,1.2
|
||||
c-0.4,0.3-0.9,0.5-1.4,0.6c-0.7,0.2-1.4,0.2-2.1,0.2H100z M101.7,32.7h2.8c0.5,0,1.1,0,1.6-0.1c0.4-0.1,0.7-0.3,1-0.6
|
||||
c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.8-0.3-1.1c-0.2-0.3-0.5-0.6-0.9-0.7c-0.6-0.1-1.3-0.2-2-0.2h-2.6V32.7z M101.7,38.6h3.2
|
||||
c0.4,0,0.8,0,1.2-0.1c0.3-0.1,0.7-0.2,1-0.4c0.3-0.2,0.5-0.4,0.7-0.7c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.9-0.4-1.3
|
||||
c-0.2-0.4-0.6-0.6-1-0.7c-0.6-0.2-1.2-0.2-1.9-0.2h-3L101.7,38.6z"/>
|
||||
<path d="M112,40.2V27.3h1.7v11.4h6.3v1.5L112,40.2z"/>
|
||||
<path d="M122.2,40.2V27.3h9.3v1.5h-7.6v3.9h7.1v1.5h-7.1v4.4h7.9v1.5L122.2,40.2z"/>
|
||||
</g>
|
||||
<path id="path3733" class="st0" d="M139.9,19.1v28.3"/>
|
||||
<g>
|
||||
<path d="M148.5,36l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C148.7,37.6,148.5,36.8,148.5,36z"/>
|
||||
<path d="M164.7,40.2v-5.5l-5-7.4h2.1l2.5,3.9c0.5,0.7,0.9,1.5,1.3,2.2c0.4-0.7,0.9-1.4,1.4-2.3l2.5-3.8h2l-5.1,7.4v5.5H164.7z"/>
|
||||
<path d="M173,40.2V27.3h1.7l6.8,10.1V27.3h1.6v12.9h-1.7L174.7,30v10.1H173z"/>
|
||||
<path d="M195.2,35.6l1.7,0.4c-0.3,1.3-0.9,2.4-1.9,3.2c-1,0.8-2.2,1.1-3.4,1.1c-1.2,0.1-2.4-0.2-3.4-0.8c-0.9-0.6-1.6-1.5-2-2.5
|
||||
c-0.5-1.1-0.7-2.3-0.7-3.5c0-1.2,0.2-2.4,0.8-3.5c0.5-1,1.2-1.8,2.2-2.3c1-0.5,2-0.8,3.1-0.8c1.2,0,2.3,0.3,3.3,1
|
||||
c0.9,0.7,1.5,1.7,1.8,2.8l-1.7,0.4c-0.2-0.8-0.7-1.5-1.3-2c-0.6-0.4-1.4-0.7-2.1-0.6c-0.9,0-1.8,0.2-2.5,0.7
|
||||
c-0.7,0.5-1.2,1.1-1.4,1.9c-0.3,0.8-0.4,1.6-0.4,2.5c0,1,0.1,2,0.5,2.9c0.3,0.8,0.8,1.4,1.5,1.8c0.7,0.4,1.4,0.6,2.2,0.6
|
||||
c0.9,0,1.7-0.3,2.4-0.8C194.6,37.5,195.1,36.6,195.2,35.6z"/>
|
||||
<path d="M204,40.2V27.3h4.8c0.8,0,1.6,0.1,2.4,0.4c0.6,0.2,1.1,0.7,1.4,1.2c0.3,0.5,0.5,1.1,0.5,1.7c0,0.6-0.2,1.1-0.4,1.6
|
||||
c-0.3,0.5-0.8,0.9-1.4,1.2c0.7,0.2,1.3,0.6,1.8,1.2c0.4,0.6,0.6,1.2,0.6,2c0,0.6-0.1,1.2-0.4,1.7c-0.2,0.5-0.5,0.9-0.9,1.2
|
||||
c-0.4,0.3-0.9,0.5-1.4,0.6c-0.7,0.2-1.4,0.2-2.1,0.2L204,40.2z M205.7,32.7h2.8c0.5,0,1.1,0,1.6-0.1c0.4-0.1,0.7-0.3,1-0.6
|
||||
c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.8-0.3-1.1c-0.2-0.3-0.5-0.6-0.9-0.7c-0.6-0.1-1.3-0.2-2-0.2h-2.6L205.7,32.7z M205.7,38.6
|
||||
h3.2c0.4,0,0.8,0,1.2-0.1c0.3-0.1,0.7-0.2,1-0.4c0.3-0.2,0.5-0.4,0.6-0.7c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.9-0.4-1.3
|
||||
c-0.2-0.4-0.6-0.6-1-0.7c-0.6-0.2-1.2-0.2-1.9-0.2h-3L205.7,38.6z"/>
|
||||
<path d="M224.5,27.3h1.7v7.4c0,1-0.1,2.1-0.4,3.1c-0.3,0.8-0.9,1.4-1.6,1.9c-0.9,0.5-2,0.8-3,0.7c-1,0-2-0.2-3-0.6
|
||||
c-0.7-0.4-1.3-1-1.6-1.8c-0.4-1-0.5-2.1-0.5-3.2v-7.4h1.7v7.4c0,0.8,0.1,1.7,0.3,2.5c0.2,0.5,0.6,1,1.1,1.2
|
||||
c0.6,0.3,1.2,0.5,1.9,0.4c1,0.1,1.9-0.2,2.7-0.9c0.6-1,0.9-2.1,0.8-3.3L224.5,27.3z"/>
|
||||
<path d="M229.1,40.2V27.3h5.7c0.9,0,1.8,0.1,2.6,0.3c0.6,0.2,1.1,0.7,1.4,1.2c0.4,0.6,0.5,1.3,0.5,1.9c0,0.9-0.3,1.7-0.9,2.3
|
||||
c-0.8,0.7-1.7,1.1-2.7,1.2c0.4,0.2,0.7,0.4,1,0.6c0.5,0.5,1,1.1,1.4,1.7l2.2,3.5h-2.1l-1.7-2.7c-0.5-0.8-0.9-1.4-1.2-1.8
|
||||
c-0.2-0.3-0.5-0.6-0.9-0.9c-0.2-0.2-0.5-0.3-0.8-0.3c-0.3,0-0.6-0.1-0.9-0.1h-2v5.7H229.1z M230.8,33h3.7c0.6,0,1.2-0.1,1.8-0.2
|
||||
c0.4-0.1,0.8-0.4,1-0.8c0.2-0.3,0.3-0.7,0.3-1.2c0-0.6-0.2-1.1-0.7-1.5c-0.6-0.4-1.3-0.7-2.1-0.6h-4.1L230.8,33z"/>
|
||||
<path d="M241.5,36l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C241.7,37.6,241.5,36.8,241.5,36z"/>
|
||||
<path d="M257.3,40.2V28.8h-4.2v-1.5h10.2v1.5H259v11.4H257.3z"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M316.1,40.4V27.5h4.4c0.8,0,1.5,0,2.3,0.2c0.7,0.1,1.3,0.5,1.9,0.9c0.7,0.6,1.2,1.3,1.5,2.2c0.4,1,0.5,2,0.5,3.1
|
||||
c0,0.9-0.1,1.8-0.3,2.6c-0.2,0.7-0.5,1.3-0.9,1.9c-0.3,0.5-0.7,0.9-1.2,1.2c-0.5,0.3-1,0.5-1.5,0.6c-0.7,0.2-1.4,0.2-2.1,0.2
|
||||
L316.1,40.4z M317.8,38.9h2.8c0.7,0,1.3-0.1,2-0.2c0.4-0.1,0.8-0.4,1.2-0.7c0.4-0.5,0.8-1,0.9-1.6c0.2-0.8,0.4-1.6,0.3-2.5
|
||||
c0.1-1.1-0.2-2.2-0.7-3.1c-0.4-0.7-0.9-1.2-1.6-1.5c-0.7-0.2-1.5-0.3-2.2-0.3h-2.7L317.8,38.9z"/>
|
||||
<path d="M327.7,40.4l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H327.7z M331.4,35.1h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L331.4,35.1z"/>
|
||||
<path d="M343.1,40.4V29h-4.2v-1.5H349V29h-4.3v11.4H343.1z"/>
|
||||
<path d="M348,40.4l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H348z M351.7,35.1h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L351.7,35.1z"/>
|
||||
</g>
|
||||
<path id="path3733-4-5" class="st0" d="M270.8,19.1v28.3"/>
|
||||
<g>
|
||||
<path d="M1073.4,40.2V27.3h9.3v1.5h-7.6v3.9h7.1v1.5h-7.1v4.4h7.9v1.5L1073.4,40.2z"/>
|
||||
<path d="M1084.8,33.9c-0.1-1.8,0.5-3.6,1.7-5c1.2-1.2,2.8-1.9,4.4-1.8c1.1,0,2.2,0.3,3.2,0.9c0.9,0.6,1.7,1.4,2.2,2.4
|
||||
c0.5,1.1,0.8,2.3,0.8,3.5c0,1.2-0.3,2.4-0.8,3.5c-0.5,1-1.3,1.8-2.2,2.3c-1,0.5-2,0.8-3.1,0.8c-1.1,0-2.3-0.3-3.3-0.9
|
||||
c-0.9-0.6-1.7-1.4-2.2-2.4C1085.1,36.1,1084.8,35,1084.8,33.9z M1086.6,33.9c-0.1,1.3,0.4,2.7,1.3,3.7c1.7,1.7,4.4,1.8,6.2,0.1
|
||||
c0,0,0.1-0.1,0.1-0.1c0.9-1.1,1.3-2.4,1.2-3.8c0-0.9-0.2-1.9-0.5-2.7c-0.3-0.7-0.9-1.4-1.6-1.8c-0.7-0.4-1.5-0.7-2.3-0.6
|
||||
c-1.2,0-2.3,0.4-3.1,1.2C1087,30.6,1086.6,32,1086.6,33.9z"/>
|
||||
<path d="M1102.6,40.2V28.8h-4.2v-1.5h10.2v1.5h-4.3v11.4H1102.6z"/>
|
||||
</g>
|
||||
<path id="path3733-4-5-1-3" class="st0" d="M1047,19.1v28.3"/>
|
||||
<path id="path3733-4-5_00000093177594592238871140000006663593622922439060_" class="st0" d="M404.3,18.8v28.3"/>
|
||||
<g>
|
||||
<path d="M414.9,35.6l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C415.2,37.3,414.9,36.5,414.9,35.6z"/>
|
||||
<path d="M431.1,39.8v-5.5l-5-7.4h2.1l2.5,3.9c0.5,0.7,0.9,1.5,1.3,2.2c0.4-0.7,0.9-1.4,1.4-2.3l2.5-3.8h2l-5.1,7.4v5.5H431.1z"/>
|
||||
<path d="M439.5,39.8V26.9h1.7L448,37V26.9h1.6v12.9h-1.7l-6.8-10.1v10.1H439.5z"/>
|
||||
<path d="M461.7,35.3l1.7,0.4c-0.3,1.3-0.9,2.4-1.9,3.2c-1,0.8-2.2,1.1-3.4,1.1c-1.2,0.1-2.4-0.2-3.4-0.8c-0.9-0.6-1.6-1.5-2-2.5
|
||||
c-0.5-1.1-0.7-2.3-0.7-3.5c0-1.2,0.2-2.4,0.8-3.5c0.5-1,1.2-1.8,2.2-2.3c1-0.5,2-0.8,3.1-0.8c1.2,0,2.3,0.3,3.3,1
|
||||
c0.9,0.7,1.5,1.7,1.8,2.8l-1.7,0.4c-0.2-0.8-0.7-1.5-1.3-2c-0.6-0.4-1.4-0.7-2.1-0.6c-0.9,0-1.8,0.2-2.5,0.7
|
||||
c-0.7,0.5-1.2,1.1-1.4,1.9c-0.3,0.8-0.4,1.6-0.4,2.5c0,1,0.1,2,0.5,2.9c0.3,0.8,0.8,1.4,1.5,1.8c0.7,0.4,1.4,0.6,2.2,0.6
|
||||
c0.9,0,1.7-0.3,2.4-0.8C461.1,37.1,461.5,36.2,461.7,35.3z"/>
|
||||
<path d="M470.4,39.8V26.9h4.8c0.8,0,1.6,0.1,2.4,0.4c0.6,0.2,1.1,0.7,1.4,1.2c0.3,0.5,0.5,1.1,0.5,1.7c0,0.6-0.2,1.1-0.4,1.6
|
||||
c-0.3,0.5-0.8,0.9-1.4,1.2c0.7,0.2,1.3,0.6,1.8,1.2c0.4,0.6,0.6,1.2,0.6,2c0,0.6-0.1,1.2-0.4,1.7c-0.2,0.5-0.5,0.9-0.9,1.2
|
||||
c-0.4,0.3-0.9,0.5-1.4,0.6c-0.7,0.2-1.4,0.2-2.1,0.2L470.4,39.8z M472.1,32.3h2.8c0.5,0,1.1,0,1.6-0.1c0.4-0.1,0.7-0.3,1-0.6
|
||||
c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.8-0.3-1.1c-0.2-0.3-0.5-0.6-0.9-0.7c-0.6-0.1-1.3-0.2-2-0.2h-2.6L472.1,32.3z M472.1,38.3
|
||||
h3.2c0.4,0,0.8,0,1.2-0.1c0.3-0.1,0.7-0.2,1-0.4c0.3-0.2,0.5-0.4,0.6-0.7c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.9-0.4-1.3
|
||||
c-0.2-0.4-0.6-0.6-1-0.7c-0.6-0.2-1.2-0.2-1.9-0.2h-3L472.1,38.3z"/>
|
||||
<path d="M491,26.9h1.7v7.4c0,1-0.1,2.1-0.4,3.1c-0.3,0.8-0.9,1.4-1.6,1.9c-0.9,0.5-2,0.8-3,0.7c-1,0-2-0.2-3-0.6
|
||||
c-0.7-0.4-1.3-1-1.6-1.8c-0.4-1-0.5-2.1-0.5-3.2v-7.4h1.7v7.4c0,0.8,0.1,1.7,0.3,2.5c0.2,0.5,0.6,1,1.1,1.2
|
||||
c0.6,0.3,1.2,0.5,1.9,0.4c1,0.1,1.9-0.2,2.7-0.9c0.6-1,0.9-2.1,0.8-3.3L491,26.9z"/>
|
||||
<path d="M495.5,39.8V26.9h5.7c0.9,0,1.8,0.1,2.6,0.3c0.6,0.2,1.1,0.7,1.4,1.2c0.4,0.6,0.5,1.3,0.5,1.9c0,0.9-0.3,1.7-0.9,2.3
|
||||
c-0.8,0.7-1.7,1.1-2.7,1.2c0.4,0.2,0.7,0.4,1,0.6c0.5,0.5,1,1.1,1.4,1.7l2.2,3.5h-2.1l-1.7-2.7c-0.5-0.8-0.9-1.4-1.2-1.8
|
||||
c-0.2-0.3-0.5-0.6-0.9-0.9c-0.2-0.2-0.5-0.3-0.8-0.3c-0.3,0-0.6-0.1-0.9-0.1h-2v5.7H495.5z M497.2,32.6h3.7c0.6,0,1.2-0.1,1.8-0.2
|
||||
c0.4-0.1,0.8-0.4,1-0.8c0.2-0.3,0.3-0.7,0.3-1.2c0-0.6-0.2-1.1-0.7-1.5c-0.6-0.4-1.3-0.7-2.1-0.6h-4.1L497.2,32.6z"/>
|
||||
<path d="M507.9,35.6l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C508.2,37.3,507.9,36.5,507.9,35.6z"/>
|
||||
<path d="M523.8,39.8V28.4h-4.2v-1.5h10.2v1.5h-4.3v11.4H523.8z"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M582.6,40V27.1h4.4c0.8,0,1.5,0,2.3,0.2c0.7,0.1,1.3,0.5,1.9,0.9c0.7,0.6,1.2,1.3,1.5,2.2c0.4,1,0.5,2,0.5,3.1
|
||||
c0,0.9-0.1,1.8-0.3,2.6c-0.2,0.7-0.5,1.3-0.9,1.9c-0.3,0.5-0.7,0.9-1.2,1.2c-0.5,0.3-1,0.5-1.5,0.6c-0.7,0.2-1.4,0.2-2.1,0.2
|
||||
L582.6,40z M584.3,38.5h2.8c0.7,0,1.3-0.1,2-0.2c0.4-0.1,0.8-0.4,1.2-0.7c0.4-0.5,0.8-1,0.9-1.6c0.2-0.8,0.4-1.6,0.3-2.5
|
||||
c0.1-1.1-0.2-2.2-0.7-3.1c-0.4-0.7-0.9-1.2-1.6-1.5c-0.7-0.2-1.5-0.3-2.2-0.3h-2.7L584.3,38.5z"/>
|
||||
<path d="M594.1,40l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4L596,40H594.1z M597.9,34.7h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L597.9,34.7z"/>
|
||||
<path d="M609.5,40V28.6h-4.2v-1.5h10.2v1.5h-4.3V40H609.5z"/>
|
||||
<path d="M614.5,40l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H614.5z M618.2,34.7h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L618.2,34.7z"/>
|
||||
</g>
|
||||
<path id="path3733-4-5_00000005956794692188289810000002643477931960871853_" class="st0" d="M537.3,18.8v28.3"/>
|
||||
<path id="path3733-4-5_00000004546286590786815740000015974072703850002356_" class="st0" d="M673.2,47.4h-645V19.1h645V47.4z"/>
|
||||
<g>
|
||||
<path d="M787,35.9l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C787.2,37.5,787,36.7,787,35.9z"/>
|
||||
<path d="M803.2,40v-5.5l-5-7.4h2.1l2.5,3.9c0.5,0.7,0.9,1.5,1.3,2.2c0.4-0.7,0.9-1.4,1.4-2.3l2.5-3.8h2l-5.1,7.4V40H803.2z"/>
|
||||
<path d="M811.6,40V27.2h1.7l6.8,10.1V27.2h1.6V40H820l-6.8-10.1V40H811.6z"/>
|
||||
<path d="M833.8,35.5l1.7,0.4c-0.3,1.3-0.9,2.4-1.9,3.2c-1,0.8-2.2,1.1-3.4,1.1c-1.2,0.1-2.4-0.2-3.4-0.8c-0.9-0.6-1.6-1.5-2-2.5
|
||||
c-0.5-1.1-0.7-2.3-0.7-3.5c0-1.2,0.2-2.4,0.8-3.5c0.5-1,1.2-1.8,2.2-2.3c1-0.5,2-0.8,3.1-0.8c1.2,0,2.3,0.3,3.3,1
|
||||
c0.9,0.7,1.5,1.7,1.8,2.8l-1.7,0.4c-0.2-0.8-0.7-1.5-1.3-2c-0.6-0.4-1.4-0.7-2.1-0.6c-0.9,0-1.8,0.2-2.5,0.7
|
||||
c-0.7,0.5-1.2,1.1-1.4,1.9c-0.3,0.8-0.4,1.6-0.4,2.5c0,1,0.1,2,0.5,2.9c0.3,0.8,0.8,1.4,1.5,1.8c0.7,0.4,1.4,0.6,2.2,0.6
|
||||
c0.9,0,1.7-0.3,2.4-0.8C833.1,37.3,833.6,36.5,833.8,35.5z"/>
|
||||
<path d="M842.5,40V27.2h4.8c0.8,0,1.6,0.1,2.4,0.4c0.6,0.2,1.1,0.7,1.4,1.2c0.3,0.5,0.5,1.1,0.5,1.7c0,0.6-0.2,1.1-0.4,1.6
|
||||
c-0.3,0.5-0.8,0.9-1.4,1.2c0.7,0.2,1.3,0.6,1.8,1.2c0.4,0.6,0.6,1.2,0.6,2c0,0.6-0.1,1.2-0.4,1.7c-0.2,0.5-0.5,0.9-0.9,1.2
|
||||
c-0.4,0.3-0.9,0.5-1.4,0.6c-0.7,0.2-1.4,0.2-2.1,0.2L842.5,40z M844.2,32.6h2.8c0.5,0,1.1,0,1.6-0.1c0.4-0.1,0.7-0.3,1-0.6
|
||||
c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.8-0.3-1.1c-0.2-0.3-0.5-0.6-0.9-0.7c-0.6-0.1-1.3-0.2-2-0.2h-2.6L844.2,32.6z M844.2,38.5
|
||||
h3.2c0.4,0,0.8,0,1.2-0.1c0.3-0.1,0.7-0.2,1-0.4c0.3-0.2,0.5-0.4,0.6-0.7c0.2-0.3,0.3-0.7,0.3-1.1c0-0.4-0.1-0.9-0.4-1.3
|
||||
c-0.2-0.4-0.6-0.6-1-0.7c-0.6-0.2-1.2-0.2-1.9-0.2h-3L844.2,38.5z"/>
|
||||
<path d="M863,27.2h1.7v7.4c0,1-0.1,2.1-0.4,3.1c-0.3,0.8-0.9,1.4-1.6,1.9c-0.9,0.5-2,0.8-3,0.7c-1,0-2-0.2-3-0.6
|
||||
c-0.7-0.4-1.3-1-1.6-1.8c-0.4-1-0.5-2.1-0.5-3.2v-7.4h1.7v7.4c0,0.8,0.1,1.7,0.3,2.5c0.2,0.5,0.6,1,1.1,1.2
|
||||
c0.6,0.3,1.2,0.5,1.9,0.4c1,0.1,1.9-0.2,2.7-0.9c0.6-1,0.9-2.1,0.8-3.3L863,27.2z"/>
|
||||
<path d="M867.6,40V27.2h5.7c0.9,0,1.8,0.1,2.6,0.3c0.6,0.2,1.1,0.7,1.4,1.2c0.4,0.6,0.5,1.3,0.5,1.9c0,0.9-0.3,1.7-0.9,2.3
|
||||
c-0.8,0.7-1.7,1.1-2.7,1.2c0.4,0.2,0.7,0.4,1,0.6c0.5,0.5,1,1.1,1.4,1.7L879,40h-2.1l-1.7-2.7c-0.5-0.8-0.9-1.4-1.2-1.8
|
||||
c-0.2-0.3-0.5-0.6-0.9-0.9c-0.2-0.2-0.5-0.3-0.8-0.3c-0.3,0-0.6-0.1-0.9-0.1h-2V40H867.6z M869.3,32.8h3.7c0.6,0,1.2-0.1,1.8-0.2
|
||||
c0.4-0.1,0.8-0.4,1-0.8c0.2-0.3,0.3-0.7,0.3-1.2c0-0.6-0.2-1.1-0.7-1.5c-0.6-0.4-1.3-0.7-2.1-0.6h-4.1L869.3,32.8z"/>
|
||||
<path d="M880,35.9l1.6-0.1c0,0.6,0.2,1.1,0.5,1.6c0.3,0.5,0.8,0.8,1.3,1c0.6,0.3,1.3,0.4,2,0.4c0.6,0,1.2-0.1,1.7-0.3
|
||||
c0.4-0.2,0.8-0.4,1.1-0.8c0.2-0.3,0.4-0.7,0.4-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.3-0.4-0.7-0.6-1.2-0.8c-0.8-0.2-1.5-0.5-2.3-0.6
|
||||
c-0.9-0.2-1.7-0.4-2.5-0.8c-0.6-0.3-1-0.7-1.4-1.2c-0.3-0.5-0.5-1-0.5-1.6c0-0.6,0.2-1.3,0.6-1.8c0.4-0.6,1-1,1.6-1.3
|
||||
c0.8-0.3,1.6-0.5,2.4-0.4c0.9,0,1.7,0.1,2.5,0.5c0.7,0.3,1.3,0.7,1.7,1.4c0.4,0.6,0.6,1.3,0.6,2l-1.6,0.1c0-0.7-0.4-1.4-0.9-1.8
|
||||
c-0.7-0.5-1.4-0.7-2.2-0.6c-0.8-0.1-1.6,0.1-2.3,0.6c-0.4,0.3-0.7,0.8-0.7,1.4c0,0.4,0.2,0.9,0.5,1.1c0.8,0.5,1.7,0.8,2.6,0.9
|
||||
c1,0.2,1.9,0.5,2.9,0.8c0.7,0.3,1.2,0.7,1.7,1.3c0.4,0.5,0.5,1.2,0.5,1.8c0,0.7-0.2,1.4-0.6,1.9c-0.4,0.6-1,1.1-1.7,1.4
|
||||
c-0.8,0.3-1.6,0.5-2.5,0.5c-1,0-2-0.1-2.9-0.5c-0.8-0.3-1.4-0.8-1.9-1.5C880.2,37.5,880,36.7,880,35.9z"/>
|
||||
<path d="M895.9,40V28.7h-4.2v-1.5h10.2v1.5h-4.3V40H895.9z"/>
|
||||
</g>
|
||||
<g>
|
||||
<path d="M954.6,40.3V27.4h4.4c0.8,0,1.5,0,2.3,0.2c0.7,0.1,1.3,0.5,1.9,0.9c0.7,0.6,1.2,1.3,1.5,2.2c0.4,1,0.5,2,0.5,3.1
|
||||
c0,0.9-0.1,1.8-0.3,2.6c-0.2,0.7-0.5,1.3-0.9,1.9c-0.3,0.5-0.7,0.9-1.2,1.2c-0.5,0.3-1,0.5-1.5,0.6c-0.7,0.2-1.4,0.2-2.1,0.2
|
||||
L954.6,40.3z M956.3,38.7h2.8c0.7,0,1.3-0.1,2-0.2c0.4-0.1,0.8-0.4,1.2-0.7c0.4-0.5,0.8-1,0.9-1.6c0.2-0.8,0.4-1.6,0.3-2.5
|
||||
c0.1-1.1-0.2-2.2-0.7-3.1c-0.4-0.7-0.9-1.2-1.6-1.5c-0.7-0.2-1.5-0.3-2.2-0.3h-2.7L956.3,38.7z"/>
|
||||
<path d="M966.2,40.3l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H966.2z M969.9,35h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L969.9,35z"/>
|
||||
<path d="M981.6,40.3V28.9h-4.2v-1.5h10.2v1.5h-4.3v11.4H981.6z"/>
|
||||
<path d="M986.5,40.3l4.9-12.9h1.8l5.3,12.9h-1.9l-1.5-3.9h-5.4l-1.4,3.9H986.5z M990.3,35h4.4l-1.3-3.6c-0.4-1.1-0.7-2-0.9-2.7
|
||||
c-0.2,0.8-0.4,1.7-0.7,2.5L990.3,35z"/>
|
||||
</g>
|
||||
<path id="path3733-4-5_00000001663125317444461110000002885179555265459130_" class="st0" d="M909.3,19v28.3"/>
|
||||
<path id="path3733-4-5_00000072271215796960606740000007617232578408639644_" class="st0" d="M775.4,47.4V19.1h363.9v28.3H775.4z"/>
|
||||
<g>
|
||||
<g>
|
||||
<line class="st1" x1="673.2" y1="19.1" x2="679.2" y2="19.1"/>
|
||||
<line class="st2" x1="692.1" y1="19.1" x2="762.9" y2="19.1"/>
|
||||
<line class="st1" x1="769.4" y1="19.1" x2="775.4" y2="19.1"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<line class="st1" x1="673.2" y1="47.4" x2="679.2" y2="47.4"/>
|
||||
<line class="st2" x1="692.1" y1="47.4" x2="762.9" y2="47.4"/>
|
||||
<line class="st1" x1="769.4" y1="47.4" x2="775.4" y2="47.4"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Przed Szerokość: | Wysokość: | Rozmiar: 18 KiB |
|
|
@ -1,554 +0,0 @@
|
|||
---
|
||||
title: 'Data Link Layer'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
media_order:
|
||||
---
|
||||
|
||||
### Frame
|
||||
|
||||
A Frame shall be composed of a frame type specific [Synchronization Burst (Sync Burst)](#synchronization-burst-sync-burst) followed by 368 bits (184 symbols) of Payload. The combination of Sync Burst plus Payload results in a constant 384 bit (192 symbol) Frame. At the M17 data rate of 4800 symbols/s (9600 bits/s), each Frame is exactly 40ms in duration.
|
||||
|
||||
There are four frame types each with their own specific Sync Burst: [Link Setup Frames (LSF)](#link-setup-frame-lsf), Bit Error Rate Test (BERT) Frames, [Stream Frames](#stream-frames), and [Packet Frames](#packet-frames).
|
||||
|
||||
<table style="width:75%;margin-left:auto;margin-right:auto;">
|
||||
<caption><span style="font-weight:bold">Figure 5 </span><span>Frame</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<th style="border:3px solid black;text-align:center;width:35%;">SYNC BURST<br/>(16 bits / 8 symbols)</th>
|
||||
<th style="border:3px solid black;text-align:center;">PAYLOAD<br/>(368 bits / 184 symbols)</th>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### Forward Error Correction (FEC)
|
||||
The Data Link Layer Contents of a specific frame are modified using various Error Correction Code (ECC) methods. Applying these codes at the transmitter allows the receiver to correct some amount of induced errors in a Forward Error Correction (FEC) process. It is this ECC/FEC data that is inserted into the Payload portion of the Frame. The exact ECC/FEC techniques used vary by frame type.
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> Bit Types</center>
|
||||
Type | Description
|
||||
---- | -----------
|
||||
Type 1 | Data link layer content bits
|
||||
Type 2 | Bits after appropriate encoding
|
||||
Type 3 | Bits after puncturing
|
||||
Type 4 | Interleaved (re-ordered) bits
|
||||
|
||||
<center><span style="font-weight:bold">Figure 6</span> Transmit Contents to Payload</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
contents[Data Link Layer Contents] -- Type 1 bits --> fec[ECC/FEC Encode] -- Type 4 bits--> payload[Payload]
|
||||
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
|
||||
[/mermaid]
|
||||
|
||||
<center><span style="font-weight:bold">Figure 7</span> Receive Payload to Contents</center>
|
||||
[mermaid]
|
||||
graph LR
|
||||
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
|
||||
[/mermaid]
|
||||
|
||||
### Modes
|
||||
|
||||
The Data Link layer shall operate in one of three modes during a [Transmission](../physical-layer#transmission).
|
||||
|
||||
* [Stream Mode](#stream-mode)
|
||||
Data are sent in a continuous stream for an indefinite amount of time, with no break in physical layer output, until the stream ends. e.g. voice data, bulk data transfers, etc.
|
||||
Stream Mode shall start with an LSF and is followed by one or more Stream Frames.
|
||||
|
||||
* [Packet Mode](#packet-mode)
|
||||
Data are sent in small bursts, up to 798 bytes at a time, after which the physical layer stops sending data. e.g. messages, beacons, etc.
|
||||
Packet Mode shall start with an LSF and is followed by one to 32 Packet Frames.
|
||||
|
||||
* [BERT Mode](#bert-mode)
|
||||
PRBS9 is used to fill frames with a deterministic bit sequence. Frames are sent in a continuous sequence.
|
||||
Bert Mode shall start with a BERT frame, and is followed by one or more BERT Frames.
|
||||
|
||||
**Note:** As is the convention with other networking protocols, all values and data structures are encoded in big endian byte order.
|
||||
|
||||
### Synchronization Burst (Sync Burst)
|
||||
|
||||
All frames shall be preceded by 16 bits (8 symbols) of [Sync Burst](../physical-layer#synchronization-burst-sync-burst). The Sync Burst definition straddles both the Physical Layer and the Data Link Layer.
|
||||
|
||||
Only LSF and BERT Sync Bursts may immediately follow the [Preamble](../physical-layer#preamble), and each requires a different Preamble symbol pattern as shown in the table below.
|
||||
|
||||
During a [Transmission](../physical-layer#transmission), only one LSF Sync Burst may be present, and if present, it shall immediately follow the Preamble.
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 3</span> Frame Specific Sync Bursts</center>
|
||||
Frame Type | Preamble | Sync Burst Bytes | Sync Burst Symbols
|
||||
---------- | -------- | ---------------- | ------------------
|
||||
LSF | +3, -3 | 0x55 0xF7 | +3, +3, +3, +3, -3, -3, +3, -3
|
||||
BERT | -3, +3 | 0xDF 0x55 | -3, +3, -3, -3, +3, +3, +3, +3
|
||||
Stream | None | 0xFF 0x5D | -3, -3, -3, -3, +3, +3, -3, +3
|
||||
Packet | None | 0x75 0xFF | +3, -3, +3, +3, -3, -3, -3, -3
|
||||
|
||||
### Link Setup Frame (LSF)
|
||||
|
||||
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
|
||||
----- | ------ | -----------
|
||||
DST | 48 bits | Destination address - Encoded callsign or a special number (eg. a group)
|
||||
SRC | 48 bits | Source address - Encoded callsign of the originator or a special number (eg. a group)
|
||||
TYPE | 16 bits | Information about the incoming data stream
|
||||
META | 112 bits | Metadata field, suitable for cryptographic metadata like IVs or single-use numbers, or non-crypto metadata like the sender’s GNSS position.
|
||||
CRC | 16 bits | CRC for the link setup data
|
||||
Total: 240 Type 1 bits
|
||||
|
||||
##### LSF DST and SRC
|
||||
|
||||
Destination and source addresses may be encoded amateur radio callsigns, or special numbers. See the [Address Encoding Appendix](../../appendix/address-encoding) for details.
|
||||
|
||||
##### LSF TYPE
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 5</span> LSF TYPE definition</center>
|
||||
Bits | Content
|
||||
---- | -------
|
||||
0 | Packet/Stream indicator
|
||||
1..2 | Data type indicator
|
||||
3..4 | Encryption type
|
||||
5..6 | Encryption subtype
|
||||
7..10 | Channel Access Number (CAN)
|
||||
11..15 | Reserved (don’t care)
|
||||
|
||||
<center><span style="font-weight:bold">Table 5a</span> Packet/Stream indicator</center>
|
||||
Value | Mode
|
||||
---- | -------
|
||||
0 | Packet mode
|
||||
1 | Stream mode
|
||||
|
||||
<center><span style="font-weight:bold">Table 5b</span> Data type</center>
|
||||
Value | Content
|
||||
---- | -------
|
||||
\(00_2\) | Reserved
|
||||
\(01_2\) | Data
|
||||
\(10_2\) | Voice
|
||||
\(11_2\) | Voice+Data
|
||||
|
||||
<center><span style="font-weight:bold">Table 5c</span> Encryption type</center>
|
||||
Value | Encryption
|
||||
---- | -------
|
||||
\(00_2\) | None
|
||||
\(01_2\) | AES
|
||||
\(10_2\) | Scrambler
|
||||
\(11_2\) | Other/reserved
|
||||
|
||||
For the encryption subtype, meaning of values depends on encryption type.
|
||||
|
||||
##### LSF META
|
||||
|
||||
The LSF META field is defined by the specific application.
|
||||
|
||||
##### <span id="lsf-crc">LSF CRC</span>
|
||||
|
||||
M17 uses a non-standard version of 16-bit CRC with polynomial $x^{16} + x^{14} + x^{12} + x^{11} + x^8 + x^5 + x^4 + x^2 + 1$ or 0x5935 and initial value of 0xFFFF. This polynomial allows for detecting all errors up to hamming distance of 5 with payloads up to 241 bits, which is less than the amount of data in each frame.
|
||||
|
||||
As M17’s native bit order is most significant bit first, neither the input nor the output of the CRC algorithm gets reflected.
|
||||
|
||||
The input to the CRC algorithm consists of DST, SRC (each 48 bits), 16 bits of TYPE field and 112 bits META, and then depending on whether the CRC is being computed or verified either 16 zero bits or the received CRC.
|
||||
|
||||
The test vectors in the following table are calculated by feeding the given message and then 16 zero bits to the CRC algorithm.
|
||||
|
||||
<center><span style="font-weight:bold">Table 6</span> CRC Test Vectors</center>
|
||||
Message | CRC Output
|
||||
------- | ----------
|
||||
(empty string) | 0xFFFF
|
||||
ASCII string "A" | 0x206E
|
||||
ASCII string "123456789" | 0x772B
|
||||
Bytes 0x00 to 0xFF | 0x1C31
|
||||
|
||||
#### LSF Contents ECC/FEC
|
||||
|
||||
The 240 Type 1 bits of the Link Setup Frame Contents along with 4 flush bits are [convolutionally coded](../../04.appendix/03.convolutional-encoder) using a rate 1/2 coder with constraint K=5. 244 bits total are encoded resulting in 488 Type 2 bits.
|
||||
|
||||
Type 3 bits are computed by [\(P_1\) puncturing](../../04.appendix/05.code-puncturing) the Type 2 bits, resulting in 368 Type 3 bits.
|
||||
|
||||
[Interleaving](../../04.appendix/06.interleaving/) the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.
|
||||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 8</span> LSF Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
lsf_conv_coder["convolutional encoder"]
|
||||
lsf_p1_puncturer["P<sub>1</sub> puncturer"]
|
||||
lsf_interleaver["interleaver"]
|
||||
lsf_randomizer["randomizer"]
|
||||
lsf_sync["prepend LSF Sync Burst"]
|
||||
lsf_flush["add 4 flush bits"]
|
||||
|
||||
phy_cont["Physical Layer Continues..."]
|
||||
|
||||
classDef default fill:#fff,stroke:#000,stroke-width:2px
|
||||
|
||||
subgraph phy["Physical Layer"]
|
||||
lsf_randomizer --> lsf_sync -- 384-bit Frame -->phy_cont
|
||||
end
|
||||
|
||||
subgraph data_link["Data Link Layer"]
|
||||
LSF[LSF Contents] -- 240 Type 1 bits--> lsf_flush --> lsf_conv_coder -- 488 Type 2 bits --> lsf_p1_puncturer -- 368 Type 3 bits --> lsf_interleaver -- 368 Type 4 bits --> lsf_randomizer
|
||||
end
|
||||
|
||||
[/mermaid]
|
||||
|
||||
|
||||
### Stream Mode
|
||||
|
||||
In Stream Mode, an *indefinite* amount of data is sent continuously without breaks in the physical layer. Stream Mode shall always start with an LSF that has the LSF TYPE Packet/Stream indicator bit set to 1 (Stream Mode). Other valid LSF TYPE parameters are selected per application.
|
||||
|
||||
Following the LSF, one or more Stream Frames may be sent.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 9 </span><span>Stream Mode</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
<td style="border:3px solid black;">LSF SYNC BURST</td>
|
||||
<td style="border:3px solid black;">LSF FRAME</td>
|
||||
<td style="border:3px solid black;">STREAM SYNC BURST</td>
|
||||
<td style="border:3px solid black;">STREAM FRAME</td>
|
||||
<td style="border:3px dashed black;">•••</td>
|
||||
<td style="border:3px solid black;">STREAM SYNC BURST</td>
|
||||
<td style="border:3px solid black;">STREAM FRAME</td>
|
||||
<td style="border:3px solid black;">EoT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### Stream Frames
|
||||
|
||||
Stream Frames are composed of frame signalling information contained within the [Link Information Channel (LICH)](#link-information-channel-lich) combined with [Stream Contents](#stream-contents). Both the LICH and Stream Contents utilize different ECC/FEC mechanisms, and are combined at the bit level in a [Frame Combiner](#frame-combiner).
|
||||
|
||||
|
||||
##### Link Information Channel (LICH)
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 7</span> Link Information Channel Contents</center>
|
||||
Bits | Content
|
||||
---- | -------
|
||||
0..39 | 40-bit chunk of full LSF Contents (Type 1 bits)
|
||||
40..42 | LICH_CNT
|
||||
43..47 | Reserved
|
||||
Total: 48 bits
|
||||
|
||||
The 40-bit chunks start with the most significant byte of the LSF.
|
||||
|
||||
<center><span style="font-weight:bold">Table 8</span> LICH_CNT and LSF bits</center>
|
||||
LICH_CNT | LSF bits
|
||||
-------- | -------
|
||||
0 | 239:200
|
||||
1 | 199:160
|
||||
2 | 159:120
|
||||
3 | 119:80
|
||||
4 | 79:40
|
||||
5 | 39:0
|
||||
|
||||
##### LICH Contents ECC/FEC
|
||||
|
||||
The 48-bit LICH Contents is partitioned into 4 12-bit parts and encoded using [Golay (24, 12) code](../../appendix/golay-encoder). This produces 96 encoded Type 2 bits that are fed into the [Frame Combiner](#frame-combiner).
|
||||
|
||||
##### Stream Contents
|
||||
|
||||
<center><span style="font-weight:bold">Table 9</span> Stream Contents</center>
|
||||
Field | Length | Description
|
||||
----- | ------ | -----------
|
||||
FN | 16 bits | Frame Number
|
||||
STREAM | 128 bits | Stream data, can contain arbitrary data
|
||||
Total: 144 Type 1 bits
|
||||
|
||||
The Frame Number (FN) starts from 0 and increments every frame to a maximum of 0x7fff where it will then wrap back to 0. The most significant bit in the FN is used for transmission end signalling. When transmitting the last frame, it shall be set to 1 (one), and 0 (zero) in all other frames.
|
||||
|
||||
Stream data (STREAM) is obtained by extracting 128 bits at a time from the continuous stream of application layer data. If the last frame will contain less than 128 bits of valid data, the remaining bits should be set to zero.
|
||||
|
||||
##### Stream Contents ECC/FEC
|
||||
|
||||
The 144 Type 1 bits of Stream Contents along with 4 flush bits are [convolutionally coded](#../../04.appendix/03.convolutional-encoder) using a rate 1/2 coder with constraint K=5. 148 bits total are encoded resulting in 296 Type 2 bits.
|
||||
|
||||
These bits are [\(P_2\) punctured](../../04.appendix/05.code-puncturing) to generate 272 Type 3 bits that are fed into the [Frame Combiner](#frame-combiner).
|
||||
|
||||
##### 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 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
|
||||
------ | ------ | -----------
|
||||
LICH | 96 bits | ECC/FEC LICH Contents Type 2 bits
|
||||
STREAM | 272 bits | ECC/FEC STREAM Contents Type 3 bits
|
||||
Total: 368 Type 2/3 bits
|
||||
|
||||
[Interleaving](../../04.appendix/06.interleaving/) the Combined Type 2/3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.
|
||||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 10</span> Stream Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
lich_chunk_40["chunk 40 bits"]
|
||||
lich_golay_24_12["Golay (24, 12)"]
|
||||
lich_counter["add LICH counter"]
|
||||
|
||||
stream_data["Stream Data"]
|
||||
stream_chunk_128["chunk 128 bits"]
|
||||
stream_frame_number["prepend frame number"]
|
||||
stream_flush["add 4 flush bits"]
|
||||
stream_conv_coder["convolutional encoder"]
|
||||
stream_p2_puncturer["P<sub>2</sub> puncturer"]
|
||||
|
||||
lich_stream_frame_combiner["Frame Combiner"]
|
||||
|
||||
stream_interleaver["interleaver"]
|
||||
stream_randomizer["randomizer"]
|
||||
stream_sync["prepend Stream Sync Burst"]
|
||||
|
||||
phy_cont["Physical Layer Continues..."]
|
||||
|
||||
classDef default fill:#fff,stroke:#000,stroke-width:2px
|
||||
|
||||
subgraph phy ["Physical Layer"]
|
||||
stream_randomizer --> stream_sync -- 384-bit Frame --> phy_cont
|
||||
end
|
||||
|
||||
subgraph data_link["Data Link Layer"]
|
||||
LSF[LSF Contents] --> lich_chunk_40 -- 40 Type 1 bits --> lich_counter --> lich_golay_24_12 -- 96 Type 2 bits --> lich_stream_frame_combiner
|
||||
stream_chunk_128 --> stream_frame_number -- 144 Type 1 bits --> stream_flush --> stream_conv_coder -- 296 Type 2 bits --> stream_p2_puncturer -- 272 Type 3 bits --> lich_stream_frame_combiner
|
||||
lich_stream_frame_combiner -- 96 Type 2 bits + 272 Type 3 bits = 368 Type 2/3 bits --> stream_interleaver -- 368 Type 4 bits --> stream_randomizer
|
||||
end
|
||||
|
||||
subgraph application_layer["Application Layer"]
|
||||
stream_data -- Continuous data --> stream_chunk_128
|
||||
end
|
||||
|
||||
[/mermaid]
|
||||
|
||||
#### Stream Superframes
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 11</span> Stream Superframes</center>
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 11</span> Single Packet</center>
|
||||
Bytes | Meaning
|
||||
----- | -------
|
||||
1..798 | Application Packet Data
|
||||
2 | CRC
|
||||
Total: 800 bytes (maximum)
|
||||
|
||||
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 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>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
<td style="border:3px solid black;">LSF SYNC BURST</td>
|
||||
<td style="border:3px solid black;">LSF FRAME</td>
|
||||
<td style="border:3px solid black;">PACKET SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PACKET FRAME</td>
|
||||
<td style="border:3px dashed black;">•••</td>
|
||||
<td style="border:3px solid black;">PACKET SYNC BURST</td>
|
||||
<td style="border:3px solid black;">PACKET FRAME</td>
|
||||
<td style="border:3px solid black;">EoT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### Packet Frames
|
||||
|
||||
Packet Frames contain Packet Contents after ECC/FEC is applied.
|
||||
|
||||
#### Packet Contents
|
||||
|
||||
<center><span style="font-weight:bold">Table 12</span> Packet Contents</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0..199 | 200-bit chunk of Single Packet
|
||||
1 | End of Frame (EOF) indicator
|
||||
5 | Packet Frame/Byte Counter
|
||||
Total: 206 Type 1 bits
|
||||
|
||||
The metadata field contains the 1-bit End of Frame (EOF) indicator, and the 5-bit Packet Frame/Byte Counter.
|
||||
|
||||
Each Packet Frame Content payload contains up to a 25-byte chunk of the Single Packet. The 25-byte chunks start with the first byte of the Application Packet data, and finally end with the 2 CRC bytes. If fewer than 25 bytes are able to be extracted from the Single Packet (i.e. for the last Packet Frame), the Single Packet chunk is padded with undefined bytes to reach 25 bytes total. This results in a minimum of one to a maximum of 32 Packet Frames per Transmission. The Packet Frame Counter is reset to zero at the start of Packet Mode.
|
||||
|
||||
For each Packet Frame where there is at least 1 byte remaining in the Single Packet after removing a 25-byte chunk, the EOF metadata bit is set to zero, the Packet Frame Counter value is inserted into the Packet Frame/Byte Counter metadata field, and the Packet Frame Counter is incremented.
|
||||
|
||||
When there are no bytes remaining in the Single Packet after removing a 25-byte (or less) chunk, the EOF metadata bit is set to one, the Packet Byte Counter is set to the number of valid bytes extracted in the last chunk (1 to 25), inserted into the Packet Frame/Byte Counter metadata field, and Packet Mode is ended.
|
||||
|
||||
<br/>
|
||||
|
||||
<center><span style="font-weight:bold">Table 13</span> Metadata Field with EOF = 0</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Set to 0, Not end of frame
|
||||
1..5 | Frame number, 0..31
|
||||
|
||||
<br/>
|
||||
|
||||
<center><span style="font-weight:bold">Table 14</span> Metadata Field with EOF = 1</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Set to 1, End of frame
|
||||
1..5 | Number of bytes in frame, 1..25
|
||||
|
||||
##### Packet Contents ECC/FEC
|
||||
|
||||
The 206 Type 1 bits of the Packet Contents along with 4 flush bits are [convolutionally coded](#../../04.appendix/03.convolutional-encoder) using a rate 1/2 coder with constraint K=5. 210 bits total are encoded resulting in 410 Type 2 bits.
|
||||
|
||||
These bits are [\(P_3\) punctured](../../04.appendix/05.code-puncturing) to generate 368 Type 3 bits.
|
||||
|
||||
[Interleaving](../../04.appendix/06.interleaving/) the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.
|
||||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 13</span> Packet Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
packet_data["Packet Data"]
|
||||
packet_crc["add CRC"]
|
||||
packet_chunk_200["chunk 200 bits"]
|
||||
packet_frame_number["add metadata"]
|
||||
packet_flush["add 4 flush bits"]
|
||||
packet_conv_coder["convolutional encoder"]
|
||||
packet_p3_puncturer["P<sub>3</sub> puncturer"]
|
||||
packet_interleaver["interleaver"]
|
||||
packet_randomizer["randomizer"]
|
||||
packet_sync["prepend Packet Sync Burst"]
|
||||
|
||||
phy_cont["Physical Layer Continues..."]
|
||||
|
||||
classDef default fill:#fff,stroke:#000,stroke-width:2px
|
||||
|
||||
subgraph phy ["Physical Layer"]
|
||||
packet_randomizer -->packet_sync --> phy_cont
|
||||
end
|
||||
|
||||
subgraph data_link["Data Link Layer"]
|
||||
packet_crc --> packet_chunk_200 --> packet_frame_number -- 206 Type 1 bits --> packet_flush --> packet_conv_coder -- 420 Type 2 bits --> packet_p3_puncturer -- 368 Type 3 bits --> packet_interleaver -- 368 Type 4 bits --> packet_randomizer
|
||||
end
|
||||
|
||||
subgraph application_layer["Application Layer"]
|
||||
packet_data -- 798 bytes max per packet --> packet_crc
|
||||
end
|
||||
[/mermaid]
|
||||
|
||||
#### Packet Superframes
|
||||
|
||||
A Packet Superframe consists of up to the 32 Packet Frames used to reconstruct the original Single Packet.
|
||||
|
||||
### BERT Mode
|
||||
|
||||
BERT mode is a standardized, interoperable mode for bit error rate testing. The preamble is
|
||||
sent, followed by an indefinite sequence of BERT frames. Notably, an LSF is not sent in BERT mode.
|
||||
|
||||
The primary purpose of defining a bit error rate testing standard for M17 is to enhance
|
||||
interoperability testing across M17 hardware and software implementations, and to aid in the
|
||||
configuration and tuning of ad hoc communications equipment common in amateur radio.
|
||||
|
||||
<table>
|
||||
<caption><span style="font-weight:bold">Figure 14 </span><span>BERT Mode</span></caption>
|
||||
<tbody style="text-align:center;border:none;">
|
||||
<tr style="font-weight:bold; color:black;">
|
||||
<td style="border:3px solid black;">PREAMBLE</td>
|
||||
<td style="border:3px solid black;">BERT SYNC BURST</td>
|
||||
<td style="border:3px solid black;">BERT FRAME</td>
|
||||
<td style="border:3px dashed black;">•••</td>
|
||||
<td style="border:3px solid black;">BERT SYNC BURST</td>
|
||||
<td style="border:3px solid black;">BERT FRAME</td>
|
||||
<td style="border:3px solid black;">EoT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
#### BERT Frames
|
||||
|
||||
BERT Frames contain BERT Contents after ECC/FEC is applied.
|
||||
|
||||
##### BERT Contents
|
||||
|
||||
The BERT Contents consists of 197 bits from a [PRBS9](https://en.wikipedia.org/wiki/Pseudorandom_binary_sequence)
|
||||
generator. This is 24 bytes and 5 bits of data. The next BERT Contents starts with the 198th bit from the PRBS9
|
||||
generator. The same generator is used for each subsequent BERT Contents without being reset. The number of bits
|
||||
pulled from the generator, 197, is a prime number. This will produce a reasonably large number of unique
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Table 15</span> BERT Contents</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0-196 | BERT PRBS9 Payload
|
||||
Total: 197 Type 1 bits
|
||||
|
||||
##### BERT Contents ECC/FEC
|
||||
|
||||
The 197 Type 1 bits of the Packet Contents along with 4 flush bits are [convolutionally coded](#../../04.appendix/03.convolutional-encoder) using a rate 1/2 coder with constraint K=5. 201 bits total are encoded resulting in 402 Type 2 bits.
|
||||
|
||||
These bits are [\(P_2\) punctured](../../04.appendix/05.code-puncturing) to generate 368 Type 3 bits.
|
||||
|
||||
[Interleaving](../../04.appendix/06.interleaving/) the Type 3 bits produces 368 Type 4 bits that are ready to be passed to the Physical Layer.
|
||||
|
||||
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).
|
||||
|
||||
<center><span style="font-weight:bold">Figure 15</span> BERT Frame Construction</center>
|
||||
[mermaid]
|
||||
graph TD
|
||||
|
||||
bert_data["BERT PRBS9 Data"]
|
||||
bert_chunk_197["chunk 197 bits"]
|
||||
bert_flush["add 4 flush bits"]
|
||||
bert_conv_coder["convolutional encoder"]
|
||||
bert_p2_puncturer["P_2 puncturer"]
|
||||
bert_interleaver["interleaver"]
|
||||
bert_randomizer["randomizer"]
|
||||
bert_sync["prepend BERT Sync Burst"]
|
||||
|
||||
phy_cont["Physical Layer Continues..."]
|
||||
|
||||
classDef default fill:#fff,stroke:#000,stroke-width:2px
|
||||
|
||||
subgraph phy ["Physical Layer"]
|
||||
bert_randomizer --> bert_sync --> phy_cont
|
||||
end
|
||||
|
||||
subgraph data_link["Data Link Layer"]
|
||||
bert_data --> bert_chunk_197 -- 197 Type 1 bits --> bert_flush --> bert_conv_coder -- 402 Type 2 bits --> bert_p2_puncturer -- 368 Type 3 bits --> bert_interleaver -- 368 Type 4 bits --> bert_randomizer
|
||||
end
|
||||
[/mermaid]
|
||||
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* Stream FN rollover - allowed or not?
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
|
Przed Szerokość: | Wysokość: | Rozmiar: 16 KiB |
File diff suppressed because one or more lines are too long
|
Przed Szerokość: | Wysokość: | Rozmiar: 14 KiB |
File diff suppressed because one or more lines are too long
|
Przed Szerokość: | Wysokość: | Rozmiar: 12 KiB |
|
|
@ -1,6 +0,0 @@
|
|||
@BOOK{McGrew2002,
|
||||
title = {Counter mode security: Analysis and recommendations},
|
||||
author = {McGrew, David A.},
|
||||
publisher = {Cisco Systems},
|
||||
edition = {4.},
|
||||
year = {2002}}
|
||||
|
|
@ -1,275 +0,0 @@
|
|||
---
|
||||
title: 'Application Layer'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
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 licensing regimes.
|
||||
|
||||
Definitions
|
||||
- M17 Client - an end station that transmits and receives M17 voice
|
||||
- M17 Repeater - a station that receives and retransmits (repeats) M17 voice
|
||||
- M17 Gateway - a station that receives and transmits M17 voice, converting to and from different formats (e.g. D-Star, DMR, EchoLink, etc.)
|
||||
|
||||
Credit to Jonathan Naylor (G4KLX) for [documenting and implementing](#references-acknowledgements) the details included here.
|
||||
|
||||
[Data Link Layer Stream Mode](../04.data-link-layer/#stream-mode) is used for this application.
|
||||
|
||||
A Stream Mode Transmission begins with an [LSF](../04.data-link-layer/#link-setup-frame-lsf).
|
||||
|
||||
#### LSF/LICH
|
||||
|
||||
<center><span style="font-weight:bold">Table 16</span> Link Setup Frame Contents</center>
|
||||
Field | Length | Description
|
||||
----- | ------ | -----------
|
||||
DST | 48 bits | Destination address
|
||||
SRC | 48 bits | Source address
|
||||
TYPE | 16 bits | Information about the incoming data stream
|
||||
META | 112 bits | Metadata field
|
||||
|
||||
##### Address fields
|
||||
|
||||
Destination (DST) and source (SRC) addresses may be encoded amateur radio callsigns, or special identifiers. See the [Address Encoding Appendix](../../appendix/address-encoding) for details on how up to 9 characters of text can be encoded into the 6-byte address value.
|
||||
|
||||
The source address is always the callsign of the station transmitting, be it a client, repeater, or gateway. This is not a problem for a client, but for a repeater/gateway this raises issues about identifying the original source of a transmission. Having a repeater/gateway always use its own callsign for the source field does ensure that there are no issues with licensing authorities. To retain identification of the original source for a repeater/gateway, an extended callsign data field will be encoded in the LSF META field.
|
||||
|
||||
The destination address used by a client may simply be a callsign for a point to point contact, or may be one of the following special identifiers in the table below.
|
||||
|
||||
<center><span style="font-weight:bold">Table 17</span> Client destination address</center>
|
||||
Identifier | Address Value | Description
|
||||
---------------- | -------------- | -----------
|
||||
(Callsign) | varies | Destination callsign for a point to point contact
|
||||
ALL | 0xFFFFFFFFFFFF | Broadcast and any transmission is relayed to any connected reflector
|
||||
ECHO | 0x0000000ED87D | Enable the local echo function in a repeater/gateway
|
||||
INFO | 0x0000000ECDB9 | Trigger a voice and text announcement of the current linked status of the repeater/gateway
|
||||
UNLINK | 0x0000454F7745 | Unlink from a reflector and trigger an INFO response
|
||||
(Reflector Name) | varies | Link to a reflector and trigger an INFO response (if valid and not already linked)
|
||||
|
||||
The destination address of locally repeated radio transmission retains its original destination address, and the originator's callsign is encoded in the extended callsign data. For other transmissions, one of the following special identifiers may be used.
|
||||
|
||||
<center><span style="font-weight:bold">Table 18</span> Repeater/gateway destination address</center>
|
||||
Identifier | Address Value | Description
|
||||
---------------- | -------------- | -----------
|
||||
(Callsign) | varies | Destination callsign for a locally repeated radio transmission
|
||||
ALL | 0xFFFFFFFFFFFF | All transmitted reflector traffic, originator's callsign and the currently linked reflector are encoded in the extended callsign data
|
||||
ECHO | 0x0000000ED87D | Reply of the built-in echo function, originator's callsign is encoded in the extended callsign data
|
||||
INFO | 0x0000000ECDB9 | Voice and text announcement of the current linked status of the repeater/gateway
|
||||
|
||||
##### TYPE field
|
||||
|
||||
The TYPE field contains information about the frames to follow LSF.
|
||||
|
||||
<center><span style="font-weight:bold">Table 18</span> M17 Voice LSF TYPE definition</center>
|
||||
Bits | Meaning
|
||||
---- | -------
|
||||
0 | Packet/Stream indicator
|
||||
<nbsp> | 1 = Stream Mode
|
||||
1..2 | Data type indicator
|
||||
<nbsp> | $00_2$ = Reserved
|
||||
<nbsp> | $01_2$ = Data
|
||||
<nbsp> | $10_2$ = Voice only (3200 bps)
|
||||
<nbsp> | $11_2$ = Voice (1600 bps) + Data
|
||||
3..4 | Encryption type
|
||||
<nbsp> | $00_2$ = None
|
||||
<nbsp> | $01_2$ = Scrambling
|
||||
<nbsp> | $10_2$ = AES
|
||||
5..6 | Encryption subtype
|
||||
7..10 | Channel Access Number (CAN)
|
||||
11..15 | Reserved (don’t care)
|
||||
|
||||
This application requires Stream Mode.
|
||||
|
||||
The Voice only data type indicator ($10_2$) specifies voice data encoded at 3200 bps using Codec 2.
|
||||
|
||||
The Voice and Data data type indicator ($11_2$) specifies voice data encoded at 1600 bps using Codec 2, the remaining 1600 bps can be used for arbitrary data.
|
||||
|
||||
#### Encryption Types
|
||||
|
||||
Encryption is **optional**. The use of it may be restricted within some radio services and countries, and should only be used if legally permissible.
|
||||
|
||||
##### Null Encryption
|
||||
|
||||
Encryption type = $00_2$
|
||||
|
||||
When no encryption is used, the 14-byte (112-bit) META field of the LSF and corresponding LICH of the stream can be used for transmitting relatively small amounts of extended data without affecting the bandwidth available for the audio. The full 14 bytes of META extended data is potentially decodable every six stream frames, at a 240 ms update rate. The extended data is transmitted in a simple round robin manner, with the only exception being GPS data which should be transmitted as soon as possible after the GPS data is received from its source.
|
||||
|
||||
The "Encryption SubType" bits in the Stream Type field indicate what extended data is stored in the META field.
|
||||
|
||||
<center><span style="font-weight:bold">Table 19</span> Null encryption subtype bits</center>
|
||||
Encryption subtype bits | LSF META data contents
|
||||
----------------------- | ----------------------
|
||||
$00_2$ | Text Data
|
||||
$01_2$ | GNSS Position Data
|
||||
$10_2$ | Extended Callsign Data
|
||||
$11_2$ | Reserved
|
||||
|
||||
##### Text Data
|
||||
|
||||
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.
|
||||
|
||||
The Control Byte is split into two 4-bit fields. The most significant four bits are a bit map of the message length indicating how many Text Data blocks are required for a complete message. There is one bit per used Text Data block, with $0001_2$ used for one block, $0011_2$ for the two, $0111_2$ for three, and $1111_2$ for four.
|
||||
|
||||
The least significant four bits indicate which of the Text Data blocks this text corresponds to. It is $0001_2$ for the first, $0010_2$ for the second, $0100_2$ for the third, and $1000_2$ for the fourth. Any received Control Byte is OR-ed together by the receiving station, and once the most significant and least significant four bits are the same, a complete message has been received.
|
||||
|
||||
It is up to the receiver to decide how to display this message. It may choose to wait for all of the Text Data to be received, or display the parts as they are received. It is not expected that the data in the text field changes during the course of a transmission.
|
||||
|
||||
##### GNSS Data
|
||||
|
||||
Unlike Text and Extended Callsign Data, GNSS data is expected to be dynamic during the course of a transmission and to be transmitted quickly after the GNSS data becomes available. To stop the LSF/LICH data stream from being overrun with GNSS data relative to other data types, a throttle on the amount of GNSS data transmitted is needed. It is recommended that GNSS data be sent at an update rate no faster than once every five seconds.
|
||||
|
||||
The GNSS data fits within one 14-byte META field, which equates to six audio frames, and takes 240ms to transmit. This is a simple format of the GNSS data which does not require too much work to convert into, and provides enough flexibility for most cases. This has been tested on-air and successfully gated to APRS-IS, showing a location very close to the position reported by the GPS receiver.
|
||||
|
||||
GNSS Position Data stores the 112 bit META field as follows:
|
||||
|
||||
<center><span style="font-weight:bold">Table 20</span> GNSS Data encoding</center>
|
||||
Size in bits | Format | Contents
|
||||
------------ | ------ | --------
|
||||
8 | unsigned integer | Data Source
|
||||
<nbsp> | <nbsp> | Used to modify the message added to the APRS message sent to APRS-IS
|
||||
<nbsp> | <nbsp> | 0x00 : M17 Client
|
||||
<nbsp> | <nbsp> | 0x01 : OpenRTX
|
||||
<nbsp> | <nbsp> | 0x02..0xFE : reserved
|
||||
<nbsp> | <nbsp> | 0xFF : other data source
|
||||
8 | unsigned integer | Station Type
|
||||
<nbsp> | <nbsp> | Translated into suitable APRS symbols when gated to APRS-IS
|
||||
<nbsp> | <nbsp> | 0x00 : Fixed Station
|
||||
<nbsp> | <nbsp> | 0x01 : Mobile Station
|
||||
<nbsp> | <nbsp> | 0x02 : Handheld
|
||||
8 | unsigned integer | Whole number absolute value of degrees latitude
|
||||
16 | unsigned integer | Decimal degrees of latitude multiplied by 65535, MSB first
|
||||
8 | unsigned integer | Whole number absolute value of degrees longitude
|
||||
16 | unsigned integer | Decimal degrees of longitude multiplied by 65535, MSB first
|
||||
8 | unsigned integer | Latitude N/S, Longitude E/W, Altitude, Speed and Bearing bit fields
|
||||
<nbsp> | <nbsp> | $xxxxxxx0_2$ North Latitude
|
||||
<nbsp> | <nbsp> | $xxxxxxx1_2$ South Latitude
|
||||
<nbsp> | <nbsp> | $xxxxxx0x_2$ East Longitude
|
||||
<nbsp> | <nbsp> | $xxxxxx1x_2$ West Longitude
|
||||
<nbsp> | <nbsp> | $xxxxx0xx_2$ Altitude data invalid
|
||||
<nbsp> | <nbsp> | $xxxxx1xx_2$ Altitude data valid
|
||||
<nbsp> | <nbsp> | $xxxx0xxx_2$ Speed and Bearing data invalid
|
||||
<nbsp> | <nbsp> | $xxxx1xxx_2$ Speed and Bearing data valid
|
||||
16 | unsigned integer | Altitude above sea level in feet + 1500 (if valid), MSB first
|
||||
16 | unsigned integer | Whole number of bearing in degrees between 0 and 360 (if valid), MSB first
|
||||
8 | unsigned integer | Whole number of speed in miles per hour (if valid)
|
||||
|
||||
##### Extended Callsign Data
|
||||
|
||||
This is only transmitted from repeaters/gateways and not from clients, who only receive and display this data. These fields should not appear over M17 Internet links as they should only be used over the air from a repeater/gateway.
|
||||
|
||||
The META field is split into two callsign fields. The first is always present, and the second is optional. The callsign data is encoded using the standard M17 callsign [Address Encoding](../../appendix/address-encoding) which takes six bytes to encode a nine character callsign. Any unused space in the META field contains 0x00 bytes. The first callsign field starts at offset zero in the META field, and the second callsign if present starts immediately after the first. There are two unused bytes at the end of the META field.
|
||||
|
||||
The use of these two callsign fields is as follows:
|
||||
|
||||
<center><span style="font-weight:bold">Table 21</span> Extended Callsign Data encoding</center>
|
||||
Source | Callsign Field 1 | Callsign Field 2
|
||||
------------------- | ---------------- | ----------------
|
||||
Locally Repeated RF | Originator | Unused
|
||||
ECHO Reply | Originator | Unused
|
||||
Reflector Traffic | Originator | Reflector Name
|
||||
|
||||
The extended callsign data is not used under any other circumstances than the above currently.
|
||||
|
||||
It is not expected that the data in the extra callsign fields change during the course of a transmission.
|
||||
|
||||
##### Scrambling
|
||||
|
||||
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 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
|
||||
------------------ | --------------- | ----------- | ---------------
|
||||
$00_2$ | $x^8 + x^6 + x^5 + x^4 + 1$ | 8 bits | 255
|
||||
$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 LFSR 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 LFSR taps</center>
|
||||
|
||||
|
||||
##### Advanced Encryption Standard (AES)
|
||||
|
||||
Encryption type = $10_2$
|
||||
|
||||
This method uses AES block cipher in counter (CTR) mode, with a 96-bit nonce that should never be used for more than one separate stream and a 32-bit CTR.
|
||||
|
||||
The 96-bit AES nonce value is extracted from the 96 most significant bits of the META field, and the remaining 16 bits of the META field form the highest 16 bits of the 32-bit counter. The FN (Frame Number) field value is then used to fill out the lower 16 bits of the counter, and always starts from 0 (zero) in a new voice stream.
|
||||
|
||||
The 16-bit frame number and 40 ms frames can provide for over 20 minutes of streaming without rolling over the counter.
|
||||
|
||||
> The effective capacity of the counter is 15 bits, as the MSB is used for transmission end signalling. At 40ms per frame, or 25 frames per second, and $2^{15}$ frames, we get $2^{15}$ frames / 25 frames per second = 1310 seconds, or almost 22 minutes.
|
||||
|
||||
The random part of the nonce value should be generated with a hardware random number generator or any other method of generating non-repeating values.
|
||||
|
||||
To combat replay attacks, a 32-bit timestamp shall be embedded into the cryptographic nonce field. The field structure of the 96 bit nonce is shown in Table 9. Timestamp is 32 LSB portion of the number of seconds that elapsed since the beginning of 1970-01-01, 00:00:00 UTC, minus leap seconds (a.k.a. “unix time”).
|
||||
|
||||
##### 96 bit nonce field structure
|
||||
|
||||
<center><span style="font-weight:bold">Table 23</span> Nonce field</center>
|
||||
| Timestamp | Random Data | CTR_HIGH |
|
||||
| --------- | ----------- | -------- |
|
||||
| 32 | 64 | 16 |
|
||||
|
||||
**CTR_HIGH** field initializes the highest 16 bits of the CTR, with the rest of the counter being equal to the FN counter. Encryption subtypes are not applicable for this encryption scheme. All parties are assumed to know the key length used for each transmission.
|
||||
|
||||
!! In CTR mode, AES encryption is malleable. That is, an attacker can change the contents of the encrypted message without decrypting it. This means that recipients of AES-encrypted data must not trust that the data is authentic. Users who require that received messages are proven to be exactly as-sent by the sender should add application-layer authentication, such as HMAC. In the future, use of a different mode, such as Galois/Counter Mode, could alleviate this issue.
|
||||
|
||||
##### Channel Access Number (CAN)
|
||||
|
||||
The Channel Access Number (CAN) is a four bit code that may be used to filter received audio, text, and GNSS data. A receiver may optionally allow reception from sources only if their transmitted CAN value matches the receiver's own specified CAN value.
|
||||
|
||||
#### Stream Frames
|
||||
|
||||
[Stream Frames](../data-link-layer#stream-frames) will contain the appropriate LICH data (described above). The Stream Contents will include the incrementing 16-bit Frame Number, and 128 bits of Codec 2 data (unencrypted or encrypted).
|
||||
|
||||
#### References / Acknowledgements
|
||||
|
||||
- [Jonathan Naylor (G4KLX) Source/Destination and META fields in the M17 Voice Application](https://discourse.m17project.org/t/callsigns-and-extended-use-of-the-meta-field-in-m17/103)
|
||||
- [Jonathan Naylor (G4KLX) GPS Encoding in META field](https://discourse.m17project.org/t/the-format-of-the-m17-gps-data/107/3)
|
||||
- [Jonathan Naylor (G4KLX) Multi-Mode Digital Voice Modem (MMVDM)](https://github.com/g4klx/MMDVM)
|
||||
|
||||
|
||||
### Packet Application
|
||||
|
||||
**!!! Incomplete !!! This is work in progress.**
|
||||
|
||||
A single packet of up to 798 bytes of data may be sent in one transmission.
|
||||
|
||||
Packets are sent using [Packet Mode](../data-link-layer#packet-mode).
|
||||
|
||||
A Stream Mode Transmission begins with an [LSF](../04.data-link-layer/#link-setup-frame-lsf).
|
||||
|
||||
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 identifiers are reserved in the M17 packet spec:
|
||||
|
||||
##### Reserved Protocols
|
||||
|
||||
<center><span style="font-weight:bold">Table 24</span> Packet protocol identifiers</center>
|
||||
Identifier | Protocol
|
||||
---------- | --------
|
||||
0x00 | RAW
|
||||
0x01 | AX.25
|
||||
0x02 | APRS
|
||||
0x03 | 6LoWPAN
|
||||
0x04 | IPv4
|
||||
0x05 | SMS
|
||||
0x06 | Winlink
|
||||
|
||||
The data type specifier is used to compute the CRC, along with the payload.
|
||||
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
---
|
||||
title: 'Part I - Air Interface'
|
||||
taxonomy:
|
||||
category: docs
|
||||
---
|
||||
|
||||
### Part I
|
||||
|
||||
# Air Interface
|
||||
|
|
@ -1,99 +0,0 @@
|
|||
---
|
||||
title: 'IP Networking'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
Digital modes are commonly networked together through linked repeaters using IP networking.
|
||||
|
||||
For commercial protocols like DMR, this is meant for linking metropolitan and state networks together and allows for easy interoperability between radio users. Amateur Radio uses this capability for creating global communications networks for all imaginable purposes, and makes ‘working the world’ with an HT possible.
|
||||
|
||||
M17 is designed with this use in mind, and has native IP framing to support it.
|
||||
|
||||
In competing radio protocols, a repeater or some other RF to IP bridge is required for linking, leading to the use of hotspots (tiny simplex RF bridges).
|
||||
|
||||
The TR-9 and other M17 radios may support IP networking directly, such as through the ubiquitous ESP8266 chip or similar. This allows them to skip the RF link that current hotspot systems require, finally bringing to fruition the “Amateur digital radio is just VoIP” dystopian future we were all warned about.
|
||||
|
||||
## Standard IP Framing
|
||||
|
||||
M17 over IP is big endian, consistent with other IP protocols. We have standardized on UDP port 17000, this port is recommended but not required. Later specifications may require this port.
|
||||
|
||||
##### Internet Frame Fields
|
||||
|
||||
Field | Size | Description
|
||||
----- | ---- | -----------
|
||||
MAGIC | 32 bits | Magic bytes 0x4d313720 (“M17 “)
|
||||
StreamID (SID) | 16 bits | Random bits, changed for each PTT or stream, but consistent from frame to frame within a stream
|
||||
LICH | 224 bits | The meaningful contents of a LICH frame (dst, src, streamtype, META field) as defined earlier.
|
||||
FN | 16 bits | Frame number (exactly as would be transmitted as an RF stream frame, including the last frame indicator at (FN & 0x8000)
|
||||
Payload | 128 bits | Payload (exactly as would be transmitted in an RF stream frame)
|
||||
CRC16 | 16 bits | CRC for the entire packet, as defined earlier [CRC definition](../../part-1/data-link-layer#lsf-crc)
|
||||
|
||||
The CRC checksum must be recomputed after modification or re-assembly of the packet, such as when translating from RF to IP framing.
|
||||
|
||||
## Control Packets
|
||||
|
||||
Reflectors use a few different types of control frames, identified by their magic:
|
||||
|
||||
* CONN - Connect to a reflector
|
||||
* ACKN - acknowledge connection
|
||||
* NACK - deny connection
|
||||
* PING - keepalive for the connection from the reflector to the client
|
||||
* PONG - keepalive response from the client to the reflector
|
||||
* DISC - Disconnect (client->reflector or reflector->client)
|
||||
|
||||
#### CONN
|
||||
|
||||
##### Bytes of CONN Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "CONN"
|
||||
4..9 | 6-byte ‘From’ callsign including module in last character (e.g. “A1BCD D”) encoded as per Address Encoding
|
||||
10 | Module to connect to - single ASCII byte A-Z
|
||||
|
||||
A client sends this to a reflector to initiate a connection. The reflector replies with ACKN on successful linking, or NACK on failure.
|
||||
|
||||
#### ACKN
|
||||
|
||||
##### Bytes of ACKN Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "ACKN"
|
||||
|
||||
#### NACK
|
||||
|
||||
##### Bytes of NACK Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "NACK"
|
||||
|
||||
#### PING
|
||||
|
||||
##### Bytes of PING Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "PING"
|
||||
4..9 | 6-byte ‘From’ callsign including module in last character (e.g. “A1BCD D”) encoded as per Address Encoding
|
||||
|
||||
#### PONG
|
||||
|
||||
##### Bytes of PONG Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "PONG"
|
||||
4..9 | 6-byte ‘From’ callsign including module in last character (e.g. “A1BCD D”) encoded as per Address Encoding
|
||||
|
||||
#### DISC
|
||||
|
||||
##### Bytes of DISC Packet
|
||||
|
||||
Bytes | Purpose
|
||||
----- | -------
|
||||
0..3 | Magic - ASCII "DISC"
|
||||
4..9 | 6-byte ‘From’ callsign including module in last character (e.g. “A1BCD D”) encoded as per Address Encoding
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
---
|
||||
title: 'Part II - Internet Interface'
|
||||
taxonomy:
|
||||
category: docs
|
||||
---
|
||||
|
||||
### Part II
|
||||
|
||||
# Internet Interface
|
||||
|
|
@ -1,171 +0,0 @@
|
|||
---
|
||||
title: 'Address Encoding'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
M17 uses 48-bit (6-byte) addresses. Callsigns and special purpose addresses are encoded into these 6 bytes in the following ways:
|
||||
|
||||
* An address of 0 is invalid.
|
||||
* Address values between 1 and 262143999999999 ($40^{9}−1$), contain up to 9 characters of text encoded using base-40 as described below.
|
||||
* Address values between 262144000000000 ($40^{9}$) and 281474976710654 ($2^{48}−2$) are reserved for future use.
|
||||
* An address of 0xFFFFFFFFFFFF is a broadcast.
|
||||
|
||||
### Address Scheme
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> M17 Addresses</center>
|
||||
Address Range (base-16) | Category | Number of Addresses | Remarks
|
||||
------------- | -------- | ------------------- | -------
|
||||
0x000000000000 | INVALID | 1 |
|
||||
0x000000000001 - 0xEE6B27FFFFFF | Unit ID | 262143999999999 |
|
||||
0xEE6B28000000 - 0xFFFFFFFFFFFE | RESERVED | 19330976710655 | For future use
|
||||
0xFFFFFFFFFFFF | Broadcast | 1 | Valid only for destination
|
||||
|
||||
### Callsign Encoding: base-40
|
||||
|
||||
9 characters from an alphabet of 40 possible characters can be encoded into 48 bits (6 bytes). The base-40 alphabet is:
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> M17 Callsign Alphabet</center>
|
||||
Value (base-10) | Character | Note
|
||||
--------------- | --------- | ----
|
||||
0 | ' ' | A space, ASCII 32 (0x20). Invalid characters will be replaced with this.
|
||||
1 - 26 | 'A' - 'Z' | Upper case letters, ASCII 65 - 90 (0x41 - 0x5A).
|
||||
27 - 36 | '0' - '9' | Numerals, ASCII 48 - 57 (0x30 - 0x39).
|
||||
37 | '-' | Hyphen, ASCII 45 (0x2D).
|
||||
38 | '/' | Forward Slash, ASCII 47 (0x2F).
|
||||
39 | '.' | Dot, ASCII 46 (0x2E).
|
||||
|
||||
When computing the base-40 value of the callsign, the left most character of the callsign is the least significant value. Callsigns must be
|
||||
left justified. Leading spaces are not permitted.
|
||||
|
||||
After the base-40 value is calculated, the final 6-byte address is the big endian encoded (most significant byte first) representation of the base-40 value.
|
||||
|
||||
For example, for the callsign AB1CD, the base-40 representation would be DC1BA, and would be calculated as:
|
||||
|
||||
('D': $4 \times 40^4$) + ('C': $3 \times 40^3$) + ('1': $28 \times 40^2$) + ('B': $2 \times 40^1$) + ('A': $1 \times 40^0$)
|
||||
|
||||
DC1BA (base-40), 0x0000009fdd51 (base-16), 10476881 (base-10)
|
||||
|
||||
The final address encoded into the 6-byte LSF/LICH field would be 0x0000009fdd51
|
||||
|
||||
#### Example Encoder
|
||||
|
||||
```python
|
||||
def encodeM17(call):
|
||||
"""Encode a text string into an M17 address value"""
|
||||
|
||||
charMap = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-/.'
|
||||
|
||||
# convert to upper case
|
||||
call = call.upper()
|
||||
|
||||
# generate an assert error if more than 9 characters long
|
||||
assert len(call) <= 9, 'Error: <callsign> must be 9 characters or less'
|
||||
|
||||
if call == 'ALL':
|
||||
# handle the special case for Broadcast
|
||||
encoded = 0xFFFFFFFFFFFF
|
||||
else:
|
||||
encoded = 0
|
||||
# loop through the characters starting from the end (right most character)
|
||||
for c in call[::-1]:
|
||||
# find the position of the character in the map
|
||||
value = charMap.find(c)
|
||||
|
||||
# if value < 0, the character was not found
|
||||
# invalid characters are forced to 0
|
||||
if value < 0:
|
||||
value = 0
|
||||
|
||||
# shift the current value by one base-40 character (40 decimal)
|
||||
# and add the current value
|
||||
encoded = encoded*40 + value
|
||||
|
||||
return encoded
|
||||
```
|
||||
|
||||
#### Example Decoder
|
||||
|
||||
```python
|
||||
def decodeM17(encoded):
|
||||
"""Decode an M17 address value to a text string"""
|
||||
|
||||
charMap = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-/.'
|
||||
|
||||
# check for unique values
|
||||
if encoded == 0xFFFFFFFFFFFF:
|
||||
# BROADCAST
|
||||
call = 'ALL'
|
||||
elif encoded == 0:
|
||||
call = 'RESERVED'
|
||||
elif encoded >= 0xEE6B28000000:
|
||||
call = 'RESERVED'
|
||||
else:
|
||||
call = ''
|
||||
while (encoded > 0):
|
||||
call = call + charMap[encoded % 40]
|
||||
encoded = encoded // 40
|
||||
|
||||
return call
|
||||
```
|
||||
|
||||
#### Why base-40?
|
||||
|
||||
##### Callsign Formats
|
||||
|
||||
The [International Telecommunication Union (ITU)](https://www.itu.int/) coordinates radio callsign formats worldwide, with format details specified in ITU [Radio Regulations](https://www.itu.int/pub/R-REG-RR/en) Articles 19.67 through 19.69. A very extensive [Wikipedia entry for Amateur Radio Call Signs](https://en.wikipedia.org/wiki/Amateur_radio_call_signs) includes implementation details on callsign use around the world.
|
||||
|
||||
From the ITU Articles, the longest standard callsign may consist of up to seven characters, with longer temporary special occasion callsigns allowed. The allowed callsign characters, or "callsign alphabet", are the 26 letters of the English alphabet ('A' through 'Z') and the ten digits ('0' through '9').
|
||||
|
||||
##### Secondary Operating Suffixes
|
||||
|
||||
Secondary operating suffixes are often added to callsign to indicate temporary changes of status, such as "AB1CD/M" for a mobile station, or "AB1CD/AE" to signify the station has additional operating privileges, etc. The '/' character will be included in callsign alphabet.
|
||||
|
||||
##### Bits per Characters
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 3</span> Storage required for number of callsign characters</center>
|
||||
Callsign Characters | Bits | Bytes
|
||||
------------------- | ---- | -----
|
||||
7 | $log_2(37^7)=36.47$ | 5
|
||||
8 | $log_2(37^8)=41.67$ | 6
|
||||
9 | $log_2(37^9)=46.89$ | 6
|
||||
10 | $log_2(37^{10})=52.09$ | 7
|
||||
11 | $log_2(37^{11})=57.30$ | 8
|
||||
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 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
|
||||
|
||||
The following table shows how many bytes are required to encode a 9 character callsign using callsign alphabet sizes of 37 through 41.
|
||||
|
||||
<center><span style="font-weight:bold">Table 4</span> Storage required for alphabet size</center>
|
||||
Alphabet Size | Bits | Bytes
|
||||
------------- | ---- | -----
|
||||
37 | $log_2(37^9)=46.89$ | 6
|
||||
38 | $log_2(38^9)=47.23$ | 6
|
||||
39 | $log_2(39^9)=47.57$ | 6
|
||||
40 | $log_2(40^9)=47.90$ | 6
|
||||
41 | $log_2(41^9)=48.22$ | 7
|
||||
|
||||
The largest callsign alphabet size able to encode 9 characters into 6 bytes is 40. This means the minimal callsign alphabet of 37 can be extended with three additional characters.
|
||||
|
||||
##### Multiple Stations
|
||||
|
||||
To indicate multiple stations by the same operator, the '-' character can be used. A callsign such as "AB1CD-1" is considered a different station than "AB1CD-2" or even "AB1CD", but it is understood that these all belong to the same operator, "AB1CD". The '-' character will be included in callsign alphabet.
|
||||
|
||||
##### Fill
|
||||
|
||||
A space ' ' character is included in the callsign alphabet as a fill character or as a substitute for characters that are not part of the callsign alphabet.
|
||||
|
||||
##### Dot
|
||||
|
||||
A dot '.' character is included in the callsign alphabet as ... TBD ...
|
||||
|
||||
##### M17 base-40 Callsign Alphabet
|
||||
|
||||
These final additions complete the 40 character M17 callsign alphabet as ' ' (space), 'A' through 'Z', '0' through '9', '-' (hyphen), '/' (forward slash), and '.' (dot).
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
title: 'Randomizer Sequence'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Randomizer values</center>
|
||||
Seq. number | Value | Seq. number | Value
|
||||
----------- | ----- | ----------- | -----
|
||||
00 | 0xD6 | 23 | 0x6E
|
||||
01 | 0xB5 | 24 | 0x68
|
||||
02 | 0xE2 | 25 | 0x2F
|
||||
03 | 0x30 | 26 | 0x35
|
||||
04 | 0x82 | 27 | 0xDA
|
||||
05 | 0xFF | 28 | 0x14
|
||||
06 | 0x84 | 29 | 0xEA
|
||||
07 | 0x62 | 30 | 0xCD
|
||||
08 | 0xBA | 31 | 0x76
|
||||
09 | 0x4E | 32 | 0x19
|
||||
10 | 0x96 | 33 | 0x8D
|
||||
11 | 0x90 | 34 | 0xD5
|
||||
12 | 0xD8 | 35 | 0x80
|
||||
13 | 0x98 | 36 | 0xD1
|
||||
14 | 0xDD | 37 | 0x33
|
||||
15 | 0x5D | 38 | 0x87
|
||||
16 | 0x0C | 39 | 0x13
|
||||
17 | 0xC8 | 40 | 0x57
|
||||
18 | 0x52 | 41 | 0x18
|
||||
19 | 0x43 | 42 | 0x2D
|
||||
20 | 0x91 | 43 | 0x29
|
||||
21 | 0x1D | 44 | 0x78
|
||||
22 | 0xF8 | 45 | 0xC3
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
title: 'Convolutional Encoder'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
The convolutional code shall encode the input bit sequence after appending 4 tail bits at the end of the sequence. Rate of the coder is R=½ with constraint length K=5. The encoder diagram and generating polynomials are shown below.
|
||||
|
||||
\(
|
||||
\begin{align}
|
||||
G_1(D) =& 1 + D^3 + D^4 \\
|
||||
G_2(D) =& 1+ D + D^2 + D^4
|
||||
\end{align}
|
||||
\)
|
||||
|
||||
The output from the encoder must be read alternately.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Convolutional encoder</center>
|
||||
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* More details on parameter choice/performance
|
||||
|
|
@ -1,84 +0,0 @@
|
|||
---
|
||||
title: 'Golay Encoder'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
#### Extended Golay(24,12) code
|
||||
|
||||
The extended Golay(24,12) encoder uses generating polynomial *g(x)* given below to generate the 11 check bits. The check bits and an additional parity bit are appended to the 12 bit data, resulting in a 24 bit codeword. The resulting code is systematic, meaning that the input data (message) is embedded in the codeword.
|
||||
|
||||
\(g(x) = x^{11} + x^{10} + x^6 + x^5 + x^4 + x^2 + 1\)
|
||||
|
||||
This is equivalent to 0xC75 in hexadecimal notation. Both the generating matrix \(G\) and parity check matrix \(H\) are shown below.
|
||||
|
||||
\(
|
||||
\begin{align}
|
||||
G = [I_{12}|P] = \left[
|
||||
\begin{array}{cr}
|
||||
I_{12} \begin{matrix} 1&1&0&0&0&1&1&1&0&1&0&1\\
|
||||
0&1&1&0&0&0&1&1&1&0&1&1\\
|
||||
1&1&1&1&0&1&1&0&1&0&0&0\\
|
||||
0&1&1&1&1&0&1&1&0&1&0&0\\
|
||||
0&0&1&1&1&1&0&1&1&0&1&0\\
|
||||
1&1&0&1&1&0&0&1&1&0&0&1\\
|
||||
0&1&1&0&1&1&0&0&1&1&0&1\\
|
||||
0&0&1&1&0&1&1&0&0&1&1&1\\
|
||||
1&1&0&1&1&1&0&0&0&1&1&0\\
|
||||
1&0&1&0&1&0&0&1&0&1&1&1\\
|
||||
1&0&0&1&0&0&1&1&1&1&1&0\\
|
||||
1&0&0&0&1&1&1&0&1&0&1&1
|
||||
\end{matrix}
|
||||
\end{array}
|
||||
\right]
|
||||
\newline\newline
|
||||
H = [P^T|I_{12}] = \left[
|
||||
\begin{array}{cr}
|
||||
\begin{matrix}
|
||||
1&0&1&0&0&1&0&0&1&1&1&1\\
|
||||
1&1&1&1&0&1&1&0&1&0&0&0\\
|
||||
0&1&1&1&1&0&1&1&0&1&0&0\\
|
||||
0&0&1&1&1&1&0&1&1&0&1&0\\
|
||||
0&0&0&1&1&1&1&0&1&1&0&1\\
|
||||
1&0&1&0&1&0&1&1&1&0&0&1\\
|
||||
1&1&1&1&0&0&0&1&0&0&1&1\\
|
||||
1&1&0&1&1&1&0&0&0&1&1&0\\
|
||||
0&1&1&0&1&1&1&0&0&0&1&1\\
|
||||
1&0&0&1&0&0&1&1&1&1&1&0\\
|
||||
0&1&0&0&1&0&0&1&1&1&1&1\\
|
||||
1&1&0&0&0&1&1&1&0&1&0&1
|
||||
\end{matrix} I_{12}
|
||||
\end{array}
|
||||
\right]
|
||||
\end{align}
|
||||
\)
|
||||
|
||||
The output of the Golay encoder is shown in the table below.
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Golay encoder details</center>
|
||||
Field | Data | Check bits | Parity
|
||||
----- | ---- | ---------- | ------
|
||||
Position | 23..12 | 11..1 | 0 (LSB)
|
||||
Length | 12 | 11 | 1
|
||||
|
||||
Four of these 24-bit blocks are used to reconstruct the LSF.
|
||||
|
||||
Sample MATLAB/Octave code snippet for generating \(G\) and \(H\) matrices is shown below.
|
||||
|
||||
```
|
||||
|
||||
P = hex2poly('0xC75');
|
||||
[H,G] = cyclgen(23, P);
|
||||
|
||||
G_P = G(1:12, 1:11);
|
||||
I_K = eye(12);
|
||||
G = [I_K G_P P.'];
|
||||
H = [transpose([G_P P.']) I_K];
|
||||
```
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* More details on Golay choice/performance
|
||||
* Golay(24,12) matrix in C form
|
||||
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
---
|
||||
title: 'Code Puncturing'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
Removing some of the bits from the convolutional coder’s output is called code puncturing. The nominal coding rate of the encoder used in M17 is ½. This means the encoder outputs two bits for every bit of the input data stream. To get other (higher) coding rates, a puncturing scheme has to be used.
|
||||
|
||||
Two different puncturing schemes are used in M17 stream mode:
|
||||
|
||||
1. \(P_1\) leaving 46 from 61 encoded bits
|
||||
2. \(P_2\) leaving 11 from 12 encoded bits
|
||||
|
||||
Scheme \(P_1\) is used for the *link setup frame*, taking 488 bits of encoded data and selecting 368 bits. The \(gcd(368, 488)\) is 8 which, when used to divide, leaves 46 and 61 bits. However, a full puncture pattern requires the puncturing matrix entries count to be divisible by the number of encoding polynomials. For this case a partial puncture matrix is used. It has 61 entries with 46 of them being ones and shall be used 8 times, repeatedly. The construction of the partial puncturing pattern \(P_1\) is as follows:
|
||||
|
||||
\(
|
||||
\begin{align}
|
||||
M = & \begin{bmatrix}
|
||||
1 & 0 & 1 & 1
|
||||
\end{bmatrix} \\
|
||||
P_{1} = & \begin{bmatrix}
|
||||
1 & M_{1} & \cdots & M_{15}
|
||||
\end{bmatrix}
|
||||
\end{align}
|
||||
\)
|
||||
|
||||
In which \(M\) is a standard 2/3 rate puncture matrix and is used 15 times, along with a leading \(1\) to form \(P_1\), an array of length 61.
|
||||
|
||||
The first pass of the partial puncturer discards \(G_1\) bits only, second pass discards \(G_2\), third - \(G_1\) again, and so on. This ensures that both bits are punctured out evenly.
|
||||
|
||||
Scheme \(P_2\) is for frames (excluding LICH chunks, which are coded differently). This takes 296 encoded bits and selects 272 of them. Every 12th bit is being punctured out, leaving 272 bits. The full matrix shall have 12 entries with 11 being ones.
|
||||
|
||||
The puncturing scheme \(P_2\) is defined by its partial puncturing matrix:
|
||||
|
||||
\(
|
||||
\begin{align}
|
||||
P_2 = & \begin{bmatrix}
|
||||
1 & 1 & 1 & 1 & 1 & 1 \\
|
||||
1 & 1 & 1 & 1 & 1 & 0
|
||||
\end{bmatrix}
|
||||
\end{align}
|
||||
\)
|
||||
|
||||
The linearized representations are:
|
||||
|
||||
```
|
||||
P1 = [1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1,
|
||||
1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1,
|
||||
0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 1]
|
||||
|
||||
P2 = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0]
|
||||
```
|
||||
|
||||
One additional puncturing scheme \(P_3\) is used in the packet mode. The puncturing scheme is defined by its puncturing matrix:
|
||||
|
||||
\(
|
||||
\begin{align}
|
||||
P_3 = & \begin{bmatrix}
|
||||
1 & 1 & 1 & 1 \\
|
||||
1 & 1 & 1 & 0
|
||||
\end{bmatrix}
|
||||
\end{align}
|
||||
\)
|
||||
|
||||
The linearized representation is:
|
||||
|
||||
```
|
||||
P3 = [1, 1, 1, 1, 1, 1, 1, 0]
|
||||
```
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* More details on parameter choice/performance
|
||||
|
|
@ -1,112 +0,0 @@
|
|||
---
|
||||
title: Interleaving
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> Interleaver mapping</center>
|
||||
input index | output index | input index | output index | input index | output index | input index | output index
|
||||
----------- | ------------ | ----------- | ------------ | ----------- | ------------ | ----------- | ------------
|
||||
0 | 0 | 92 | 92 | 184 | 184 | 276 | 276
|
||||
1 | 137 | 93 | 229 | 185 | 321 | 277 | 45
|
||||
2 | 90 | 94 | 182 | 186 | 274 | 278 | 366
|
||||
3 | 227 | 95 | 319 | 187 | 43 | 279 | 135
|
||||
4 | 180 | 96 | 272 | 188 | 364 | 280 | 88
|
||||
5 | 317 | 97 | 41 | 189 | 133 | 281 | 225
|
||||
6 | 270 | 98 | 362 | 190 | 86 | 282 | 178
|
||||
7 | 39 | 99 | 131 | 191 | 223 | 283 | 315
|
||||
8 | 360 | 100 | 84 | 192 | 176 | 284 | 268
|
||||
9 | 129 | 101 | 221 | 193 | 313 | 285 | 37
|
||||
10 | 82 | 102 | 174 | 194 | 266 | 286 | 358
|
||||
11 | 219 | 103 | 311 | 195 | 35 | 287 | 127
|
||||
12 | 172 | 104 | 264 | 196 | 356 | 288 | 80
|
||||
13 | 309 | 105 | 33 | 197 | 125 | 289 | 217
|
||||
14 | 262 | 106 | 354 | 198 | 78 | 290 | 170
|
||||
15 | 31 | 107 | 123 | 199 | 215 | 291 | 307
|
||||
16 | 352 | 108 | 76 | 200 | 168 | 292 | 260
|
||||
17 | 121 | 109 | 213 | 201 | 305 | 293 | 29
|
||||
18 | 74 | 110 | 166 | 202 | 258 | 294 | 350
|
||||
19 | 211 | 111 | 303 | 203 | 27 | 295 | 119
|
||||
20 | 164 | 112 | 256 | 204 | 348 | 296 | 72
|
||||
21 | 301 | 113 | 25 | 205 | 117 | 297 | 209
|
||||
22 | 254 | 114 | 346 | 206 | 70 | 298 | 162
|
||||
23 | 23 | 115 | 115 | 207 | 207 | 299 | 299
|
||||
24 | 344 | 116 | 68 | 208 | 160 | 300 | 252
|
||||
25 | 113 | 117 | 205 | 209 | 297 | 301 | 21
|
||||
26 | 66 | 118 | 158 | 210 | 250 | 302 | 342
|
||||
27 | 203 | 119 | 295 | 211 | 19 | 303 | 111
|
||||
28 | 156 | 120 | 248 | 212 | 340 | 304 | 64
|
||||
29 | 293 | 121 | 17 | 213 | 109 | 305 | 201
|
||||
30 | 246 | 122 | 338 | 214 | 62 | 306 | 154
|
||||
31 | 15 | 123 | 107 | 215 | 199 | 307 | 291
|
||||
32 | 336 | 124 | 60 | 216 | 152 | 308 | 244
|
||||
33 | 105 | 125 | 197 | 217 | 289 | 309 | 13
|
||||
34 | 58 | 126 | 150 | 218 | 242 | 310 | 334
|
||||
35 | 195 | 127 | 287 | 219 | 11 | 311 | 103
|
||||
36 | 148 | 128 | 240 | 220 | 332 | 312 | 56
|
||||
37 | 285 | 129 | 9 | 221 | 101 | 313 | 193
|
||||
38 | 238 | 130 | 330 | 222 | 54 | 314 | 146
|
||||
39 | 7 | 131 | 99 | 223 | 191 | 315 | 283
|
||||
40 | 328 | 132 | 52 | 224 | 144 | 316 | 236
|
||||
41 | 97 | 133 | 189 | 225 | 281 | 317 | 5
|
||||
42 | 50 | 134 | 142 | 226 | 234 | 318 | 326
|
||||
43 | 187 | 135 | 279 | 227 | 3 | 319 | 95
|
||||
44 | 140 | 136 | 232 | 228 | 324 | 320 | 48
|
||||
45 | 277 | 137 | 1 | 229 | 93 | 321 | 185
|
||||
46 | 230 | 138 | 322 | 230 | 46 | 322 | 138
|
||||
47 | 367 | 139 | 91 | 231 | 183 | 323 | 275
|
||||
48 | 320 | 140 | 44 | 232 | 136 | 324 | 228
|
||||
49 | 89 | 141 | 181 | 233 | 273 | 325 | 365
|
||||
50 | 42 | 142 | 134 | 234 | 226 | 326 | 318
|
||||
51 | 179 | 143 | 271 | 235 | 363 | 327 | 87
|
||||
52 | 132 | 144 | 224 | 236 | 316 | 328 | 40
|
||||
53 | 269 | 145 | 361 | 237 | 85 | 329 | 177
|
||||
54 | 222 | 146 | 314 | 238 | 38 | 330 | 130
|
||||
55 | 359 | 147 | 83 | 239 | 175 | 331 | 267
|
||||
56 | 312 | 148 | 36 | 240 | 128 | 332 | 220
|
||||
57 | 81 | 149 | 173 | 241 | 265 | 333 | 357
|
||||
58 | 34 | 150 | 126 | 242 | 218 | 334 | 310
|
||||
59 | 171 | 151 | 263 | 243 | 355 | 335 | 79
|
||||
60 | 124 | 152 | 216 | 244 | 308 | 336 | 32
|
||||
61 | 261 | 153 | 353 | 245 | 77 | 337 | 169
|
||||
62 | 214 | 154 | 306 | 246 | 30 | 338 | 122
|
||||
63 | 351 | 155 | 75 | 247 | 167 | 339 | 259
|
||||
64 | 304 | 156 | 28 | 248 | 120 | 340 | 212
|
||||
65 | 73 | 157 | 165 | 249 | 257 | 341 | 349
|
||||
66 | 26 | 158 | 118 | 250 | 210 | 342 | 302
|
||||
67 | 163 | 159 | 255 | 251 | 347 | 343 | 71
|
||||
68 | 116 | 160 | 208 | 252 | 300 | 344 | 24
|
||||
69 | 253 | 161 | 345 | 253 | 69 | 345 | 161
|
||||
70 | 206 | 162 | 298 | 254 | 22 | 346 | 114
|
||||
71 | 343 | 163 | 67 | 255 | 159 | 347 | 251
|
||||
72 | 296 | 164 | 20 | 256 | 112 | 348 | 204
|
||||
73 | 65 | 165 | 157 | 257 | 249 | 349 | 341
|
||||
74 | 18 | 166 | 110 | 258 | 202 | 350 | 294
|
||||
75 | 155 | 167 | 247 | 259 | 339 | 351 | 63
|
||||
76 | 108 | 168 | 200 | 260 | 292 | 352 | 16
|
||||
77 | 245 | 169 | 337 | 261 | 61 | 353 | 153
|
||||
78 | 198 | 170 | 290 | 262 | 14 | 354 | 106
|
||||
79 | 335 | 171 | 59 | 263 | 151 | 355 | 243
|
||||
80 | 288 | 172 | 12 | 264 | 104 | 356 | 196
|
||||
81 | 57 | 173 | 149 | 265 | 241 | 357 | 333
|
||||
82 | 10 | 174 | 102 | 266 | 194 | 358 | 286
|
||||
83 | 147 | 175 | 239 | 267 | 331 | 359 | 55
|
||||
84 | 100 | 176 | 192 | 268 | 284 | 360 | 8
|
||||
85 | 237 | 177 | 329 | 269 | 53 | 361 | 145
|
||||
86 | 190 | 178 | 282 | 270 | 6 | 362 | 98
|
||||
87 | 327 | 179 | 51 | 271 | 143 | 363 | 235
|
||||
88 | 280 | 180 | 4 | 272 | 96 | 364 | 188
|
||||
89 | 49 | 181 | 141 | 273 | 233 | 365 | 325
|
||||
90 | 2 | 182 | 94 | 274 | 186 | 366 | 278
|
||||
91 | 139 | 183 | 231 | 275 | 323 | 367 | 47
|
||||
|
||||
#### References
|
||||
|
||||
- [Trifina Lucian, Tarniceriu Daniela, Munteanu Valeriu. "Improved QPP Interleavers for LTE Standard." ISSCS 2011 - International Symposium on Signals, Circuits and Systems (2011)](https://arxiv.org/abs/1103.3794)
|
||||
|
||||
### Issues to address...
|
||||
|
||||
* More details on parameter choice/performance
|
||||
|
|
@ -1,148 +0,0 @@
|
|||
---
|
||||
title: 'BERT Details'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
#### PRBS Generation
|
||||
|
||||
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 pseudorandom binary sequence.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 1</span> Traditional form LFSR</center>
|
||||
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 2</span> M17 LFSR</center>
|
||||
|
||||
|
||||
This will result in the same sequence, just shifted by nine bits.
|
||||
|
||||
\({M17\_PRBS}_{n} = {PRBS9}_{n + 8}\)
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 3</span> M17 PRBS9 Generator</center>
|
||||
|
||||
|
||||
```
|
||||
class PRBS9 {
|
||||
static constexpr uint16_t MASK = 0x1FF;
|
||||
static constexpr uint8_t TAP_1 = 8; // Bit 9
|
||||
static constexpr uint8_t TAP_2 = 4; // Bit 5
|
||||
|
||||
uint16_t state = 1;
|
||||
|
||||
public:
|
||||
bool generate()
|
||||
{
|
||||
bool result = ((state >> TAP_1) ^ (state >> TAP_2)) & 1;
|
||||
state = ((state << 1) | result) & MASK;
|
||||
return result;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
The PRBS9 SHOULD be initialized with a state of 1.
|
||||
|
||||
#### PRBS Receiver
|
||||
|
||||
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 synchronized at the start. This, however, is not common
|
||||
nor is it required. PRBS generators can be self-synchronizing.
|
||||
|
||||
##### Synchronization
|
||||
|
||||
The receiver will synchronize the PRBS by first XORing the received bit
|
||||
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 synchronized.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 4</span> M17 PRBS9 Synchronization</center>
|
||||
|
||||
|
||||
During synchronization, bits received and bit errors are not counted towards
|
||||
the overall bit error rate.
|
||||
|
||||
```
|
||||
class PRBS9 {
|
||||
...
|
||||
static constexpr uint8_t LOCK_COUNT = 18; // 18 consecutive good bits.
|
||||
...
|
||||
// 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 synchronize(bool bit)
|
||||
{
|
||||
bool result = (bit ^ (state >> TAP_1) ^ (state >> TAP_2)) & 1;
|
||||
state = ((state << 1) | bit) & MASK;
|
||||
if (result) {
|
||||
sync_count = 0; // error
|
||||
} else {
|
||||
if (++sync_count == LOCK_COUNT) {
|
||||
synced = true;
|
||||
...
|
||||
}
|
||||
}
|
||||
return result;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
##### Counting Bit Errors
|
||||
|
||||
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.
|
||||
|
||||
<center><span style="font-weight:bold">Figure 5</span> M17 PRBS9 Validation</center>
|
||||
|
||||
|
||||
```
|
||||
class PRBS9 {
|
||||
...
|
||||
// PRBS validator. Returns 0 if the bit matches the PRBS, otherwise 1.
|
||||
// The results are only valid when sync() returns true;
|
||||
bool validate(bool bit)
|
||||
{
|
||||
bool result;
|
||||
if (!synced) {
|
||||
result = synchronize(bit);
|
||||
} else {
|
||||
// PRBS is now free-running.
|
||||
result = bit ^ generate();
|
||||
count_errors(result);
|
||||
}
|
||||
return result;
|
||||
}
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
##### Resynchronization
|
||||
|
||||
The receiver must keep track of the number of bit errors over a period of
|
||||
128 bits. If more than 18 bit errors occur, the synchronization process
|
||||
starts anew. This is necessary in the case of missed frames or other serious
|
||||
synchronization issues.
|
||||
|
||||
Bits received and errors which occur during resynchronization are not counted
|
||||
towards the bit error rate.
|
||||
|
||||
#### References
|
||||
|
||||
- [ITU O.150 : Digital test patterns for performance measurements on digital transmission equipment](http://www.itu.int/rec/T-REC-O.150-199210-S)
|
||||
- [PRBS (according ITU-T O.150) and Bit-Sequence Tester : VHDL-Modules](http://www.pldworld.com/_hdl/5/-thorsten-gaertner.de/vhdl/PRBS.pdf)
|
||||
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
---
|
||||
title: 'KISS Protocol'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
The purpose of this appendix is to document conventions for adapting KISS TNCs to M17 packet and streaming modes. M17 is a more complex protocol, both at the baseband level and at the data link layer than is typical for HDLC-based protocols commonly used on KISS TNCs. However, it is well suited for modern packet data links, and can even be used to stream digital audio between a host and a radio.
|
||||
|
||||
This appendix assumes the reader is familiar with the streaming and packet modes defined in the M17 spec, and with KISS TNCs and the KISS protocol.
|
||||
|
||||
In all cases, the TNC expects to get the data payload to be sent and is responsible for frame construction, FEC encoding, puncturing, interleaving and decorrelation. It is also responsible for baseband modulation.
|
||||
|
||||
For streaming modes, all voice encoding (Codec2) is done on the host and not on the TNC. The host is also responsible for constructing the LICH.
|
||||
|
||||
### References
|
||||
|
||||
* [http://www.ax25.net/kiss.aspx](http://www.ax25.net/kiss.aspx)
|
||||
* [https://packet-radio.net/wp-content/uploads/2017/04/multi-kiss.pdf](https://packet-radio.net/wp-content/uploads/2017/04/multi-kiss.pdf)
|
||||
* [https://en.wikipedia.org/wiki/OSI_model](https://en.wikipedia.org/wiki/OSI_model)
|
||||
|
||||
### Glossary
|
||||
|
||||
#### TNC
|
||||
Terminal node controller -- a baseband network interface device to allow host computers to send data over a radio network, similar to a modem. It connects a computer to a radio and handles the baseband portion of the physical layer and the data link layer of network protocol stack.
|
||||
|
||||
#### KISS
|
||||
Short for "Keep it simple, stupid". A simplified TNC protocol designed to move everything except for the physical layer and the data link layer out of the TNC. Early TNCs could include everything up through the application layer of the OSI network model.
|
||||
|
||||
#### SLIP
|
||||
[Serial Line Internet Protocol](https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol) -- the base protocol used by the KISS protocol, extended by adding a single **type indicator** byte at the start of a frame.
|
||||
|
||||
#### type indicator
|
||||
A one byte code at the beginning of a KISS frame which indicates the TNC **port** and KISS **command**.
|
||||
|
||||
#### port
|
||||
A logical port on a TNC. This allowed a single TNC to connect to multiple radios. Its specific use is loosely defined in the KISS spec. The high nibble of the KISS **type indicator**. Port 0xF is reserved.
|
||||
|
||||
#### command
|
||||
A KISS command. This tells the TNC or host how to interpret the KISS frame contents. The low nibble of the KISS **type indicator**. Command 0xF is reserved.
|
||||
|
||||
#### CSMA
|
||||
[Carrier-sense multiple access](https://en.wikipedia.org/wiki/Carrier-sense_multiple_access) -- a protocol used by network devices to minimize collisions on a shared communications channel.
|
||||
|
||||
#### HDLC
|
||||
[High-Level Data Link Control](https://en.wikipedia.org/wiki/High-Level_Data_Link_Control) -- a data link layer framing protocol used in many AX.25 packet radio networks. Many existing protocol documents, including KISS, reference HDLC because of its ubiquity when the protocols were invented. However, HDLC is not a requirement for higher level protocols like KISS which are agnostic to the framing used at the data link layer.
|
||||
|
||||
#### EOS
|
||||
End of stream -- an indicator bit in the frame number field of a stream data frame.
|
||||
|
||||
#### LICH
|
||||
Link information channel -- a secondary data channel in the stream data frame containing supplemental information, including a copy of the link setup frame.
|
||||
|
||||
### M17 Protocols
|
||||
|
||||
This specification defines KISS TNC modes for M17 packet and streaming modes, allowing the KISS protocol to be used to send and receive M17 packet and voice data. Both are bidirectional. There are two packet modes defined. This is done to provide complete access to the M17 protocol while maintaining the greatest degree of backwards compatibility with existing packet applications.
|
||||
|
||||
These protocols map to specific KISS port. The host tells the TNC what type of data to transmit based on the port used in host to TNC transfers. And the TNC tells the host what data it has received by the port set on TNC to host transfers.
|
||||
|
||||
This document outlines first the two packet protocols, followed by the streaming protocol.
|
||||
|
||||
### KISS Basics
|
||||
|
||||
#### TX Delay
|
||||
|
||||
If a **KISS TX** delay $T_d$ greater than 0 is specified, the transmitter is keyed for $T_d ∗ 10ms$ with only a DC signal present.
|
||||
|
||||
The $T_d$ value should be adjusted to the minimum required by the transmitter in order to transmit the full preamble reliably.
|
||||
|
||||
Only a single 40ms preamble frame is ever sent.
|
||||
|
||||
!! A TX delay may be necessary because many radios require some time between when PTT is engaged and the transmitter can begin transmitting a modulated signal.
|
||||
|
||||
### Packet Protocols
|
||||
|
||||
In order to provide backward compatibility with the widest range of existing ham radio software, and to make use of features in the the M17 protocol itself, we will define two distinct packet interfaces BASIC and FULL.
|
||||
|
||||
The KISS protocol allows us to target specific modems using the port identifier in the control byte.
|
||||
|
||||
We first define basic packet mode as this is initially likely to be the most commonly used mode over KISS.
|
||||
|
||||
#### M17 Basic Packet Mode
|
||||
|
||||
Basic packet mode uses only the standard KISS protocol on TNC port 0. This is the default port for all TNCs. Packets are sent using command 0. Again, this is normal behavior for KISS client applications.
|
||||
|
||||
##### Sending Data
|
||||
|
||||
In basic mode, the TNC only expects to receive packets from the host, as it would for any other mode supported AFSK, G3RUH, etc.
|
||||
|
||||
If the TNC is configured for half-duplex, the TNC will do P-persistence CSMA using a 40ms slot time and obey the P value set via the KISS interface. CSMA is disabled in full-duplex mode.
|
||||
|
||||
The **TX Tail** value is deprecated and is ignored.
|
||||
|
||||
The TNC sends the preamble burst.
|
||||
|
||||
The TNC is responsible for constructing the link setup frame, identifying the content as a raw mode packet. The source field is an encoded TNC identifier, similar to the APRS TOCALL, but it can be an arbitrary text string up to 9 characters in length. The destination is set to the broadcast address.
|
||||
|
||||
In basic packet mode, it is expected that the sender callsign is embedded within the packet payload.
|
||||
|
||||
The TNC sends the link setup frame.
|
||||
|
||||
The TNC then computes the CRC for the full packet, splits the packet into data frames encode and modulate each frame back-to-back until the packet is completely transmitted.
|
||||
|
||||
If there is another packet to be sent, the preamble can be skipped and the TNC will construct the next link setup frame (it can re-use the same link setup frame as it does not change) and send the next set of packet frames.
|
||||
|
||||
##### Limitations
|
||||
|
||||
The KISS specification defines no limitation to the packet size allowed. Nor does it specify any means of returning error conditions back to the host. M17 packet protocol limits the raw packet payload size to 798 bytes. The TNC must drop any packets larger than this.
|
||||
|
||||
##### Receiving Data
|
||||
|
||||
When receiving M17 data, the TNC must receive and parse the link setup frame and verify that the following frames contain raw packet data.
|
||||
|
||||
The TNC is responsible for decoding each packet, assembling the packet from the sequence of frames received, and verifying the packet checksum. If the checksum is valid, the TNC transfers the packet, excluding the CRC to the host using **KISS port** 0.
|
||||
|
||||
#### M17 Full Packet Mode
|
||||
|
||||
The purpose of full packet mode is to provide access to the entire M17 packet protocol to the host. This allows the host to set the source and destination fields, filter received packets based on the content these fields, enable encryption, and send and receive type-coded frames.
|
||||
|
||||
Use M17 full packet mode by sending to **KISS port** 1. In this mode the host is responsible for sending both the link setup frame and the packet data. It does this by prepending the 30-byte link setup frame to the packet data, sending this to the TNC in a single KISS frame. The TNC uses the first 30 bytes as the link setup frame verbatim, then splits the remaining data into M17 packet frames.
|
||||
|
||||
As with basic mode, the TNC uses the **Duplex** setting to enable/disable CSMA, and uses the **P value** for CSMA, with a fixes slot time of “4” (40 ms).
|
||||
|
||||
##### Receiving Data
|
||||
|
||||
For TNC to host transfers, the same occurs. The TNC combines the link setup frame with the packet frame and sends both in one KISS frame to the host using **KISS port** 1.
|
||||
|
||||
### Stream Protocol
|
||||
|
||||
The streaming protocol is fairly trivial to describe. It is used by sending first a link setup frame followed by a stream of 26-byte data frames to KISS port 2.
|
||||
|
||||
#### Stream Format
|
||||
|
||||
##### M17 KISS Stream Protocol
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> KISS Stream</center>
|
||||
Frame Size | Contents
|
||||
---------- | --------
|
||||
30 | Link Setup Frame
|
||||
26 | LICH + Payload
|
||||
26 | LICH + Payload
|
||||
... | ...
|
||||
26 | LICH + Payload with EOS bit set
|
||||
|
||||
The host must not send any frame to any other KISS port while a stream is active (a frame with the EOS bit has not been sent).
|
||||
|
||||
It is a protocol violation to send anything other than a link setup frame with the stream mode bit set in the first field as the first frame in a stream transfer to KISS port 2. Any such frame is ignored.
|
||||
|
||||
It is a protocol violation to send anything to any other KISS port while a stream is active. If that happens the stream is terminated and the packet that caused the protocol violation is dropped.
|
||||
|
||||
#### Data Frames
|
||||
|
||||
The data frames contain a 6-byte (48-bit) LICH segment followed by a 20 byte payload segment consisting of frame number, 16-byte data payload and CRC. The TNC is responsible for parsing the frame number and detecting the end-of-stream bit to stop transmitting.
|
||||
|
||||
##### KISS Stream Data Frame
|
||||
|
||||
<center><span style="font-weight:bold">Table 2</span> KISS Stream Data</center>
|
||||
Frame Size | Contents
|
||||
---------- | --------
|
||||
6 | LICH (48 bits)
|
||||
2 | Frame Number and EOS Flag
|
||||
16 | Payload
|
||||
2 | M17 CRC of frame number and payload
|
||||
|
||||
The TNC is responsible for FEC-encoding both the LICH the payload, as well as interleaving, decorrelation, and baseband modulation.
|
||||
|
||||
#### Timing Constraints
|
||||
|
||||
Streaming mode provides additional timing constraints on both host to TNC transfers and on TNC to host transfers. Payload frames must arrive every 40ms and must have a jitter below 40ms. In general, it is expected that the TNC has up to 2 frames buffered (buffering occurs while sending the preamble and link setup frames), it should be able to keep the transmit buffers filled with packet jitter of 40ms.
|
||||
|
||||
The TNC must stop transmitting if the transmit buffers are empty. The TNC communicates that it has stopped transmitting early (before seeing a frame with the end of stream indicator set) by sending an empty data frame to the host.
|
||||
|
||||
### TNC to Host Transfers
|
||||
|
||||
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 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.
|
||||
|
||||
### Busy Channel Lockout
|
||||
|
||||
The TNC implements **busy channel lockout** by enabling half-duplex mode on the TNC, and disables **busy channel lockout** by enabling full-duplex mode. When busy channel lockout occurs, the TNC keeps the link setup frame and discards all data frames until the channel is available. It then sends the preamble, link setup frame, and starts sending the data frames as they are received.
|
||||
|
||||
Note: BCL will be apparent to a receiver as the first frame received after the link setup frame will not start with frame number 0.
|
||||
|
||||
#### Limitations
|
||||
|
||||
Information is lost by having the TNC decode the LICH. It is not possible to communicate to the host that the LICH bytes are known to be invalid.
|
||||
|
||||
Should we have the TNC signal the host by dropping known invalid LICH segments? The host can tell that the LICH is missing by looking at the frame size.
|
||||
|
||||
### Mixing Modes
|
||||
|
||||
An M17 KISS TNC need not keep track of state across distinct TNC ports. Packet transfers are sent one packet at a time. It is OK to send to port 0 and port 1 in subsequent transfers. It is also OK to send a packet followed immediately by a voice streams. As mentioned earlier, it is a protocol violation to sent a KISS frame to any other port while a stream is active. However, a packet can be sent immediately following a voice stream (after EOS is sent).
|
||||
|
||||
#### Back-to-back Transfers
|
||||
|
||||
The TNC is expected to detect back-to-back transfers from the host, even across different KISS ports, and suppress the generation of the preamble.
|
||||
|
||||
For example, a packet containing APRS data sent immediately on PTT key-up should be sent immediately after the EOS frame.
|
||||
|
||||
Back-to-back transfers are common for packet communication where the window size determines the number of unacknowledged frames which may be outstanding (unacknowledged). Packet applications will frequently send back-to-back packets (up to window size packets) before waiting for the remote end to send ACKs for each of the packets.
|
||||
|
||||
### Implementation Details
|
||||
|
||||
#### Polarity
|
||||
|
||||
One of the issues that must be addressed by the TNC designer, and one which the KISS protocol offers no ready solution for, is the issue of polarity.
|
||||
|
||||
A TNC must interface with a RF transceiver for a complete M17 physical layer implementation. RF transceivers may have different polarity for their TX and RX paths.
|
||||
|
||||
M17 defines that the +3 symbol is transmitted with a +2.4 kHz deviation (2.4 kHz above the carrier). **Normal polarity** in a transceiver results in a positive voltage driving the frequency higher and a lower voltage driving the frequency lower. **Reverse polarity** is the opposite. A higher voltage drives the frequency lower.
|
||||
|
||||
On the receive side the same issue exists. **Normal polarity** results in a positive voltage output when the received signal is above the carrier frequency. **Reverse polarity** results in a positive voltage when the frequency is below the carrier.
|
||||
|
||||
Just as with transmitter deviation levels and received signal levels, the polarity of the transmit and receive path must be adjustable on a 4-FSK modem. The way these adjustments are made to the TNC are not addressed by the KISS specification.
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
title: 'File Formats'
|
||||
taxonomy:
|
||||
category:
|
||||
- docs
|
||||
---
|
||||
|
||||
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 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.
|
||||
|
||||
#### Deviation Function (Transmit)
|
||||
A function used to convert symbol values to frequency deviation in RF hardware. This can be used to set hardware registers, create voltages, etc. depending on the hardware used.
|
||||
|
||||
#### Deviation Function (Receive)
|
||||
A function used to convert frequency deviation in RF hardware to symbol values. This can be used when reading hardware registers, sampling voltages, etc. depending on the hardware used.
|
||||
|
||||
#### Dibit
|
||||
Two bits used to represent a symbol, as shown in [Physical Layer](https://spec.m17project.org/part-1/physical-layer) Table 1.
|
||||
|
||||
#### Endianness, Byte order, Big-endian (BE), Little-endian (LE)
|
||||
[Endianness](https://en.wikipedia.org/wiki/Endianness) is the order of the bytes in a word of digital data. In this document, we will refer to big-endian (BE) and little-endian (LE).
|
||||
BE means that the most significant byte of a word is at the lowest memory location, while LE means that the least significant byte is at the lowest memory location.
|
||||
|
||||
#### RF Sample Rate
|
||||
The rate at which deviation values are updated. This will vary depending on the hardware. M17 test software commonly uses 48000 samples per second.
|
||||
|
||||
#### Root-raised-cosine (RRC) Filter
|
||||
A filter used to in digital communications to help reduce intersymbol interference. The M17 [Physical Layer](https://spec.m17project.org/part-1/physical-layer) specifies a root-raised-cosine (RRC) filter with alpha = 0.5 [Root Raised Cosine](https://en.wikipedia.org/wiki/Root-raised-cosine_filter)
|
||||
|
||||
#### Symbol
|
||||
An M17 [Physical Layer](https://spec.m17project.org/part-1/physical-layer) symbol of +3, +1, -1, and -3.
|
||||
|
||||
#### Symbol Rate
|
||||
The rate at which new symbols are generated. For M17, this is 4800 symbols per second.
|
||||
|
||||
### 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.
|
||||
|
||||
<center><span style="font-weight:bold">Table 1</span> File extensions</center>
|
||||
Extension | Description | Data Format | Data Rate
|
||||
--------- | ----------- | ----------- | ---------
|
||||
aud | Mono audio | Signed 16-bit LE | 8000 samples per second
|
||||
sym | M17 symbols | Signed 8-bit | 4800 symbols per second
|
||||
bin | Packed M17 Dibits | MSB first, Unsigned 8-bit | 4800 symbols per second (1200 bytes per second)
|
||||
rrc | RRC filtered and Scaled M17 symbols | Signed 16-bit LE | 48000 samples per second
|
||||
dev | Deviation values | Varies | Varies
|
||||
|
||||
#### aud
|
||||
Mono audio of signed 16-bit LE at a rate of 8000 samples per second. This is often referred to as a "raw" audio file and contains no embedded header information.
|
||||
|
||||
#### sym
|
||||
M17 symbols (+3, +1, -1, -3) encoded as signed 8-bit values at rate of 4800 symbols per second.
|
||||
|
||||
#### bin
|
||||
M17 symbols packed 2 bits per symbol (dibits), 4 symbols per byte (+3 = 01, +1 = 00, -1 = 10, -3 = 11) with the MSB first. These are unsigned 8-bit values at 4800 symbols per second, which is 4 symbols per byte at 1200 bytes per second.
|
||||
|
||||
#### rrc
|
||||
RRC filtered and scaled M17 symbols. In order to generate a reasonable RRC waveform, the symbol rate (4800 symbols per second) is upsampled by a factor of 10 to an RRC sample rate of 48000 samples per second. Then the upsampled symbols are passed through the RRC filter. The output samples of the RRC filter are multiplied by 7168 to fit within a signed 16-bit LE representation (e.g. a +3 value would be +21504).
|
||||
|
||||
#### dev
|
||||
Hardware specific deviation values. These would be obtained by passing RRC filtered values through a deviation function. Since these are device specific, it is recommended to use an underscore plus device type as part of the filename. For example, the Semtech SX1276 uses a deviation step size of 61 Hz per bit. An M17 1600 Hz frequency step is equivalent to an SX1276 deviation value change of 26. Since the SX1276 only accepts positive deviation steps, the deviation function for the SX1276 would be (rrc value + 3.0) x 13. The .dev file specific for the SX1276 would contain those values, and could have a name such as m17test_sx1276.dev
|
||||
|
||||
### Example file flows
|
||||
These show the file types in order of processing for transmit and receive flows. Each "->" symbolizes processing required to move from one file type to the next.
|
||||
|
||||
#### Transmit
|
||||
|
||||
aud -> sym -> rrc -> dev
|
||||
|
||||
aud -> bin -> rrc -> dev
|
||||
|
||||
#### Receive
|
||||
|
||||
dev -> rrc -> sym -> aud
|
||||
|
||||
dev -> rrc -> bin -> aud
|
||||
|
||||
### To-Do
|
||||
File formats for packet and voice + data streams.
|
||||
|
||||
### References
|
||||
|
||||
Bit numbering https://en.wikipedia.org/wiki/Bit_numbering
|
||||
|
||||
Endianness https://en.wikipedia.org/wiki/Endianness
|
||||
|
||||
M17 Physical Layer https://spec.m17project.org/part-1/physical-layer
|
||||
|
||||
Root Raised Cosine https://en.wikipedia.org/wiki/Root-raised-cosine_filter
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
title: Appendix
|
||||
taxonomy:
|
||||
category: docs
|
||||
---
|
||||
|
||||
# Appendix
|
||||
|
|
@ -1 +0,0 @@
|
|||
|
||||
Ładowanie…
Reference in New Issue