Cross-band’owy digipeater/iGate APRS FM/LoRa oparty na aprx

Jako fan komunikacji zawsze pociągało mnie zagadnienie modulowania sygnału radiowego celem przesyłania informacji. Na początku drogi związanej z krótkofalarstwem dotarły do mnie sygnały, że istnieje prastary sposób na transfer danych nisko przepustowym kanałem w oparciu o protokół AX.25. Mowa tu o APRS. Początkowe wczytywanie się w to o co chodzi i kto tego używa zupełnie mnie nie porwało, ale gdy zobaczyłem, że poza jednokierunkowym zalewaniem Internetu danymi z odbiorników radiowych, istnieje sposób na dwukierunkowe przesyłanie wiadomości pomiędzy urządzeniami w 100% falami eteru oczy zaświeciły mi się jak pięciozłotówki. Świeciły tak do czasu, gdy okazało się, że aby wszystko to dobrze działało należy rozwijać infrastrukturę naziemną, której krajowy niedobór powoduje, że cała zabawa albo przechodzi do Internetu (sic!), albo zwyczajnie się kończy ponieważ nie ma czym dalej przesyłać informacji radiowo. Tak narodził się pomysł budowy APRS-owego digipeatera celem poznania technologii, oraz wypełnienia luki pokrycia zasięgu w moim QTH.

Jak do tego doszło

Pewnego dnia, gdy miałem okazję zabrać ze sobą radio do pracy, całkiem przypadkowo, przeprowadziłem QSO z Ryśkiem SQ9MDD, który przyjechał w pewnych sprawach do Wrocławia. W trakcie łączności zeszło na temat APRS i tak od słówka do słówka i Rysiek odwiedził mnie w biurze oraz przekazał 2 sztuki płytek do budowy VPDIGI. Rzeczone urządzenie to samodzielna realizacja digipeatera APRS z obsługą zaawansowanych funkcji nowoczesnej sieci APRS. Ze względu na możliwość komunikacji po USB VPDIGI i wsparciu dla protokołu KISS z powodzeniem może być integrowane także w większych systemach. Przy okazji spotkania rozmawialiśmy też o powstającej infrastrukturze APRS opartej o modulację LoRa i wyzwaniach związanych z jej budową. Emisja ta znalazła swoje miejsce w paśmie 70[cm] i jest doskonałym uzupełnieniem dobrze znanej wersji FM w paśmie 2[m]. Na koniec spotkania omówiliśmy koncepcyjne rozwiązanie międzypasmowej bramki retransmitującej radiowo dane APRS pomiędzy pasmami 2[m] FM, a 70[cm] LoRa. Biorąc pod uwagę moje rosnące zainteresowanie APRS-em i możliwość uruchomienia swojej konstrukcji w miejscu, gdzie nie ma pokrycia sieci bez wahania zabrałem się za studiowanie materiałów i przygotowania do budowy urządzenia.

Elementy systemu

Do zbudowania w pełni działającej bramki cross-bandowej dla APRS pozwalającej na radiową retransmisję i przerzucanie pakietów pomiędzy pasmami 2[m] FM i 70[cm] LoRa wymagane jest zgromadzenie kilku elementów dzięki którym warstwy: radiowa i oprogramowania sterującego mogą rozpocząć współpracę.

Rozwiązanie, którego budowy się podjąłem, wymagało użycia:

