Jak wszyscy zapewne wiedzą najprostszą metodą aby zaistnieć w sieci APRS jest posiadanie komputera z dostępem do Internetu. I o ile komputer jest urządzeniem już rozpowszechnionym to z tym dostępem nie zawsze bywa kolorowo. Pozostaje nam wtedy standardowa metoda podłączenia się do sieci APRS czyli via RF. Czy jednak będziemy musieli dokupić modem TNC?


Na szczęście nie :) Karta dźwiękowa wbudowana w komputer z powodzeniem może go nam zastąpic. I w tym własnie artykule postaram sie przedstawić jak tego dokonać w oparciu o system operacyjny Linux i program do APRS: Xastir. Wykorzystamy w tym celu softwarowe sterowniki które napisał Thomas Sailer (HB9JNX/AE4WA): http://www.baycom.org/~tom/ham/soundmodem/ . Zanim jednak przejdziemy do konkretów może krótko na temat  dystrybucji w oparciu o którą przygotowywany był ten opis.

Po wielu latach przygody z Debianem i przejściu na rodzinę systemów *BSD, ze względu na brak w tychże drugich wsparcia dla AX.25
zainstalowalem w celach eksperymentalnych GENTOO ( http://www.gentoo.org ).  Ponieważ, nie posiadałem najnowszej wersji, na potrzeby tego artykułu używać będę wersji 2005.1 i kernela z pakietu gentoo-sources (w wersji 2.6.14-gentoo-r2), który jest kernelem z dodatkowymi łatami. Myślę jednak, że nie powinno to mieć większego znaczenia i na "czystym" kernelu nie powinno być problemów z instalacją. Dodam tylko, że korzystam z systemu plików urządzeń "udev" ( http://pl.wikipedia.org/wiki/Udev ) zamiast przestarzałego "devfs". Ponieważ "udev" w Gentoo jest
delikatnie podkręcony w stosunku do założeń tego systemu plików, dla chętnych lektura " http://www.gentoo.org/doc/pl/udev-guide.xml"

Jeśli chodzi o hardware, to całość pracuje na leciwym Compaq Deskpro z PII 400MHz w obudowie SFF Slim, który ma wbudowaną na pokładzie kartę muzyczną opartą o chipset ESS1869, którą oczywiście wykorzystamy jako nasz modem TNC. Od wielu lat jako sterowników dźwięku używam ALSA (Advanced Linux Sound Architecture) i polecam te drivery każdemu. W kernelach 2.6.x są one jako defaultowe, natomiast sterowniki OSS oznaczone są jako przestarzałe. Jako część radiową wykorzystałem handhelda Yaesu VX-5R, którego podłączyłem za pomocą bardzo prostego interfejsu (sterowanie ptt za pomocą COM). Zabieramy się za konfigurację.

Aby nasz soundmodem mógł funkcjonować, karta dżwiękowa musi zostać rozpoznana i zainstalowana w naszym systemie. Jeśli nie wiemy jaką kartę posiadamy, to możemy użyć odpowiednich narzędzi aby spróbować się tego dowiedzieć. Jeśli karta oparta jest o szynę PCI, to sprawdźmy co pokaże nam wywołanie polecenia "lspci" (w gentoo w pakiecie "pciutils"), dla kart USB - pomocne może być "lsusb" (pakiet usbutils),  w przypadku kart PnP ISA pakiet "isapnptools". Jeśli zaś posiadacie kartę noPnP ISA, to pozostaje ruletka z wstrzeleniem się z IRQ, IO itp ;) Ja miałem to szczęście, ze parametry mojej noPnP ISA karty dźwiękowej odczytałem z poziomu BIOS`u. Konfigurujemy kernel:
                   
Device Drivers --->
Sound --->
<M> Sound card support
  Advanced Linux Sound Architecture --->
  Open Sound System --->

Wchodzimy do:
 
Advanced Linux Sound Architecture --->
<M> Advanced Linux Sound Architecture
<M> Sequencer support
<M> OSS Mixer API  
<M> OSS PCM (digital audio) API

Zwracam uwagę na dwie ostatnie opcje. Dzięki nim będziemy mieli wsparcie dla programów korzystających z OSS API i wykorzystujących urządzenia /dev/mixer* i /dev/dsp*
 
Wybieramy właściwy sterownik dla naszej karty dźwiękowej. W moim przypadku był to:

ISA Devices --->
<M> Generic ESS ES18xx driver
 
W tym miejscu mogę tylko dodać, że jeśli nie jesteśmy pewni, który moduł wybrać możemy skompilować wszystkie drivery
dla kart ISA, PCI i USB do modułów probując szczęścia z programem "alsaconf" z pakietu "alsa-utils". Narzędzie "alsaconf" sprobuje wykryć
kartę dźwiękową i odpowiednio skonfigurować sterowniki w systemie. W pakiecie tym znajdziemy również narzędzie "alsamixer".

Oczywiście z racji indywidualnego charakteru każdej konfiguracji w tym miejscu zakładam, że karta już pracuje w systemie, urządzenie
/dev/dsp jest dostępne dla programów i możemy zająć się "częścią radiową". O instalacji AX.25 w Linuksie można przeczytać w artykule
AX25 w linuxie . Sprawne oko zapewne zauważyło, że w kernelu 2.4.x możemy wybrać opcje Soundcard modem driver. Jednak przeszukując opcje konfiguracyjne np. kernela 2.6.13 czy 2.6.14 można zauważyć, brak driverów dla soundmodemu. Dlaczego ? Otóż, soundmodem został przeniesiony z kernela do przestrzeni użytkownika. Jedyne czego potrzebujemy to wsparcia dla sterownika KISS (choć i to nie do końca jest prawdą). Ja jednak proponuje wkompilować do modułów wszystko co związane jest z Amateur Radio support. Dzięki temu, możemy eksperymentować bez konieczności rekompilacji kernela.
 
Networking ---> 
[*] Networking support
[*] Amateur Radio support --->
--- Amateur Radio support
--- Packet Radio protocols
<M> Amateur Radio AX.25 Level 2 protocol
[*] AX.25 DAMA Slave support
<M> Amateur Radio NET/ROM protocol
<M> Amateur Radio X.25 PLP (Rose)
AX.25 network device drivers --->
<M> Serial port KISS driver
<M> Serial port 6PACK driver
<M> BPQ Ethernet driver
<M> High-speed (DMA) SCC driver for AX.25
<M> Z8530 SCC driver
[*] additional delay for PA0HZP OptoSCC compatible boards
[*] support for TRX that feedback the tx signal to rx
<M> BAYCOM ser12 fullduplex driver for AX.25
<M> BAYCOM ser12 halfduplex driver for AX.25
<M> BAYCOM picpar and par96 driver for AX.25
<M> BAYCOM epp driver for AX.25
<M> YAM driver for AX.25
 
Wsparcie dla AX.25 mamy w kernelu i pozostaje nam tylko skompilować kernel. Metodę pozostawiam do wyboru - czy ręcznie za pomocą make & make modules_install, czy np. za pomocą narzędzia Gentoo genkernel. Więcej na temat kompilacji kernela w Gentoo znajdziecie na http://www.gentoo.org/doc/pl/kernel-upgrade.xml
 
 
Przyszła pora na instalację soundmodemu, konfigurację i uruchomienie naszej stacji w sieci APRS. Ponieważ nie znalazłem w portage (system pakietów Gentoo) soundmodemu pozostała mi kompilacja ręczna. Po ściągnięciu z  http://www.baycom.org/~tom/ham/soundmodem/ źródeł programu i rozpakowaniu do katalogu wydałem trzy magiczne komendy, znane zapewne tym którzy kompilowali coś samodzielnie:
 
./configure
make
make install

Jesli wszystko przebiegło pomyślnie to w katalogu /usr/local/bin powinniśmy znaleźć program: soundmodemconfig a w /usr/local/sbin/  program soundmodem. Oczywiście przypominam o poleceniu "whereis", które może być pomocne do ustalenia gdzie trafiły pliki po instalacji. Ale ponieważ to nie jest kurs obsługi Linuksa, dlatego zakładam - że w tej chwili każdy posiada binarki czy to po instalacji z pakietu czy z kompilacji własnej. 
 
Na początek wykorzystamy narzędzie soundmodemconfig, za pomocą którego w prosty sposób stworzymy config dla soundmodemu. Konfiguracja jest bardzo prosta, choć będzie wymagała odpowiedniego ustawienia poziomu dźwięku. Ale o tym za chwile. Uruchamiamy program soundmodemconfig (zakładam, ze posiadacie środowisko graficzne - jeśli nie - pozostaje ręczna konfiguracja).
 
Wybieramy z menu File - New Configuration, w pole Configuration Name wpisujemy nazwę dla naszej konfiguracji i klikamy OK. Poniżej powinna się nam pojawić nazwa naszej konfiguracji. Po kliknięciu na nią pojawią nam sie dwie zakładki IO i Channel Access. Na zakładce IO wybieramy Mode: soundcard, Audio Driver: /dev/dsp. Jeśli chodzi o PTT Driver - to wybieramy port przez który będziemy sterować nadawaniem. Jeśli będzie to port COM1 to wpisujemy /dev/ttyS0, COM2 to wpisujemy /dev/ttyS1 itd. W moim przypadku, ponieważ port na płycie głównej był uszkodzony, wykorzystałem przejściówke USB-RS-232 na układzie Prolific PL2303 - dlatego na zrzucie ekranu jest wpis /dev/ttyUSB0. Gwoli wyjaśnienia, screeny zostały wykonane już po skonfigurowaniu soundmodemu, więc nie przejmuj się, że u Ciebie mogą sie nieznacznie różnić np. brakiem wpisu Channel0, który widnieje na poniższym obrazku, do tego dojdziemy wkrótce. 
 
 
 
Na zakładce Channel Access może zainteresować nas parametr TxDelay i TxTail. Pierwszy określa w milisekundach ile czasu upłynie zanim program zacznie nadawać nasze ramki po uruchomieniu PTT. TxTail dokładnie to samo, tylko na zakończenie transmisji. W moim przypadku TxDelay musiałem zwiększyć do 300ms, TxTail pozostał bez zmian. Możemy również zaznaczyć FullDuplex jeśli nasza karta dźwiękowa potrafi pracować w takim trybie. P-persistence i Slot Time z tego co wyczytałem odnosi sie do algorytmu CSMA (wykrywanie kolizji/zajętości kanału ?) ale ze wzlędu na brak czasu, aby wczytać się w dokumentację pozostawiłem te parametry bez modyfikacji. Może kiedyś znajdę chwilę czasu aby dokładnie wyczytać o co chodzi ;]
 
 

 
Czas na konfigurację kanału. Wybieramy z menu File - New Channel i tworzymy tym sposobem Channel 0. Na zakładce Modulator wybieramy jako Mode: afsk. Pozostałe parametry pozostawiłem bez zmian.
 
 

 
Na zakładce Demodulator postępujemy analogicznie jak w przypadku zakładki Modulator. Wybieramy afsk pozostawiając pozostałe parametry bez zmian.
 

 
Na zakładce Packet IO dokonamy większych zmian niż te defaultowe. Jak już wcześniej wspomniałem nie do końca będziemy wykorzystywać moduł mkiss ;) W zakładce Mode wybieramy zamiast MKISS tryb KISS. Wskazujemy plik /dev/soundmodem0 jako urządzenie naszego soundmodemu. I to by było na tyle z konfiguracji :) Teraz pora na pierwsze testy.
 
 

  
Obok menu File jest menu Diagnostic z szeregiem opcji umożliwiających przetestowanie naszych ustawień. Wykorzystamy dwie funkcje: Scope i Monitor. Na okienku Scope będziemy mogli obserwować amplitudę naszego sygnału i dzięki temu będziemy mogli ustawić głośność tak aby nasz sygnał nie był przesterowany itd. Możemy tego dokonać albo regulacją głośności na naszym radiu lub np. w mikserze systemowym (alsamixer). 
 
 

 
Poniżej wygląd okna Scope podczas  odbierania ramki APRS.

 
 
 
Ale kiedy mieć pewność, że nasze ustawienia są poprawne ? Dzięki funkcji Monitor, która na bieżąco będzie dekodowac to co usłyszy. W ten sposób możemy sobie idealnie dopasować siłę sygnału tak aby większość ramek była dekodowana poprawnie. 
 
 
 
 
Jeśli się przyjrzymy temu co się dzieje na konsoli z której uruchamialiśmy program soundmodemconfig, zauważymy, że tam również pojawiają się zdekodowane ramki. Zwracam na to uwagę ponieważ komunikaty wyrzucane są na standardowe wyjście, co przy dużej ilości odebranych danych, może zaśmiecić nam konsolę. 
 
 

 
Dla tych, którzy nie posiadają graficznego środowiska wklejam konfig jaki został wygenerowany przez soundmodemconfig. Znajduje się on w Gentoo w katalogu /etc/ax25/soundmodem.conf
 
<?xml version="1.0"?>
  <modem>
   <configuration name="sq5vdr">
    <channel name="Channel 0">
      <mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1"/>
      <demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1"/>
      <pkt mode="KISS" ifname="sm0" hwaddr="" ip="10.0.0.1" netmask="255.255.255.0" broadcast="10.0.0.255" file="/dev/soundmodem0" unlink="1"/>
    </channel>
    <chaccess txdelay="300" slottime="100" ppersist="40" fulldup="1" txtail="10"/>
    <audio type="soundcard" device="/dev/dsp" halfdup="0"/>
    <ptt file="/dev/ttyUSB0"/>
  </configuration>
</modem>
 
Ok, odbieramy dane -- konfiguracja jest poprawna, czas uruchomić docelowy program soundmodem. Ponieważ próba uruchomienia programu z prawami użytkownika nie powiodła się, a nie chciało mi się walczyć z prawami, uruchomiłem program jako root. O ile program uruchomił sie bez problemu (co nie jest wcale dziwne ;P) to teraz programy uruchamiane z prawami użytkownika nie mogły używać pliku /dev/soundmodem0.
Jeśli się przyjrzymy jak wygląda plik /dev/soundmodem0 zauważymy, że jest to symlink do /dev/pts/x gdzie x może przyjmować różne wartości. 
 
ls -la /dev/soundmodem0 
lrwxrwxrwx 1 root root 10 2007-10-30 13:48 /dev/soundmodem0 -> /dev/pts/5
 
Prawa wyglądają poprawnie, użytkownik powinien posiadać możliwość odczytu i zapisu z/do takiego urządzenia, ale jak przyjrzymy sie plikowi /dev/pts/5 wtedy znajdziemy przyczynę.
                
ls -la /dev/pts/5 
crw--w---- 1 root tty 136, 5 2007-10-30 13:48 /dev/pts/5

Nie mogłem ustawić praw na sztywno ponieważ  przy kolejnym uruchomieniu soundmodemu mogłby się on podlinkować do calkiem innego  /dev/pts/ np. /dev/pts/4 dlatego napisałem bardzo prosty skrypcik służący do uruchamiania programu. W plikach źródłowych co prawda znajduje się jakiś skrypt startowy ale nie testowałem go. Mój skrypt startowy wygląda tak:
 
# Zabij wszystkie procesy soundmodem
killall -9 soundmodem
# Czekaj 2 sekundy
sleep 2
echo "Odpalam soundmodem"
# Uruchom soundmodem w tle - dzięki parametrowi v0 soundmodem nie będzie siał komunikatami
/usr/local/sbin/soundmodem -v 0 &
# Czekaj 10 sekund -- aż program odpali sie w pełni
sleep 10
# Sprawdz do którego /dev/pts/ podlinkował sie /dev/soundmodem0
link=`ls -la /dev/soundmodem0 | cut -f12 -d " "`
echo "Ustawiam parametry dla /dev/pts/"
# Ustaw prawa dla /dev/pts/ podlinkowanego z /dev/soundmodem0
chmod 666 $link
 
Dzięki takiemu prostemu skryptowi w bashu zautomatyzowałem proces uruchamiania programu. Uruchamiamy skrypt, sprawdzamy czy proces soundmodemu istnieje w systemie (ps auxwww | grep soundmodem) i jeśli wszystko jest w porządku przejdziemy do konfiguracji Xastira. O tym programie trochę już napisano w naszym serwisie, dlatego skupię sie wyłącznie na konfiguracji interfejsu. 
 
Po uruchomieniu Xastira, wybieramy z Menu - Interface - Interface Control a następnie klikamy na przycisk Add: 
 
 

 
Wybieramy typ naszego interfejsu. W naszym przypadku będzie to Serial KISS TNC. Następnie znowu Add:
 

 
 
I przystępujemy  do konfiguracji.  Opcje Activate on Startup zaznaczamy jeśli chcemy aby interfejs był podnoszony przy starcie programu. Allow transmitting? -- jeśli chcemy aby nasze ramki były nadawane. Jako TNC Port wpisujemy nasze /dev/soundmodem0.  Wpisujemy ścieżkę w pole Path - ta na poniższym obrazku nie koniecznie jest poprawna - WIDE1-1 to dawne Relay i w zasadzie jako stacja domowa mająca w zasięgu DIGI czy IGATE nie powinniśmy takiej ścieżki używać. U mnie pojawiła się tylko ze względu na problemy ze slyszalnością mojej stacji podczas pisania tego artykułu.  I w zasadzie tyle jeśli chodzi o konfiguracje, nie zapominając oczywiście o konfiguracji menu File/Configure/Station, gdzie podajemy parametry naszej stacji. 

 

 
Zamykamy przyciskiem OK i jeśli wszystko poszło poprawnie to w oknie Interface Control przy naszym device TNC Serial KISS powinien pojawić się stan UP, tak jak to widać kilka obrazków powyżej.  Z menu View wybieramy Incoming Data i sprawdzamy czy faktycznie jakieś dane odbieramy:
 
 

 
Jeśli tak, oczywiście będziemy mieli te dane odwzorowane na mapie.

 
I to by było na tyle jeśli chodzi o konfigurację Soundmodemu w systeme operacyjnym Linux w oparciu o program do APRS Xastir. Artykuł oczywiście nie wyczerpuje całego tematu jeśli chodzi o Soundmodem, jego możliwości są znacznie szersze, ale poznawanie tego programu pozostawiam jako pole do eksperymentów dla czytających. Proszę mi również wybaczyć ewentualny techniczny bełkot ale starałem sie pisać prosto  i zrozumiale dla każdego, co mam nadzieję, że choć po części mi się udało. 
 
Jako ciekawostkę mogę jeszcze napisać, że całkiem niedawno ukazało się kolejne wydanie dystrybucji Ubuntu - 7.10 Gutsy Gibbon. Dystrybucja ta zawiera zarówno program Xastir jak i soundmodem! Wystarczy zainstalować z paczek i (uwaga !!!) nawet nie potrzeba kompilować kernela !! AX.25 jest w modułach w defaultowym kernelu więc wszystko co należy zrobić, to w zasadzie wykonanie konfiguracji soundmodemu, co zaznaczyłem etykietką Stage 2.  Dystrybucja Ubuntu jest dostarczana jako LIVE CD co przy odrobinie umiejętności pozwoli przetestowanie soundmodemu z Xastirem w zasadzie bez instalacji systemu na twardym dysku.
 
73` de SQ5VDR Darek