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