• Baofeng UV-5R – radiotelefon amatorski o mocy 5[W] będący analogowym interfejsem radiowym do emisji FM w paśmie 2[m],
• LILYGO LoRa 433MHz – płytka rozwojowa IoT będąca cyfrowym interfejsem radiowym do emisji LoRa w paśmie 70[cm],
• płytka VPDIGI – płytka bazowa digipeatera APRS wykorzystana tu jako element tworzący interfejs cyfrowy do analogowej części radiowej będącej transceiverem na pasmo 2[m],
• STM32 Bluepill – płytka rozwojowa na platformę STM32, użyta jako element składowy VPDIGI,
• Raspberry PI 3B+ – centralne sterowanie, gdzie uruchomiony jest program aprx zarządzający odbiorem, analizą i transmisją pakietów APRS,
• duplekser VHF/UHF MX72 – umożliwiający jednoczesną komunikację przez oba interfejsy radiowe z wykorzystaniem jednej dwupasmowej anteny 2[m]/70[cm],
• zasilacz moudułowy 5[V] Meanwell RS-25-5 – centralny punkt zasilający dla Raspberry PI i podłączonych interfejsów, oraz jako źródło mocy dla radia 2[m],
• moduł przetwornicy step-up XL6009 – pozwala na wytworzenie zasilania niezbędnego do pracy analogowego radia 2[m],
• eliminator baterii do UV-5R – umożliwiający zasilanie radia 2[m] wprost z przetwornicy bez potrzeby korzystania z akumulatorów czy baterii,
• ELEKTRO-PLAST 2719-00 – uszczelniana obudowa IP65 220x270x106,
• Diamond X30N – dwupasmowa antena 2[m]/70[cm] ze złączem N,
• połączeniowe kable audio, złącza, przejścia i kable radiowe, kable USB, złącza zasilania powerCON,
• opaski winylowe “tryty”, uchwyty montażowe klejone do mocowania “trytów”.

Jak to działa

Centralny element systemu to komputer sterujący oparty o system operacyjny Linux. W tej roli wykorzystałem Raspberry PI 3+ (RPi), na którym pracuje oprogramowanie aprx (może to być dowolny i mniej wydajny system oparty o Linux, na którym można zainstalować/skompilować aprx). RPi podłączone jest do Internetu za pomocą WiFi, co umożliwia jego zdalne zarządzanie jak i dostęp programu aprx do danych sieci APRSIS. VPDIGI z na stałe przyłączoną płytką STM32 Bluepill tworzy cyfrowy interfejs dla analogowego radiotelefonu FM 2[m]. Interfejs ten pracuje w standardzie KISS i dołączony jest do RPi za pomocą USB. Sam radiotelefon dołączony jest do płytki bazowej VPDIGI przy pomocy kabli audio z końcówkami Jack 2.5[mm] i 3.5[mm]. Sygnały dźwiękowe przetwarzane są w soft-modemie zaimplementowanym w oprogramowaniu VPDIGI pracującym na Bluepill. Połączenie kablowe poza przenoszeniem sygnału audio pozwala także na realizację funkcji PTT. LILYGO jest zintegrowanym interfejsem radiowym LoRa dla pasma 70[cm] dostępnym dla RPi po protokole KISS przez USB. Oba radia dołączone są do dwupasmowej anteny za pomocą dupleksera VHF/UHF, a całość zasilana jest z zasilacza modułowego 5[V]/5[A]. Mniejsza moc zasilacza nie pozwala na poprawną pracę ze względu na zapady napięcia wywołane udarami prądowymi podczas nadawania radiem FM. Napięcie potrzebne do poprawnej pracy radiotelefonu dostarczane jest z przetwornicy podwyższającej. Całość zamknięta jest w szczelnej obudowie z tworzywa sztucznego, zaś dostęp sygnałowy na zewnątrz zrealizowany jest przez dwustronne złącze żeńskie N (sygnał radiowy) oraz gniazdo zasilające 230[V] typu powerCON.

Aprx, pracujący na RPi, jest oprogramowaniem digipeatera/iGate APRS. Nasłuchuje pakietów APRS na zdefiniowanych interfejsach, oraz informacji otrzymywanych z internetowego serwisu APRSIS. Bazując na swojej konfiguracji decyduje co zrobić z każdą z odebranych ramek. Dzięki elastyczności konfiguracji możliwa jest retransmisja lub przesyłanie danych pomiędzy interfejsami, filtrowanie oraz dodawanie usług jak na przykład bikonowanie. Warte zauważenia jest to, iż najważniejszym miejscem budowanego rozwiązania (pod względem funkcjonalności) jest plik konfiguracyjny programu aprx.

Konstrukcja prezentowanej bramki zasadniczo polega na odpowiednim podłączeniu wymaganego sprzętu i wgraniu do poszczególnych jej elementów dedykowanego oprogramowania. Cała reszta to już magia aprx.

Budowa sprzętu

Elementy zostały rozmieszczone w obudowie tak, aby dało się w łatwy sposób przeprowadzać akcje serwisowe.

Zasilacz modułowy 5[V] znajduje się blisko gniazda powerCON i bezpośrednio zasila RPi oraz moduł przetwornicy step-up. Z przetwornicy podwyższone napięcie zasila radiotelefon 2[m] przy pomocy eliminatora baterii.

VPDIGI oraz moduł LoRa przyłączone są kablami USB do RPi skąd jednocześnie czerpią zasilanie.

Radiotelefon Baofeng oraz moduł LILYGO zostały podłączone (przy pomocy dodatkowych przejściówek) do dupleksera VHF/UHF 10[cm] odcinkami kabla RG316 z zarobionymi odpowiednimi wersjami złączy SMA. Sam duplekser do podwójnego złącza N żeńskiego, zamontowanego w obudowie, podłączony został przy pomocy przejścia UHF męskie na N męskie.

Transceiver 2[m] został dodatkowo spięty z płytką VPDIGI przy pomocy kabli audio podłączanych do bocznego złącza mikrofono-głośnika w standardzie Kenwood. W moim przypadku zamiast kupowania dedykowanego rozwiązania skorzystałem z dwóch osobnych kabli zakończonych wtykami Jack stereo 2.5[mm] i 3.5[mm].

Napięcie jałowe zasilacza modułowego zostało ustalone (potencjometrem regulacyjnym) na wartość 5.2[V]. Wartość ta pozwala na nadal prawidłową pracę urządzeń dołączanych do magistrali USB, a także zapewnia margines napięcia pozwalający na poprawną pracę RPi pod obciążeniem prądowym nadającego radiotelefonu. Podczas pracy nadajnika UV5R z pełną mocą napięcie zasilacza spadało do wartości 5.05[V]

Napięcie zasilające radiotelefon, otrzymywane z przetwornicy step-up, zostało ustalone (potencjometrem regulacyjnym) na wartość ~8[V] (blisko 8.1). Jest to wartość pomiędzy napięciem nominalnym stosowanego w tym radiu pakietu akumulatorowego wynoszącym 7.4[V] a wartością w pełni naładowanego akumulatora – 8.4[V].

Konfiguracja UV5R

Jedyną rzeczą jaką należało zrobić było zapewnienie by po każdym uruchomieniu radia ustawiało się ono na kanał APRS. Stosowna konfiguracja została przygotowana w programie CHIRP i wgrana do transceivera. W pamięci znajduje się tylko jeden kanał ustawiony na częstotliwość 144.800[MHz] emitujący sygnał w wąskim FM-ie bez kodu CTCSS z maksymalną mocą.

Położenie potencjometru głośności zostało dobrane eksperymentalnie podczas kalibracji poziomu sygnałów VPDIGI – opisanych w dalszej części.

Tak przygotowany radiotelefon jest gotowy do pracy.

Konfiguracja VPDIGI

Po zmontowaniu elektroniki i wgraniu oprogramowania na płytkę Bluepill należy przeprowadzić kalibrację. Ustawienia domyślne oprogramowania umożliwiają pracę urządzenia jako KISS TNC.

Do komunikacji z płytką potrzebne jest ustalenie pod jaką ścieżką w systemie dostępne jest VPDIGI. W tym celu przed, oraz po podłączeniu kabla USB należy wykonać listing urządzeń ttyACM, żeby zaobserwować nowo pojawiający się interfejs. Komenda listująca to:

cat /dev/ttyACM*

W moim przypadku system przydzielił oznaczenie ttyACM0.

Następnym krokiem jest przeprowadzenie prostej konfiguracji polegającej na określeniu sposobu wytwarzania przebiegów audio oraz kalibracji poziomu sygnału nadawanego, a także czułości odbiornika. Żeby to zrobić należy podłączyć się do urządzenia jakimkolwiek programem terminalowym. W moim przypadku był to minicom. Z racji tego, że nie był on dostępny w systemie dokonałem jego instalacji komendą:

sudo apt update && sudo apt -y install minicom

Po zainstalowaniu należy uruchomić minicom w trybie konfiguracji i ustalić parametry połączenia szeregowego:

sudo minicom -s

W pojawiającym się menu tekstowym należy wybrać “Serial port setup” i skonfigurować następujące parametry:

• Serial Device – /dev/ttyACM0
• Bps/Par/Bits – 9600 8N1

Reszta opcji bez zmian. Po zatwierdzeniu ekran podsumowania powinien wyglądać jak poniżej.

Po potwierdzeniu parametrów łącza z menu głównego należy wybrać opcję “Exit“, która spowoduje opuszczenie trybu konfiguracji i otwarcie ustalonego połączenia.

Parametryzacja

Standardowo VPDIGI uruchamia się w trybie KISS i nie daje echa dla przesyłanych znaków. Z tego powodu wpisywanie czegokolwiek na klawiaturze nie będzie miało wizualnego efektu. Żeby przełączyć urządzenie w tryb konfiguracji należy wpisać słowo “config” i nacisnąć Enter. Wówczas pokaże się menu konfiguracyjne, a w oknie terminala będzie pojawiać się echo wpisywanych znaków.

Skonfigurowaniu podlega sposób pracy programowego przetwornika DAC. Dla nowszych wersji oprogramowania zaleca się stosowanie trybu PWM co wraz z akompaniującym obwodem elektronicznym dostępnym na płytce VPDIGI v2 daje możliwość generowania tonów audio kodujących dane APRS.

Komenda konfigurująca sposób generowania tonów to::

pwm on

Potwierdzenie wprowadzonej zmiany można uzyskać korzystając z opcji

print

zaś, bezwzględnie wymagany, zapis ustawień do pamięci nieulotnej realizuje się komendą:

save

W najnowszej wersji oprogramowania (2.0.0+) to ustawienie jest domyślne i nie trzeba go modyfikować.

Kalibracja

Aby ustalić poziomy sygnałów audio dla poprawnej współpracy z dołączonym radiotelefonem analogowym należy dokonać regulacji torów: odbiorczego i nadawczego korzystając z potencjometrów zamontowanych na płytce urządzenia. By dokonać regulacji należy przełączyć VPDIGI w tryb monitorowania komendą:

monitor

Pierwszym elementem kalibracji jest ustawienie odpowiedniej czułości toru odbiorczego. Poziom sygnału odbieranego weryfikuje się odczytując go z pojawiających się w terminalu raportów odebranych pakietów. Przykładowy początek linii z raportem wygląda tak:

(AX.25) Frame received [FP], signal level 89%

Z linii tej dowiadujemy się jakiego typu ramka danych została zdekodowana, ale co bardziej istotne z jakim poziomem sygnału. Instrukcja głosi, że należy wykonać czasowy nasłuch i spróbować tak doregulować wartość potencjometru oznaczonego INPUT LVL, żeby średnio rzecz biorąc siła odbieranych sygnałów oscylowała w okolicy 50%, a na pewno w zakresie poniżej 100%. Jest to operacja “na słuch” i angażuje nie tylko potencjometr na płytce VPDIGI lecz także ten regulujący głośność radiotelefonu i czas.

W przypadku takim jak mój, gdy w czasie budowy digipeatera w pobliżu nie było słyszalnych ramek APRS, posiłkowałem się własnoręcznie nadawanymi danymi testowymi korzystając z radia ręcznego Anytone 878. Kilka emisji przeprowadziłem w bliskim sąsiedztwie anteny, a kilka oddalając się z radiotelefonem na odległość około 1[km].

Drugim krokiem kalibracji było dobranie poziomu sygnału nadawanego. Polegało to na emisji tonu wysokiego (modulacji AFSK) i regulacji potencjometrem oznaczonym OUTPUT LVL amplitudy sygnału do wartości, kiedy na dowolnym (lecz dostrojonym do częstotliwości pracy nadajnika) radiu nie będzie słychać dalszego wzrostu głośności odbieranego sygnału audio. Emisję testową tonu wysokiego uruchamia się poleceniem:

