SVXlink od podstaw

Drukuj

SVXLink od podstaw – to moja próba wyjaśnienia krok po kroku procesu przygotowania systemu oraz instalacji programu SVXLink. Materiał skierowany jest do osób początkujących, które chcą samodzielnie zbudować i skonfigurować własny system.

Warto pamiętać, że większość sieci oferuje gotowe obrazy systemu – i jak najbardziej polecam skorzystanie z takiego rozwiązania, zwłaszcza na początek.

Niemniej jednak uważam, że samodzielne przejście przez cały proces instalacji i konfiguracji pozwala lepiej zrozumieć zasadę działania SVXLinka, a przy tym daje dużą satysfakcję z faktu, że udało się wszystko zbudować własnymi siłami.

Na tej stronie znajdziesz wiele opisów różnych konfiguracji sprzętowych, ale jest jeden wspólny mianownik — Raspberry Pi Zero lub Raspberry Pi Zero W 2. Czy to oznacza, że tylko te modele są wspierane?
Nie! To po prostu najtańsza i najbardziej dostępna opcja.

Osobiście moim ulubionym modelem jest Raspberry Pi 3A+ — ma ten sam procesor co wersja 3B+, połowę pamięci RAM (co w tym zastosowaniu nie przeszkadza), a co najważniejsze — można je zasilać podobnie jak Raspberry Pi Zero W, np. bezpośrednio z gniazda zapalniczki 5 V. Dlaczego to takie ważne? Bo wersje 3B+ i nowsze często „marudzą”, gdy napięcie spadnie poniżej 5.1 V.

Ostatecznie wybór modelu Raspberry Pi to indywidualna sprawa i zależy głównie od tego, ile chcemy w ten projekt zainwestować. Ja sam używam Raspberry Pi 1 i Raspberry Pi Zero W — więc naprawdę da się to uruchomić praktycznie na wszystkim.
A że jestem wyznawcą religii BIEDA-EDYSZON, to wiadomo – im taniej, tym lepiej. 😄

Warto też wspomnieć, że Raspberry Pi to nie jedyna platforma, na której można zbudować hotspot. Coraz większą popularność zyskują Orange Pi, głównie dzięki wbudowanej karcie dźwiękowej, co pozwala stworzyć bardziej kompaktowe rozwiązanie.

 

Opisywany tutaj przykład będzie oparty na Raspberry Pi Zero W 2 z nakładkową kartą dźwiękową ReSpeaker. Jest to ciekawa alternatywa dla popularnego układu CM108, a przy tym nie wymaga lutowania ani stosowania adapterów z microUSB na USB-A, co w przypadku Raspberry Pi Zero znacząco upraszcza montaż.
Dodatkowo ReSpeaker oferuje kilka interesujących możliwości — ale o tym opowiem w dalszej części.

Cały opis postaram się podzielić na sekcje tematyczne: przygotowanie systemu, instalacja, konfiguracja, podłączenie radia, instalacja dashboardu, instalacja pluginów i kilka innych.
Mam nadzieję, że taki podział ułatwi zrozumienie całości i że ten materiał okaże się dla kogoś przydatny.

 

Należy na wstępie wyjaśnić że instalacja svxlink niesię za soba automatyczne posiadanie svxreflector.  Svxlink to aplikacja klient która służy do połączenia naszego hotspot, gateway, przemiennik  z svxreflektorem który instaluje się automatycznie i jest integralną częścią całego pakietu SVX. 

Zadaniem SVXreflektora jest umożliwienie klientom SVXlinkom połączenie się w sieć i tymsamym umożliwia komunikację pomiędzy sobą. A nie zawsze tak było ponieważ svxlink przez wiele lat bym głównie kontrolerem przemiennika umożliwiającym połaczenie tylko z siecią EchoLink, potem doszła obsługa sieci FreeRadioNetwork i obsługa SVXreflektor. Dlatego przypominam że svxlink i svxreflektor to jedno i każdy z tych elementów składowych ma własny plik konfiguracyjny, w przypadku svxlink jest to plik svxlink.conf a w przypadku svxreflektor ma plik svxreflector.conf

 

Tak więc jest to już takie ukierunkowanie że każdy z Was posiadający hotspot, przemiennik może być budowniczym własnej sieci bo ma już wbudowany SvxReflektor i jedyne co Was przed tym broni to potrzeba i możliwości zintegrowania się z pewną grupą ludzi. Wielu ludzi myśli że to jakaś kosmiczna technologia która wymaga jakiś wybitnych informatycznych umiejętności - otóż tak nie jest, i jedyne co odróżnia serwer od serwera jest jego DASHBOARD i pewne nazwijmy to modyfikacje i dodatki bez których można bez problemu pracować, a ich istnienie jest podyktowane unowoczesnieniem lub wzbogaceniem SvxReflektor o funkcje których on nie posiada w oryginale.  Kończąc wątek serwera SVXreflektor to należ ywspomnieć że może być cieżko z dashboard do reflektor poniewaź istniejące publicznie albo sa toporne w instalacji , albo trochę już przedawnione , ale i na to znajdzie się rozwiązanie. 

 

PROSZĘ NIE TRAKTOWAĆ TEGO OPISU JAKO JEDYNEGO WŁAŚCIWEGO - To moja mniej lub bardziej udana próba wyjaśnienia co i jak MOŻNA i to często wbrew elementarnej logice i jakimkolwiek zasadom elektroniki. 

Traktujcie to bardziej jak DROGOWSKAZ

