kopia lustrzana https://github.com/sq8vps/vp-digi
readme, manuals
sq8vps
rodzic
b4a774bb52
commit
8adf034d26
|
|
@ -1,4 +1,4 @@
|
|||
# 2.0.0 (2023-09-05)
|
||||
# 2.0.0 (2023-09-09)
|
||||
## New features
|
||||
* New modems: AFSK Bell 103 (300 Bd, 1600/1800 Hz), GFSK G3RUH (9600 Bd), AFSK V.23 (1200 Bd, 1300/2100 Hz)
|
||||
* FX.25 (AX.25 with Reed-Solomon FEC) support
|
||||
|
|
@ -6,6 +6,7 @@
|
|||
* none
|
||||
## Other
|
||||
* New signal level measurement method
|
||||
* Full documentation (English and Polish) in Markdown
|
||||
## Known bugs
|
||||
* none
|
||||
# 1.3.3 (2023-09-04)
|
||||
|
|
|
|||
38
README.md
38
README.md
|
|
@ -1,7 +1,7 @@
|
|||
# VP-Digi
|
||||
VP-Digi is a functional, cheap, easy to assemble and configure STM32-based APRS digipeater controller with built-in KISS modem.\
|
||||
Full documentation can be found [here](doc/manual.md).\
|
||||
Dokumentacja po polsku dostępna jest [tutaj](doc/manual_pl.md).
|
||||
Polska wersja tego pliku dostępna jest [tutaj](README_pl.md).
|
||||
|
||||
**VP-Digi** is a functional, affordable, easy-to-assemble, and configure STM32-based APRS digipeater controller with a built-in KISS modem.
|
||||
|
||||
* Multiple modems:
|
||||
* 1200 Bd AFSK Bell 202 (VHF standard)
|
||||
|
|
@ -14,35 +14,35 @@ Dokumentacja po polsku dostępna jest [tutaj](doc/manual_pl.md).
|
|||
* FX.25 (AX.25 with error correction) coder/decoder, fully compatible with [Direwolf](https://github.com/wb2osz/direwolf) and [UZ7HO Soundmodem](http://uz7.ho.ua/packetradio.htm)
|
||||
* Digipeater: 4 settable n-N aliases, 4 simple aliases, viscous delay (known from aprx) or direct only, black and white list
|
||||
* 8 independent beacons
|
||||
* KISS mode (can be used as an ordinary Packet Radio, Winlink, APRS etc. modem)
|
||||
* USB and 2 UARTs: independent, running in KISS, monitor or configuration mode
|
||||
* KISS mode (can be used as an ordinary Packet Radio, Winlink, APRS, etc. modem)
|
||||
* USB and 2 UARTs: independent, running in KISS, monitor, or configuration mode
|
||||
|
||||
## Download and setup
|
||||
The latest compiled firmware can be downloaded [here](https://github.com/sq8vps/vp-digi/releases).\
|
||||
Full documentation can be found [here](doc/manual.md).
|
||||
|
||||
## Updating to 2.0.0+ on older hardware
|
||||
Since version 2.0.0 the component values have changed to provide support for faster modulations (9600 Bd). If you want to use these some components must be replaced. For more informations refer to the [manual](doc/manual.md) ([polska wersja](doc/manual_pl.md)).
|
||||
|
||||
Since version 2.0.0, the component values have changed to provide support for faster modulations (9600 Bd). If you want to use these, some components must be replaced. For more information, refer to the [manual](doc/manual.md).
|
||||
|
||||
## Description, schematic, instructions
|
||||
The user manual and technical description is available [here](doc/manual.md) ([polska wersja](doc/manual_pl.md)).
|
||||
|
||||
The user manual and technical description are available [here](doc/manual.md).
|
||||
|
||||
## Source code
|
||||
The firmware was written using System Workbench for STM32 (SW4STM32) and you should be able to import this repository directly to the IDE. You can get the source code using:
|
||||
|
||||
The firmware was written using System Workbench for STM32 (SW4STM32), and you should be able to import this repository directly into the IDE. You can get the source code using:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/sq8vps/vp-digi.git
|
||||
```
|
||||
Since version 2.0.0 you will also need to get appropriate submodule ([LwFEC](https://github.com/sq8vps/lwfec) for Reed-Solomon FEC):
|
||||
Since version 2.0.0, you will also need to get the appropriate submodule ([LwFEC](https://github.com/sq8vps/lwfec) for Reed-Solomon FEC):
|
||||
|
||||
```bash
|
||||
git submodule init
|
||||
git submodule update
|
||||
```
|
||||
Since version 2.0.0 there is also a possibility to build the firmware with or without FX.25 protocol support. The ```ENABLE_FX25``` symbol must be defined to enable FX.25 support. On SW4STM32 (and STM32CubeIDE probably) this can be done under *Project->Properties->C/C++ Build->Settings->Preprocessor->Defined symbols*.
|
||||
|
||||
## References
|
||||
The project took a lot of time to finish, but now it's probably the most effective, publicly available, STM32-based modem and the most customizable microcontroller-based APRS digipeater. I would like to mention some resources I found really useful or inspiring:
|
||||
* [multimon-ng](https://github.com/EliasOenal/multimon-ng) - general demodulator idea (correlation)
|
||||
* [BeRTOS](https://github.com/develersrl/bertos) - AX.25 decoder
|
||||
* [Forum thread by SP8EBC](http://forum.aprs.pl/index.php?topic=2086.0) - inspiration
|
||||
* [DireWolf](https://github.com/wb2osz/direwolf) - PLL bit recovery idea, FX.25 references
|
||||
* [A High-Performance Sound-Card AX.25 Modem](https://www.tau.ac.il/~stoledo/Bib/Pubs/QEX-JulAug-2012.pdf) - preemphasis and low pass filtering idea
|
||||
* [UZ7HO Soundmodem](http://uz7.ho.ua/packetradio.htm) - PLL-based DCD idea
|
||||
Since version 2.0.0, there is also a possibility to build the firmware with or without FX.25 protocol support. The `ENABLE_FX25` symbol must be defined to enable FX.25 support. On SW4STM32 (and STM32CubeIDE probably), this can be done under *Project->Properties->C/C++ Build->Settings->Preprocessor->Defined symbols*.
|
||||
|
||||
## Contributing
|
||||
All contributions are appreciated.
|
||||
|
|
|
|||
81
README_pl.md
81
README_pl.md
|
|
@ -1,48 +1,49 @@
|
|||
# VP-Digi (PL)
|
||||
VP-Digi to funkcjonalny, tani, łatwy w montażu i konfiguracji sterownik APRS digipeater oparty na STM32 z wbudowanym modemem KISS.
|
||||
# VP-Digi
|
||||
|
||||
* modem 1200 Bd Bell 202 (standard VHF APRS)
|
||||
* Generowanie sygnału R2R lub PWM
|
||||
* Analogowo-cyfrowe wykrywanie zajętego kanału (wykrywanie nośnika danych)
|
||||
* koder/dekoder AX.25 zaprojektowany dla ramek APRS
|
||||
* digipeater: 4 ustawialne aliasy n-N, 4 proste aliasy, opóźnienie lepkie (znane z aprx) lub tylko bezpośrednie, lista czarno-biała.
|
||||
**VP-Digi** jest funkcjonalnym tanim, łatwym w budowie i konfiguracji kontrolerem digipeatera APRS opartym na procesorze STM32 z wbudowanym TNC KISS.
|
||||
|
||||
* Wiele modemów:
|
||||
* 1200 Bd AFSK Bell 202 (standard VHF)
|
||||
* 300 Bd AFSK Bell 103 (standard HF)
|
||||
* 9600 Bd GFSK G3RUH (standard UHF)
|
||||
* 1200 Bd AFSK V.23
|
||||
* Generowanie sygnału z użyciem PWM (lub R2R - niezalecane)
|
||||
* Analogowo-cyfrowe wykrywanie zajętości kanału (DCD)
|
||||
* Obsługa AX.25
|
||||
* Obsługa FX.25 (AX.25 z korekcją błędów), w pełni kompatybilna z [Direwolf](https://github.com/wb2osz/direwolf) i [UZ7HO Soundmodem](http://uz7.ho.ua/packetradio.htm)
|
||||
* Digipeater: 4 ustawialne aliasy n-N, 4 proste aliasy, *viscous delay* (znane z aprx) lub tryb bezpośredni, lista czarna i biała
|
||||
* 8 niezależnych beaconów
|
||||
* tryb KISS (może być używany jako zwykły modem z UI-View, APRSIS32, XASTIR itp.)
|
||||
* USB i 2 UART-y: niezależne, działające w trybie KISS, monitora lub konfiguracji
|
||||
* Tryb KISS (użycie jako zwykły modem Packet Radio, Winlink, APRS itp.)
|
||||
* USB i 2 interfejsy UART: niezależne, działające w trybie KISS, monitora lub konfiguracji
|
||||
|
||||
## Opis, schemat, instrukcja
|
||||
Jeśli nie interesuje Cię kod źródłowy, to repozytorium nie jest dla Ciebie. Możesz znaleźć pełny opis projektu, schematy, skompilowany firmware i instrukcje [na mojej stronie](https://sq8l.pzk.pl/index.php/vp-digi-cheap-and-functional-aprs-digipeater-controller-with-kiss-modem/).
|
||||
## Pobieranie i konfiguracja
|
||||
Najnowsze skompilowane oprogramowanie można znaleźć [tutaj](https://github.com/sq8vps/vp-digi/releases).\
|
||||
Pełną dokumentację można znaleźć [tutaj](doc/manual_pl.md).
|
||||
|
||||
## Wykorzystanie kodu źródłowego
|
||||
Firmware został napisany przy użyciu System Workbench for STM32 (SW4STM32) i powinieneś być w stanie zaimportować to repozytorium bezpośrednio do IDE. Kod źródłowy jest publicznie dostępny od wersji 1.3.0.
|
||||
## Aktualizacja oprogramowania do wersji 2.0.0+ na starszym sprzęcie
|
||||
|
||||
## Opis techniczny
|
||||
Projekt został zaprojektowany do uruchomienia na płytce Blue Pill (STM32F103C8T6) z kryształem 8MHz. Firmware został napisany z wykorzystaniem jedynie operacji na rejestrach (z nagłówkami ST) oraz bibliotek CMSIS. HAL jest tam tylko dla USB. Kod jest (dość) obszernie komentowany tam gdzie trzeba, więc nie powinien być bardzo trudny do zrozumienia.
|
||||
W wersji 2.0.0 wartości komponentów zostały zmienione, aby umożliwić obsługę szybszych modulacji (9600 Bd). W przypadku potrzeby użycia tych modulacji niektóre komponenty muszą zostać wymienione. Więcej informacji dostępnych jest w [instrukcji obsługi](doc/manual_pl.md).
|
||||
|
||||
### Demodulator
|
||||
Są dwa demodulatory (i dekodery) pracujące równolegle, aby zapewnić lepszą wydajność. Sygnał jest próbkowany z częstotliwością 38400Hz (32 próbki na symbol) przez DMA. Przerwanie jest generowane po otrzymaniu 4 próbek, a próbki są decymowane. Następnie przechodzą one przez filtr preemfazy/deemfazy (jeśli jest włączony), który wyrównuje amplitudy tonów. Przefiltrowane próbki są mnożone przez lokalnie generowane tony znakowe i przestrzenne (ich części I i Q - cosinus i sinus). Daje to współczynnik korelacji pomiędzy sygnałem wejściowym a każdym tonem. W międzyczasie wytwarzany jest niefiltrowany symbol, który służy do wysterowania PLL detekcji nośnej danych. Różnica współczynników korelacji stanowi nową próbkę i jest przepuszczana przez filtr dolnoprzepustowy w celu wyeliminowania szumu. Filtrowane próbki są porównywane z zerem i demodulowany symbol jest wysyłany do mechanizmu odzyskiwania bitów.
|
||||
### Odzyskiwanie bitu (i dekoder NRZI)
|
||||
Mechanizm odzyskiwania bitów jest oparty na cyfrowym PLL. PLL pracuje nominalnie z częstotliwością 1200Hz (=1200 Baud). Zmiana symbolu powinna nastąpić w pobliżu zera licznika PLL, tak aby licznik przepełnił się w połowie symbolu i wartość symbolu została spróbkowana. Przy każdej zmianie symbolu licznik jest mnożony przez współczynnik <1, aby zbliżyć go do zera, utrzymując PLL i sygnał przychodzący w fazie. Sygnał DCD jest multipleksowany z obu modemów. Wyjaśnione więcej w [modem.c](Src/drivers/modem.c). Próbkowany symbol jest dekodowany przez dekoder NRZI i wysyłany do warstwy AX.25.
|
||||
### Dekodowanie AX.25
|
||||
Dekoder AX.25 jest dość standardowy. CRC, PID i Control Byte są sprawdzane i obie ścieżki modemu są multipleksowane, aby wyprodukować tylko jedną ramkę wyjściową.
|
||||
### Wykrywanie nośnika danych
|
||||
DCD wykorzystuje podejście analogowo-cyfrowe: oparte na PLL, ale pracujące na cyfrowym, niefiltrowanym strumieniu symboli. PLL działa w taki sam sposób jak PLL odzyskiwania bitów, z wyjątkiem tego, że jest zaimplementowany specjalny mechanizm liczenia impulsów DCD, wyjaśniony w [modem.c](Src/drivers/modem.c). Takie podejście wydaje się być znacznie bardziej efektywne niż typowa, cyfrowa, oparta na AX.25 detekcja.
|
||||
### Kodowanie AX.25
|
||||
Koder AX.25 jest również dość prosty. Może obsługiwać wiele ramek w rzędzie (ograniczone długością bufora). Każda transmisja rozpoczyna się od flag preambuły, następnie flag nagłówka, danych rzeczywistych, CRC, flag stopki/rozdzielających, danych rzeczywistych, CRC, flag stopki/rozdzielających... i flag ogona. Bity surowe są żądane przez modulator.
|
||||
### Modulator (i koder NRZI)
|
||||
Koder NRZI pracuje dokładnie z częstotliwością 1200Hz (=1200 Baud) i żąda bitów od kodera AX.25. Bity są kodowane do symboli, a interwał timera próbkowania DAC jest ustawiony w zależności od wartości symbolu. Z tego powodu używana jest tylko jedna tabela sinusów. Dla tonu 1200 Hz interwał timera jest większy niż dla tonu 2200 Hz - częstotliwość próbkowania jest zmieniana, aby zmienić częstotliwość sygnału wyjściowego. Indeks tablicy jest zawsze zachowany, aby faza sygnału wyjściowego była ciągła.
|
||||
## Używanie kodu VP-Digi w twoim projekcie
|
||||
Chciałbym usłyszeć o projektach, które implementują kod źródłowy VP-Digi. Jeśli tworzysz taki, daj mi znać na sq8vps(at)gmail.com.
|
||||
## Referencje
|
||||
Ukończenie projektu zajęło sporo czasu, ale obecnie jest to prawdopodobnie najbardziej efektywny, publicznie dostępny modem oparty na STM32 i najbardziej konfigurowalny, oparty na mikrokontrolerze digipeater APRS. Chciałbym wspomnieć o kilku źródłach, które uznałem za naprawdę przydatne lub inspirujące:
|
||||
* [multimon-ng](https://github.com/EliasOenal/multimon-ng) - ogólny pomysł na demodulator (korelacja)
|
||||
* [BeRTOS](https://github.com/develersrl/bertos) - dekoder AX.25
|
||||
* [Forum thread by SP8EBC](http://forum.aprs.pl/index.php?topic=2086.0) - inspiracja
|
||||
* [DireWolf](https://github.com/wb2osz/direwolf) - pomysł na odzyskanie bitów PLL
|
||||
* [A High-Performance Sound-Card AX.25 Modem](https://www.tau.ac.il/~stoledo/Bib/Pubs/QEX-JulAug-2012.pdf) - pomysł na preemfazę i filtrowanie dolnoprzepustowe
|
||||
* [UZ7HO Soundmodem](http://uz7.ho.ua/packetradio.htm) - pomysł DCD opartego na PLL
|
||||
## Przyczynianie się
|
||||
Wszystkie wkłady są doceniane, ale proszę o utrzymanie kodu w miarę czystego. Proszę również upewnić się, że firmware działa dobrze przed stworzeniem pull request.
|
||||
## Opis, schemat, instrukcje
|
||||
|
||||
Instrukcja użytkownika i opis techniczny są dostępne [tutaj](doc/manual_pl.md).
|
||||
|
||||
## Kod źródłowy
|
||||
|
||||
Firmware został napisany w środowisku System Workbench for STM32 (SW4STM32), gdzie można bezpośrednio zaimportować projekt. Kod źródłowy można pobrać za pomocą:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/sq8vps/vp-digi.git
|
||||
```
|
||||
Począwszy od wersji 2.0.0 konieczne jest także pobranie odpowiedniego modułu ([LwFEC](https://github.com/sq8vps/lwfec) dla obsługi kodowania Reeda-Solomona):
|
||||
```bash
|
||||
git submodule init
|
||||
git submodule update
|
||||
```
|
||||
Począwszy od wersji 2.0.0 istnieje również możliwość kompilowania oprogramowania z obsługą lub bez obsługi protokołu FX.25. Symbol `ENABLE_FX25` musi zostać zdefiniowany, aby włączyć obsługę FX.25. W SW4STM32 (i prawdopodobnie w STM32CubeIDE) można to zrobić w menu *Project->Properties->C/C++ Build->Settings->Preprocessor->Defined symbols*.
|
||||
|
||||
## Wkład
|
||||
Każdy wkład jest mile widziany.
|
||||
|
||||
## Licencja
|
||||
Projekt jest objęty licencją GNU GPL v3 (zobacz [LICENSE](LICENSE)).
|
||||
Projekt jest objęty licencją GNU GPL v3 (zobacz [LICENSE](LICENSE)).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,340 @@
|
|||
# VP-Digi - documentation
|
||||
Copyright 2023 Piotr Wilkoń\
|
||||
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is available under [LICENSE_FDL](LICENSE_FDL).\
|
||||
The changelog is placed at the bottom of this document.
|
||||
## Table of contents
|
||||
- [VP-Digi - documentation](#vp-digi---documentation)
|
||||
- [Table of contents](#table-of-contents)
|
||||
- [1. Functional description](#1-functional-description)
|
||||
- [2. User manual](#2-user-manual)
|
||||
- [2.1. Configuration mode](#21-configuration-mode)
|
||||
- [2.1.1. Commands](#211-commands)
|
||||
- [2.1.2. Example configuration](#212-example-configuration)
|
||||
- [2.2. Monitor mode](#22-monitor-mode)
|
||||
- [2.2.1. Commands](#221-commands)
|
||||
- [2.2.2. Received packet view](#222-received-packet-view)
|
||||
- [2.3. KISS mode](#23-kiss-mode)
|
||||
- [2.4. Signal level setting](#24-signal-level-setting)
|
||||
- [2.5. Programming](#25-programming)
|
||||
- [2.5.1. Programming using an ST-Link programmer](#251-programming-using-an-st-link-programmer)
|
||||
- [2.5.2. Programming using a USB-UART adapter](#252-programming-using-a-usb-uart-adapter)
|
||||
- [2.6. Initialization](#26-initialization)
|
||||
- [3. Technical description](#3-technical-description)
|
||||
- [3.1. Hardware](#31-hardware)
|
||||
- [3.1.1. Reception](#311-reception)
|
||||
- [3.1.2. Transmission](#312-transmission)
|
||||
- [3.2. Software](#32-software)
|
||||
- [3.2.1. Modem](#321-modem)
|
||||
- [3.2.1.1. Demodulation](#3211-demodulation)
|
||||
- [3.2.1.2. Modulation](#3212-modulation)
|
||||
- [3.2.1.3. Bit recovery](#3213-bit-recovery)
|
||||
- [3.2.2. Protocols](#322-protocols)
|
||||
- [3.2.2.1. Reception](#3221-reception)
|
||||
- [3.2.2.2. Transmission](#3222-transmission)
|
||||
- [3.2.3. Digipeater](#323-digipeater)
|
||||
- [4. Documentation changelog](#4-documentation-changelog)
|
||||
- [2023/09/06](#20230906)
|
||||
|
||||
## 1. Functional description
|
||||
VP-Digi is a standalone AX.25 digipeater controller (e.g., APRS) and a KISS TNC controller. The software is equipped with the following modems:
|
||||
- Bell 202 AFSK 1200 Bd 1200/2200 Hz (VHF standard)
|
||||
- G3RUH GFSK 9600 Bd (UHF standard)
|
||||
- Bell 103 AFSK 300 Bd 1600/1800 Hz (HF standard)
|
||||
- V.23 AFSK 1200 Bd 1300/2100 Hz (alternative VHF standard)
|
||||
|
||||
Each modem utilizes carrier detection based on detecting the correct modulating signal rather than decoded data, increasing reliability and reducing collisions.
|
||||
|
||||
Furthermore, the software supports the following protocols:
|
||||
- AX.25 (Packet Radio/APRS standard)
|
||||
- FX.25 - AX.25 with error correction, fully compatible with AX.25
|
||||
|
||||
VP-Digi allows configuration of:
|
||||
- Your own callsign, SSID, and destination address
|
||||
- Modem parameters (*TXDelay*, *TXTail*, quiet time, DAC type, receiver type)
|
||||
- Serial port baud rates
|
||||
- 4 digipeater aliases of the *New-N* type (e.g., *WIDEn-N*)
|
||||
- 4 simple digipeater aliases (e.g., *CITY*)
|
||||
- Hop count thresholds for *New-N* type aliases
|
||||
- Enabling tracing for each alias
|
||||
- *Viscous delay* mode and *direct only* mode for each alias
|
||||
- Filtering lists (excluding or including)
|
||||
- Enabling reception of non-APRS packets
|
||||
- Enabling monitoring of own packets through the KISS port
|
||||
|
||||
The device provides:
|
||||
- 2 serial ports
|
||||
- USB port
|
||||
|
||||
Each port operates independently and can function in the following modes:
|
||||
- TNC KISS
|
||||
- Frame monitor
|
||||
- Configuration terminal
|
||||
|
||||
## 2. User manual
|
||||
### 2.1. Configuration mode
|
||||
Device configuration can be done through any port (USB, UART1, UART2). To enter configuration mode, use the `config` command.
|
||||
> Note! If the port is in KISS mode (default after startup), the entered characters will not be visible.
|
||||
|
||||
> Note! After completing the configuration, remember to save it to memory using the `save` command.
|
||||
|
||||
#### 2.1.1. Commands
|
||||
The following commands are available in configuration mode:
|
||||
- `call CALLSIGN-SSID` - sets the callsign along with SSID. The callsign must consist of a maximum of 6 A-Z and 0-9 characters. SSID is optional and must be within the range of 0-15.
|
||||
- `dest ADDRESS` – sets the destination address. The address must consist of a maximum of 6 A-Z and 0-9 characters , without SSID. *APNV01* is the official and recommended address for VP-Digi.
|
||||
- `modem <1200/300/9600/1200_V23>` - sets the modem type: *1200* for 1200 Bd modem, *300* for 300 Bd modem, *9600* for 9600 Bd modem, or *1200_V23* for the alternative 1200 Bd modem.
|
||||
- `txdelay TIME` – sets the preamble length before transmitting a frame. Value in milliseconds, ranging from 30 to 2550.
|
||||
- `txtail TIME` – sets the tail length after a frame transmission. Value in milliseconds, ranging from 10 to 2550. Set to the minimum value if not needed.
|
||||
- `quiet TIME` – sets the time that must elapse between channel release and transmission start. Value in milliseconds, ranging from 100 to 2550.
|
||||
- `rs1baud BAUDRATE` – sets the baud rate for UART1 port. Value ranging from 1200 to 115200.
|
||||
- `rs2baud BAUDRATE` – sets the baud rate for UART2 port. Value ranging from 1200 to 115200.
|
||||
- `pwm <on/off>` – sets the DAC type. *on* when a PWM filter is installed, *off* when an R2R ladder is installed. Starting from version 2.0.0, it is recommended to use only PWM.
|
||||
- `flat <on/off>` – configures the modem for use with a radio with *flat audio* output. *on* when the signal is fed from the *flat audio* connector, *off* when the signal is fed from the headphone jack. This option only affects 1200 Bd modems.
|
||||
- `beacon NUMBER <on/off>` – *on* activates, *off* deactivates the beacon with the specified number, ranging from 0 to 7.
|
||||
- `beacon NUMBER iv TIME` – sets the beacon transmission interval (in minutes) for the beacon with the specified number, ranging from 0 to 7.
|
||||
- `beacon NUMBER dl TIME` – sets the delay/offset for beacon transmission (in minutes) for the beacon with the specified number, ranging from 0 to 7.
|
||||
- `beacon NUMBER path PATHn-N[,PATHn-N]/none` – sets the beacon path for the beacon with the specified number, ranging from 0 to 7. The command accepts one (e.g., *WIDE2-2*) or two (e.g., *WIDE2-2,MA3-3*) path elements or the *none* option for no path.
|
||||
- `beacon NUMBER data CONTENT` – sets the content of the beacon with the specified number, ranging from 0 to 7.
|
||||
- `digi <on/off>` – *on* enables, *off* disables the digipeater.
|
||||
- `digi NUMBER <on/off>` – *on* enables, *off* disables the handling of the alias with the specified number, ranging from 0 to 7.
|
||||
- `digi NUMBER alias ALIAS` – sets an alias with the specified number, ranging from 0 to 7. For slots 0-3 (type *n-N*), it accepts up to 5 characters without SSID, and for slots 4-7 (simple aliases), it accepts aliases in the form of callsigns with SSID or without.
|
||||
- `digi NUMBER max N` – sets the maximum *n* (ranging from 1 to 7) for normal repeating of *n-N* type aliases (ranging from 0 to 3).
|
||||
- `digi NUMBER rep N` – sets the minimum *n* (ranging from 0 to 7) from which *n-N* type aliases (ranging from 0 to 3) will be processed as simple aliases. Setting *N* to 0 disables this feature.
|
||||
- `digi NUMBER trac <on/off>` – sets the selected alias (ranging from 0 to 7) as traceable (*on*) or non-traceable (*off*).
|
||||
- `digi NUMBER viscous <on/off>` – *on* enables, *off* disables the *viscous delay* function for the alias with the specified number, ranging from 0 to 7.
|
||||
- `digi NUMBER direct <on/off>` – *on* enables, *off* disables the function of repeating only frames received directly for the alias with the specified number, ranging from 0 to 7.
|
||||
> The operation of the digipeater is described in [section 3.2.3](#323-digipeater).
|
||||
- `digi NUMBER filter <on/off>` – *on* enables, *off* disables frame filtering for the alias with the specified number, ranging from 0 to 7.
|
||||
- `digi filter <black/white>` – sets the type of frame filtering list: *black* (exclusion - frames from characters on the list will not be repeated) or *white* (inclusion - only frames from characters on the list will be repeated).
|
||||
- `digi dupe TIME` – sets the duplicate filtering buffer time, preventing multiple repetitions of a previously repeated packet. Time in seconds, ranging from 5 to 255.
|
||||
- `digi list POSITION set CALLSIGN-SSID` – enters a call sign into the selected position (ranging from 0 to 19) of the filtering list. You can use \* to mask all characters to the end of the call sign. *?* masks a single letter in the call sign. To mask the SSID, you can use \* or *?*.
|
||||
- `digi list POSITION remove` – removes the selected position (ranging from 0 to 19) from the filtering list.
|
||||
- `monkiss <on/off>` – *on* enables, *off* disables sending own and repeated frames to KISS ports.
|
||||
- `nonaprs <on/off>` – *on* enables, *off* disables the reception of non-APRS packets (e.g., for Packet Radio).
|
||||
- `fx25 <on/off>` - *on* enables, *off* disables FX.25 protocol support. When enabled, both AX.25 and FX.25 packets will be received simultaneously.
|
||||
- `fx25tx <on/off>` - *on* enables, *off* disables transmission using the FX.25 protocol. If FX.25 support is completely disabled (command *fx25 off*), packets will always be transmitted using AX.25.
|
||||
|
||||
Additionally, there are control commands available:
|
||||
- `print` – displays the current settings.
|
||||
- `list` – displays the contents of the filtering list.
|
||||
- `save` – saves the settings to memory and restarts the device. Always use this command after completing configuration. Otherwise, unsaved configuration will be discarded.
|
||||
- `eraseall` – clears the entire configuration and restarts the device.
|
||||
|
||||
Common commands are also available:
|
||||
- `help` – displays the help page.
|
||||
- `reboot` – restarts the device.
|
||||
- `version` – displays software version information.
|
||||
- `monitor` – switches the port to monitor mode.
|
||||
- `kiss` – switches the port to KISS mode.
|
||||
|
||||
|
||||
#### 2.1.2. Example configuration
|
||||
|
||||
- Beacon\
|
||||
Example for beacon number 0. Beacons are available from 0 to 7.
|
||||
1. *beacon 0 data !5002.63N/02157.91E#Digi Rzeszow* – setting APRS standard beacon data
|
||||
2. *beacon 0 path WIDE2-2,SP2-2* – setting the path
|
||||
3. *beacon 0 iv 15* – transmitting every 15 minutes
|
||||
4. *beacon 0 dl 5* – the beacon will be transmitted for the first time after 5 minutes from device startup
|
||||
5. *beacon 0 on* – enabling the beacon
|
||||
- Fill-in WIDE1-1 digipeater\
|
||||
Example for alias number 0. Alias numbers range from 0 to 3.
|
||||
1. *digi 0 alias WIDE* – repeating WIDEn-N type aliases. Numbers n and N are NOT set here.
|
||||
2. *digi 0 max 1* – repeating paths up to a maximum of WIDE1-1
|
||||
3. *digi 0 rep 0* – disabling path limiting and simplification
|
||||
4. *digi 0 trac on* – enabling path tracing (WIDEn-N paths are traced)
|
||||
5. *digi 0 on* – enabling handling of the alias
|
||||
6. *digi on* – enabling the digipeater
|
||||
|
||||
- Fill-in digipeater with *viscous delay* (recommended configuration)\
|
||||
Example for alias number 0. Alias numbers range from 0 to 3.
|
||||
1. *digi 0 alias WIDE* – repeating WIDEn-N type aliases. Numbers n and N are NOT set here.
|
||||
2. *digi 0 max 2* – repeating paths up to a maximum of WIDE2-2
|
||||
3. *digi 0 rep 3* – WIDE3-3 and longer paths will be simplified when repeated
|
||||
4. *digi 0 trac on* – enabling path tracing (WIDEn-N paths are traced)
|
||||
5. *digi 0 viscous on* – enabling the *viscous delay* mode
|
||||
6. *digi 0 on* – enabling handling of the alias
|
||||
7. *digi on* – enabling the digipeater
|
||||
|
||||
- Regional WIDEn-N + MAn-N digipeaters (recommended configuration)\
|
||||
Examples for aliases 0 (for WIDE) and 1 (for MA).
|
||||
1. *digi 0 alias WIDE* – repeating WIDEn-N type aliases. Numbers n and N are NOT set here.
|
||||
2. *digi 0 max 2* – repeating paths up to a maximum of WIDE2-2
|
||||
3. *digi 0 rep 3* – WIDE3-3 and longer paths will be simplified when repeated
|
||||
4. *digi 0 trac on* – enabling path tracing (WIDEn-N paths are traced)
|
||||
5. *digi 0 on* – enabling handling of the alias
|
||||
6. *digi 1 alias MA* – repeating MAn-N type aliases. Numbers n and N are NOT set here.
|
||||
7. *digi 1 max 7* – repeating paths up to a maximum of SP7-7
|
||||
8. *digi 1 rep 0* – no path hop limiting
|
||||
9. *digi 1 trac off* – disabling path tracing (regional paths are not traced)
|
||||
10. *digi 1 on* – enabling handling of the alias
|
||||
11. *digi on* – enabling the digipeater
|
||||
|
||||
|
||||
### 2.2. Monitor mode
|
||||
|
||||
Device operation can be observed through any port (USB, UART1, UART2). Switching to monitor mode is done by issuing the `monitor` command.
|
||||
> Note! If the port is in KISS mode (default after startup), entered characters will not be visible.
|
||||
|
||||
In monitor mode, received and transmitted packets are displayed, and it is also possible to perform signal level calibration.
|
||||
|
||||
#### 2.2.1. Commands
|
||||
|
||||
The following commands are available:
|
||||
|
||||
- `beacon NUMBER` - transmits a beacon from 0 to 7 if that beacon is enabled.
|
||||
- `cal <low/high/alt/stop>` - starts or stops calibration mode: *low* transmits a low tone, *high* transmits a high tone, *alt* transmits zero bytes/alternating tones, and *stop* stops transmission. For the 9600 Bd modem, zero bytes are always transmitted.
|
||||
|
||||
Common commands are also available:
|
||||
|
||||
- `help` – displays the help page.
|
||||
- `reboot` – restarts the device.
|
||||
- `version` – displays software version information.
|
||||
- `config` – switches the port to configuration mode.
|
||||
- `kiss` – switches the port to KISS mode.
|
||||
|
||||
#### 2.2.2. Received packet view
|
||||
|
||||
For each received AX.25 packet, the header is displayed in the following format:
|
||||
> Frame received [...], signal level XX% (HH%/LL%)
|
||||
>
|
||||
For each received FX.25 packet, the format is as follows:
|
||||
> Frame received [...], N bytes fixed, signal level XX% (HH%/LL%)
|
||||
|
||||
Where:
|
||||
- *...* specifies which modems received the packet and what type of filter was used. The following statuses are possible:
|
||||
- *P* - high tone pre-emphasis filter
|
||||
- *D* - high tone de-emphasis filter
|
||||
- *F* - flat filter
|
||||
- *N* - no filter
|
||||
- *_* - modem did not receive the frame\
|
||||
For example, the status *[_P]* indicates that the first modem did not receive the frame, and the second modem received the frame and uses a pre-emphasis filter. Another example status *[N]* means that only one modem without a filter is available, and it received the frame.
|
||||
- *N* specifies how many bytes were fixed by the FX.25 protocol. This field is not displayed for AX.25 packets.
|
||||
- *XX%* indicates the signal level, i.e., its amplitude.
|
||||
- *HH%* indicates the level of the upper peak of the signal.
|
||||
- *LL%* indicates the level of the lower peak of the signal.
|
||||
> Note! The level of the upper peak should be positive, and the level of the lower peak should be negative. Furthermore, these levels should be symmetrical with respect to zero. A large imbalance indicates incorrect polarization of the ADC input.
|
||||
|
||||
|
||||
### 2.3. KISS mode
|
||||
KISS mode is used for working as a standard TNC KISS, compatible with many Packet Radio, APRS, and similar programs. In this mode, there is no echo (typed characters are not displayed). The available commands for switching modes are:
|
||||
- `monitor` – switches the port to monitor mode
|
||||
- `config` – switches the port to configuration mode
|
||||
|
||||
### 2.4. Signal level setting
|
||||
After device startup, you should enter monitor mode (using the `monitor` command) and wait for packets to appear. You should adjust the signal level so that most packets have a signal level of around 50% (as described in [section 2.2.2](#222-received-packet-view)). The received signal level should be maintained within the range of 10-90%.
|
||||
To ensure the best network performance, the transmitted signal level should also be properly set. This is especially important for the 1200 Bd modem, where the signal is transmitted through the standard microphone connector of an FM radio. Excessive signal levels can lead to distortion and significant tone amplitude imbalances.
|
||||
Signal calibration requires an FM receiver tuned to the same frequency as the transmitter. You should enter monitor mode (using the `monitor` command) and enable high tone transmission (using the `cal high` command). You should set the potentiometer to the minimum amplitude level position and then slowly increase the level while carefully monitoring the signal strength in the receiver, which should increase. At some point, the signal level will stop increasing. At that point, gently retract the potentiometer and turn off the calibration mode (using the `cal stop` command). After this operation, the transmitter should be correctly driven.
|
||||
> Note! If you fail to reach the point where the signal level stops increasing, the resistor value in the TX path is probably too high. If the signal level is clearly too low, reduce the value of this resistor. Otherwise, no action is necessary.
|
||||
|
||||
### 2.5. Programming
|
||||
Programming (flashing firmware) can be done in two ways: using an ST-Link programmer or through the UART1 serial port (e.g., using a USB-UART adapter).
|
||||
In both methods, you need to download the VP-Digi software (HEX file) beforehand.
|
||||
|
||||
#### 2.5.1. Programming using an ST-Link programmer
|
||||
1. Download and install the *ST-Link Utility* program along with the appropriate drivers.
|
||||
2. Connect VP-Digi to the programmer.
|
||||
3. Connect the programmer to the USB port.
|
||||
4. In *ST-Link Utility*, go to *File->Open file* and select the downloaded HEX file with the firmware.
|
||||
5. Go to *Target->Program & Verify* and click *Start*. After a while, the device will restart, and the actual software will start.
|
||||
|
||||
#### 2.5.2. Programming using a USB-UART adapter
|
||||
1. Ensure that the adapter works with logic levels of 0/3.3V.
|
||||
2. If necessary, install drivers for the adapter.
|
||||
3. Download and install the *Flasher-STM32* program.
|
||||
4. On the board, set the jumper closer to the reset button to position 0, and the one farther away to 1.
|
||||
5. Connect the *TX* pin of the adapter to the *PA10* pin and *RX* to *PA9*. Connect power (e.g., from the adapter).
|
||||
6. Determine which COM port the adapter is available on.
|
||||
7. Start *Flasher-STM32*, select the appropriate COM port, and click *Next*.
|
||||
> If an error occurs, reset the microcontroller and check the connections and jumper settings.
|
||||
8. On the next screen, click *Next*.
|
||||
9. On the following screen, select the option *Download to device* and choose the downloaded HEX file.
|
||||
10. Check the options *Erase necessary pages* and *Verify after download*, then click *Next*. After a moment, the device should be programmed. Revert both jumpers to position 0, reset the microcontroller, and disconnect the adapter. The proper software should start running.
|
||||
|
||||
### 2.6. Initialization
|
||||
To use the device, you should assemble it according to the schematic presented in [section 3.1](#31-hardware) and program it (description in [section 2.5](#25-programming)).
|
||||
After startup, all ports (USB, UART1, UART2) operate in KISS mode, and the baud rate for UART1 and UART2 ports is 9600 Bd (the USB port's speed doesn't matter).
|
||||
To configure VP-Digi or monitor frames, you need to connect it to a computer via the USB or UART port and install a terminal program (*TeraTerm*, *RealTerm*, etc.). As mentioned in the preceding sections, switching to configuration and monitor mode is done by entering the commands `config` and `monitor` respectively and confirming with the Enter key.
|
||||
> In KISS mode, echo (displaying entered characters) is disabled, so you won't see the entered commands.
|
||||
|
||||
Device configuration should be carried out using the commands described in [section 2.1](#21-configuration-mode).
|
||||
|
||||
|
||||
## 3. Technical description
|
||||
### 3.1. Hardware
|
||||
VP-Digi natively operates on the STM32F103C8T6 microcontroller with a core frequency of 72 MHz, requiring an external 8 MHz resonator. It is recommended to build the device using the *STM32 Blue Pill* board.
|
||||
|
||||
The construction of VP-Digi based on the *STM32 Blue Pill* board is presented in the schematic:
|
||||
|
||||
|
||||
#### 3.1.1. Reception
|
||||
The received signal is provided to pin *PA0* using decoupling capacitors (*C4*, *C6*), polarizing resistors (*R6*, *R9*), and limiting resistors (*R7*, *R11*). To ensure proper reception of FSK modulation, capacitors with relatively large capacitance values must be used. To achieve correct reception, the DC voltage at pin *PA0* should be around half of the supply voltage, i.e., 1.65 V. Incorrect polarization manifests as asymmetry in the signal level (see [section 2.2.2](#222-received-packet-view)) or loss of reception.
|
||||
In the receiving path, a serial resistor *R7* is used to limit the maximum pin current. This is done to protect the converter from damage caused by excessive signal levels using the microcontroller's built-in diodes as a voltage limiter.
|
||||
If the transceiver has an adjustable output signal level, the installation of components *RV2*, *R11*, and *C6* is not necessary.
|
||||
|
||||
#### 3.1.2. Transmission
|
||||
The transmitted signal can be generated using PWM or R2R (not recommended from version 2.0.0 onwards) converter. PWM conversion utilizes hardware pulse width modulation and a second-order RC filter (*R5*, *C3*, *R3*, *C2*) to filter out unwanted components. The filter consists of two first-order RC filters with a cutoff frequency of approximately 7200 Hz to ensure an adequate passband for the 9600 Bd modem. Furthermore, for proper FSK modulation, a decoupling capacitor *C1* with a relatively large capacitance must be used.
|
||||
Resistor *R2* is used to significantly reduce the signal amplitude when using a standard microphone input with high gain. The value of this resistor should be selected individually.
|
||||
The transceiver is switched to the transmission state by applying a low state through the NPN transistor *Q1*. If the transceiver has a PTT input, it should be connected directly to the collector of the transistor, and resistor *R1* should not be installed. For standard transceivers with a microphone input, resistor *R1* should be installed.
|
||||
|
||||
|
||||
### 3.2. Software
|
||||
VP-Digi's software is written in the C language using standard CMSIS libraries and ST headers for the microcontroller, with register-level operations. The HAL library is used only for USB support and configuring clock signals.
|
||||
|
||||
#### 3.2.1. Modem
|
||||
##### 3.2.1.1. Demodulation
|
||||
Receiving frames begins with sampling the input signal. The input signal is oversampled four times, resulting in a sampling rate of 153600 Hz for the 9600 Bd modem and 38400 Hz for the other modems. After receiving four samples, they are decimated and sent for further processing (resulting in frequencies of 38400 Hz and 9600 Hz, respectively). For the 1200 Bd modem, 8 samples per symbol are used, for the 300 Bd modem, 32 samples per symbol, and for the 9600 Bd modem, 4 samples per symbol are used. The signal's amplitude is tracked using a mechanism similar to AGC. If the modem has a pre-filter, the samples are filtered. For AFSK modems, the current sample and the previous sample are multiplied with signal of the numerical generator at frequencies corresponding to the *mark* and *space* frequencies (correlation is calculated, which corresponds to discrete frequency demodulation). The results of multiplication in each path are summed, and then the results are subtracted from each other, yielding a *soft* symbol. For the (G)FSK modem, this step does not occur because the FM (FSK) demodulation function is performed by the transceiver. At this stage, carrier detection is performed, based on a simple digital PLL. This loop nominally operates at a frequency equal to the symbol rate of the signal (e.g., 1200 Hz = 1200 Bd). When a change in the *soft* symbol is detected, the distance from the PLL counter zero crossing is checked. If it is small, indicating that the signals are in phase, the input signal is likely correct. In this case, an additional counter is increased. If it exceeds a set threshold, the signal is finally considered correct. The algorithm also works in the reverse direction: if the signals are out of phase, the counter value is decreased. The demodulated signal (*soft symbol*) is filtered by a low-pass filter (appropriate for the symbol rate) to remove noise, and then the symbol value is determined and sent to the bit recovery mechanism.
|
||||
|
||||
##### 3.2.1.2. Modulation
|
||||
The AFSK modulator is based on outputting samples of a sinusoidal signal generated at startup to the digital-to-analog converter. Depending on the symbol frequency, the sample output frequency is changed, i.e., for an array with length *N* and signal frequency *f*, successive samples are output at a frequency of *f/N*. During signal generation, continuity of the array indices is maintained, resulting in phase preservation.
|
||||
|
||||
For the GFSK modem, symbols from the higher layer (square wave) are filtered by a low-pass filter (common for both demodulator and modulator) and output at a constant frequency of 38400 Hz to the converter.
|
||||
|
||||
##### 3.2.1.3. Bit recovery
|
||||
Bit recovery is performed by the modem. A digital PLL (similar to carrier detection) operating at the symbol frequency is used. At the end of each full period, the final symbol value is determined based on several previously received symbols. At the same time, the loop phase is adjusted to the signal phase, i.e., to the moments of symbol changes. For modems using bit scrambling (e.g., G3RUH modem), descrambling is performed. Finally, NRZI decoding is executed, and the bits are passed to the higher layer.
|
||||
|
||||
#### 3.2.2. Protocols
|
||||
##### 3.2.2.1. Reception
|
||||
The HDLC, AX.25, and FX.25 protocols are handled by a single module that functions as a big state machine. Received bits are continuously written to a shift register. This register is monitored for the presence of the HDLC flag to detect the beginning and end of an AX.25 frame, as well as for bit synchronization with the transmitter (i.e., alignment to a full byte). When FX.25 reception is enabled, the occurrence of any of the correlation tags is simultaneously monitored, which also serves as a synchronization marker and the beginning of an FX.25 frame. Received bits are written to a buffer, and the checksum is calculated in real-time. An important moment is the reception of the first eight data bytes, during which it is not known whether it is an FX.25 frame or not. Therefore, both protocol decoders work simultaneously during this time. If the correlation tag does not match any known tags, the frame is treated as an AX.25 packet. In this case, bits are written until the next flag is encountered. Subsequently, if only APRS packet reception is allowed, the Control and PID fields are checked. Finally, the checksum is verified. If it is correct, modem multiplexing is performed (in case more than one modem receives the same packet). If the correlation tag is valid, its expected packet length is determined based on it, and all bytes are written until that length is reached. Then, data correctness is checked, and any necessary fixes are made using the Reed-Solomon algorithm. Regardless of the operation's result, the raw frame is decoded as an AX.25 packet (additional bits and flags are removed), and the checksum is verified. If it is correct, modem multiplexing is similarly performed.
|
||||
|
||||
##### 3.2.2.2. Transmission
|
||||
Similar to reception, the bit generation module for transmission is a state machine. Initially, a preamble of a specified length is transmitted. When the AX.25 protocol is used, a certain number of flags are transmitted, followed by data bits. Bit stuffing and checksum calculation are performed in real-time, and the checksum is appended after the entire frame is transmitted. A specified number of flags is transmitted, and if there are more packets to be sent, the actual data is sent immediately. Finally, a tail of a specified length is transmitted, concluding the transmission.
|
||||
|
||||
For FX.25, the input packet is previously encoded as an AX.25 packet, i.e., additional bits, flags and CRC are added, and it is placed in a separate buffer. This allows receivers that do not support FX.25 to still receive this packet. The remaining part of the buffer is filled with the appropriate bytes. Then, Reed-Solomon encoding is performed, which inserts parity bytes into the buffer. When transmission begins, a preamble is sent, followed by the appropriately selected correlation tag. Then, the previously prepared frame is transmitted. If there are more packets to be sent, the process is repeated. Finally, a tail is transmitted, concluding the transmission.
|
||||
|
||||
#### 3.2.3. Digipeater
|
||||
After receiving a packet, its hash is calculated (CRC32 algorithm). Then, the occurrence of the same hash is checked in the *viscous delay* buffer. If the hashes match, the packet is removed from the buffer, and no further action is taken. Similarly, the occurrence of the same hash is checked in the duplicate filter buffer. If the hashes match, the packet is immediately discarded. Next, the *H-bit* is searched in the path, indicating the last element of the path processed by other digipeaters. If there is no next element ready for processing, the packet is discarded. If there is a ready-to-process element, the following steps are taken:
|
||||
- The element is compared to digipeater's own call sign (i.e., whether the own call sign appears explicitly in the path). If the comparison is successful, only the *H-bit* is added to the element, e.g., *SR8XXX* becomes *SR8XXX\**.
|
||||
- The element is similarly compared to all simple aliases entered in the configuration (if they are enabled). If the comparison is successful:
|
||||
- If the alias is traced, it is replaced with the own call sign, and an *H-bit* is added (e.g., *RZ* becomes *SR8XXX\**).
|
||||
- If the alias is untraced, only the *H-bit* is added (e.g., *RZ* becomes *RZ\**).
|
||||
|
||||
The first part of the element is compared to all *New-N* aliases (if they are enabled). If the comparison is successful, the *n* number is extracted, and the SSID called *N* is saved (e.g., in the path *WIDE2-1*, *n* is 2, and *N* is 1). Initially, the path's validity conditions are checked, i.e., whether 0 < *n* < 8, 0 <= *N* < 8, and *N* <= *n*. If any of the conditions are not met, the packet is discarded. Examples of invalid paths include:
|
||||
- *WIDE8-1*
|
||||
- *WIDE1-2*
|
||||
- *WIDE0-3*
|
||||
- *WIDE2-8*
|
||||
- and many others
|
||||
|
||||
Simultaneously, if in the element *N* = 0, the path is exhausted, and the packet is discarded. Then, *n* is compared to the configured values of *max* and *rep*. If *max* < *n* < *rep* (the number is not within any of the ranges), the packet is discarded. If the path is traced, then if:
|
||||
- *n* <= *max* and *N* > 1, e.g., *WIDE2-2*, the call sign of the digipeater with the *H-bit* is added before the element, and *N* is reduced by 1, e.g., *SR8XXX\*,WIDE2-1*.
|
||||
- *n* <= *max* and *N* = 1, e.g., *WIDE2-1*, the call sign of the digipeater with the *H-bit* is added before the element, *N* is reduced by 1 (becoming zero), and the *H-bit* is added, e.g., *SR8XXX\*,WIDE2\**.
|
||||
- *n* >= *rep* (if *rep* > 0), e.g., *WIDE7-4*, the element is replaced with the call sign of the digipeater with the *H-bit*, e.g., *SR8XXX\** (limiting the path). The value of *N* is not considered.
|
||||
|
||||
If the path is untraced, then if:
|
||||
- *n* <= *max* and 1 < *N* < *n*, e.g., *SP3-2*, *N* is reduced by 1, e.g., *SP3-1*.
|
||||
- *n* <= *max* and *N* = *n*, and it is not the first element in the entire path, e.g., *...,SP3-3*, *N* is reduced by 1, e.g., *...,SP3-2* (behavior identical to before).
|
||||
- *n* <= *max* and *N* = *n*, and it is the first element in the entire path (the first hop of the packet), e.g., *SP3-3*, the path is treated as traced, i.e., the call sign of the digipeater with the *H-bit* is added before the element, and *N* is reduced by 1, e.g., *SR8XXX\*,SP3-2*.
|
||||
- *n* <= *max* and *N* = 1, e.g., *SP3-1*, *N* is reduced by 1 (becoming zero), and the *H-bit* is added, e.g., *SP3\**.
|
||||
- *n* >= *rep* (if *rep* > 0), e.g., *SP7-4*, the element is replaced with the call sign of the digipeater with the *H-bit*, e.g., *SR8XXX\** (limiting the path). The value of *N* is not considered.
|
||||
|
||||
> Note! If *max* and *rep* values create overlapping intervals (*max* >= *rep*), the *max* value is given priority.
|
||||
|
||||
> Note! If *rep* = 0, the path limiting functionality is disabled.
|
||||
|
||||
If *direct only* functionality (repeating only packets received directly) is enabled for the matched alias, and the element is not the first element in the entire path or *N* < *n*, the packet is discarded.
|
||||
If *viscous delay* functionality is enabled for the matched alias, the completed packet is stored in a buffer, and its transmission is delayed. If the same packet is repeated by another digipeater within a specified time, the buffered packet is removed (see *the beginning of this section*). If none of these functions is enabled, the hash of the packet is saved to the duplicate filter buffer, and the packet is transmitted.
|
||||
In addition, the *viscous delay* buffer is regularly refreshed. If the specified time has passed, and the packet has not been removed from the buffer (see *the beginning of this section*), its hash is saved to the duplicate filter buffer, the packet is transmitted, and removed from the *viscous delay* buffer.
|
||||
|
||||
## 4. Documentation changelog
|
||||
### 2023/09/06
|
||||
- First version - Piotr Wilkoń
|
||||
|
|
@ -109,7 +109,7 @@ W trybie konfiguracji dostępne są następujące polecenia:
|
|||
- `digi NUMER filter <on/off>` – *on* włącza, *off* wyłącza filtrowanie ramek dla aliasu z zakresu od 0 do 7.
|
||||
- `digi filter <black/white>` – ustawia typ listy filtrującej ramki: *black* (wykluczenie - ramki od znaków z listy nie będą powtarzane) lub *white* (wyłączność – tylko ramki od znaków z listy będą powtarzane).
|
||||
- `digi dupe CZAS` – ustawia czas bufora filtrującego duplikaty, który zapobiega wielokrotnemu powtarzaniu już powtórzonego pakietu. Czas w sekundach z zakresu od 5 do 255.
|
||||
- `digi list POZYCJA set ZNAK-SSID` – wpisuje znak na wybraną pozycję (z zakresu od 0 do 19) listy filtrującej. Można używać znaku * do zamaskowania wszystkich liter do końca znaku. *?* maskuje pojedynczą literę w znaku. Do zamaskowania SSID można użyć * lub *?*.
|
||||
- `digi list POZYCJA set ZNAK-SSID` – wpisuje znak na wybraną pozycję (z zakresu od 0 do 19) listy filtrującej. Można używać znaku \* do zamaskowania wszystkich liter do końca znaku. *?* maskuje pojedynczą literę w znaku. Do zamaskowania SSID można użyć \* lub *?*.
|
||||
- `digi list POZYCJA remove` – usuwa wybraną pozycję (z zakresu od 0 do 19) z listy filtrującej
|
||||
- `monkiss <on/off>` – *on* włącza, *off* wyłącza wysyłanie własnych i powtórzonych ramek na porty KISS
|
||||
- `nonaprs <on/off>` – *on* włącza, *off* wyłącza odbiór pakietów niebędących pakietami APRS (np. dla Packet Radio)
|
||||
|
|
@ -284,7 +284,7 @@ Protokoły HDLC, AX.25 i w dużej mierze FX.25 obsługiwane są przez jeden modu
|
|||
Odebrane bity są na bieżąco zapisywane w rejestrze przesuwnym. Rejestr ten monitorowany jest pod kątem wystąpenia flagi HDLC w celu wykrycia początku i końca ramki AX.25, ale również synchronizacji bitowej z nadajnikiem (tzn. wyrównania do pełnego bajtu). Gdy włączony jest odbiór FX.25, to równoczeście monitorowane jest wystąpienie któregoś z tagów korelacyjnych, który również pełni funkcję synchronizacyjną i początku ramki, ale tym razem FX.25. Odbierane bity są zapisywane do bufora, a suma kontrolna jest na bieżąco liczona. Istotnym momentem jest odbiór pierwszych ośmiu bajtów danych, podczas których nie wiadomo, czy jest to ramka FX.25, czy nie, więc wówczas dekodery obydwu protokołów pracują równocześnie. Jeśli tag korelacyjny nie pokrywa się z żadnym znanym, to ramka traktowana jest jako pakiet AX.25. Wówczas bity zapisywane są aż do momentu wystąpienia kolejnej flagi. Następnie, jeśli dozwolony jest wyłącznie odbiór pakietów APRS, sprawdzane są pola Control i PID. Ostatecznie sprawdzana jest suma kontrolna. Jeśli jest prawidłowa, to dokonywana jest multipleksacja modemów (w wypadku gdy więcej niż jeden modem odbierze ten sam pakiet). W przypadku, gdy tag korelacyjny jest prawidłowy, to na jego podstawie określana jest oczekiwana długość pakietu i zapisywane są wszystkie bajty aż do osiągnięcia tej długości. Następnie sprawdzana jest poprawność danych i ewentualna naprawa z użyciem algorytmu Reeda-Solomona. Niezależnie od wyniku operacji surowa ramka jest dekodowana jak pakiet AX.25 (usuwane są dodatkowe bity, flagi) i sprawdzana jest suma kontrolna. Jeśli jest prawidłowa, to podobnie dokonywana jest multipleksacja modemów.
|
||||
##### 3.2.2.2. Nadawanie
|
||||
Podobnie jak w przypadku odbioru moduł generujący bity do nadania jest maszyną stanów. Początkowo nadawana jest preambuła o zadanej długości. Gdy używany jest protokół AX.25, to nadawana jest określona ilość flag i nadawane są bity informacyjne. Na bieżąco realizowane jest nadziewanie bitami (*bit stuffing*) i liczenie sumy kontrolnej, która jest dołączana po nadaniu całej ramki. Następuje nadanie określonej liczby flag, i jeżeli są kolejne pakiety do nadania, to od razu następuje przejście do nadania właściwych danych. Ostatecznie nadawany jest ogon o zadanej długości i transmisja kończy się.\
|
||||
W przypadku FX.25 pakiet wejściowy jest wcześniej kodowany jak pakiet AX.25, tzn. zostają dodane dodatkowe bity i flagi i jest umieszczany w oddzielnym buforze. Dzięki temu odbiorniki nieobsługujące FX.25 nadal będą mogły odebrać ten pakiet. Pozostała część bufora zostaje wypełniona odpowiednimi bajtami. Następnie wykonywane jest kodowanie Reeda-Solomona, które wprowadza do bufora bajty parzystości. Gdy rozpoczyna się transmisja, nadana zostaja preambuła, ale po niej nadawany jest odpowiednio dobrany tag korelacyjny. Wówczas następuje nadanie wcześniej przygotowanej ramki. Jeśli są do nadania kolejne pakiety, to proces się powtarza. Ostatecznie nadawany jest ogon i transmisja kończy się.
|
||||
W przypadku FX.25 pakiet wejściowy jest wcześniej kodowany jak pakiet AX.25, tzn. zostają dodane dodatkowe bity, flagi, CRC i pakiet jest umieszczany w oddzielnym buforze. Dzięki temu odbiorniki nieobsługujące FX.25 nadal będą mogły odebrać ten pakiet. Pozostała część bufora zostaje wypełniona odpowiednimi bajtami. Następnie wykonywane jest kodowanie Reeda-Solomona, które wprowadza do bufora bajty parzystości. Gdy rozpoczyna się transmisja, nadana zostaja preambuła, ale po niej nadawany jest odpowiednio dobrany tag korelacyjny. Wówczas następuje nadanie wcześniej przygotowanej ramki. Jeśli są do nadania kolejne pakiety, to proces się powtarza. Ostatecznie nadawany jest ogon i transmisja kończy się.
|
||||
#### 3.2.3. Digipeater
|
||||
Po odebraniu pakietu liczony jest jego hasz (algorytm CRC32). Następnie sprawdzane jest wystąpienie takiego samego haszu w buforze *viscous delay*. Jeśli hasze są takie same, to pakiet jest usuwany z bufora i nie są podejmowane żadne dalsze działania. Podobnie sprawdzane jest wystąpienie takiego samego haszu w buforze filtra duplikatów. Jeśli hasze są takie same, to pakiet jest od razu odrzucany. Następnie w ścieżce wyszukiwany jest *H-bit*, informujący o ostatnim elemencie ścieżki przetworzonym przez inne digipeatery. Jeśli nie ma kolejnego elementu gotowego do przetworzenia, to pakiet jest odrzucany. Jeśli występuje element gotowy do przetworzenia, to podejmowane są kroki:
|
||||
- element porównywany jest z własnym znakiem (tj. czy własny znak występuje *explicite* w ścieżce). Jeśli porównanie jest pomyślne, to do elementu dodawany jest tylko *H-bit*, np. *SR8XXX* przechodzi w *SR8XXX\**.
|
||||
|
|
@ -300,22 +300,22 @@ Pierwsza cześć elementu jest porówywana z wszystkimi aliasami *New-N* (o ile
|
|||
- i wiele innych
|
||||
|
||||
Jednocześnie jeśli w elemencie *N*=0, to ścieżka jest wyczerpana i pakiet jest odrzucany. Potem *n* porównywana jest z zapisaną wartością *max* oraz *rep*. Jeśli *max*<*n*<*rep* (liczba nie zawiera się w żadnym z ustawionych zakresów), to pakiet jest odrzucany. W przypadku, gdy ścieżka jest trasowana, to jeśli:
|
||||
- *n*<=*max* i *N*>1, np. *WIDE2-2*, to przed elementem dodawany jest znak digipeatera z *H-bitem*, a *N* jest pomniejszane o 1, np. *SR8XXX\*,WIDE2-1*
|
||||
- *n*<=*max* i *N*=1, np. *WIDE2-1*, to przed elementem dodawany jest znak digipeatera z *H-bitem*, *N* jest pomniejszane o 1 (czyli staje się zerem) i dodawany jest *H-bit*, np. *SR8XXX\*,WIDE2\**
|
||||
- *n*>=*rep* (o ile *rep*>0), np. *WIDE7-4*, to element zostaje zastąpiony znakiem digipeatera z *H-bitem*, np. *SR8XXX\** (następuje ograniczenie ścieżki). Wartość *N* nie jest brana pod uwagę.
|
||||
- *n* <= *max* i *N* > 1, np. *WIDE2-2*, to przed elementem dodawany jest znak digipeatera z *H-bitem*, a *N* jest pomniejszane o 1, np. *SR8XXX\*,WIDE2-1*
|
||||
- *n* <= *max* i *N*=1, np. *WIDE2-1*, to przed elementem dodawany jest znak digipeatera z *H-bitem*, *N* jest pomniejszane o 1 (czyli staje się zerem) i dodawany jest *H-bit*, np. *SR8XXX\*,WIDE2\**
|
||||
- *n* >= *rep* (o ile *rep*>0), np. *WIDE7-4*, to element zostaje zastąpiony znakiem digipeatera z *H-bitem*, np. *SR8XXX\** (następuje ograniczenie ścieżki). Wartość *N* nie jest brana pod uwagę.
|
||||
|
||||
W przypadku, gdy ścieżka nie jest trasowana, to jeśli:
|
||||
- *n*<=*max* i 1<*N*<*n*, np. *SP3-2*, to *N* jest pomniejszane o 1, np. *SP3-1*
|
||||
- *n*<=*max* i *N*=*n* i nie jest to pierwszy element całej ścieżki, np. *...,SP3-3*, to *N* jest pomniejszane o 1, np. *...,SP3-2* (zachowanie identyczne jak wcześniej)
|
||||
- *n*<=*max* i *N*=*n* i jest to pierwszy element całej ścieżki (jest to pierwszy skok pakietu), np. *SP3-3*, to ścieżka traktowana jest jak trasowalna, tzn. przed elementem dodawany jest znak digipeatera z *H-bitem*, a *N* jest pomniejszane o 1, np. *SR8XXX\*,SP3-2*
|
||||
- *n*<=*max* i *N*=1, np. *SP3-1*, to *N* jest pomniejszane o 1 (staje się zerem) i dodawany jest *H-bit*, np. *SP3\**
|
||||
- *n*>=*rep* (o ile *rep*>0), np. *SP7-4*, to element zostaje zastąpiony znakiem digipeatera z *H-bitem*, np. *SR8XXX\** (następuje ograniczenie ścieżki). Wartość *N* nie jest brana pod uwagę.
|
||||
- *n* <= *max* i 1 < *N* < *n*, np. *SP3-2*, to *N* jest pomniejszane o 1, np. *SP3-1*
|
||||
- *n* <= *max* i *N* = *n* i nie jest to pierwszy element całej ścieżki, np. *...,SP3-3*, to *N* jest pomniejszane o 1, np. *...,SP3-2* (zachowanie identyczne jak wcześniej)
|
||||
- *n* <= *max* i *N* = *n* i jest to pierwszy element całej ścieżki (jest to pierwszy skok pakietu), np. *SP3-3*, to ścieżka traktowana jest jak trasowalna, tzn. przed elementem dodawany jest znak digipeatera z *H-bitem*, a *N* jest pomniejszane o 1, np. *SR8XXX\*,SP3-2*
|
||||
- *n* <= *max* i *N* = 1, np. *SP3-1*, to *N* jest pomniejszane o 1 (staje się zerem) i dodawany jest *H-bit*, np. *SP3\**
|
||||
- *n* >= *rep* (o ile *rep* > 0), np. *SP7-4*, to element zostaje zastąpiony znakiem digipeatera z *H-bitem*, np. *SR8XXX\** (następuje ograniczenie ścieżki). Wartość *N* nie jest brana pod uwagę.
|
||||
|
||||
> Uwaga! Jeśli wartości *max* i *rep* tworzą zachodzące na siebie przedziały (*max*>=*rep*), to wartość *max* jest traktowana priorytetowo.
|
||||
> Uwaga! Jeśli wartości *max* i *rep* tworzą zachodzące na siebie przedziały (*max* >= *rep*), to wartość *max* jest traktowana priorytetowo.
|
||||
|
||||
> Uwaga! Jeśli *rep*=0, to funkcjonalność ograniczania ścieżki jest wyłączona.
|
||||
|
||||
Jeśli dla dopasowanego aliasu włączona jest funkcja *direct only* (powtarzania wyłącznie pakietów odebranych bezpośrednio), a element nie jest pierwszym elementem w całej ścieżce lub *N*<*n*, to pakiet jest odrzucany.
|
||||
Jeśli dla dopasowanego aliasu włączona jest funkcja *direct only* (powtarzania wyłącznie pakietów odebranych bezpośrednio), a element nie jest pierwszym elementem w całej ścieżce lub *N* < *n*, to pakiet jest odrzucany.
|
||||
Jeśli dla dopasowanego aliasu włączona jest funkcja *viscous delay*, to gotowy pakiet zapisywany jest w buforze, a jego nadanie jest odkładane. Jeśli ten sam pakiet zostanie powtórzony przez inny digipeater w określonym czasie, to zbuforowany pakiet zostanie usunięty (patrz *początek tej sekcji*). Jeśli żadna z tych funkcji nie jest włączona, to do bufora filtra duplikatów zapisywany jest hasz pakietu i pakiet jest wysyłany.\
|
||||
Ponadto regularnie odświeżany jest bufor funkcji *viscous delay*. Jeśli minął odpowiedni czas i pakiet nie został usunięty z bufora (patrz *początek tej sekcji*), to jego hasz jest zapisywany do bufora filtra duplikatów, pakiet jest wysyłany i usuwany z bufora *viscous delay*.
|
||||
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue