AKTUALIZACJA 22.05.2025
Koncepcyjny projekt powstaje z czystej ciekawości, aby zbadać, czy możliwe jest stworzenie funkcjonalnego hotspotu przy użyciu radia Quansheng. W porównaniu do modułów takich jak SR105 czy SA818, Quansheng oferuje elastyczność mocy wyjściowej (20-3500mW), co czyni go lepszą alternatywą. Używając 20mW, hotspot działa w optymalny sposób, minimalizując zakłócenia elektromagnetyczne, które mogą wystąpić przy wyższych mocach.
Quansheng, jako dual band radio, umożliwia elastyczny wybór częstotliwości, co zwiększa jego funkcjonalność w różnych warunkach. Choć to nadal budżetowe rozwiązanie, to jego wydajność i łatwość użytkowania sprawiają, że jest to interesujący wybór dla entuzjastów radiokomunikacji, zwłaszcza przy zastosowaniu alternatywnego firmware.
Najważniejsze że projekt jest robiony pod hasłem BIEDA-EDYSZON - a to zobowiązuje do bycia możliwie najtańszym rozwiązaniem jakie jestem w stanie zbudować z nowych elementów. Oczywiście "naj" proszę brać z przymrużeniem oka
UWAGA !!! w dalszej części może pojawić się nazwa / skrót SvxPi_Qhs - otóż rozkładając to na czynniki to SvxPi to nazwa obrazu / wsadu na jakim to działa. a dokładnie jest to SvxPi - Lite z wyłączoną obsługa wyświetlacza i serwera www. Natomiast Qhs to skrót od Quansheng HotSpot
Koncepcyjna robocza budowa zawierająca RaspberryPi 0W oraz CM108 FOB została wyposażona w mocowanie na klips do paska jaki mamy z tyłu baterii.
Pozwala mi to usztywnić konstrukcję i jedynym ruchomym elementem będzie kilka centymetrów kabla zakończonego złączami jack 2.5 i 3.5 mm do połączenia z radiem.
Dzięki połączeniu z baterią mamy sztywną konstrukcję bez konieczności pilnowania w terenie, aby kabel łączący RaspberryPi z Quansheng nie urwał się.
Koncepcyjnie będzie wykonane odpowiednie złącze w obudowie pozwalające na podłączenie się do pinów baterii które służą do połączenia ze stacją ładowania.
A to wszystko po to aby zasilić RaspberryPi z baterii Quansheng. Spokojnie dlatego że nadajemy mocą 20mW to mamy spory zapas energii. Dokładnie ile to wyjdzie w praktyce ale ja osobiście zakładam pracę 2-3 godziny dziennie w trakcie poruszania się autem, zawsze można jeszcze użyć złącza USB-C w radiu w celu dodatkowego podładowania baterii.
KONCEPT ten będzie testowany jako hotspot analogowy w sieci SvxReflector, będzie testowany także jako APRS 144.800MHz tracker ( jeśli uda się upchać mały GPS ), ale z pewnością na tym nie zakończę. Musze tylko zakończyć projekty aDVPi i SvxPi.
JEST TO KONCEPT KTÓRY BĘDZIE REALIZOWANY W RAMACH EKSPERYMENTU - kto wie może z tego wyjdzie finalne powtarzalne rozwiązanie do budowania analogowych hotspot i słowo klucz BIEDA-EDYSZON. A jak bardzo to będzie budżetowe rozwiązanie to niech posłuży cennik zamówionych części do tego projektu.
Około 200 złoty za hotspot ? BEZCENNE
Aktualizacja 05-1-2024
Pierwsze uruchomienie
Podsumowanie
Hotspot jest w pełni funkcjonalny i działa w moim mniemaniu dobrze. przez 2 tygodnie był katowany jako hotspot na 20mW i nic negatywnego się z nim nie działo. Do komunikacji z nim używałem dokładnie takiego samego Quansheng z firmware według F4HWN 2.7 i także nadawałem z mocy 20mW. W moim mniemaniu to jest właściwa moc dla prawdziwego hotspot, gdyż po jakiś 100 metrach traci się zasięg co sprawia że na tej samej częstotliwości spokojnie może ich w okolicy pracować wiele i nikt nikomu nie przeszkadza. Jedno watowe i więcej to delikatne nieporozumienie a w duecie z ręcznym radiem które także pluje 1W to tylko generuje śmietnik elektromagnetyczny.
Tak więc koncept jest i działa, używa wsadu SvxPi z wyłączonym trybem graficznym, nie posiada DASHBOARD, jest kompatybilny z oryginalną wersją SvxReflector.
Aktualizacja 05,01,2025
BUDOWA
Zacznijmy od RaspberryPi. Aby podłączyć do niego kartę dziœkowa mamy dwie opcje, albo dedykowana tak zwana nakładkowa na GPIO lub tańsze rozwiązanie karta USB przykładowo CM108
Aby podłączyć kartę USB potrzebujemy użyć do tego mini-USB jakie mamy na płycie. Można połączyć się poprzez stosowny adapter lub przylutować się do RaspberryPi.
RaspberryPi 0W ma na spodzie miejsce z którego możemy uzyskać sygnał DATA+ i DATA- z USB. Oznaczyłem je kolorami żółtym i zielonym aby było łatwiej w dalszej części.
Do pełni działania karty USB potrzebujemy jeszcze 5V zasilania które bierzemy z GPIO. +5V oraz GND z miejsc oznaczonych na zdjęciu
Tak uzyskane 4 kabelki możemy przylutować do złącza USB naszej karty. Ja używam CM108 ale bez modyfikacji dla uzyskania z niej PTT/COS ponieważ prościej jest do tego użyć GPIO.
Teraz trzeba przygotować sobie kable jack z Quansheng i wyciągnąć potrzebne nam sygnały.
Wejście mikrofonu MIC+ podłączamy poprzez rezystor do wyjścia SPK naszej karty dźwiękowej
Masę właściwą GND / PTT / SPK- podłączamy do masy naszej karty dźwiękowej oraz do tranzystorów 2N7000 nóżka 1
SPK+ z radia podłączamy do wejścia mikrofonowego.
PTT / MIC- - używamy tylko do załączenia PTT w radiu.
Po otwarciu blokady SQL z poprawnym CTCSS pojawia się napięcie 4V pomiędzy SPK+ a GND - jest to teoretycznie za dużo aby podać na GPIO bezpośrednio dlatego sugerowane jest użycie tego prądu do wysterowania tranzystora.
NIE POLECAM ale tylko informuję że ja osobiście podałem sygnał z SPK+ bezpośrednio na GPIO 16 i nic się nie dzieje od 2 miesięcy - ale ze względów bezpieczeństwa polecam obniżyć to napięcie przez dzielnik rezystorowy lub użyć tranzystora.
Powiem TAK - ja to zmontowałem w taki sposób i działa mi bezawaryjnie - NIE POLECAM podpinać bezpośrednio do GPIO ale ja na własną odpowiedzialność tak uczyniłem wbrew zdrowemu rozsądkowi i mi działa taki "ulep" na jednym tranzystorze 2N7000
Można z powodzeniem użyć przekaźników jednokanałowych 5V aby zamiast tranzystorów wysterować sobie PTT / COS , ale to zwiększy i cenę i gabaryty, plus doda "klikanie" które może być dla wielu problemem
Materiał wideo pokazujący poprawną pracę hotspot dostępny na YouTube
AKTUALIZACJA 22.05.2025
W dniu dzisiejszym zakończyłem budowę dwóch kolejnych hotspot na bazie tego opisu i chyba mogę potwierdzić że jest to powtarzalny schemat zarówno na RaspberryPi 0W jak i RaspberryPi 0W2.
Jakość wykonania nie jest powalająca, ale na pocieszenie wspomnę że znam kilka "ładnych" a działających jak szlifierka - dla mnie ważne że działa, i to całkiem nieźle.
Jedyną zmianą jaką dokonałem to zmiana pinów GPIO odpowiedzialnych za nadawanie i odbiór. Jako PTT użyłem GPIO16 co w konfigu Tx1 daje
PTT_TYPE=GPIOD
PTT_GPIOD_CHIP=gpiochip0
PTT_GPIOD_LINE=16
a jako detekcja SQL w Rx1 jest GPIO20
SQL_DET=GPIOD
SQL_GPIOD_CHIP=gpiochip0
SQL_GPIOD_LINE=20Dodatkowo na linii SPK karty dźwiękowej a wejście mikrofonowe radia dałem 22k rezystor oraz między wejściem MIC i GND na karcie audio także jest 22k rezystor. ( wartości te najlepiej dobrać doświadczalnie ).
Dzięki temu i ustawieniu regulacji głośności w Quansheng na poziomie "godzina 9-ta" udało mi się osiągnąć poziom głośności na zalecanym przez SVXlink poziomie -6
Dodanie funkcjonalności GPS
W samym svxlink mamy w sumie w 2 miejscach podawane nasze dane geolokalizacyjne. jest to w pliku svxlink.conf
[LocationInfo]
CALLSIGN=EL-MB7ITN
#SOURCE_CALLSIGN=M0IQF-1
#LOGIN_CALLSIGN=M0IQF-1
APRS_SERVER_LIST=euro.aprs2.net:14580
STATUS_SERVER_LIST=aprs.echolink.org:5199
#FILTER=m/10
SYMBOL=/r
LON_POSITION=000.28.50W
LAT_POSITION=51.53.43N
FREQUENCY=430.075
#TX_OFFSET=-600
NARROW=1
TX_POWER=3
ANTENNA_GAIN=6
ANTENNA_HEIGHT=7m
#ANTENNA_DIR=-1
PATH=TCPIP*
BEACON_INTERVAL=10
STATISTICS_INTERVAL=10
STATISTICS_LOGIC=SimplexLogic
TONE=110
COMMENT=HUBLINK SvxReflector
#PTY_PATH=/dev/shm/aprs_pty
#DEBUG=0
jak i w pliku node_info.json
{
"nodeLocation": "Luton",
"hidden": false,
"sysop": "M0IQF",
"toneToTalkgroup": {
"110.9": 0
},
"qth": [
{
"name": "Hotspot",
"pos": {
"lat": "51.896",
"long": "-0.481",
"loc": "IO91SV"
},
"rx": {
"R": {
"name": "SvxPi_Qhs",
"freq": 438.800,
"sqlType": "CTCSS",
"ant": {
"comment": "",
"height": "0",
"dir": "0"
}
}
},
"tx": {
"T": {
"name": "Tx1",
"freq": 0.0,
"pwr": "0.02",
"ant": {
"comment": "",
"height": "0",
"dir": "0"
}
}
}
}
]
}
Niestety każda z tych "lokalizacji" nie nadaje się do aktualizacji ponieważ te dane są pobierane podczas uruchamiania svxlink. A po uruchomieniu nawet naniesienie zmian nie wpływa na dalsze prezentacje ich w sieci. Dla wyjaśnienia dane z node_info.json są używane do pokazania na mapie reflektora
natomiast dane z pliku svxlink.conf są używane do serwisu APRSIS
Niestety aby użyć odbiornika GPS i w miarę na bieżąco aktualizować swoją pozycję trzeba użyć innych narzędzi.
Koncept GPS będzie realizowany w dwóch etapach
1. Uruchomienie usługi GPS tracker niezależnie od SVXlink bazując na Direwolf lub innym skrypcie.
2. Integracja nowych danych geolokalizacyjnych z SVXlink i możliwość ręcznego ( na żądanie ) , poprzez DTMF aktualizowania pozycji - wymaga to restartu svxlink jako programu co powoduje że nie można tego zautomatyzować, i aktualizacja + restart będą się odbywały komendą DTMF. I aby to było możliwe popełnię coś co nazwałem SvxLink-menu https://youtube.com/shorts/JrXaxe7A28Y