Cały ten opis powstał podczas budowania PiHOT 2.0 - svxlink hotspot za mniej niż 150PLN - i zaznaczam że wszelkie testy wykonywałem na Naszym testowym serwerze HUBlink ( http://portal.d4a.uk/ ) 

 

 

" Podczas realizacji tego materiału nie ucierpiał żaden administrator."

 


Wprowadzenie

Jak już zostało wspomniane, opis ten będzie oparty na Raspberry Pi Zero W 2

Oczywiście jest to bazowe rozwiązanie dlatego skupimy się na samej instalacji i konfiguracji i celowo  nie bede wspominał o takich dodatkach jak moduły GPS, ekrany OLED czy dodatkowe moduły radiowe jak LoRa czy MMDVM.

Tu poprzestanę tylko na warstwie podstawowej aby nie zrobić tego opisu zbyt zawiłym. 

 

Dlaczego RaspberryPi ? Bo to mój wybór ale może być dosłownie cokolwiek co pozwoli na instalację systemu Linux. Platformy takie jak RaspberryPi czy OrangePi lub inne zdobyły popularność dzięki posiadaniu złącza GPIO które pozwala nam na wysterowanie nadawania w radiu PTT i zwrotnie danie systemowi informacji kiedy radio coś odbiera. W tym celu potrzebny będzie nam jakiś interfejs pośredniczący dedykowany pod konkretne radia. W zalezności jakimi sygnałami dysponuje radio taki albo kupujemy lub budujemy. Nalezy pamietać że niektóre radia staruje się poprzez zwarcie do masy lub podają jakieś napięcie i nie zawsze jest to napięcie pozwalające na podłaczenie bezpośrednio pod RaspberryPi - co z resztą nie jest polecane praktycznie nigdy nie nalezy robić. Zawsze warto użyć albo tranzystorów do wysterowania GPIO lub w najprostrzej wersji przekaźnika jednokanałowego - wszystk ojest podyktowane jakie radio podłączamy.  

  


Przygotowanie systemu to procedura samodzielnej instalacji systemu operacyjnego, i programu svxlink. Jest ona skierowana dla ludzi chcących samemu przejśc proces instalacji, kompilacji i konfiguracji

 

Na naszym komputerze instalujemy sobie program  RaspberryPi Imager który mozna pobrać w tej strony - https://www.raspberrypi.com/software/

Wkładamy nasza kartę SD do komputera i po uruchmieniu programu pierwsze pole jakie mamy do wyboru rodzaj urządzenia, w moim przypadku RaspberryPi Zero 2W

 

Kolejnym krokiem jest wybór systemu operacyjnego. I tu pierwsze ostrzeżenie - NIE WYBIERAMY NAJNOWSZEJ WERSJI TRIXI, idziemy do OTHER

 

i wybieramy RaspberryPi OS ( Legacy, 32bit) LITE BOOKWORM - wersja LITE nie posiada pulpitu i jest idealna i sprawdzona do tego rozwiązania

Po wybraniu systemu i nastepnie karty na jakiem mamy zapisać nasz system możemy przejsc do NEXT w celu zapisu.

Wyskoczy nam okno z zapytaniem czy chcemy dokonac personalizacji naszego obrazu. Klikamy Edit Settings

 

 

W tym oknie możemy wybrac nazwę host, podać username i password  które będzie używane do logowania poprzez SSH, dodatkowo wypełniamy pole naszej sieci WIFI - nazwe i hasło.  Ponadto w zakładce SERVICE warto sprawdzić czy jest tam aktywna opcja SSH server.

 

Po dokonaniu wszystkich ustawnień możemu przejsc do "wypalenia" naszego obrazu na karcie SD

 

 

Po wgraniu systemu na karte i uruchomieniu RaspberryPi, jakimś czasie w naszej sieci pojawi się nasz fmnode. Pierwsze uruchomienie może troche trwać dlatego prosze się uzbroic w cierpliwość i jak to powiada pewien klasyk " Daj temu poleżeć"

 

W celu odnalezienia naszego RaspberryPi w naszej sieci lokalnej albo użyjmy skanerów sieci lokalnej albo zalogować się trzeba do routera czy innego kontrolera sieci.  Znając adres IP możemy podjąc próbe połaczenia sie z nim poprzez ssh - w przypadku posiadaczy systemu Windows może być przydatny program Putty a potem WinSCP w celu wgrywania plików.

 


 Instalacja SVXlink

 

Zanim przechodzimy do samej instalacji, to pierwszą aplikacją jaką instaluje jest Midnight Commander , pokolenie pamietające Norton Commander poczuje delikatną nostalgię :) 

sudo apt install mc 

 

 

 

 

 

 

Sam proces instalacji svxlink można przejść na dwa sposoby, i dlaczego zawsze wybiera się ten trudniejszy ? 

Otóz można zainstalować svxlink z repozytoriu komenda :

sudo apt install svxlink-server

 

W dalszej czesci widzimy jakie pliki zalezności będą się instalować 

 Pomijając fakt że w repozytorium jest starsza wersja SvxLink ( co może być plusem ) to brakuje w niej ważnego elementu w postaci wsparcia dla biblioteki GPIOD, a to zmuszać nas będzie to starszej i moim zdaniem mniej elastycznej metody zarządzania GPIO.  To jest chyba główny powód dlaczego przechodzimy proces instalacji SvxLink instalując go ze źródła co jest bardziej czasochłonne.

 

 

 

UWAGA !!! - opis nie jest optymalny i zautomatyzowany i jest to celowy zabieg aby wykazać jakie sa pliki współpracujące z samym svxlink, mam nadzieję że pozwoli to zrozumieć pewne zależności i kierunek gdzie można coś zmodyfikować lub zrozumieć co gdzie trzeba zmienić jeśli coś nie działa. 

 

W terminalu najpierw wydajemy komendy aktualizacji systemu 

sudo apt update 
sudo apt upgrade -y

Następnie instalujemy niezbędne "zależności" programy niezbędne do prawidłowej kompilacji svxlink.

sudo apt install -y build-essential git alsa-utils mc
sudo apt install -y libasound2-dev g++ gcc make cmake groff gzip doxygen tar tcl
sudo apt install -y libspeex-dev libspeexdsp-dev libopus-dev libvorbis-dev
sudo apt install -y libpopt-dev libsigc++-2.0-dev python3-dev python3-pip
sudo apt install -y libgcrypt20-dev libgsm1-dev swh-plugins tap-plugins ladspa-sdk
sudo apt install -y librtlsdr-dev libjsoncpp-dev nodejs node-ws dos2unix
sudo apt install -y bc tcl-dev libgpiod2 libgpiod-dev gpiod gawk lynx curl rtl-sdr
sudo apt install -y libcurl4-openssl-dev curl libjson-perl libwww-perl net-tools sqlite3
sudo apt install -y sox libsox-dev curl python3 python3-dev python3-numpy python3-pip python3-suds
sudo apt install -y libssl-dev

 

Jeśli chcemy na tym urządzeniu zainstalować także dashboard to musimy przygotować dla niego środowisko pracy

sudo apt install -y apache2 php libapache2-mod-php php-mbstring php-cgi php-common php-curl php-sqlite3 apache2-utils

 

Kolejnym krokiem jest utworzenie użytkownika svxlink ponieważ jest on wymagany do instalacji. W późniejszym etapie możecie sobie sami zmienić ustawienia, lecz na etapie instalacji taki użytkownik powinien być istniejący.

W przypadku RaspberryPi komenda jest taka: 

sudo /usr/sbin/useradd -c "svxlink user" -G audio,dialout,daemon,plugdev,gpio -d /home/svxlink -m -s /sbin/nologin svxlink

 

Można powiedzieć że jeśli wszystkie wymienione kroki zakończyły się sukcesem i nie wystąpiły jakieś problemy z  ich instalacją to możemy przejść do instalacji samego svxlink. 

 

Oto spis komend prowadzących nas przez proces pobrania, kompilacji i instalacji svxlink / svxreflector

sudo -s
cd /opt
mkdir src
cd src
git clone http://github.com/sm0svx/svxlink.git
mkdir svxlink/src/build
cd svxlink/src/build
cmake -DUSE_QT=OFF -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONF_INSTALL_DIR=/etc -DLOCAL_STATE_DIR=/var -DCMAKE_BUILD_TYPE=Release ..

 

 

Ważne aby na tym etapie obserwować czy przypadkiem nie mamy komunkatu o błedzie lub że brakuje jakiegoś elementu

 

make
make install
/usr/sbin/ldconfig

 

 

Musimy jeszcze utworzyć dwa pliki : 

1. plik autostartu

sudo nano /lib/systemd/system/svxlink.service

i wklejamy : 

[Unit]
Description=SvxLink repeater control software
Documentation=man:svxlink(1)
After=network.target remote-fs.target syslog.target time.target
After=rc-local.service sound.target

[Service]
EnvironmentFile=/etc/default/svxlink
PIDFile=${PIDFILE}
ExecStartPre=/bin/mkdir -p /var/run/svxlink
ExecStartPre=/bin/chown ${RUNASUSER}:${RUNASUSER} /var/run/svxlink
ExecStartPre=/bin/chmod 775 /var/run/svxlink
ExecStartPre=-/bin/touch ${LOGFILE}
ExecStartPre=-/bin/chown ${RUNASUSER} ${LOGFILE}
ExecStart=/usr/bin/svxlink --logfile=${LOGFILE} --config=${CFGFILE} --pidfile=${PIDFILE} --runasuser=${RUNASUSER}
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
TimeoutStartSec=60
TimeoutStopSec=10
#WatchdogSec=@SVX_WatchdogSec@
#NotifyAccess=main
LimitCORE=infinity
WorkingDirectory=/etc/svxlink

[Install]
WantedBy=multi-user.target

 

 

 

następnie sudo nano /etc/default/svxlink

i wklejamy 

# This file copy to /etc/defualt/

#
# Enable Alsa zerofill if set to 1 (see manual page)
#ASYNC_AUDIO_ALSA_ZEROFILL=0

############################################################################
#
# Configuration file for the SvxLink Systemd unit file
#
#############################################################################

# The user to run the SvxLink server as
RUNASUSER=svxlink

# Specify which configuration file to use
CFGFILE=/etc/svxlink/svxlink.conf

# Where to place the log file
LOGFILE=/var/log/svxlink.log

# Where to place the PID file
PIDFILE=/run/svxlink.pid

# Enable Alsa zerofill if set to 1 (see manual page)
#ASYNC_AUDIO_ALSA_ZEROFILL=0

Teraz możemy wydawać komendy : 

sudo systemctl status svxlink
sudo systemctl stop svxlink
sudo systemctl start svxlink
sudo systemctl restart svxlink

 

 

Zanim zakończymy warto dla ułatwienia sobie życia pobrać prawie gotowy plik konfiguracyjny przygotowany pod RaspberryPi i sterowanie za pomoca GPIO - pozwoli mieć to punkt wyjściowy na start i do porównania z oryginałem na przyszłość. 

Najpierw wykonajmy kopię zapasowa oryginalnego pliku konfiguracyjnego komendą : 

sudo cp /etc/svxlink/svxlink.conf /etc/svxlink/svxlink.conf.bak

a następnie moge zasugerowac pobranie prostego pliku konfiguracyjnego pod simplex hotspot 

sudo wget -O /etc/svxlink/svxlink.conf https://d4a.uk/git/svx/svxlink.conf

Edycję i konfigurację opisze w dalszej cześci. 

 

 

 

Dlatego już w tym momencie polecam każdemu po przejściu procesu kompilacji zrobić sobie kopie karty SD - aby kolejny raz już tego nie robić i nie tracić kolejnych godzin.

 


 Dashboard

 

Dashboard (panel sterowania) jest wizualną nakładką graficzną (GUI), która znacząco ułatwia zarządzanie i obsługę naszego hotspotu SVXLink. W przeciwieństwie do podstawowej konfiguracji tekstowej, dashboard umożliwia intuicyjną kontrolę nad systemem.

Chociaż niewiele tego typu paneli jest publicznie dostępnych, w tym przewodniku skupimy się na procesie instalacji rozwiązania dostępnego na platformie GitHub: 

Adres URL projektu: https://github.com/f5vmr/SVXLink-Dash-V2

 

Należy podkreślić, że prezentowana wersja jest propozycją startową, która nie jest związana z żadną konkretną siecią radiową. Oznacza to pełną swobodę w jej używaniu, testowaniu i dowolnym modyfikowaniu pod własne potrzeby.

Dashboard jest elementem wymiennym i dynamicznie rozwijanym. Społeczność krótkofalowców, zwłaszcza użytkownicy Linuxa, aktywnie wspiera ideę Open Source Software (oprogramowania otwartoźródłowego). Dzięki temu, inni entuzjaści dzielą się własnymi modyfikacjami i wariacjami, które powstają z pasji do technologii i chęci dzielenia się wiedzą, a nie dla zysków komercyjnych.

 

Zanim rozpoczniemy instalacje musze wspomnieć że prawie każdy dashboard wymaga dostępu do pewnych plików aby mógł działać poprawnie. 

 

/var/log/svxlink.log - to plik log programu svxlink będacy podstawowym źródłem informacji o tym co się dzieje aby móc nam to pokazać na dashboard. Czasami niektóre projekty ogarniają plik /var/log/svxlink a nie /var/log/svxlink.log ale to wynika chyba z pewnych praktyk deweloperów. 

/etc/svxlink/svxlink.conf - plik konfiguracyjny programu svxlink w którym są podane pewne dane zmienne jak nasz znak, ustawienie audio czy uruchomione moduły. Dane te są wyświetlane na dashboard.

/tmp/dtmf_svx -  ten plik głównie występował w dashboard autorstwa Waldka SP2ONG i służy to wymiany informacji dashboard <-> svxlink, jaki DTMF ma być wstrzykniety do programu svxlink w ramach wybieranego za pomoca wirtualnej klawiatury DTMF czy przycisków pamięci

