Aktualizacja 04-01-2025
SvxPi to "KONCEPCYJNY" wsad, obraz systemu , w pełni darmowy i budowany pod konkretne zastosowanie czyli SVXREFLECTOR CLIENT. Jest to mocno odchudzona wersja zdolna pracować z ekranem 3,5" bez konieczności uruchamiania pulpitu. Działa RaspberryPi 3A+ z wyświetlaczem a bez wyświetlacza nawet na RaspberryPi 0W. Głównym i jedynym zadaniem jest obsługa programu SVXLINK i bycie lżejszym bratem aDVPi_2024.05
Koncept który przeszedł jakiś etap testów i w wersji BETA będzie do pobrania od początku stycznia 2025 roku. Wsad można podłączyć do dowolnego reflektora i obsługuje komunikaty językowe: PL / EN / DE / RO / FR / ES
Na wstępie proszę zrozumieć pewną różnicę pomiędzy aDVPi a SvxPi. Otóz aDVPi było ograniczone do pewnego standardu połączeń GPIO nałożonych przez sam program DVPi, aby zachować funkcjonalność obu programów konieczne uzależnienie się od oryginalnego wsadu DVPi który pracował na RaspberryPi 3B+ lub 4, ale nie wszystkich. Dodatkowo DVPi wymuszało obecność pulpitu i obecność bibliotek emulacji windows a to podnosiło pułap urządzeń na jakich można to było uruchomić.
SvxPi zrobiłem z myślą o użytku tylko pod kątem svxlink i nie koniecznie z użyciem ekranu dotykowego, przykładem jest Quansheng hotspot extension - koncept , który pracuje na tym własnie obrazie SvxPi. Do wyświetlania panelu sterowania na wyświetlaczu 3,5" nie jest już konieczne uruchamianie srodowiska graficznego ( potocznie pulpitu ) tylko chromium jest uruchamiane z poziomu terminala ( opisane tu : aDVPi na obrazie FM Poland ) , pozwala to zaoszczędzić zasoby sprzętowe RaspberryPi i tymsamym uruchomić nawet na RaspberryPi 0W w przypadku braku wyświetlacza. Niestety świat nie jest idealny i jedyne czym obecnie dysponujemy to albo wyświetlacz OLED, lub inny do wyświetlania danych o pracy hotspot, albo rozwiązanie pochodzące z SvxHandy ver.0.2 gdzie mamy już realną możliwość sterowania , no albo ten 3,5" ekran i panel kontrolny na bazie PHP. Może kiedyś ktoś coś napisze co będzie działało jako kontroler z udziałem dotyku ale bez konieczności uruchamiania serwera www i przeglądarki chromium.
Schemat
Wielu ludzi pyta się o schemat mojego Network Radio, dlatego postanowiłem go przypomnieć. Jest to schemat pochodzący z urządzenia DVPi i konsekwentnie się go trzymam. Jak coś jest dobre to nie widzę powodu aby to zmieniać.
Oczywiście nie zawsze i wszystkie komponenty są stosowane. Schemat poniżej przewiduje jedynie PTT i dwie diody sygnalizujące status pracy, a czasami nawet ich nie ma.
Schemat a raczej jego pewien standard według DVPi jest dla mnie ważny ponieważ potem pisząc jakiś skrypt odnoszący się do GPIO to mam pewność że będzie działał w każdej mojej konstrukcji bez konieczności mapowania od nowa które GPIO za co odpowiada.
Oprogramowanie
Bazą będzie RaspiOS Lite z najnowszym SvxLink w wersji oryginalnej. Panel kontrolny będzie wyświetlany na 3,5" wyświetlaczu dzięki przeglądarce Chromium uruchamianej z poziomu terminala. Panel sterowania jest zmodyfikowaną wersją z aDVPi - 2024 finalna wersja a ten bazuje na Dashboard dla SvxLink zrobionego przez Waldka SP2ONG w ramach projektu svxlink.pl - potem FM POLAND.
Od strony programowej to zmodyfikowany został panel sterowania , i głównym celem modyfikacji było dostosowanie go do warunków mobilnych i jednocześnie dostarczenie większej liczby wiadomości i co ważniejsze w czytelniejszej dla mnie formie. Aby zaoszczędzić zasobów RaspberryPi, wyłączone zostały w większości programów możliwość tworzenia plików log , i jedynie svxlink tworzy go w pamięci RAM na wirtualnym dysku.
Główna strona otrzymała teraz jakby 3 tryby pracy. Ten poniżej pokazuje stan spoczynku, nikt nic nigdzie nie nadaje, wyświetlana jest godzina, monitorowane grupy TG, nazwa reflektora do którego jesteśmy podłączeni i czas ping do tego reflektora. UWAGA !!! zdjęcia mogą się różnić od wersji finalne i może się zdarzyć że będą w artykule zdjęcia ze starszej lub nowszej wersji - wybaczcie.
W górnym pasku mamy realny wskaźnik zasięgu WiFi oraz adres IP naszego urządzenia, ponadto element lokowania darmowego produktu :) i dalej temperaturę i zużycie procesora. czas ping reflektora jest dla mnie ważny ponieważ pokazuje w jakim stanie jest moje połączenie internetowe i niejako wskazuje potencjalne możliwości wystąpienia kłopotów w komunikacji. Oczywiście czas ping nie jest miarodajny dlatego proszę potraktować to jako wskazanie, a nie pomiar.
Wydawało mi się osobiście że pomiar czasu PING wydaje się być potrzebny w moich zastosowaniach, lecz ostatecznie tego nie będzie.
Pojawiła się też opcja NAZWY reflektora do którego jesteśmy podłączeni i pobierana jest z pliku svxlink.conf , dokładnie z sekcji [ReflectorLogic] FMNET= . Jest to wynikiem tego że SvxPi robię pod siebie i chcę mieć możliwość przełączania się pomiędzy kilkoma różnymi reflektorami. Czasami będę na naszym lokalnym HUBlink, czasami będę na FM_UK lub FM POLAND a czasami nawet na MiniLink lub innym , dlatego uznałem że jest konieczna informacja gdzie obecnie jestem podłączony.
Tryb drugi to aktywna grupa TG - znika zegar a w zamian mamy numer aktywnej TG na czerwono i poniżej nazwę tej TG. Nazwa grupy rozmownej jest dodatkiem który ma niejako ułatwić poruszanie się po sieci. Z pewnością łatwiej jest zapamiętać nazwę niż kolejny i kolejny numer. Nazwa ta jest pobierana z pliku tgdb.dat który wywodzi się z oryginalnego tgdb.php którego zrobił Waldek SP2ONG w swoim dashboard. Plik ten może być uaktualniany ręcznie przez każdego z nas co pozwala na personalizowanie sobie opisów według własnego uznania.
Tryb trzeci to ktoś nadaje - mamy ZNAK, numer TG i poniżej NAZWĘ TG a także dodatkowe informacje odnośnie pracującej stacji. Dodatkowe informacje będą pochodzić z dwóch źródeł, jednym z nich jest widoczne obecnie Local_db, czyli plik lokalny zawierający spis znaków i danych przypisanych do tego znaku.
W SvxPi po raz pierwszy pojawiło się kolorowe rozróżnienie stany TX i RX. Od teraz sygnały odbierane są wyświetlane w kolorze zielonym a nadawane w czerwonym
w połączeniu z opcjonalną sygnalizacją LED , daje to chyba dobry efekt wizualny. Oczywiście można sobie zmienić kolorystykę według własnego uznania.
W poprzedniej wersji artykułu pisałem że dodatkowe dane będą pobierane z API serwera. Otóż niestety nie będzie tego. I teraz postaram się wyjaśnić dlaczego. Jak widzicie ekran to można go podzielić na 3 części, pasek na górze ( plik system.php ) odświeżany co 15 sekund, pasek największy ( plik talk.php ) odświeżany co 2 sekundy i elementy przycisków ładowane wraz z załadowaniem strony. Problemem jest właśnie pasek środkowy który zapewnia nam własnie interaktywnych danych.
1. Problem polega na tym że jest on bardzo często odświeżany co w połączeniu z koniecznością pobrania z reflektora danych za każdym razem generuje strumień zapytań do serwera nawet gdy nikt nie rozmawia. Problemem jest sposób komunikacji z API serwera, to serwer powinien informować klienta że coś się zmieniło a nie klient bez namysłu walić pakietami do reflektora.
2. Problem to notoryczne odpytywanie się serwera generuje niepotrzebny ruch sieciowy, co w połączeniu ze słabym łączem internetowym jak GSM, powodować może negatywny wpływ na samą komunikację audio, gdyż zapychamy łącze zbytecznymi zapytaniami o API.
3. Problem to niekompatybilność danych zawartych w plikach node_info.json a tym samym potem w API serwera. Nie ukrywam że jak zaczynałem na svxlink.pl ( potem FM POLAND ) to nie widziałem w tym problemu, natomiast problem się pojawia jeśli ktoś nie jest tylko do jednego reflektora podłączony, i okazuje się że w większości albo nie ma wsparcia API, albo jak jest to jest ono oparte o oryginalny format node_info.json. Nie ma potrzeby polemizować na ten temat, kazdy buduje jak mu wygodnie.
Rozwiązanie: API w SvxPi nie będzie wspierane i to rozwiąże wszystkie problemy jakie były w aDVPi, gdyż wielu kolegów z europy pisało że ten element albo im nie działa albo nie działa prawidłowo i jak się go albo pozbyć albo dostosować. Aby jednak uzupełnić lukę w postaci źródła takich danych jak imię ( API nie dostarczało tego parametru ) , lokalizację i przykładowo mode jako info czy to przemiennik, czy network radio czy hotspot postanowiłem pobawić się lokalną bazą userdb.dat, która będzie odpowiedzialna za wyświetlanie podstawowych informacji o kliencie.
Tym samym SvxPi jest odcięty od online data i bazuje na pliku log programu svxlink oraz dwóch plikach zawierających spis nazw TalkGroup i danych rozmówców.
DTMF
Zmieniłem także rozmiar wirtualnej klawiatury aby łatwiej było trafić w przyciski z poziomu obsługi w samochodzie.
MEMO
Wzbogacona została o większa ilość przycisków i wynika to z przeniesienia tu przycisków szybkiego wyboru dostępnych prędzej w panelu głównym. Przyciski te można sobie dowolnie programować i zmieniać ich nazwy - opis w konfiguracji
SvxLink
Zakładka ta pierwotnie była dedykowana na pamięci dla modułu EchoLink ( wywołania połączenia do konkretnego echolink klienta ) lub uruchamianie modułów svxlink jak EchoLink, Parrot czy pogoda, lecz może być z powodzeniem używana jako więcej pamięci dla reflector TG.
Config
Jest jeszcze w trakcie modyfikacji i możliwe są jeszcze zmiany. Przeniosłem tu możliwość włączenia klienta FRN , a także jest już tu opcja SvxReflector switch oraz jest UPDATE który jest dedykowany pod Nasz serwer.
Wspomniany SvxReflector Switch to nic innego jak opcja pozwalająca na przełączanie się pomiędzy różnymi reflektorami. Oczywiście dany tych reflektorów musza być prędzej zdefiniowane przez użytkownika ponieważ zawsze jest tak że na jednym reflectorze mamy inne dane logowania, adresy i porty połączenia ale nawet grupy monitorowane czy domyślne. Przykładowo moje połączenie z FM_UK a FM Poland jest na innym znaku, haśle, monitorowanych grupach i aktywnej grupie - wybranie jednego z tych przycisków zmienia dane zawarte w pliku svxlink.conf i restartuje svxlink.
UWAGA !!! przyciski te nadpisują plik svxlink.conf i jeśli nie są one odpowiednio skonfigurowane naciśnięcie ich spowoduje wymazanie danych połączenia z reflektorem. Więcej o konfiguracji tego elementu w dalszej części poświęconej konfiguracji.
FRN client - to załączany na stałe zakładka która pozwala na komunikacje z serwerami Free Radio Network. Moduł FRN wywoływany jest komendą dtmf 7# przypisaną do przycisku zielonego i rozłączenie następuje poprzez DTMF # przycisk czerwony. W prostokątnym okienku pokazuje sie nam Znak i Imię korespondenta z sieci FRN.
Lastheard to informacje o ostatnio słyszanych stacjach - ale tylko z grup jakie monitorujemy
Wspomniany także przycisk UPDATE daje nam do wyboru co chcemy EKSPERYMENTALNIE uaktualnić, listę nazw grup TG czy listę klientów Znaków i przypisanych do nich takich danych jak Imie, QTH czy Mode.
Przycisk Add USER Record prowadzi Nas do takiej prostej strony która pozwoli na ręczne przypisanie do znaku dodatkowych informacji.
Informacje te są widoczne są w rubrykach Name , QTH i Type ( w aktualnej wersji INFO )
Podobnie sprawa wygląda z nazwami grup TG.
Pierwsze uruchomienie / konfiguracja / personalizacja
Postaram się wyjaśnić co autor miał na myśli o może uda mi się objaśnić ten zawiły proces konfiguracji.
Zacznijmy od informacji że svxlink jest nie modyfikowany i można znaleźć pełne wsparcie w internecie. Celowo trzymam się oficjalnej edycji ponieważ potem jest większe pole manewru ze znalezieniem wsparcia przy rozwiązywaniu problemów.
Należy także zapamiętać że czym innym jest konfiguracja svxlink - który może działać samodzielnie a czym innym jest konfiguracja SvxPi który wymaga svxlink uruchomionego i działającego poprawnie.
Po zalogowaniu się poprzez SSH ( login: pi hasło raspberry ) zobaczymy takie oto okno. Starałem się ułatwić życie u przygotowałem zestaw komend które mają prowadzić w konkretne miejsce bez konieczności wpisywania długich komend.
Komendy pomocnicze zostały podzielone na te potrzebne do konfiguracji svxlink i te do konfiguracji SvxPi. Wydając komendę svxlink-help dostaniemy spis wszystkich komend jakie mogą nam się przydać. Mamy komedę svxlink-start i stop która uruchamia lub wyłącza program. svxlink. Mamy także svxlink-config który jest odpowiednikiem komendy sudo nano /etc/svxlink/svxlink.conf i pozwala nam na dostęp do pliku konfiguracyjnego svxlink. Analogicznie -info, -echolink, -frn, -log dają nam bezpośredni o szybszy dostęp do plików konfiguracyjnych.
Komendy svxpi służą pomocą w konfiguracji samego elementu graficznego, personalizacji ustawień, przycisków i innych.
svxpi-config - pozwala na konfigurację przycisków pamięci MEMO.
svxpi-ref1 do 5 - pozwala na konfigurację przycisków przełączania pomiędzy SvxReflektorami
Podchodząc do pierwszego uruchomienia warto sprawdzić jaki numer ma nasza karta dźwiękowa - powinna mieć numer card 0 - będzie to nam opcjonalnie potrzebne do konfiguracji svxlink.
Wydajemy komendę svxlink-config lub sudo nano /etc/svxlink.conf i przechodzimy do części [ReflectorLogic] gdzie uzupełniamy dane logowania na svxreflector
Uaktualniamy ustawienia squelch SQL w części [Rx1] - i tu ważna sprawa. SQL w network radio odpowiada za PTT w kierunku internetu. Czasami z przyzwyczajenia że PTT to Radio i załączanie nadawania, budując Network Radio zapominamy że nasze PTT w mikrofonie odpowiada za otwarcie SQL. Postawienie wykrzyknika przed cyfrą odwraca "polaryzację" - zmienia ustawienie czy to stan wysoki czy niski na GPIO załącza SQL.
W części [Tx1] mamy parametr PTT które jest zbyteczne w Network Radio, lecz można tego sygnału użyć do diody LED wskazującej nam że ktoś nadaje.
Po takiej wstępnej konfiguracji można podejść do pierwszego uruchomienia. Warto to zrobić recznie w terminalu aby można było obserwować jak się uruchomił svxlink i czy nie ma jakiś błędów.
Abu uruchomić svxlink ręcznie wydajemy komendę zakończenia pracy svxlink-stop lub sudo systemctl stop svxlink a następnie wydajemy komendę svxlink
W terminalu będziemy mogli zobaczyć także aktywność innych stacji z grup monitorowanych
ale także wpisy kiedy my naciśniemy przycisk PTT i svxlink wykryje to jako Rx1: The squelch is OPEN
Warto w między czasie sprawdzić na dashboard serwera SvxReflector czy jesteśmy widoczni i czy dashboard poprawnie reaguje na nasze PTT. Jak już jesteśmy przy dashboard to część serwerów posiada mapy podłączonych klientów.
Za wyświetlanie danych na mapie odpowiedzialny jest plik node_info.json którego możemy edytować komendą svxlink-info lub sudo nano /etc/svxlink/node_info.json
Niestety tu będzie problem ponieważ istnieje wiele wariantów i formatów tego pliku dlatego warto zapoznać się z z preferencjami serwera do którego się podłączamy. Przedstawiony przykład jest oryginalnym pochodzącym z od producenta svxlink i kompatybilny z svxportal.
SvxPortal potrafi zmieniać kolory pinesek na mapie wskazując jaki jest ich status, RX czy TX poprzez kropkę w środku, i kolor pineski jest przypisany do grupy TG. Dzięki temu można obserwować na mapie festiwal kolorów i przeskakiwania statusów. Daje to fajny wodotrysk w postaci monitorowania całej narodowej sieci i jej pracy na mapie.
Po wstępnej konfiguracji można już spokojnie uruchomić naszego klienta i przejść do konfiguracji poziomów audio.
svxlink-start - komenda uruchomienia svxlink
alsamixer - zmiany poziomów ustawienia karty dźwiękowej.
sudo alsactl store - zapisanie ustawień alsamixer
Poziom audio mikrofonu ludzie ustawiają na różne sposoby, są wbudowane nagrywaczki we wsady, można na ucho korespondenta, Ja osobiście nagrywam sobie swoje audio poprzez funkcję QSO recorder, wciagam to nagranie z RaspberryPi programem jak WinSCP i następnie ładuję go na jakiś program typu GoldWave czy Audacity. Dzięki temu moge nagrywać i sprawdzac zarówno własne jak i czyjeś audio z sieci. Polecam się tym pobawic a sami zobaczycie ile stacji chodzi na głebokim przesterowaniu - byle tylko głośniej.
Formalnie mamy uruchomiony svxlink, podłączony do serwera, ustawione GPIO dla SQL , uzupełniony plik node_info i poziomy głośności na akceptowalnym poziomie - to oznacza że wstępna konfiguracja svxlink dobiegła końca.
SvxPi konfiguracja
Konfigurację SvxPi rozpoczniemy od przypomnienia sobie pomocniczych komend svxpi-help
Zajmiemy sie teraz personalizacją przycisków szybkiego wybierania tak zwanych MEMO
Aby zmienić sobie w przyciskach nazwy i przypisane do nich grupy TG wydajemy komendę svxpi-config
Zobaczymy plik /var/www/html/480x320/include/config.php w którym możemy zmienić ustawienia wszystkich przycisków dostępnych w svxpi.
Przykładowo chcemy zmienić przycisk Memo1 który obecnie ustawiony jest na TG1 na grupę TG9990 o nazwie EchoTest.
Oryginalna linijka:
define("KEY111", array('Memo1','911#','green'));
zmodyfikowana linijka:
define("KEY111", array('EchoTest','919990#','green'));
i wynik na pulpicie sterowania:
Możemy tak sobie zmienić wszystkie przyciski podmieniając cyfry i nazwy, nalezy pamiętac że 919990# to kod DTMF, tak więc na cokolwiek zmieniamy to zawsze musi to być kod DTMF zaczynający się od 91 dla TG i # na zakończenie.
Procedura ta dotyczy także zakładki SvxLink
Kolejnym elementem który można sobie spersonalizować jest menu wyboru SvxReflector.
Wskazane nazwy są moją roboczą wersją i w finalnej wersji będą miały nazwy z gatunku Reflector 1 , Reflector 2 itd.
NIE NACISKAJ, nigdy przenigdy nigdy zanim nie dokonasz konfiguracji - w przeciwnym razie czeka cie ponowna konfiguracja svxlink a dokładnie wpisanie danych logowania do [ReflectorLogic]
JAK TO DZIAŁA
Stosunkowo prosto, każdy z przycisków aktywuje jeden z 5 skryptów, których zadaniem jest podmiana danych logowania w [ReflectorLogic] - obecnie są puste i ich naciśnięcie spowoduje wykasowanie danych z pliku svxlink.conf.
Tak więc mamy 5 przycisków i 5 sktyptów do nich przypisanych, to jak to ustawić wszystko? Jeśli potrzebujesz używać Network Radio SvxPi na więcej niż jednym serwerze to dalszy opis jest dla ciebie. Natomiast jeśli chcesz pracować tylko na jednym to nie używaj tych przycisków, nigdy nie dotykaj i wszystko będzie OK.
svxpi-ref1 to komenda konfigurująca pierwszy przycisk o nazwie HUBlink - celowo przedstawię Wam moją konfigurację , może wzrokowcy lepiej zrozumieją.
W rubryki new_ trzeba wpisać własne dane odpowiadające formatowi z pliku svxlink.conf, czyli:
new_hosts - adres serwera
new_port - port serwera
new_callsign - nasz znak logowania
new_auth_key - nasze hasło do reflektora
new_default_tg - domyślna grupa TG
new_monitor_tgs - monitorowane grupy TG
new_fmnet - nazwa naszego serwera
new_api - adres API naszego serwera ( w przypadku SvxPi nie jest potrzebna )
W taki samo sposób konfigurujemy kolejne przyciski komendami svxpi-ref2 , svxpi-ref3 itd.
Jak widzicie daje to możliwość przypisania do konkretnego serwera innej grupy domyślnej i innych grup monitorowanych, co daje komfort poruszania się po różnych serwerach
Po dokonaniu tej konfiguracji , proszę zapamiętać iż TERAZ to te pliki są odpowiedzialne za zmiany w grupach monitorowanych. Jeśli przykładowo będąc na serwerze "A" zechcenie dopisać w pliku svxlink.conf grupę 1 do monitorowanych to pamiątajcie że po przełączeniu się serwera "A" na "B" o ponownie na "A" grupy monitorowane zostaną zmienione na te które są w svxpi-ref. Dlatego warto właśnie w svxpi-ref zmieniać grupy monitorowane i domyślne.
Po konfiguracji należy się upewnić że wszystko działa i porównać wyświetlane dane na panelu sterowania z dashboard reflektora.
Jak wspomniałem w finalnej wersji nazwy przycisków będą typu Reflector 1 , Reflector 2 itd, aby to zmienić trzeba edytować plik komendą svxpi-reflector, odszukać w nim linijki odpowiedzialnej za przyciski i zmienić nazwę i kolory
Dla przykładu jak widzicie mam MiniLink na szaro ponieważ muszę uważać i nie używać tego przycisku na TYM konkretnym urządzeniu , ponieważ mogę być zalogowany z innego - mam jeden login i hasło.
UPDATE
Update to eksperyment który z pewnością przyda Nam się w ramach HUBlink. O ile UPDATE TG jest normalne i realizowane w innych obrazach i sieciach, my postanowiliśmy po rezygnacji z API, bo nie wszystkie serwery go wspierają, poszukać alternatywnego źródła pozyskania danych. Zamysł jest taki że Update TG i Update User będzie pobierało aktualne dane z serwera i zastępowało plik na RaspberryPi, dzięki czemu jeden klik i wszystko działa.
Przycisk Add USER record prowadzi do strony która pozwala ręcznie przypisać do znaku dodatkowe informacje
Wszystko po to aby zamiast posiadania tylko znaku u numeru TG oraz przypisanego do tego numeru nazwy, mieć coś więcej niż puste pola.
Dlatego bawiąc się tym projektem poszedłem w kierunku lokalnej bazy / pliku ze spisem krótkofalowców i bramek, hotspotów i interlinków.
Baza Grup TG
Add TG record prowadzi nas do takiej strony, gdzie w łatwy sposób możemy sami mobie nadać nazwę przypisaną grupie TG
Oto przykład przy braku danych dla konkretnego TG
A tak wygląda po przypisaniu nazwy konkretnemu numerowi TG
Pewnie wielu zada pytanie po co to skoro można zrobić bazę danych numerów TG i ich nazw i mieć to już we wsadzie, ba nawet można je aktualizować - TAK tylko nie zapominajcie że Wy poruszacie się w ramach jednego serwera, nie jest problemem zrobić taką listę pod jeden konkretny serwer, problem się robi jak chcesz mieć listę z kilku serwerów, w moim przypadku 5. Różne języki, nazwy, kolizje numerów TG bo jakiś serwer postanowił używać TG nie pochodzących z jego kodu ID kraju, nikt nie będzie chciał takiej bazy ogarniać i za jej poprawność odpowiadać, dlatego odpowiedzialność za bazę TG oddaje w ręce posiadaczy SvxPi.
EXTRA dodatki
PTT LED
Jest to skrypt monitorujący GPIO na którym mamy ustawione PTT ( SQL w svxlink ) i na jego podstawie zapala diode czerwoną na innym GPIO. W sumie ekran pokazuje to samo ponieważ sygnalizuje nadawanie ale czas zwłoki i przyzwyczajenie do diody RX i TX powodują że zostało to wzięte z projektu aDVPi to SvxPi także. Uruchamianie tego jest opcjonalne dlatego jest odpowiedni przycisk w Config.
Rotary Encoder
Rotary Encoder w różnych projektach jeszcze pozostaje. moje SvxPi ma generalnie w tym miejscu głośnik, ale obudowa projektowana pod DVPi ma encoder i postanowiłem dodać jakąkolwiek funkcjonalność.
Jest to prosty skrypt emulujący klawisze TAB i ENTER
Podsumowanie
Mam nadzieje że opisałem wszystkie zagadnienia. W miarę jak mi pamieć coś przyniesie to dodam artykułu
Obraz na RaspberryPi można pobrać w dziale DOWNLOAD plik o nazwie SvxPi-Lite_2025.zip lub za pośrednictwem tego linku https://d4a.uk/index.php/pobieranie/category/1-raspberrypi?download=75:svxpi-lite