AX.25 howto
1. Requirements
2. Direwolf
3. Linux, vagy BSD?
4. APRS
4.1. Xastir (preambulum)
4.2. Xastir (compile)
4.3. APRX
5. Baudline
6. PTT
7. TCP/IP
+1. USB-serial átalakítók
+2. Műholdkövetés
Mivel elkezdtem beleásni magam a témába, akár írhatnék is róla, ugye.
Az AX.25 egy protokoll, amit mondjuk az IP-vel szemben lehet megfeleltetni, ha gyors magyarázat kell a helyi nyugdíjasotthon bennszülötteinek (képzavar, never mind). Felhasználási módját tekintve amatőr (ham) packet rádiózásban megtalálható, de ennyit mindenki tud. Ennyit tudtam én is róla, amikor úgy 12 éve felvetődött pici agyamban, hogy talán ezt meg is kéne csinálni. A terv a nálam megszokott sebességgel bontakozott ki, így idén meg is kezdtem a szükséges stuffok beszerzését, úgy mint:
rtl_tcp használata esetén (tehát amikor
nem ugyanazon a kompjúteren fut az SDR# mint amiben a DVB eszköz van)
ezen DLL használata
kötelező, különben:
Mivel digitális adatforgalmazást tervezünk, a rádión a zajzárat (squelch, sql) feltétlen (!) kapcsoljuk ki, különben elég nagy lesz a csomagveszteség. További kikapcsolnivaló az a kedves funkció, amelyik nem engedi az adást, ha foglalt a frekvencia (Baofeng menüben: 23-BCL).
Hardverről egyelőre ennyit. A fentiekkel már vidáman lehet zaklatni jobb sorsra érdemes felebarátainkat a környéken (in voice, természetesen), vagy esetleg hallgatni a napi holokausztmegemlékezést a tévében (484.737MHz). Ez természetesen nem perspektíva. A packet rádiózáshoz az ilyen világi analóg hívságokon felül digitális mütyürökre van szükség.
TNC: stuff, aminek az egyik végén a rádió mic/spk kábelei vannak, a másikon meg egy soros port. Röviden: modem. Na ezzel nem foglalkozok, control-freak lévén a folyamat minden lépését személyes diktatórikus kényem-kedvemnek akarom alávetni. Különben se szeretem ha firmware-eket kell upgradelni, vagy ilyenek. Marad a szoftver.
[ Klikk ide a felesleges sallang átugrásához ]
Szoftverből megvalósított modemek tekintetében viszonylag széles (ráadásul bővülő) a választék:
A közkedvelt operációs rendszerre a FlexNet nevű all-inkluzív programcsomag áll az egyszeri rádiós rendelkezésére. Ennek része a Thomas Sailer által írt "soundmodem" fantázianevű soundmodem, mely Sound Blaster és Windows Sound System-kompatibilis hangkártyák (és egy minimum 486-körüli sebességű CPU) segítségével tud AFSK vagy FSK csomagokat dekódolni. Az install marha egyszerű:
@echo off
flexnet
smodem\smsbc
flex
smodem\smmixer /s:line
essvol /l:15
loadhi smodem\smafsk12
fset mode 0 1200A rádiót a hangkártya line bemenetére kötve, majd egy SHOW parancs kiadása után már meg is jelennek a dekódolt packet-ek.
Felinstalloztam egy Windows 98-at, és a TrueTTY nevű stuff segítségével azonnal ment is minden. Ki lepődött meg? Ez a software szerencsére grafikus, realtime lehet nézni a hullámformákat, waterfallokat, frekvenciát tologatni, üzemmódot váltani, miegymás. XML konfigfileok basztatása nélkül.
Kerülendő. A
Az előzőekben bemutatott TrueTTY-t már kiismertem, ezért arra gondoltam, hogy tengernyi időmet egyéb bugware szemetek felfedezésére fogom fordítani. Így jött képbe az imént említett meglehetősen fantáziadús nevű soundmodem util UNIX-os verziója.
Anno a linuxkernálba bekommitelődött egy kernelspace soundmodem implementáció, Sound Blaster és WSS hangkártyákhoz. Elég szomorú elképzelés volt (arrafelé minden szart a kernelbe tolnak, majd természetesen megy az önfeledt örömködés hogy "linux supports XYZ". Hja, más kérdés, hogy elméletileg és gyakorlatilag is szarul), felvilágosodott korunkban már van userspace megoldás (Sailer úr munkája): elméletileg fut BSD-n és Windows-on is.
Gyakorlatilag itt egy GTK2, pango, pkg-config, libxml2, X11, stb mindenkurvaannyára szanaszét dependáló commandline gánytengerről van szó. Avatattabb fülűek számára ezzel valószínűleg el is mondtam róla minden jót és rosszat amit tudni érdemes... akinek ez nem elég kielégítő, az keressen fel egy prostituáltat, vagy olvasson tovább.
Nade mire is installáljam? A teljesen agyhalott OS-ek (Linux, NetBSD) természetesen szóba se jöhetnek, Solarist még mindig nem kívánom, marad a FreeBSD és az OpenBSD. Mivel pont ezutóbbi volt a kezem ügyében CF kártyán, így ezt izgattam be. A soundmodem lefordítása közben megjelenő hibaüzenetek cseppet sem reménykeltő módon jelezték, hogy ezt rajtam kívül még senki se próbálta meg (minő meglepetés...), de azért sikerült egy többé-kevésbé használhatónak tűnő executable-t linkelni (s/I_FLUSH/AUDIO_FLUSH/).
Ami természetesen nem működött. Láthatóan a hangkártya megnyitásának bonyolult (20 éves) tudományát nem sikerült tökéletesen abszolválni, ugyanis egy kurva bit sem jelent meg az input oldalon. Akkor erről egyelőre ennyit, jöjjön a (nagyobb esélyekkel kecsegtető - értsd: ott legalább lefordul) FreeBSD.
Mivel FreeBSD 4.11-en akartam használni (Pentium 1, 16Mb RAM), a fordítás némi nehézségekbe ütközött, lévén a keresztbe dependáló openszorsz szarok tipikus "rendszerfüggetlen" megvalósításával összhangban: nem sikerült. Későbbi FreeBSD-n statikusan lefordítva, majd a célgépre átmásolva már jobb eredményeket sikerült elérni - persze a grafikus diagnosztikai util-ról a fent említett függőségek miatt le kell mondani.
Ezen a ponton azért egy tekintélyes fuck-ot megelőlegezek a FreeBSD-seknek: azt úgy mégis hogy a retekbe képzelik, hogy a Gravis Ultrasound Classic unsupported? Mondom ezt attól függetlenül, hogy 8 bites ADC-vel rendelkező kártyaként modemezésre alkalmatlan lenne.
Ám sajnos egyéb audio hardware-ek terén sincsenek a kedves userek elkényeztetve:
A megfelelő - alacsony/közepes - hangerő beállítása után (az egyik korábbi part-ban emlegetett soundmodemconfig nevű bloated szemét biztosít néhány vizualizációs tool-t e célra) igazából elég straightforward a dolgok menete: a /dev/soundmodem0 file-t hozza létre a ware, mi pedig ezen keresztül tudunk cu-val, xastir-ral, vagy a preferenciánknak megfelelő egyéb bugware programmal KISS módban kommunikálni a "modemmel" (esetleg érdemes megnézni, hogy külső soros port megadása is működik-e a fenti helyett). Meglehetősen prosztó ötlet ugyanakkor az, hogy a "device-t" egyszerre több programmal is meg lehet nyitni, és ilyenkor teljesen random, hogy melyik packetet melyik program fogja kapni.
Mint már korábban említettem, van egy ócskavas, kijelző nélküli, rugdosásra "működő" Compaq P1-es laptopom, amit rádiós workstation-ként ki akartam próbálni - illetve voltaképpen Windows 98 és TrueTTY segítségével minden további nélkül működött is TNC-ként. Az én hatalmas, életemet nyomorba döntő dilemmám akkor keletkezett, amikor is számba vettem (khm) az egyes BSD-k releváns funkcióit e téren. Lőn egy <table> a szoftveres Soundmodem által supportált platformok illetve eszközök tekintetében:
| OS | SB comp. | SB Live | Intel 82801JI integr. | any card |
|---|---|---|---|---|
| Windows 98 | ||||
| FreeBSD 8 | ||||
| FreeBSD 4 | ||||
| OpenBSD 5 |
Mivel az (1993-as mércével) töméntelen 16Mb mennyiségű memóriával felszerelt gépen egy aktuális FreeBSD - és az azzal járó siralmas memóriazabálás - szóba se jöhet, nagy nehezen rászántam magam egy maximum 2.4-es kernelt tartalmazó binux installálására. RedHat sajnos a fasorban sincs nálam a szépemlékű 2.96-os gcc forkjuk óta, így a még annál is kevésbé agyhalott Slackware (11) nevű fércműre esett a választásom.
A GTK-s szemét frontend eleve reménytelen lefordítását --really-fucking-force módon skippelve közepes mennyiségű idő eltelte után előállt egy használható executable, mely - érthetetlen módon - hozta az elvárásaimat: használatba vette az integrált ESS-1888 chipsetes SB Pro klón card-ot. Hurrá?
Nos, számottevő örvendezésre nincs semmi ok, s ez a szokásos linuxbetegség miatt van: ugyan több minden működik...de az szarul.
Nem sikerült például az OSS driverrel működésre bírni a Baudline-t. Ami már csak azért is pajzán, mert az ALSA driverrel, plusz a Baudline-hoz szükséges OSS emulációs layerrel viszont igen. Nonszensz. FreeBSD-vel ellentétben itt nem működik egyszerre a soundmodem és a Baudline. Nesze neked vizualizáció... Ezek minden kipróbált kártyára igazak. Opcionálisan azon is lehet jókat kacarászni, ahogy az OSS Gravis MAX-nak látja az ACE kártyát, az ALSA pedig egyáltalán nem.
Linux.
| OS | SB comp. | SB Live | Intel 82801JI integr. | any card |
|---|---|---|---|---|
| Windows 98 | ||||
| FreeBSD 8 | ||||
| FreeBSD 4 | ||||
| OpenBSD 5 | ||||
| Linux |
Whatever. Szerencsére, ha van supported hangkártya, akkor innentől kezdve alapvetően egész jól megy a stuff, ugyanazt a rögzített packet forgalmazást a TrueTTY-n és ezen keresztülzavarva hasonló eredményt kaptam, és - ezidáig - el se szállt (majd fog). Az egyetlen "fájdalmam" az, hogy a Windows 98 egy (vagy több) tetszőleges (akár régi) hangkártyával és TrueTTY-vel kenterbe veri a BSD-s soundmodem összeállításomat. Sailer soundmodem: szabvány FLOSS-quality.
Avoid.
[ download ]
Ez már jobb stuff, több demodulátort futtat párhuzamosan, minekfolytán a sikeresen dekódolt csomagok száma is megnövekszik. A CPU idővel együtt... Az sajnos nem a soundmodemnél megszokott 1%, hanemdeviszont 20% (Pentium II 300MHz). Hatalmas hátránya, hogy C++ nyelvben lett összedobva, de ennél is siralmasabb, hogy a lightweight-nek aligha nevezhető Boost library-ra épül. Néhány gigahertz feltétlen szükséges a lefordításához...
Audio support tekintetében a portaudio lib-et használja. Ezzel kapcsolatban egyelőre annyit tudok elmondani, hogy FreeBSD-n biztosan működik, OSX-en pedig biztosan nem (oké, elvileg igen, gyakorlatilag nem volt kimondottam triviális). Fontos tudnivaló, hogy a soundmodem-hez képest itt a rádió hangerejét minél hangosabbra kell állítani (tökig erősíteni azért nem kell).
Szerencsére itt már egy-egy TCP socketen keresztül történik a kommunikáció, azaz akármennyi programot is lehet egyszerre használni. Két portot kell megadni, az egyiken KISS formátumban, a másikon az AGWPE nevű windowsos soft szája íze szerint történik a communication. További követelmény, hogy valamilyen soros port meg legyen adva PTT eszközként egy harmadik opcióval (nem kell, hogy legyen is rádugva egy), különben segfaultot dob indításnál. Tipikus C++ coding.
Avoid.
[ download ]
Ez a legjobb szoftveres AFSK/FSK modem. C nyelv, több szimultán demodulátor (szabadon definiálható), opcionális hibajavítás, válaszható sampling freq, ANSI color output, KISS+AGWPE TCP (AGWPE porton több connection esetén csak az első fog látni bármit is!), APRStt support (APRS csomag küldése DTMF kódokkal közvetlenül a rádióról), minden van. A line-in két csatornáján egyszerre két rádióról is tud fogadni. Fut Free-, és OpenBSD-n is (patch), bár a kedves szerző újabban elkezdett kiírtani mindent a Linux/ALSA-n kívül...
Linux, vagy BSD?
Itt el kell dönteni, hogy mit is akarunk csinálni. Ha APRS a cél (lásd alant), akkor csakis BSD. Ha TCP/IP over AX.25 hálózatot akarunk csinálni, csakis Linux, (és sok szerencsét). Elvileg a WAMPES (eredetileg: KA9Q NOS) nevű IP stack segítségével szinte bármilyen UNIX-on többé-kevésbé megoldható az IP connectivity valamilyen módon, de ezzel eddig még csak különféle bájos kernel panic-okat tudtam előidézni. Work in progress!
A Direwolf sem tökéletes. Néhány ismert caveat:
"Sound: DMA (input) timed out - IRQ/DRQ config error?" üzenetekkel fogja tudomásunkra hozni, hogy valami el van rontva, a kiadott csomagok pedig random szanaszét vágva lesznek hallhatóak. Nade van nekünk ALSA driver (snd-sb8) is! Ami egyébként e téren működik is. Aprócska probléma, hogy a Direwolf ALSA-n keresztül csakis full-duplexben nyitja meg a kártyákat, ami itt természetesen nem fog menni (vagy két hangkártyát, esetleg /dev/stdin-t kell használni, blech). Sloppy programming.Az elmaradhatatlan sample config:
ADEVICE /dev/dsp
ARATE 11025
ACHANNELS 1
CHANNEL 0
MYCALL XYZ
MODEM 1200 1200 2200 abcd
SLOTTIME 50
PERSIST 128
PTT /dev/cuau0 RTS
TXDELAY 15
TXTAIL 10
AGWPORT 30000
KISSPORT 31000
FIX_BITS 2
# lassabb CPU-val a FIX_BITS hibajavítást is csökkenteni lehet
Vegyük sorra az adáshoz fontos paramétereket.
TXDELAY és a TXTAIL: evilági
nyelven a PTT bekapcsolása és a rádió tulajdonképpeni adáskészültségének beállása
közötti időt (előbbi), és az csomag vége utáni plusz adásidőt jelenti (utóbbi). Khm, szóval addig kell emelni/csökkenteni, amíg a rádió nem harapja le a packetek elejét, de nem is
trillázik - időtöltés gyanánt - a szükségesnél tovább, valamint a célállomás is
tudja dekódolni amit kiadunk. Részemről a fenti értékek voltak célravezetők.SLOTTIME és PERSIST: ez nagyon vicces lesz, de egyben marha fontos is. Ezek azt határozzák meg, hogy az adásra kijelölt csomagok mekkora késleltetéssel lesznek kiküldve. A SLOTTIME paraméterben szereplő szám jelöli azt az időegységet, amelyekben PERSIST eséllyel sor kerül az átvitelre. Huh. Talán vegyünk egy példát. A direwolf/soundmodem először is (a fenti paraméterek esetén) vár 500 msec-et (SLOTTIME 50), és ha ezalatt nem érkezett a rádió felől dekódolandó FSK adat, akkor 256/128 (PERSIST) azaz 50%-os eséllyel elküldi a mi csomagunkat. Ha viszont valaki közben elkezd forgalmazni, akkor az egész várakozás újrakezdődik. A PERSIST értékét úgy érdemes kiszámolni, hogy 256-ot elosztjuk az állomások számával (itt 2). Könnyen látható, hogy a round-time meglehetős tempóval fog növekedni több user esetén...Az AGWPORT-nál megadott TCP port az Xastir, a KISSPORT pedig az APRX csatlakoztatására szolgál. TCP/IP-hez a -p opciót kell command line-ban megadni, erről később.
A fentiek megvalósítása után, a rádiót a PC line-in bemenetére kötve már élvezhetjük is a környéken áthaladó APRS csomagokat (az európai frekvencia: 144.800 MHz). Szerencsés időpontokban a Nemzetközi Űrállomáson keresztül érkező APRS csomagokat is összenyálazhatjuk (145.825MHz). Ez a frekvencia természetesen nem a 446MHz PMR-hez való 70cm hullámhosszú antennával érhető el jól (sőt azzal egyáltalán nem), hanem a 2 méteressel.
Ja, és hogy mi az az APRS: olyan eszközök használják, amik a saját GPS pozíciójukat nem mobil neten óhajtják közvetíteni, inkább a környékbeli (értsd: többszáz-ezer-kettőzere-hatvanötezer km) rádiósok felszerelésére (ilyen van az ISS-en is, e célra nyugodtan használható is) bízva a csomagot, ami addig visszhangzik a világban, míg valahol elér a fogadó állomásig, és/vagy a netig. Bővebb dox itt.
Hogy az APRS struktúráját megértsük, először is tekintsetek meg egy scenario-t ahol emberünk APRS trackert installál repülőgépébe. Nem túl komplikált dolog, persze ez egy "végfelhasználói" APRS setup, Windowsos PC és Macintosh helyett 1 db céleszközzel.
A jármű/repülőgép által küldött APRS packeteket jó esetben veszi egy WIDE1 és WIDE2 maszkokra hallgató APRS eszköz. Ezek alatt azokat kell érteni, amik ideális helyekre vannak felszerelve, hogy mást ne mondjak: hegycsúcsra, toronyra. Ideális esetben internet kapcsolattal is rendelkeznek, és a fogadott APRS packet-ek rögtön a netes APRS adatbázisba+térképre kerülnek. A rádiós route-olási folyamat a digipeat, azt ezt végző router pedig a digipeater.
Ám, ha éppen nincs a környéken WIDE1 digipeater, akkor jönnek szóba a WIDE2 maszkra reagáló eszközök, amik a közmegegyezés szerint a földfelszíni/otthoni, "ha jobb nincs" pontokat jelzik. Ilyet fogunk most csinálni, mert ez a legegyszerűbb, csak a már meglévő eszközparkra van szükség hozzá.
Most, hogy sikerült fogadni az első APRS packeteket, talán nem ártana valami értelmezhető formátumban meg is tekinteni őket... Erre az Xastir nevű stuffot fogjuk használni.
Egész jó ware. Talán ott is kezdhetem a bemutatást, hogy a GUI nem holmi agyaroggyant GTK-ban (plusz! kettő! kettő-kötőjel-kettő! és egyéb verziók), urambocsá Qt-ban íródott. Fontjait sem fontconfig, freetype, és hasonló több tíz megás linuxista dependencia DLL hegyekkel igyekszik bugosan megjeleníteni. A configure scriptje a pkg-config-ot se használja. Utóbbi egyébként egy rákos daganat, ami úgy 10 évvel ezelőtt fészkelte be magát a köztudatba. Természetesen a "freedesktop" néven hírhedtté vált judeo-anarchista terrorista group-től származik. A köznép felé aképp indokolják a létezését, hogy majd ez a tool megoldja azt a hatalmas, ősi problémát, hogy linkelésnél nem lehet tudni (?) az éppen linkelt filehoz kapcsolódó lib-ek milyen további flag-eket (?!) igényelnek, hovatovább egyáltalán hol is vannak azok a lib-ek. Ez az ötlet minden valamirevaló developernél heveny szemöldökrángásokat eredményezhet(ne, ha léteznének még ilyenek - és nem szemöldökökre gondoltam), lévén ez a "probléma" sem létezett soha, csakúgy mint a "freedesktopos" lamerek által "megoldott" többi sem.
A helyzetet súlyosbítja, hogy a nemlétező probléma valójában tényleg létezik, csakhogy éppen "freedesktop" felebarátaink tevékeny - és aktív - részvételével jött, és jön létre. A rák gócpontja a glib2 és gtk2 néven ismert trójai szoftveregyüttes, melyek szintén nemlétező problémák "megoldásai", és mint minden ideológiai alapon létrejött szoftver, ezeknek is már a nevükbe ivódott a verziószámuk - tudniillik (az éppen aktuális) Világforradalom előtti időktől Elhatárolódunk(C), élesen elkülönülünk, ordas eszméikkel (pl. pkg-config nélküli élet) demokratikus européer közösséget nem alkotunk(R)!
Aki azt hiszi viccelek (avagy meghibbantam), nyugodtan megpróbálhatja mondjuk - hogy valóban nehéz feladatot ne adjak - lefordítani az aktuális glib-et (kettő! glibkettő!) egy rák nélküli OS-en. Mi, hogy pkg-config kell a lefordításához? Dehát a pkg-config lefordításához meg pont a glibKETTŐ kell... (biztos erre a dependenciára is kitalálnának a terroristák valami hihetetlenül hangzó ideológiát, részemről a "cui prodest" elv alapján azt látom, hogy nekik érdekük hogy terjedjen a rákjuk, és ennek ez a - szemlátomást jól működő - módszere). Én kérek elnézést. Ezt az ellentmondást oldja fel aki akarja - és közben idáig hallom a "working as intended!" vonalat hurrogó kórust (ha jól számolom két ember).
Mellesleg féltve őrzöm azokat a glib2(!) verziókat, amelyek utolsóként fordulnak egy-egy UNIX-on - az utánuk következők természetesen nem. Csak szólok, hogy még mindig egy "portolhatóságot megkönnyítő apró (?!) toolról" beszélünk. Hmmm...
A rák (pkg-config) terjesztésének másik ága ugyancsak a glib2 (ez annyira
így van, hogy ők is beismerik),
lévén a headerjeit a "modularitás" néven jelzett anarchista ideológia
jegyében szanaszét szórja a filerendszerben (különböző elmés neveken). A
rettegés ott kezdődik, hogy /usr/local/include/glib-2.0. Igen,
feltétlen kell kötőjel, és nem egy, hanem KETTŐ verziószám. Megtekintettem,
nálam csak a freetype2 és ez a trash csinálja így - mindkettő a fenti
csoport terméke. Merészebbek a könyvtárba belépve szomorúan konstatálhatják,
hogy ez a remek dir további subdir-eket rejt magában, például egy "glib"
nevűt. Igen, "#include <glib-2.0/glib/glist.h>", és ez most nem egy pulóver kötési mintájának
egy része, bár a hasonlóság tagadhatatlan.
A tradícionális (mellesleg jól működő) módszer ugye az, hogy a system-wide include dirbe subdirként költöző headerek a subdir nevével együtt vannak #include-olva. A rákos sejt (freedesktop software) ezt a metódust úgy alakítja át (miután ő maga megteremtette a problémát, lásd előző bekezdés), hogy a subdir "kezelését" - mint írtam - kiszervezi egy külön szoftverbe (pkg-config), és különböző dogmák hangoztatásával arra kényszeríti a jobb sorsra érdemes fejlesztőket, hogy csak a header file-t írják az #include sorba, a szükséges path-t meg majd a vonatkozó daganategyüttes (pkg-config, gnumake, autoconf) állapítja meg, a C fordítót lehetőleg a döglassú - és megintcsak teljesen felesleges - libtoolon keresztül meghívva.
És így készült el a totálisan freedesktop-platformfüggő, linuxspecifikus software. De mintha kissé elkalandoztam volna. Akit érdekel a téma, az itt folytathatja.
(to Xastir guys: keep up the Motif style! No freedesktop-dependency bullshit please!)
Szóval, szerencsénkre ezt a szoftvert nem elmeroggyantak fejlesztik. Az irányelve a
régivágású "UNIX workstation" jegyet követi, ennek fényében a GUI toolkit a
jó öreg Motif. Talán még VMS-re is le lehetne fordítani. A forgatás sem
követel tőlünk semmi olyat, amivel szemben szűzies hajlamaink kétségeket
fogalmazhatnának meg: az
openmotif-2.1.32_IST.source.tar.gz file szó nélkül lefordult
Mac OS/X 10.4 powerpc-re, bár a headerek és lib-ek (1-2 db) installálását
kézzel kellett elvégeznem... Igen, kitaláltátok miért:
/usr/bin/libtool: can't locate file for: -lXt
/usr/bin/libtool: file: -lXt is not an object file (not allowed in a library)
Értelmezhetetlen. De szerencsére a lib-ek megvannak, mivel a Motif makefile nem szarik maga alá az ilyen bullshitektől. Kellhet még az Xastir-hez ImageMagick, vagy (mivel azzal szemben is vannak erős fenntartásaim) GraphicsMagick, legalábbis ha bitmap térképeket is szeretnénk nézegetni vonalak helyett.
Ezután maga a software szó nélkül lefordul. (majdnem: nálam a
map_shp.c file elejére kellett egy typedef unsigned char
uint8_t; mert a bugoktól tökéletesen mentes, a clang-et több linux
user szerint porba alázó gcc ezen forrásfile-al találkozván
megrökönyödésében kissé érdekesen interpretálja a stdint.h-t. Illetve a kész
executable-t sem kellett strippelnem, hacsak nem akartam a Warning: Fatal Error:
_XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL
hibaüzenetben gyönyörködni.
Sajnos találkoztam az Xastir-ban egy nagy buggal is: egy bizonyos digipeateren keresztül érkező csomagokat - bár a soundmodemben még rendben vannak - teljesen rosszul értelmez, rosszul jelenít meg (azt hiszi, a küldő állomás neve WIDE2-1), majd ezt az állapotot a szerver felé is jelzi, mindenki nagy örömére. Ennélfogva én I-gate-ként nem is használom. Van helyette:
Ez egy nagyon egyszerű, kicsi és gyors digipeater/i-gate daemon. Grafikus, vagy egyáltalán bármilyen megjelenítésre természetesen nem képes. Íme egy példa cfg:
mycall STATION
<aprsis>
passcode [ize]
# az xastir-es "callpass" util tud generálni
server hun.aprs2.net
filter "m/1"
</aprsis>
<logging>
pidfile /tmp/aprxpid
rflog /data/aprs/aprx.log
</logging>
# Direwolf KISS port
<interface>
tcp-device 127.0.0.1 31000 KISS
tx-ok false
</interface>
<beacon>
beaconmode aprsis
cycle-size 10m
beacon srccall STATION symbol "/&" lat "5050.50N" lon "05050.50E" comment "komment he."
</beacon>Az alap konfigolást (állomásunk neve, szélességi/hosszúsági foka) minden fejlett prokarióta megejtheti maga.
Nyilván a TNC-re mutató interface-en ne legyen bekapcsolva az "Allow
transmitting", a netes szerverhez tartozón viszont annál inkább (hacsak nem
az a cél, hogy a TNC PC audio kimenetén hallgassuk az általünk kiküldött
packeteket, lévén a PTT áramkör esetleg még nincs elkészítve, tehát TX-elni
nem tud a ware - élelmesebbek esetleg nyomva tarthatják a PTT gombot mikor
APRS packetet szeretnének küldeni...) Utóbbi kapcsán még annyit, hogy az ott
megadandó callsign-hoz az Xastir-hez járó callpass programmal
generálni kell egy passwordöt, majd az interface létrehozásánál azt beírni.
Ajánlott a filter résznél mondjuk egy "m/200"-at beírni, ami azt jelzi, hogy
csak az ennél közelebbi állomásokról küldjön a szerver infót (km).
Hopp, és hirtelen kész is lett, ennyi volt egy otthoni I-gate létrehozása. Mivel az APRS packet az AX.25 egy subsetje, lehet örvendezni az első AX.25-ös sikernek is. A környékbeli APRS userek biztosan örülnek majd nekünk.
Érdemes lehet "néhány szavat" írnom az APRS packetekben szereplő "Data path" paraméterről is. Mivel az APRS frekvencián egyszerre csak egy packet mehet, így a kapacitása meglehetősen limitált, megfelelően bekonfigurált eszközökkel és digipeaterekkel azonban több, mint elég. Törekedni kell arra, hogy a packet a biztos célbajutásnál (net/célállomás) nagyobb távra ne terjedjen, rádiófrekvencián legalábbis. Ennek a terjedésnek a mértékét lehet itt megadni. A tartalmára és életútjára vonatkozóan szemléltető példa egy mobil állomással:
Ami heveny tapsikolást vált ki az egyszeri rádióbuziból, az ez a program. Windows-ra nincs, csak Linux, FreeBSD (linuxemu), Solaris, és MacOS X (Intel, és G4 PowerPC 10.5+) platformokon fut (bonus pont jár azért, hogy a forrás csak pénzért vehető meg). Hogy mi is ez, azt majd mindenki kihámozza ebből: "Baudline is a time-frequency browser designed for scientific visualization of the spectral domain."
A lényeg, hogy lényegesen finomabb felbontású (+zoom! scroll!) benne a waterfall, mint mondjuk a TrueTTY vagy az FLDIGI beépített rutinja, a soundmodem GTK-s szarjában pedig ilyen eleve nincs is, csak két, marginálisan használhatatlan vizualizáció, amik a BaudLine-al szöges ellentétben egy 1GHz-es CPU-n már majdnem fele olyan gyorsak, mint egy 20 évvel ezelőtti MOD lejátszó egy 20MHz-es 386-on. (opensource, mondtam már?)
Egyszerre tud futni a soundmodemmel (SB Live-on legalábbis), úgyhogy az egyetlen lehetséges buktatóval sem sikerült találkoznom szerencsére. További közvetlen előnye, hogy X11-et használ, ezért nem kell a "radio shack"-ben fagyoskodnom télen, lévén remote X terminálon is lehet használni.
Hogy tudjátok is mivel tesztelni, itt downloadolhattok egy WAV file-t, melynek tartalma néhány - a Nemzetközi Űrállomás által továbbküldött - APRS csomag.
Az adáshoz szükség lesz egy eszközre, amely "megnyomja" az adó PTT (Push-To-Talk) gombját amikor a Direwolf csomagot küld. Ez esetünkben egy egyszerű áramkör lesz. A működése kvázi-szabvány a különböző szoftveres modemek között: a soros port RTS és GND lábaival operál (párhuzamos, sőt game portos verzió is létezik, a soros port azonban több sikerrel kecsegtet a tetves UNIX-ok által supportált portokat illetően). Van olyan util is, ami lehetőséget ad más lábak használatára.
Ingredients:
Ez egy elég egyszerű dolog, mert még egy ilyen semmihez sem értőnek mint én is elsőre sikerült működő példányt összeállítani, pedig még soha nem csináltam áramkört. Ennek megfelelően az első verzió "kissé" gány, ám legalább meglehetősen "vizuális" lett:
A második verziót már bele lehetett nyomorgatni egy DB9 tokba... Az általam használt Baofeng rádió a PTT bekapcsolt állapotát a mikrofonbemenet földelésén nézi (a hangkimenet is csatlakoztatva kell hogy legyen elektronikailag ugyanabba az "áramkörbe", azaz pl. hangkártyába), ha egy teljesen intakt kábellel az user összedugja egy hangkártyával, akkor a TX lámpa azonnal világítani kezd. A teendő tehát a PTT két kivezetését ráforrasztani a kábel kettévágott földelésére 1-1 ponton.
Ezután egy tetszőleges kalóz callsign beírása, és mondjuk percenként egy darab beacon packet beállítása következik. Xastir-ben mindenki beklikkelheti, aprx-ben meg például így néz ki:
<beacon>
beaconmode radio
cycle-size 1m
beacon interface $mycall srccall HA9PIR-1 lat "0000.00N" lon "00000.00E" symbol "/A" comment "+++ATH0, losers" via "WIDE1-2,WIDE2-1"
</beacon>
Ha ez is megvan, akkor elméletileg arcunkon torz vigyorral, hátradőlve/ugrándozva konstatálhatjuk, ahogy a 30km-rrel odébb található digipeater (AAAAAA-99) vissza+továbbküldi a packet-ünket, majd ezt a digipeatelt packet-et egy még távolabbi digipeater (BBBBBB) továbbadja: (utóbbit a mi adónk nem éri el, de az általa sugárzott jel hozzánk visszaér, mivel a kérdéses állomás hegyen található)
HA9PIR-1>APRX26,AAAAAA-99*,WIDE1*,WIDE2-2:!0000.00N/00000.00ER+++ATH0, losers
HA9PIR-1>APRX26,AAAAAA-99*,BBBBBB*,WIDE2-1:!0000.00N/00000.00ER+++ATH0, losers
Ebből áll tehát egy AX.25 packet küldése. Licensz hiányában ennyi élvezkedés elég is lesz az APRS frekvencián, még mielőtt a házunk előtt gyülekezni nem kezdenek a rosszarcú feljelentgetők, akiknek testeit ennélfogva kénytelenek lennénk a disznók elé vetni. Természetesen a fentiek is (a holokauszttal ellentétben) csak a fantázia szüleményei, képzelt scenario, etc, etc...
Nade mi is kell egy ilyen hálózat létrehozásához?
Ezen cikksorozat/howto eddigi részeiben már mélyrehatóan foglalkoztunk a Direwolf és különböző kliens applikációk kapcsolataival és beállításaival, tehát most elég lesz csak az azon felüli új paramétereket áttekinteni. Ami a felhasznált cfg file-t illeti:
SLOTTIME 50 - ez a beosztás pont elég a Baofeng UV-5R rádiók TX-ből visszakapcsolásához
PERSIST 255 - csak két node lesz, tehát nem kell másokra várni
PTT /dev/cuau1 RTS - ezen a serial porton van a PTT
DCD /dev/cuau1 DTR - serial DTR pin-re LED-et kötve lehet látni amikor RX van
TXDELAY 25 - UV-5R-re méretezve
TXTAIL 2
SERIALKISS /dev/ptyq2 115200 - ez a V1.4-es Direwolf újdonsága, BSD pty I/O interface. Ehhez fog kapcsolódni az IP stack. Aki XT-s DOS-on kívánja futtatni a JNOS IP node-t, az egy másik Direwolf opcióval megadhat valós serial portot is. Ami nem cross-platform, annak ott a jakobinus platform!
Most jöhet a JNOS. Tessék applikálni a patch-emet, mert anélkül nem fog BSD-n lefordulni. Meg nem erősített információk szerint gőzerővel dolgozok az OSX 10.4 supporton is. A /dev/tun3 filenevet mindenki írja át arra amire neki tetszik, nálam ez volt a free, device enumerációt meg nem volt kedvem feleslegesen írni. Tudniillik TUN device-on keresztül fog kommunikálni a host OS, és a JNOS. Jöjjön a cfg (autoexec.nos):
attach asy ttyq2 - ax25 ax0 4096 256 115200
ifconfig ax0 ipaddress 44.0.0.1
ifconfig ax0 linkaddress STA1A
ifconfig ax0 netmask 0xffffff00 up
# reach dest subnet via 1200 or 2400
#route add 44.0.2.0/24 ax0 44.0.0.2
route add 44.0.2.0/24 ax1 44.1.0.2
Ez az első interface, mint látható a Direwolf-ban megadott /dev/ptyq2 file párja. A route parancs opcionális, a remote node mögötti host subnet elérését hivatott route-olhatóvá tenni. A "256" az MTU. Az IP layerre 216 byte marad, de egyébként nagyobb adatmennyiség esetén majdnem mindegy mert egy adás ideje alatt úgyis egyszerre több AX.25 packet fog kimenni, ha telik a SendQ. Az azokat ACK-oló TCP packetek is majd egy-egy nagyobb batch-ben fognak egyszerre érkezni. Ezért is jó, ha korábbi Linuxos tévelygésekkel ellentétben a JNOS IP stack-et használjuk, mert az erre fel van készítve, nem fog összefosódni attól ha nem azonnal épül fel egy TCP session. Ha már itt tartunk, a host node net.inet.tcp.keepidle és keepintvl sysctl-jei (azaz az inaktív TCP session keepalive check-je) is jó ha mondjuk több percre vannak állítva, ha a hostról is akarunk kapcsolatot felépíteni - és hát mi a fészkes fenéért ne akarnánk efféle bohóságokat?!
attach asy ttyq3 - ax25 ax1 4096 256 115200
ifconfig ax1 ipaddress 44.1.0.1
ifconfig ax1 linkaddress STA1B
ifconfig ax1 netmask 0xffffff00 up
Ez a második interface szintén opcionális. Egyből "dual-stack" networköt csináltam ugyanis: két direwolf futott 1200 és 2400 baud sebességű módban. Most jöhet a tun interface:
attach tun tun0 1500 0
ifconfig tun0 ipaddr 44.0.1.1 up
ifconfig tun0 netmask 0xffffff00
ifconfig tun0 broadcast 44.0.1.255
shell ifconfig tun3 44.0.1.2 44.0.1.1 up
shell route add 44.0.0.0/24 44.0.1.1
shell route add 44.1.0.0/24 44.0.1.1
domain addserver 44.0.0.1
arp add 44.0.0.2 ax25 STA2A ax0
arp add 44.1.0.2 ax25 STA2B ax1
start telnet
start ftp
start smtp
start ax25
start httpvnc
A statikus ARP optimalizációs célokat szolgál. Mivel a hálózat tagjai ismertek (helló NNI!), így teljesen felesleges állandóan ARP kérésekkel borzolni az étert. Ez mellesleg "hagyományos" hálózatokon (ethernet, 802.11, stb) is követendő módszer. Ennyi a szoftveroldal. Ezen a ponton már igazán érdemes ellenőrizni a hangkártyák ki-, és bemeneti jelszintjeit. A bemeneti oldalon a hangkártya összes (mic/line, record/input, stb.) hangszintjét a lehető legkisebbre kell csökkenteni. Ebbe ugyanis a PC összes statikus zaja beleszűrődik, úgyhogy talán nem kellene még erősítgetni is rajta... A rádió hangerejét ezzel szemben olyan magasra kell állítani amennyinél még épp nincs clipping, torzítás. Audacity, VU-meter, urambocsá sox, bármi használható e célra. Output oldalon hasonlóképp kell eljárni: amikor az egyes gépek remote párjain futó Direwolf-ok szerint a bejövő "audio level" 45-55 között van, akkor léphetünk is tovább.
Ezen a ponton már bőszen lehet pingelgetni egymást a két gépen, ellenőrizendő hogy jól működik-e a demoduláció, vesznek-e el packetek, van-e "crosstalk" (azaz a SLOTTIME, PERSIST, TXDELAY, TXTAIL opciók illetve paramétereik nem szarok-e).
SSH-t természetesen nem érdemes használni, egy jól beállított hálózaton is 2 perc (!) egy hostkey-es login, RSH-n viszont csak 20 sec. A hatszor lassabb SSH egyébként a "rendes" interneten se üti meg a használhatóság szintjét szerénytelen személyem szerint, ezért is érdemes helyette VPN felett RSH-t használni (OpenBSD és FreeBSD meg szokás szerint kurvára el van tévedve ezen utility-k önkényes, sőt: fejlődésmániás, szélsőségesen idealista eltávolításával). Mellesleg crypto használata ham frekvenciákon illegális is, már ha valakit ez érdekel. Egyébként nem használhatatlan (bár nekem ugye a 14.4k modem se volt az), az első billentyűleütés még külön megy el (és ACK-elődik le), de az ezen tranzakció (2-3 sec) közben érkező újabb inputok már batch-ben mennek ki. Egy közepes ls -l ideje alatt pedig nyugodtan (vagy ha máshogy nem: idegesen) lehet hozni egy kis Edelweiss-t a hűtőből, közben a jelen folyamat látványától agyvérzésben elpusztult, csiligány komfortérzethez szocializálódott ADHD-s hülyegyerekek holttestein átlépkedve.
Host-host (tehát nem NOS-NOS) közötti filetranszfer közben egy tshark-ot futtatva nagy valószínűséggel találkozhatunk a TCP retransmission jelenségével, azaz a remote oldal megrémülve attól hogy az elküldött TCP packetekre nem az ezen évszázadban megszokott időn belül jön az ACK reply, újraküldi azokat. Mivel egy mindössze 100 cps sebességű linken ülünk, ez nyilván nem fogja az orcánkra az öröm piros rózsáit csalni... Egy idő után a host IP stackje szerencsére veszi a lapot, és az észlelt borzalmas round time-t alapul véve szomorkodva lecsökkenti az igényszintjét (smoothed round-trip time) özönvíz előtti szintekre. A net.inet.tcp.rexmit_slop sysctl preemptíven történő jó magasra állításával szerencsére meg lehet adni az alaphangot.
Nem kevés fejfájást okozott a használni kívánt 145MHz, ugyanis a rádió - adáserősségtől többnyire függetlenül - amint adni kezdett rögvest bele is szállt az elektronikába, azonnal kikapcsolva a PTT-t. Az alufóliás szigetelés hatástalannak bizonyult, viszont ha egy ember (sofőr) került a rádió és a mobil node közé, az kellően leárnyékolta az elektromos mezőt. További opció volt a 446MHz-re hangolt kollineár antenna ami közvetlenül a 2m sávszélességű párja mellé került fel (a pletykák által emlegetett elhangolódást a gyorsan elvégzett kísérletek eredményei nem igazolták). Ilyen rövid távon nem volt észlelhető a hullámhossz rövidülésével járó range csökkenés, ellenben a tereptárgyak - természetszerűleg - észlelhetően jobban árnyékolnak ezen a frekvencián. Tagadhatatlan előny viszont, hogy 446-on már egyáltalán nem akart megsülni minden elektromos eszköz a környéken.
atest utillal dekódolható, Baudline-nal megcsodálható.A rendelkezésemre álló példányok ezekkel a paraméterekkel bírnak:
| Eszköz | FreeBSD | OpenBSD | Note |
|---|---|---|---|
| Prolific | PTT kezelésére nem jó, az ehhez kellő pineket nem kezeli | ||
| Keyspan USA-19H | ez elvileg PTT-nek is megfelel(ne) |
Ha esetleg a Szahara kies pusztaságában tengetnénk mindennapjainkat, a VHF/UHF sáv viszonylag kevés izgalmat fog nyújtani. Vigyázó tekinteteket tehát a kozmoszra vessétek! Számos műhold kering az égbolton, melyek jeleinek dekódolásával kellemesen múlathatjuk gondtalan hétköznapjainkat. Ez annyiban különbözik a földfelszíni okoskodástól, hogy a nem-geostacionárius műholdak (tehát az amatőr/ham műholdak 99%-a) által használt frekvenciák a Doppler-effektus miatt nem állandóak. Amikor a műhold közeledik, a relatív nagyobb sebesség miatt a frekvenciája 10kHz-el magasabbről indul, és a hozzánk (mint megfigyelőpont) viszonyított sebesség függvényében fog csökkenni, amíg el nem éri azt a távolságot ahonnan már csak távolodni bír: ekkor fog csak a megadott középfrekvencián sugározni. Távolodáskor természetesen ennek ellenkezője játszódik le, mely folyamat végén a frekvencia 10kHz-cel lesz alacsonyabb.
Mondhatni: mi ezzel a gond, hiszen a rádióm nemcsak 12.5, de 25kHz-es frekvenciaszélességre is állítható. Ez valóban módfelett remek, csakhogy a fogadott jelen kívül fennmaradó frekvenciákon ilyenkor a nem túl kellemes alapzaj található, és a 400, vagy akár 2000km távolságba vesző műhold jele ebbe esetleg bele méltóztatik veszni, arról nem is beszélve, hogy amikor egy 13kHz szélességben adó műhold az emelkedő fázisában feltűnik a horizonton (+10kHz), akkor ebből 25kHz szélesség esetén (12.5kHz a középfrekvencia mindkét oldalán) csak 2.5kHz-et fogunk hallani...
Műholdkövetéshez tehát eléggé musthave egy olyan rádió, amelyet nagyon könnyen lehet 100Hz-enként léptetni. Hint: a Baofeng nem tartozik ezek közé... Itt jön a képbe a "Requirements" fejezetünkben a sárga földig lehordott RTL-SDR USB eszközcsalád, amely ugyan azóta sem lett jobb, de ennek a feltételnek tökéletesen megfelel, és ha olyan kedvünk van, akár 2MHz-nyi frekvenciát is egyszerre láthatunk, azaz rögtön evidens lesz, ha egy-egy műhold felbukkan a látóhatáron.
Maradjunk a fapadnál: indítsunk egy SDRsharp-ot, és kapcsolódjunk a Realtek dongle-ünkhöz: akinek a gépéhez van vezetve az antennája, az praktikusan USB-n (sok szerencsét a windows-os USB driver szelektív lecseréléséhez a ZADIG.EXE nevű rettenetes dologgal), akinek pedig távolabb van (pl. én), az TCP-n is hozzáférhet a másik gépbe dugott USB eszközhöz az azon a gépen futó RTL_TCP programmal. A gain-t nyugodtan toljuk fel a maximumra (pl. 49.6), mert ennek hiányában csak a Depeche Mode "Enjoy the silence" c. számának jegyében ténykedhetünk.
E ponton feltétlen érdemes úgy beállítani a waterfall színtartományát, hogy a háttérzaj szintje csak egy sötétkék alapként jelenjen meg. Zoomoljunk rá valamelyest a nekünk kellő frekvenciára (lásd a képen).
Ez itt fent az Aeneas nevű műhold jele, melyet a 437.600MHz frekvencia körül kolbászolva lelhetünk fel (TLE). E ponton érdemes megjegyezni, hogy az űrkommunikációk hullámhosszonként egy-egy szabványos frekvenciasávban történnek a félreértések elkerülése végett: a 70cm-es sávban ez a 435-438MHz közötti - azaz egy 2MHz szélességű RTL-SDR kártyával szinte az egészet egyszerre látni a képernyőn. Jelenleg nem tartózkodik a sat célokra elég fapados antennánkhoz képest szerencsés pozícióban, ezért alig emelkedik ki a háttérzajból. De ha egy kicsit várunk...
Már csak annyi maradt hátra, hogy egy virtuális loopback kábel segítségével visszaadjuk az audiót a Direwolf-nak:
KE6YFA-1>CQ,TELEM:4341455255531D0040020001060B04022C50FF070000001100F075000070230049702226423C08 (csak példa)
Az Aeneas műhold esetében a kettőspont után látható telemetriát elküldhetjük a aeneas@astronautics.usc.edu mailcímre, ahol meleg gratulációval fogadják.
Röviden érdemes megemlékezni az SDR#-hoz elérhető frekvenciatuner pluginról, ami az orbitális testek követését végző szoftverek (pl.: Orbitron, WXtrack) segítségével automatikus korrekciót végez(ne) a Doppler torzulás függvényében. A feltételes mód használata teljes mértékben indokolt: ez a plugin - csakúgy mint az _összes_ általam próbált SDR# plugin - voltaképpen egy működésképtelen szemét, amely jelző még impresszívebben fog hatni ha elmondom, hogy már a tervezésekor egy ronda hack-nek készült. Ennyit erről.
Az SDR# ugyan alkalmas a műholdas alapok megismerésére, de ezen felül mindenki sokkal jobban fog járni, ha jelen korunk .Net, Java, és Python szemetei helyett valami '90-es évekbeli megoldásban gondolkodik.
 |
  |
 |
 |
 |
 |
 |