/var/run/svxlink/dtmf_svx -  ten plik w zastępstwie za /tmp/dtmf_svx został wprowadzony przy okazji modyfikacji "Svxlink Dashboard by SP2ONG" - i tego pliku się teraz będziemy się go trzymać.

 

 

 

 

Proces instalacji 

Rozpoczynamy od wykasowania zawartości katalogu html.  A to że coś mamy można łatwo stwierdzić odwiedzając adres ip naszej maliny. Jest to standardowy plik pozostały po instalacji naszego serwera www. 

Aby on nie kolidował z nowym dashboard trzeba wykasować zawartość katalogu /var/www/html/ - choć autor podaje aby wykasować cały katalog. 

sudo rm -r /var/www/html

Teraz zgodnie z opisem na stronie pobieramy dashboard 

sudo git clone https://github.com/f5vmr/SVXLink-Dash-V2 /var/www/html

 

Po wydaniu tej komendy naszym oczom ukazać się powinien taki widok.

 

Niestety to nie koniec , ponieważ teraz trzeba nadać uprawnienia aby wszystkie elementy panelu sterowania działały. Zgodnie z opisem na github musimy edytować plik konfiguracyjny apache2

sudo nano /etc/apache2/envvars

Szukamy fragmentu zaznaczonego

 

i podmieniamy www-data na svxlink w obu linijkach 

 

Teraz zapisyjemy CTRL+X a nastepnie Y. 

 

Następnie musimu edytować plik /usr/lib/systemd/system/apache2.service

sudo nano /usr/lib/systemd/system/apache2.service

 Po edycji odszukujemy linijkę "PrivateTmp=true"  i podmieniamy na "PrivateTmp=false" 

Następnie zapisujemy CTRL+X oraz Y dla potwierdzenia. 

 

teraz już finalnie możemy przeładować  usłyge serwera www komendą

sudo systemctl daemon-reload && sudo systemctl restart apache2

 

 

Tu należy wykonać jeszcze komendę sudo ./upgrade.sh - lecz ja pozostawiam to dla potencjalnego posiadacza tego obrazu - TAK poniżej bedzie link do pobrania obrazu z na RaspberryPi dokładnie z tego punktu . Ponieważ podczas wykonywania tej komendy trzeba podać login i hasło jakim bedzie zabezpieczony nasz dashboard przed nieautoryzowanym dostępem.

 

Przestrzagam !!! - aby nikt nie wpadł na pomysł że skoro dashboard ma login hasło to moge go wystawić na publiczny widok - możecie się bardzo zdziwić jak słabe jest to zabezpieczenie i ktoś zacznie Wam mieszac w konfiguracji. Nigdy, przenigdy , nigdy nie wystawiamy takich rozwiązań na publiczny dostęp - a jak chcemy mieć sami dostep z zewnątrz to polecam VPN ( zero-tier, tailscale ) 

 

 

Ja osobiście  polecam teraz wykonać restart RaspberryPi a po poprawnym ruchomieniu wykonac kopie zapasową naszego obrazu. 

Teraz zanim cokolwiek dalej zrobisz prosze wyjmij kartę z RaspberryPi i zrób kopię zapasową, oczywiście najpierw warto zamknąc system komendą sudo shutdown now

 


Alternatywny Dashboard 

 

 

Alternatywny Dashboard w początkowej wersji bazuje na pomysłach Waldka SP2ONG z projektu "Svxlink Dashbord" z 2020 roku -  głównie lh.php i svxref.php. 

Powtał z potrzeby chwili jako koncept wyjściowy na poczatek, i w miare potrzeb każdy będzie miał możliwość dodawania sobie elementów jakie sa mu potrzebne. Chodzi także o zminimalizowanie obciażenia CPU podczas generowania strony  i odświeżanych elementów.  Jest to rozwiazanie przejściowe zanim zmieniony zostanie kompletnie sposób dostarczania informacji na www.

Dashboard ten posiada kilka wariantów / sposobów dostarczania informacji o statusie hotspot czy reflektor , ale jest to tylko punkt wyjściowy do czegoś więcej. Mamy do dyspozycji cztery menu które moze być otwierane niezaleznie i kazde z nich ma inna funkcję, co mam nadzieję że pozwoli na element personalizacji co chce się widzieć. 

Menu lewe - to menu nawigacyjne pozwalające nam na przełaczanie się pomiędzy dostepnymi funkcjami. 

Menu prawe - to status svxlink znany z innych dash ale odświezany tylko gdy jest wyswietlany.

 

 

Dolne menu to panel przycisków programowalnych pozwalający na przełaczanie się pomiędzy grupami TG. 

 

Menu górne to klawiatura DTMF pozwalająca nam sterować naszym SVXlink.

 

 

 Mamy obecnie prosty  panel konfiguracyjny - chyba z najważnieszymi funkcjami do wyboru - więcej można sobie doinstalować na życzenie.

 

 

No i własnie jeśli jest mowa o doinstalowaniu, to mam chęć aby ten proces był trochę łatwiejszy i pozwalał każdemu wybrać co chce i tymsamym mieć własny indyfidualny hotspot, zmontowany na jego potrzeby. Bo po co komu system obciażony obsługa GPS czy SA818 jak ktoś tego nie ma i nie chcę używać.  Taki sklep z wtyczkami to ciekawa alternatywa, pozwalająca modyfikować nie tylko sam svxlink czy system ale przykładowo wybierać z "skórki" naszego dashboard.

Koncept jest na etapie prostego uruchomienia i moze społeczność to przyjmie. 

 

 

 

 

 

 

DASHBOARD ten pisze z przeznaczeniem dla dwóch urządzeń M0IQF-R - mobilny przemiennik low-power oraz PiHOT 2.0 - svxlink hotspot za mniej niż 150PLN. Jeśli się uda to postaram się go opisać jak go pobrać i zainstalować

 

 

 


 

AUDIO 

 

Teraz przyszedł czas na instalację sterowników do tej karty ReSpeaker jeśli ktoś ją używa

 

 

 Ja osobiście używam sterowników ze strony https://github.com/ubopod/WM8960-Audio-HAT/ gdzie jest opisany proces instalacji. 

 

 Generalnie wystarczy w terminalu wydać te komendy : 

git clone https://github.com/waveshare/WM8960-Audio-HAT
cd WM8960-Audio-HAT
sudo ./install.sh 
sudo reboot

 

