xastir, aprsdigi, aprsd v telefonu

[vanous22]

jak jsem slíbil, tady je pár shotů z xastir na telefonu, zároveň je vidět i aprsd a aprsdigi a podobně. není tedy třeba nic tvořit, vše již je.

neo


xastir, konfigurace rozhraní


xastir mapa


aprs programy, včetně právě spuštěného aprsdigi. debian armel linux

[ok2jkd]

Tak tohle je fakt parada, hlavne ta konzole na posledni fotce.

[ok1mx]

Hele, to "local TNC" na JKD-3 mne zaujalo. Můžeš popsat jak to máš udělané? Je to totiž vynikající nástroj jak sledovat chování sítě a hledat problémy vzniknuvší blbou konfigurací DIGI. Člověk totiž se svým TNC vidí jen provoz okolo sebe, který může být OK, ale velmi snadno se může chyba projevit o 200km dále.

[ok2jkd]

Hele, to "local TNC" na JKD-3 mne zaujalo. Můžeš popsat jak to máš udělané? Je to totiž vynikající nástroj jak sledovat chování sítě a hledat problémy vzniknuvší blbou konfigurací DIGI. Člověk totiž se svým TNC vidí jen provoz okolo sebe, který může být OK, ale velmi snadno se může chyba projevit o 200km dále.

To neni "udelane" to je normalni vlastnost aprsd. Veskery popis najdes zde: http://www.wa4dsy.net/aprs/ports.html
Aprsd po spusteni otevre cca asi 10 portu (udp/tcp)

Ja mam "ven" povolene:

http://wr.rbone.cz:14501 web status OK2JKD-3
pak
telnet://wr.rbone.cz:14580 coz je taky raw tnc port, kde by mely byt videt stream ze serveru, ke kterym je aprsd pripojen, seznam serveru ke kterym je aprsd pripojen je v tom web statusu (+ klienti aktualne pripojeni)
a jiz zmineny
local TNC telnet://wr.rbone.cz:14579 kde by mely byt pakety vyhradne z lokalniho RF tnc, tj. v mem pripade co posbira Foxdigi

Dale pak vyuzivam UDP port 1314 (povolen pouze v ramci localhost a local LAN), kde pomoci scriptu propaguji objekty prevadece kolem OK2JKD-3

[OK2NID]

Dobrý den vespolek.
Debaty okolo "telefonního" APRS pomalu utichly, ale nápad stále žije a postupně se testuje a odlaďuje. Dostali jsme se od stavu, kdy data šly vlivem přepočtu posílat jen z určitých oblastí - pak docházelo k chybě, při které chybělo jedno desetinné místo - až do stavu, kdy systém počítá se změnou kursu a podle toho posílá pakety i mimo nastavení časového intervalu.

Momentální vlastnosti bych shrnul asi takto:
- nastavení základních parametrů je v txt režimu, uživatel může po spuštění změnit značku, time delay (5-300s), comment z grafického prostředí programu, po znovu spuštění jsou nastaveny původní hodnoty. Plánuje se ještě možnost změny ikonky.
- minimální delay je 5 sekund, v kratším časovém intervalu program paket prostě nepošle - stává se, že paket přijde i dříve, je to vlivem určité latence sítě - plánujeme změnu.
- program nepošle duplicitní paket ze stejného místa - stává se, že telefon již vyhodnotí změnu polohy, ale ve zdrojových paketech na aprs.fi je vyhodnocen jako duplicitní.
- program vyhodnocuje směr cesty, pokud je změna o více než 15 stupňů od posledního odeslaného paketu, pošle polohu "mimo pořadí".
- program umí "ručně" a "teď" odeslat polohu. Musí být dodržena podmínka 5 sec a poloha nesmí být duplicitní.

Ukazuje se, že v autě a pod. jsou parametry vcelku OK, ale pokud jde člověk pěšky, dochází k přílišnému posílání. Proto se plánují parametry "pěšky" a "kolo", které by měly docílit méně časté odesílání, důležité je, aby zůstala zachována přesnost získaná vyhodnocováním změny směru. Program je zatím stále ve stavu, kdy číslovat verze je asi brzy... Proto bude lepší ukázat dva příklady: ZDE http://aprs.fi/?call=OK2NID-9&dt=125824 ... range=3600 je cesta ještě bez vyhodnocení změny směru, v některých zatáčkách jsem posílal pakety ručně, ale prosím zaměřte se na oblast serpentin nad Lošticemi, tam se mi i přes snahu povedlo docílit "rovné cesty" v zatáčkách. Naopak o cca kilometr dále v Obectově jsem to vychytal. Ale ruční posílání rozhodně není účelem.

Druhým příkladem je dnešní pěší cesta po městě: http://aprs.fi/?call=OK2NID-9&dt=125867 ... range=3600 Timeout sice 70 sec, ale neumím chodit rovně a podle toho to vypadá. Počítat změnu například o 90 stupňů mi připadá zase příliš nahrubo.

Myslím si, že toto je ta chvíle, kdy je možno začít diskutovat nad možnostmi a parametry i přes to, že vím, že primárně je síla aprs v RF a ne via internet.