cal high

Aby, po regulacji, wyłączyć ton testowy należy wprowadzić komendę:

cal stop

Zakończenie

Aby zakończyć proces konfigurowania VPDIGI należy przełączyć urządzenie spowrotem w tryb KISS wydając polecenie:

kiss

W terminalu nie będzie już dostępne lokalne echo i wpisywane z klawiatury znaki nie będą widoczne na ekranie. VPDIGI jest gotowe do pracy pod nadzorem aprx.

Konfiguracja LILYGO

Po wgraniu i skonfigurowaniu oprogramowania dla płytki LoRa jest ona dostępna po USB jako KISS TNC.

Zgodnie ze sposobem detekcji nazwy urządzenia opisanym w części “Konfiguracja VPDIGI” należy ustalić jak urządzenie widoczne jest dla systemu operacyjnego pracującego na RPi. W moim przypadku było to /dev/ttyACM1. Informacja ta plus wiedza o prędkości połączenia szeregowego (ustalona na 115200 8N1) potrzebne są do wykonania poprawnej konfiguracji programu aprx.

Sposób wgrywania oprogramowania i konfigurację (częstotliwość i parametry transmisji) dla interfejsu LoRa przedstawię niebawem.

Moduł radiowy LoRa jest gotowy do pracy pod nadzorem aprx.

Konfiguracja aprx

Do pracy z RPi wybrałem lekką wersję systemu operacyjnego (bez trybu graficznego) dedykowaną na tą platformę. Sam program aprx zainstalowałem korzystając z managera apt dystrybucji raspbian. Instalacja sprowadziła się do wydania komend:

sudo apt update && sudo apt -y install aprx

Po instalacji w katalogu /etc utworzony został plik aprx.conf, który od razu skopiowałem by móc do niego wrócić w razie potrzeby. Kopia wykonana została poleceniem:

cp /etc/aprx.conf /etc/aprx-original.conf

Następnie przystąpiłem do konfiguracji budowanej bramki polegającej na edycji pliku /etc/aprx.conf przy pomocy edytora nano:

sudo nano /etc/aprx.conf

Mając oryginalny, referencyjny, plik konfiguracyjny i kilka informacji zebranych z różnych źródeł zacząłem wprowadzać do wyczyszczonego pliku kolejne sekcje konfiguracji. Na początek dane globalne o znaku stacji i pozycji geograficznej bramki (znak wywoławczy oraz dane z “X” należy poprawić):

mycall                N0CALL
myloc                 lat 51XX.XXN lon 017XX.XXE

Następnie dodałem sekcję aprsis konfigurującą dostęp do danych APRSIS + filtrowanie potencjalnie emitowanych radiowo ramek zawierających informacje o położeniu. Owo filtrowanie służy ograniczeniu nadawania informacji nie przeznaczonych dla bliskiego sąsiedztwa mojego nadajnika (dane z “X” należy zastąpić hasłem dostępowym do serwisu APRSIS):

<aprsis>
    login             $mycall
    passcode          XXXX
    server            euro.aprs2.net 14580
    filter            "m/6" # accept packets in 6km range
</aprsis>

Kolejnym elementem pliku konfiguracyjnego stała się sekcja odpowiedzialna za ustalenie gdzie i pod jakimi nazwami będą zapisywane dwa istotne logi programu: log związany z pracą aprx i log związany z aktywnością sieciowo/radiową w obszarze APRS:

<logging>
    rflog             /tmp/aprx-rf.log
    aprxlog           /tmp/aprx.log
</logging>

Następny element pliku konfiguracyjnego to zdefiniowanie obu wykorzystywanych interfejsów radiowych (znak wywoławczy oraz SSID należy poprawić):

<interface>           # 2m AFSK 1200 via vpdigi
    callsign          N0CALL-1
    serial-device     /dev/ttyACM0 9600 8n1 KISS
    tx-ok             true
    telem-to-is       false
    alias             WIDE,SP
</interface>