Na tym etapie warto mieć głosniczek lub słuchawki w celu potwierdzenia ze wszystko działą zanim podłaczymy radio. 

 

🎧 Test dźwięku

Spróbuj odtworzyć dźwięk:

 
speaker-test -D hw:0,0 -c 2

Zatrzymaj test Ctrl + C.
Jeśli słyszysz szum lub kliknięcia — wszystko działa.

🎙️ Test mikrofonu

Nagraj 5 sekund dźwięku z mikrofonu:

 
arecord -D hw:0,0 -f cd -c 2 -d 5 test.wav

A potem odtwórz:

 
aplay -D hw:0,0 test.wav

Jeśli słyszysz swój głos → mikrofony działają 🎤

 

 

 

 

 

 Karta ReSpeaker posiada wbudowany mikrofon , złącze SPEAKER OUT gdzie możemy sobie podłaczyć głośniczek, lub użyć 3.5mm audio jack do testowego podłączenia słuchawek lub głosnika.  Złącze I2C pozwoli nam na podłaczenie akranu OLED a wbudowany przycisk BUTTON to GPIO17 którego można użyć jako testowe PTT.  Ponadto GPIO12 pozwoli nam na podłączenia PTT/COS z radia w celu wysterowania go ( ale o podłączeniu radia będzie dalej ) 

 

Taki zestaw jest już pełnoprawnym Network Radio na którym można dokonywać pierwszych testów. Teoretycznie nasza karta powinna mieć numer 0 co będzie widoczne po wydaniu komendy : 

aplay -l
arecord -l

 

 

Tak więc można przejśc do zmiany konfiguracji naszego svxlink.  Jedyne co trzeba na starcie dokonać to przypisać  przycisk na karcie aby pozwalał nam nadawać.  Tu musze wtrącić pewną uwagę - mianowicie często ludzie myślą że skoro przycisk bedzie nam robił za PTT i my będzie my nadawać to dokomują zmian logicznie w dziale nadawania czyli Tx1. Niestety to jest bład ponieważ NetworkRadio działa na odwrotnej logice. To co my wciskamy owszem jest naszym PTT ale my musimy uruchomić odbiornik czyli Rx1 a nie nadajnik. Nadajnik w naszym przypadku to głośnik który uruchamia się sam, a odbiornikiem jest mikrofon.

 

Albo w terminalu albo za pośrednictwem www zmieniamy w Rx1 wartość w SQL_GPIOD_LINE na !17

 

I teoretycznie mamy działający Network Radio który wymaga korekty poziomów audio ale już powinien działać . 

 

 

 

Oczywiście można użyć karty CM108

 

 

 


 

Interfejs to temat trudny i jednoczesnie prosty. Osobiśnie uważam że nie ma uniwersalnego interfejsu do wszystkich kodeli radia z jakich można zbudować hotspot czy gateway. 

Naprawdę najpierw trzeba wiedzieć jak radi ojest sterowane , czy zwarciem do masy czy podaniem napięcia, potem siedzieć jak radio nas informuje że otworzyło blokadę SQL, jakie poziomy napiecia aby potem zbudowac sobie sterowanie. 

 

Pierwszym naturalnym wyborem jest przekaźnik jednokanałowy 

 

 

 

 

 

Potem zaczyna się kombinowanie a może użyć opto-isolatora 

 

 

 

 

 

Aby finalnie zacząć kombinować z tranzystorami ( przykładowo 2N7000 ) 

 

 

 

 

Wszystko jest podyktowane radiem, bo przykładowo SA818 wymaga tylko jednego tranzystora  po stronie PTT, Quansheng najlepiej 2 tranzystory  - jeden TX drugi RX, Motorola GM300 dostała jeden przekaźnik jednokanałowy a Icom z uwagi na wysokie napięcie 8V dostała 2x przekaźniki jednokanałowe ale wersje 12V. No i Finalnie stare CB Radio pracujące na 29MHz dostało przekażnik jednokanałowy ze stanami NO COM NC - Kto pamieta konstrokcje mikrofonu ten wie dlaczego trzeba dla odbiornika i nadajnika zewrzeć inne kable. 

 

NAJpierw informacja jak sterować radiem - POTem dobieramy elementy lub sięgamy do kieszeni i kupujemy dedykowany interface.

 

 

 

 

 

 

 

 

 

 


 

svxlink.conf 

 

 Postaram się tutaj przybliżyć pewne funkcje dostępne w pliku konfiguracyjnym aby ułatwić dokonywanie zmian. 

 

Aby sobie ułatwić omówimy sobie DEMO plik konfiguracyjny  https://d4a.uk/git/svx/svxlink.conf

 
W pliku mamy takie nazwijmy to kategorie: 

[GLOBAL]
...
[ReflectorLink]
...
[SimplexLogic]
...
[ReflectorLogic]
...
[Rx1]
...
[Tx1]
...

 One czesto sa w innej kolejności poukładane ale to nie ma znaczenia, ważne że to jest nazwijmy to niezbedne minimum do pracy hotspot. Postaram sie w miarę możliwości kolejno je przedstawić i wyjasnić funkcje w nich dostępne, ale te najważniejsze. Prosze pamietac że plik svxlink.conf ma o wiele więcej funkcji ale dla tego konkretnego przykładu mamy minimum dla ułatwienia sobie pracy na poczatek. 

 

 

Pierwszy i główny jest GLOBAL który może wygladać tak

[GLOBAL]

MODULE_PATH=/usr/lib/arm-linux-gnueabihf/svxlink
LOGIC_CORE_PATH=/usr/lib/arm-linux-gnueabihf/svxlink
LOGICS=SimplexLogic,ReflectorLogic
LINKS=ReflectorLink
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S"
CARD_SAMPLE_RATE=48000
CARD_CHANNELS=1

 

Z tego elementu głownie nas interesuje linijka

LOGICS=SimplexLogic,ReflectorLogic

Ona informuje program svxlink aby "załadował" moduły SimplexLogic ( bo to hotspot simplex ) oraz że będziemy kożystali z połaczenia z svxreflektor i dlatego ma załadować ReflectorLogic. W przypadku gdy jest to przemiennik zamiast SimplexLogić załadujemy RepeaterLogic.

W dalszej części mamy jeszcze LINKS informująca o dalszej czesci konfigu gdzie sa opisane reguły linkowania. Nazwa po znaku = może być dowolna aby tylko w samym konfigu raka sekcja wystepowała.

LINKS=ReflectorLink

 

 

