tak jsem trochu prochazel ten koda zdrojove packety z COM-10 a napadlo me, jestli v tom scriptu neni jedna chybka. Testuje se tam, zda jsme packet uz nahodou negejtovali, ale testuje to kde? Pokud to bere z aprs streamu, znamenalo by to, a odpovidaji tomu i zdrojove packety, ze pokud uz je odgejtovano jinou digi (gejtem), tak moje digi uz gejtovat nebude. Snad jsem to napsal srozumitelne.
Je ale mozne, ze jsem uplne vedle a placam nesmysly 😀 Tak moc se v tom kodu zase nevyznam 😉
2 ALX: Ke kazdemu igate by se mel dostat i ten originalni paket, ktery by mela igate poslat na RF. Nasledne se pak do IS dostanou obsahove shodne pakety, ktere projdou IS2RF a neslene nejakou jinou gate zpet do internetu. Vsechny pakety, krere projdou IS2RF jsou oznacene APZQRT, aby nemohlo dojit k opetovnemu vyslani toho smameho paketu az se nekde dostane zpet do IS. To same se deje i s 3rd header pakety, ty jsou dokonce ignorovane uz rovnou na gejtu do IS.
Wildcard bych nezavadel. Mylsim si, ze neni potreba mit na RF informaci o tom jake je pocasi na druhe strane republiky. Dokonce planuji do dalsich verzi moznost filtrovani podle vzdalenosti. Prijde mi zbytecne, aby v Praze byla na RF infromace o tom jake je pocasi zrovna na Lyse hore. Naopak na Morave asi nebudou potrebovat vedet jak je v Karlovych varech. To dost odlehci siti pri mimoradnych udalostech (bourka, SPA) a jestli budou data z dalsich silnicnich meteohlasek (ISMET), bude to temer nutnost filtrovat data podle vzdalenosti, protoze jinak bychom sit asi dost zahltili.
Wildcard bych nezavadel. Mylsim si, ze neni potreba mit na RF informaci o tom jake je pocasi na druhe strane republiky. Dokonce planuji do dalsich verzi moznost filtrovani podle vzdalenosti. Prijde mi zbytecne, aby v Praze byla na RF infromace o tom jake je pocasi zrovna na Lyse hore. Naopak na Morave asi nebudou potrebovat vedet jak je v Karlovych varech. To dost odlehci siti pri mimoradnych udalostech (bourka, SPA) a jestli budou data z dalsich silnicnich meteohlasek (ISMET), bude to temer nutnost filtrovat data podle vzdalenosti, protoze jinak bychom sit asi dost zahltili.
To je vcelku jednoduche. Staci se pripojit na spravny port a vyslat serveru nejakou svou pozici..
Pozor, jedna drobnost k filtrovani na urovni javaprs serveru.
Filtry jsou aditivni, to znamena, ze se jedna o logicke OR, nejde tedy na urovni serveru vytvorit filtr obsahujici logicke AND:
"chci pouze vsechny objekty od OK1COM ktere jsou do 100km od moji pozice".
Pokud byste zadali filtr "b/OK1COM m/100" dostanete vsechno do OK1COM a k tomu jeste vsechno co je do 100km od vasi pozice.
K dispozici je pouze logicke NOT (znaminko - pred prislusnym filtrem) - to ma prednost pred standardnimi aditivnimi filtry. Priklad:
"m/100 -b/OK1COM"
Dostanete vse do 100km od vasi pozice ale nebude v tom nic od OK1COM.
S autorem javAPRS serveru jsem na tohle tema jiz diskutoval, lec je to nepruchozi a evidetne to neni ani vyhledove dostupna funkce.
Resenim je tedy poslat serveru filtr m/100 a buddy filtr na OK1COM delat az na urovni scriptu.
No nevim.. Me to teda funguje.. IS2RF se dela na urovni software. Pokud se pripojim na filtrovany port a poslu mu nejaky majak o pozici te dane volacky, tak mi server posila do streamu stanice a objekty jen do okruhu sveho filtru.. Tim padem mi IS2RF posle ven jen veci co dostane do streamu.. Tedy mam-li nastaven m/100, tak od COM-10 dostanu jen pocasi od LKNA a LKTB a pod. jen do vzdalenosti 100km ode me.. ze mi pak prijdou i dalsi odjinud, to uz neresim.. 😉