<interface>           # LoRa via TTGO-433
    callsign          N0CALL-2
    serial-device     /dev/ttyACM1 115200 8n1 KISS
    tx-ok             true
    telem-to-is       false
    alias             WIDE,SP
</interface>

W kolejnym etapie pora na zdefiniowanie parametrów bikonowania czyli automatycznego rozgłaszania radiowego o dostępności bramki na każdym z pasm. 15[min] okres cyklu daje naprzemienną emisję informacji z każdego interfejsu co około 7.5[min] (znak wywoławczy oraz SSID należy poprawić).

<beacon>
    mode              radio
    cycle-size        15m
    beacon            interface N0CALL-1 via WIDE1-1 srccall N0CALL-1 symbol "/#" $myloc comment "FM Digi/iGate AFSK 1K2 crossed with LoRa N0CALL-2"
    beacon            interface N0CALL-2 via WIDE1-1 srccall N0CALL-2 symbol "L#" $myloc comment "LoRa Digi/iGATE AFSK 1K2 crossed with FM N0CALL-1"
</beacon>

Ostatnimi wpisami są, dedykowane poszczególnym interfejsom radiowym, zasady pracy digipeatera. Określają one jakie informacje pojawiające się na dostępnych źródłach danych (interfejsy radiowe lub sieć APRSIS) mogą być emitowane w eter. Część ta jest esencją pracy z programem aprx pozwalając na dużą elastyczność w kreowaniu możliwości digipeatera, który nie tylko potrafi obsługiwać emisję danych z Internetu czy odbijać ramki radiowe, ale także przepuszczać ruch pomiędzy interfejsami – co w przypadku tej konstrukcji jest przechodzeniem pomiędzy technologiami FM i LoRa.

Sekcja digipeatera dla interfejsu FM wygląda następująco (znak wywoławczy oraz SSID należy poprawić):

<digipeater>          # DIGI 2m
    transmitter       N0CALL-1

    <source>          # 2m
        source        N0CALL-1
        relay-type    directonly
        viscous-delay 5
        ratelimit     30 60
    </source>

    <source>          # LoRa
        source        N0CALL-2
        relay-type    digipeated
        viscous-delay 3
        ratelimit     60 120
    </source>

    <source>          # APRSIS
        source        APRSIS
        relay-type    third-party
        ratelimit     30 60
        filter        t/mq # messages and querries
        filter        m/5  # 5km range
        msg-path      WIDE1-1
    </source>

    <wide>
        maxreq        3
        maxdone       3
        keys          SP,ECHO
    </wide>

    <trace>
        maxreq        3
        maxdone       3
        keys          WIDE
    </trace>
</digipeater>

Sekcja digipeatera dla interfejsu LoRa wygląda następująco (znak wywoławczy oraz SSID należy poprawić):