Tak więc nasz svxlink wie że ma załadować oba te moduły, ale nie wie co ma z nimi zrobić i jak je połaczyć. Dlatego mamy w pliku dalsza część w postaci ReflectorLink. 

 

[ReflectorLink]
CONNECT_LOGICS=SimplexLogic:9:SVX,ReflectorLogic
DEFAULT_ACTIVE=1
OPTIONS=DEFAULT_CONNECT,NO_DISCONNECT
TIMEOUT=0

Pierwsza linijka informuje jakie moduły ma ze soba połaczyć w ty mprzypadku SimplexLogic i ReflectorLogic z czego komendy DTMF dla ReflectorLogic mają się zaczynać cyfrą 9 - dlatego wybór sterowanie reflectorem zaczyna się na 9 ( przykładowo: 91260# połaczenie z tg2600 lub 9# - rozłączenie z svxreflektor. ) 

Druga linijka informuje czy to połaczenie modułów SimplexLogic i ReflectorLogic ma być domyslnie uruchomione czy nie - 1 oznacza że TAK.

Ostatnia linijka to czas po upływie jakiego ma coś się stać z tym LINKiem. Przykładowo jeśli mamy DEFAULT_ACTIVE=1 czyli domyslnie aktywny ale przy pomocy DTMF ( 9#) rozłączymy się z reflektorem to po upływie jakiego czasu bezczynności to połaczeni ma być wznowione, i analogicznie jeśli domyślnie mamy takie połączenie z reflektorem nieaktywne to po jakim czasie po jego aktywacji ma się deaktywowac i nasz przemiennik pracuje nadal ale OFFLINE.

 

 

Tak więc weźmy teraz sekcję ReflectorLogic odpowiedzialną za połączenie z serwerem SvxReflector czyli w uproszczeniu na transmisję internetową.

[ReflectorLogic]

TYPE=ReflectorV2
HOSTS=server
HOST_PORT=5300
CALLSIGN=N0CALL
AUTH_KEY=password
DEFAULT_TG=9
MONITOR_TGS=9
FMNET=server.name
API=server.api
#JITTER_BUFFER_DELAY=0
TG_SELECT_TIMEOUT=60
#TG_SELECT_INHIBIT_TIMEOUT=0
ANNOUNCE_REMOTE_MIN_INTERVAL=300
EVENT_HANDLER=/usr/share/svxlink/events.tcl
NODE_INFO_FILE=/etc/svxlink/node_info.json
MUTE_FIRST_TX_LOC=0
MUTE_FIRST_TX_REM=0
TMP_MONITOR_TIMEOUT=3600
UDP_HEARTBEAT_INTERVAL=15
QSY_PENDING_TIMEOUT=15
DEFAULT_LANG=en_US

 

zaczynając od poczatku to mamy linijkę odpowiedzialną za podanie TYPU naszego SvxReflektor

 

TYPE=ReflectorV2

Do wyboru mamy Reflector lub ReflectorV2, przy czym wiekszość serwerów pracuje w trybie kompatybilnym z V2 , niewiele zdecydowało się na przejście w standard V3 czyli oparty o certyfikaty

 

Kolejna linijki odpowiadają za połaczenie i uwieżytelnienie poprzez podanie adresu i portu serwera oraz przydzielony nam znak i hasło 

HOSTS=adres_serwera
HOST_PORT=5300
CALLSIGN=NASZ_ZNAK
AUTH_KEY=NASZE_HASŁO

 

 

Kolejne linie odpowiadają za to jakie MONITORujemy grupy TG oraz jaka jest nasza grupą domyślną. Domyślna TG to taka co to uruchamia się automatycznie gdy rylko nasz odbiornik coś odbierze. Czesto bywa to przypisana na stałe grupa która jest nasza główną ( lokalna lub klubowa ) 

DEFAULT_TG=9
MONITOR_TGS=9

Monitorowane TG to takie które nasłuchujemy w oczekiwaniu na aktywność , a po jej nastapieniu automatycznie się uaktywnia informując nas komunikatem audio. Można mieć wiele monitorowanych grup TG przykładowo: 

MONITOR_TGS=235,23511+,235++,2600

grupy TG monitorowane są oddzielone przecinkiem i można dodać znak plus + nadając wyższy priorytet, im więcej + tym priorytet jest wyższe, co oznacza że w w/w przykładzie jak bedzie aktywna TG 2600 i ktoś będzie na niej rozmawiał ( w przypadku Naszego serwera jest to Grupa Polonijna ) to pojawienie się aktywności na TG 23511 ( South East (Beds, Essex, Norf, Suff) automatycznie spowoduje rozłączenie TG2600 i będziemy słyszeli to co sie dzieje na TG23511 ponieważ ma wyższy priorytet. Analogicznie sytuacja taka sama TG2600 jest aktywna i pojawi się aktywność na TG 235 spowoduje NIC - ponieważ obie te TG mają taki sam priorytet i pozostaje aktywna ta która była pierwsza. 

Tu przy okacji trzeba wspomnieć o funkcji

TG_SELECT_TIMEOUT=60

która jest odpowiedzialna za automatyczne rozłączenie w przypadku bezczynności na TG po upływie ustawionego czasu ( w tym przypadku 60 sekund ) 

 

 

Kolejne to funkcje które nie mają nic wspólnego z svxlink jako takim a służą jedynie jako dane pomocnicze dla DASHBOARD. Ich obecnośc tutaj wynika chyba z chęci posiadania jednego głównego pliku konfiguracyjnego dla systemy svxlink + dashboard.

FMNET=server.name
API=server.api

FMNET = to na podanie nazwy serwera która często wyświetla się gdzieś w dashboard ułatwiając identyfikację z jakim serwerem jesteśmy połaczeni. 

API = tu wpisujemy adres API naszego serwera. API w serwerze udostępnia informacje o tym kto jest podłączony do serwera, jakie TG monitoruje, jaką kto ma teraz aktywną i kilka innych danych głównie z naszego pliku node_info.json. 

 

 

Warte wspomnienia w tej sekcji jest jeszcze 

MUTE_FIRST_TX_LOC=0
MUTE_FIRST_TX_REM=0
 

MUTE_FIRST_TX_LOC - pozwala włączyć nam pierwsze PTT jako głuche i nie wysyłane do reflektora. Przykładowo jesteśmy w zasięgu gateway i czesto każdy testowo naciska PTT w oczekiwaniu na odpowiedź gateway potwierdzającą że nas odebrał zanim rozpoczniemy wywołanie. I właśnie to jedno PTT spowodowało aktywację wszystkich nadajników na domyślnej TG, aby uniknąć takich sytuacji dobrą praktyką jest ustawienie MUTE_FIRST_TX_LOC=1 co spowoduje że ReflectorLogic bedzie ignorował pierwsze PTT i w sieć będzie transmitował dopiero od drugiego. Podobnie ma się sytuacja w przypadku MUTE_FIRST_TX_REM - gdzie to my na naszym gateway decydujemy czy pierwsza transmisja z reflektora ma być ignorowana.  ) to deaktywacja, 1 to aktywacja. 

 

 

 

Wydaje mi się że możemy przejść do sekcji odpowiedzialną za transmisję RF  SimplexLogic która jest połączona z sekcją Rx1 i Tx1 - 

[SimplexLogic]
#
TYPE=Simplex
RX=Rx1
TX=Tx1
MODULES=ModuleHelp,ModuleParrot
CALLSIGN=N0CALL
SHORT_IDENT_INTERVAL=5
IDENT_ONLY_AFTER_TX=4
LONG_IDENT_INTERVAL=0
EVENT_HANDLER=/usr/share/svxlink/events.tcl
DEFAULT_LANG=en_US
RGR_SOUND_DELAY=10
RGR_SOUND_ALWAYS=1
FX_GAIN_NORMAL=0
FX_GAIN_LOW=-12
QSO_RECORDER=8:QsoRecorder
DTMF_CTRL_PTY=/var/run/svxlink/dtmf_svx
MUTE_RX_ON_TX=1
MUTE_TX_ON_RX=1

 

Pierwsze o czym warto tu wspomnieć że można aktywować i deaktywować nadajnik lub odbiornik, co bywa przydatne podczas pierwszych uruchomień i testów poprzez wpisanie NONE zamiast Rx1 lub Tx1. 

RX=Rx1
TX=Tx1

Przeznaczenie tej funkcji jest trochę bardziej zaawansowane i pozwla na uruchomieni / podłaczenie kilku odbiorników lub nadajników jednocześnie ale nie o tym teraz. 

 

 

Linia MODULES= jest odpowiedzialna za to jakie moduły mają zostać załadowane, przykładowo mamy ModuleEchoLink ( sieć echolink ) , ModuleFrn ( sieć FreeRadioNetwork ), ModuleParrot ( lokalny echo test / papuga ) są jeszcze prognozy pogody według lotnisk i kilka innych. Wspomnieć tu trzeba że można samemu sobie napisać moduł który bedzie realizował jakąs funkcję w naszym gateway, przykładowo napisałem sobie ModuleSvxswitch który pozwala przy pomocy DTMF komend przełaczać się pomiędzy reflektorami. 

MODULES=ModuleHelp,ModuleParrot

 

 

Podany w tej linii znak nie jest tym samym co podany podczas logowania do Reflektor. Ten służy do identyfikacji nadajnika, i jest automatycznie nadawany co wybrany okres czasu lub na rządanie komendą *#

CALLSIGN=NASZ_ZNAK

 

Identyfikacja to funkcja właśnie automatycznego nadawania "znacznika" identyfikującego nasz nadajnik. Różnie jest w różnych krajach z przepisami w tej materii, przykładowo w UK nadajnik powinien sie identyfikować nie mniej niż raz na 10-15 minut podczas aktywności.

SHORT_IDENT_INTERVAL=5
LONG_IDENT_INTERVAL=0
IDENT_ONLY_AFTER_TX=4

Dlatego mam ustawione SHORT_IDENT_INTERVAL na 5 minut ale dopiero po wystapieniu 4 uruchomień nadajnika,  IDENT_ONLY_AFTER_TX=4

LONG_IDENT_INTERVAL - to dłuższa identyfikacja podająca czas, znak, i ctcss nadajnika, nie jest ona powiązana z IDENT_ONLY_AFTER_TX=4 c opowoduje że jeśli ktoś to uruchomi i wpisze czas przykładowo 60 minut to nieważne co bedzie się działo to co godzinę nadany zostanie taki znacznik.

Swoją drogą upierdliwa jest trochę ta niekonsekwencja w jednostkach miary czasu, raz są sekundy raz minuty - dlatego proszę uważać. 

 

 

Wybór języka komunikatów AUDIO

DEFAULT_LANG=en_US

W moim przypadku jest język Angielski ale można oczywiście wybrać Polski poprzez wpisanie pl_PL. Podobną funkcję mamy w ReflectorLogic  Oczywiście aby to zadziałało musimy mieć wgrane takie pliki do folderu /usr/share/svxlink/sounds/

 

 

 W tej częsci mamy ustawienie czy ROGER potwierdzający koniec transmisji ma być nadawany i jeśli TAK to po jakim czasie od uruchomienia nadajnika. Jest to przydatne w przypadku gdy nasz nadajnik ma pewien okres zwłoki zanim w całości nadajnik z torem audio się podniesie poprawnie i aby ten roger zdążył być nadany poprawnie. Czas podawany jest w milisekundach

RGR_SOUND_DELAY=10
RGR_SOUND_ALWAYS=1

 

 

 

FX_GAIN to ustawienia komunkatów audio identyfikatorów czy info o aktywacji TG, nadawanych przez svxlink. NORMAL to w przypadku gdy w tle nie ma rozmowy, a LOW oznacza tak zwaną nakładkę na trwająca korespondencję. 

FX_GAIN_NORMAL=0
FX_GAIN_LOW=-12

 

 

 

W simplexlogic możemy dopisać funkcjonalność NAGRYWARKI łączności , która będzie nagrywać cała aktywność do pliku WAV z pominięciem okresów ciszy. Aktywacja to DTMF 81# a deaktywacja to 80#

QSO_RECORDER=8:QsoRecorder

 

 

 

To jest element o którym wspominam przy okacji DASHBOARD, jest to ścieżka do pliku który służy do  komunikacji dashboard z programem svxlink. Komunikacja w tym przypadku polega na powiedzeniu svxlink jaki DTMF został wybrany na DASHBOARD. Jest t okluczowy element bez którego nie działają nam przyciski wirtualnek klawiatury DTMF czy przyciski szybkiego wybierania kanałów. 

DTMF_CTRL_PTY=/var/run/svxlink/dtmf_svx

 

 

MUTE to funkcja pomagająca poprawnie pracować karcie dźwiękowej poprzez wyłaczania wejscia gdy pracuje wyjście i odwrotnie, pozwala to na eliminacje potencjalnych interferencji z wejscia mikrofonowego gdy pracuje złącze słuchawek przykładowo. 

MUTE_RX_ON_TX=1
MUTE_TX_ON_RX=1

 

 

Czas zająć się teraz sekcjami odpowiedzialnymi bezpośrednio za połaczenie z nadajnikiem i odbiornikiem

 

Rx1 odpowiada za podłączenie z odbiornikiem radiowym i przekazywanie do svxlink zarówno audio jak i informacji o tym czy odbiotnik jest aktywny ( to konieczne uproszczenie tej funkcjonalności ) 

[Rx1]
#
TYPE=Local
RX_ID=R
AUDIO_DEV=alsa:plughw:0
AUDIO_CHANNEL=0
LIMITER_THRESH=-6
SQL_DET=GPIOD
SQL_START_DELAY=100
SQL_DELAY=100
SQL_HANGTIME=300
SQL_GPIOD_CHIP=gpiochip0
SQL_GPIOD_LINE=!20
SQL_TIMEOUT=420
DEEMPHASIS=0
PREAMP=-8
PEAK_METER=1
DTMF_DEC_TYPE=INTERNAL
DTMF_MUTING=1
DTMF_HANGTIME=40
1750_MUTING=1

 

Pierwszym elementem jaki nas interesuje to 

AUDIO_DEV=alsa:plughw:0

tu podajemy numer karty dźwiekowej. Numer ten jest podany w spisie kart audio w naszym systemie który można uzyskac po wpisaniu w terminal komendy aplay -l i arecord -l

 

 

 

Kolejnym ważym dla nas parametrem jest SQL_GPIOD_LINE gdzie podajemu numer GPIO które ma wykrywać sygnał z radia że blokada squelch została orwarta i radi oodbiera sygnał. Dodanie znaku ! przed numerem odwraca polaryzację ( stan niski lub wysoki to aktywacja )  Stany na GPIO to napięcie do 3.3V lub poniżej 1.4V ( nie pamietam dokładnie ale chyba już powyżej 1.4V raspberry wykrywa jako stan wysoki. 

SQL_GPIOD_LINE=!20

 

 

Po stawieniu jakie GPIO odpowiada za kontrolę blokady SQL można ustawić sobie pomocnicze parametry

SQL_START_DELAY=100
SQL_DELAY=100
SQL_HANGTIME=300

SQL_START_DELAY - to czas jaki musi być otwarta blokada aby svxlink uznał że to nie przypadek a faktyczne otwarcie blokady i zaczał nadawać w kierunku reflektor.

SQL_DELAY - to tożsama funkcja z wyżej opisaną, Różne kombinacje się stosuje co jest detektorem otwarcia blokady SQL, bo można użyć VOX a to już wymaga pewnej gimnastyki w kalibracji. 

SQL_HANGTIME - to czas jaki jest podtrzymywane nadawanie w kierunku reflektor po zamknieciu blokady SQL w radiu

Zawsze warto zapoznać się z opisem  :  https://www.svxlink.org/doc/man/man5/svxlink.conf.5.html#Local%20Receiver%20Section

 

 

 

Skoro mamy już jak i kiedy blokada SQL otwarta i ma nastąpić transmisja do internetu to wart ozabezpieczyć się przed niechcianym długim nadawaniem w przypadku wystapienia jakiejś usterki

SQL_TIMEOUT=420

Ten parametr powinien zagwarantować że po upływie 420 sekund blokada zostanie samoczynnie zamknieta uznając że przektoczony został TOT, niestety z doświadczenia wiem że czasami odbywa się to w ten sposób że faktycznie odpuszcza ale tylko na sekunde i ponownie zaciska. Możliwe że wynika to z wersji svxlink jaką testowałem. Moim zdaniem powinno to wygladać tak że po upływie czasu 420 sekund svxlink odpuszcza nadawanie do internetu i pozwoli dopiero gdy fizycznie blokada się zamknie i uruchomi ponownie. 

 

 

Odbiorniki przykładowo Motoroli pozwalają na pracę na złączach Flat Audio i w tym celu aby poprawić brzmienie svxlink ma funkcje DEEMPHASIS która mozna sobie właczyć lub wyłaczyć o zobaczyć jak słychać. Czesto jest to zjawisko "wysopranienia" audio

DEEMPHASIS=0

 

 

Poziomu audio ustawiamy w alsamixer, ale jeśli okazałoby się ze mamy wejście audio na 0 a pomimo to jest nadal troszkę za głośno to możemy poratować się obcięciem audio na poziomie svxlink. Oczywiście lepsze jest zrobienie tego na poziomie audio interface ale czasami jest to nasze opcja ratunku. Należy pamietać że jeśli poziom audio bedzie na wejściu przesterowany to możemy go przyciszyć ale nadal będzie brzmieła jak przester tylko cicho. 

PREAMP=-8

 

 

 

No i warto wspomniec jeszcze o wbudowanym "monitorze" poziomu audio

PEAK_METER=1

Pozwala on na publikowanie w plikach log informacji że wejście audio jest za głośne. 0 - wyłaczone , 1 - właczone

 

 

 

 

Czas zająć się nadajnikiem Tx1

[Tx1]
TYPE=Local
TX_ID=T
AUDIO_DEV=alsa:plughw:0
AUDIO_CHANNEL=0
LIMITER_THRESH=-6
PTT_TYPE=GPIOD
PTT_GPIOD_CHIP=gpiochip0
PTT_GPIOD_LINE=16
TIMEOUT=420
TX_DELAY=500
PREEMPHASIS=0
DTMF_TONE_LENGTH=100
DTMF_TONE_SPACING=50
DTMF_DIGIT_PWR=-15
MASTER_GAIN=0.0

 

 Podobnie jak w Rx mamy 

 

Ustawienie numeru karty audio 

AUDIO_DEV=alsa:plughw:0

 

 Ustawienie które GPIO ma sterować nadajnikiem 

PTT_GPIOD_LINE=16

 

 

Czas zwłoki uruchomienia nadajnika oraz maksymalny czas pracy nadajnika ( osobiście ten drugi programuje też w radiu ) 

TX_DELAY=500
TIMEOUT=420

 

 

Wsparcie dla Flat Audio 

PREEMPHASIS=0

 

 

Oraz mamy możliwość wzmocnienia sygnału audio gdyby alsamixer nie wystarczał 

MASTER_GAIN=0.0

 

 

 

 

 

I to chyba tyle co trzeba wyjaśnić na początek.  Za błedy przepraszam i życzę miłej zabawy