Jinak (jen okrajově) jsem provozoval stejně jako vanous xastir, ale mi osobně se příliš neosvědčil. Ale to je na jinou diskusi - bylo to kombinací hardware a xastiru, ne chybou programu jako takového.

[vanous22]

upřímně bych to tady ještě nepouštěl, je na to stále dost brzy. základní tracking máme a funkce přibývají, ale nevím, zda z toho bude někdo benefitovat. je to python + elementary (poměrně sexy grafická knihovna, zatím použita bez témování, což už později není takový problém). běží to pod pythonem, ten poběží na všem (lin, win, osx, na nokia telefonech...), elementary to samé, jen na malých přístrojích většinou nepoběží, asi mimo openmoko telefonů. takže to udává použití na openmoko. navíc se napojujeme na určité dbus volání freesmartphone.org rozhraní... třeba se to časem upraví, ta nokia by byla zajímavá.

pro ukázku:











mimo ok2nid popisu mám ještě pár poznámek:


po spuštění programu se zadrží uspávání telefonu, přibude volitelně dotaz na gprs připojení a držení i zhasínání displeje, zobrazení aktuální rychlosti... blbinky

minimální odesílání paketu nyní testuji na 7 vteřin (bavíme se o auto poslání při změně kurzu), jinak nastavení je cca 7-300. standardní je cca 30sec. problém je spíše v bufferu odesílacího rozhraní - ono se to opozdí a server nám to pak samozřejmě zahodí. toto je nyní hlavně pro testy, reálné aprs hovoří o 10 minutách jaky doporučujete vhodný čas odesílání?

spíše mám praktické dotazy a komentáře:

- vyhodím z paketu timestamp, neboť je to realtime a specifikace říká, že v tomto případě tam být nemusí. ušetří se pár bajtů (viz níže)
- přidám kurz a rychlost (i když nevím, k čemu jsou v reálu dobré, dají se dopočítat později a i se tak děje)
- komprimovat polohu, kurz a rychlost asi nebudu neboť to asi nebude mít výsledný efekt, viz níže
- rád bych z aprsd pakety i vyčítal, ale nikde nevidím jak je filtrovat už při dotazu. poslouchat neustále celou komunikaci se mi nechce, je toho hrozně moc a je to zbytečný datový tok, ale pro podporu zobrazení "kdo je poblíž", nebo "kde je ok2xxx" by to bylo prima žádoucí. stejně tak pro zprávy. rf poslouchá vše už z principu. jak z toho ven? aprsd server dokumentace toho moc nenapověděla. aprs říká, že do 10 minut bych měl mít obraz okolí. ale pokud se pohybuji, tak se to samozřejmě neustále mění...
- nemůžu najít, jaká je minimální odesílaná vzdálenost (hlavně pokud se mobil zastaví). prostá kontrola lat/lon je málo, asi to chce přepočítat na vzdálenost, ale je dáno nějaké minimum?


tolik k tomu.

p.s. xastir běžel na debianu OK, problém byl pod QX (X server v QT, což je docela overkill)...

[ok1mx]

Co se týče toho odesílání tak pro mobilní stanice se doporučuje 60s. 7s je zhůvěřivost. Zkus pogooglit termín "smart beaconning"(používá ho kenwood, OT+ a dlaší) viděl jsem algoritmy ohledně vysílání majáků popsané. Obvykle se četnost vypočítává z rychlosti a změny kurzu a dá se to celkem solidně naparametrizovat.

[vanous22]

aha, no, abysme se dobře pochopili: smart beaconing - definici jsem teď letmo zahlédl, ještě to prostuduji, ale v podstatě děláme to samé: uživatel definuje "minimální packet rate" - např 60sec, ale traker pak kontroluje kurz a na základě změny pak odesílá pakety. ještě definuji maximum paket rate, aby to nevykreslovalo zatáčky moc hustě. tam je právě oněch zmíněnch 7 sec /zahazuje se rate < 5 sec). v závislosti na rychost ještě nevím zda implementuji, neboť to v podstatě není nutné - pěšák má velké výkyvy kurzu, takže možná co provedu je: když rychlost = pěšák, tak úhel změny kurzu bude nabývat větších hodnot, ať je to méně citlivé.
jinak díky.
Petr

[vanous22]

ještě detail: změnu kurzu nekontrolujeme periodicky, ale GPS nám okamžitě ohlási když se kurz změnil, zakže program nemusí neustále cyklovat a něco kontrolovat..., je to docela vychytané ), my jenom kontrolujeme o kolik ta změna byla...

[ok1mx]

koukni na :
http://www.hamhud.net/hh2/smartbeacon.html
http://info.aprs.net/index.php/SmartBeaconing
třeba Ti to pomůže.

Každopádně cíl hry je dosáhnout toho, aby za použití co nejmenšího počtu bodů byla co nejpřesněji vykreslená trasa. Pořád je ale nutné mít na paměti že "zatím" je možné z internetu prolézt do rádia a tam není žádoucí častější vysílání majáků než 60s (výjimečně 30s) Pakliže se z těchto zařízení budou sypat data častěji nezbyde než prostup provozu z inetu do rádia nepovolit, což by podle mne byla škoda. Proto jsem reagoval na těch 7s