<digipeater>          # DIGI LoRa
    transmitter       N0CALL-2

    <source>          # 2m
        source        N0CALL-1
        relay-type    directonly
        viscous-delay 5
        filter        s/[b # pedestrians and bikes
        filter        t/m  # messages
        filter        m/5  # 5km range
        ratelimit     30 60
    </source>

    <source>          # LoRa
        source        N0CALL-2
        relay-type    digipeated
        viscous-delay 3
        ratelimit     60 120
    </source>

    <source>          # APRSIS
        source        APRSIS
        relay-type    third-party
        ratelimit     30 60
        filter        t/mq # messages and querries
        filter        m/5  # 5km range
        msg-path      WIDE1-1
    </source>

    <wide>
        maxreq        3
        maxdone       3
        keys          SP,ECHO
    </wide>

    <trace>
        maxreq        3
        maxdone       3
        keys          WIDE
    </trace>
</digipeater>

Podane wyżej sekcje tworzą cały plik konfiguracyjny, który zapisałem korzystając z kombinacji klawiszy CTRL+x, potwierdzając następnie chęć zapisania zmian klawiszem “Y” i na koniec zatwierdzając ścieżkę docelowego pliku klawiszem Enter.

Po zakończeniu procesu konfigurowania bramki, bazującym na edycji pliku /etc/aprx.conf, włączyłem automatyczne uruchamianie procesu aprx przy każdym starcie systemu komendą:

sudo systemctl enable aprx

po czym uruchomiłem go w bieżącej sesji komendą:

sudo systemctl start aprx

i sprawdziłem czy jest aktywny wpisując:

sudo systemctl status aprx

W logu statusowym pojawił się, między innymi, wpis:

Active: active (running)

co oznaczało, że wszystko działa jak należy. W przypadku błędów z uruchomieniem programu status zawierałby informację:

Active: inactive (dead)

Przed zakończeniem prac sprawdziłem najnowszy wpis loga programu komendą:

cat /tmp/aprx.log

w którym pojawiły się informacje o: wersji uruchomionego programu, stanie otwarcia portów szeregowych do współpracy z interfejsami radiowymi, oraz połączeniu z siecią APRSIS:

2023-11-29 08:38:44.185 aprx start - 2.9.0
2023-11-29 08:38:44.186 TTY /dev/ttyACM0 opened
2023-11-29 08:38:44.187 TTY /dev/ttyACM1 opened
2023-11-29 08:38:54.341 CONNECT APRSIS euro.aprs2.net:14580

Dodatkowym, i bardzo ważnym, elementem weryfikacji poprawności działania digipeatera było przeprowadzenie dwóch emisji testowych APRS po jednej w każdym paśmie. Wykonałem je używając radia ręcznego Anytone 878 do emisji FM/2[m] oraz Trackera APRS LoRa do emisji LoRa/70[cm]. Jednocześnie obserwowałem aktualizujący się log radiowy uruchamiając jego podgląd komendą:

tail -f -n 30 /tmp/aprx-rf.log

To co mnie interesowało to pojawienie się informacji o odebranej ramce przez konkretne źródło (rozróżniane po SSID) i jej retransmisji na obu interfejsach radiowych.

Dodatkowo sprawdziłem poprawność działania konfiguracji bikonów przez, tak jak ostatnio, analizę wpisów loga. Okazało się, że z pewnym rozjazdem czasowym oba interfejsy radiowe wyemitowały odpowiadające im ramki z dedykowanymi opisami (ramka LoRa została nawet odbita przez obecny w zasięgu – teraz – digipeater SQ6IUS).

Podobne wpisy, jak w załączonych wycinkach współczesnego loga, uzyskane w czasie testowania były wystarczającym potwierdzeniem poprawnej budowy i konfiguracji cross-bandowego digipeatera pod zarządem aprx.

Przydatne źródła informacji i inspiracji

• aprx
• aprx SQ9MDD
• VPDIGI SQ8L
• VPDIGI SQ9MDD
• grupa Telegramowa APRS

Napotkane problemy

Początkowy pomysł na zasilanie urządzenia po kablu Ethernet korzystając z modułów PoE okazał się być nie trafiony ze względu na niską wydajność mocową. Sprzęt restartował się przy nadawaniu radiem FM z mocą 5[W] i jedyną opcją niezakłóconej pracy było ustawienie niskiej mocy nadawania (przy znamionowym zasilaniu okolice 1[W]) i obniżenie napięcia przetwornicy zasilającej radio w rejon poniżej 7[V]. Rozwiązanie takie było akceptowalne wyłącznie w fazie testów ponieważ skutkowało bardzo małym zasięgiem w paśmie 2[m]. Przebudowa zasilania na zasilacz montażowy 5[V]/5[A] rozwiązało problem całkowicie.

Podsumowanie

Budowa międzypasmowego digipeatera APRS okazała się bardzo rozwijającym projektem krótkofalarskim. Konstrukcja poza walorem edukacyjnym ma też silny aspekt techniczny i użytkowy. Obecnie moja bramka doskonale spełnia swoją funkcję będąc pomocniczym digipeaterem wypełniającym komunikacyjną dziurę dla komunikatów APRS. Jestem nareszcie w stanie korzystać z dobrodziejstw infrastruktury radiowej FM/LoRa w mojej okolicy. Wszystkim, dla których ten artykuł wydał się być interesujący i zastanawiają się nad budową takiej, lub podobnej stacji gorąco polecam działanie.

Miłego digipeatowania!