Distribuce OK1COM-10

Fórum sysopů, výstavba, konfigurace a nastavení DIGI
User avatar
OK1ALX
Posts: 558
Joined: Mon 09. Mar 2009 15:50:19
Jméno: Libor
Location: Hostovlice, JN79RU
Contact:

Re: Distribuce OK1COM-10

Post by OK1ALX »

ok2ila wrote:Rozhodne jsem pro bulletiny. A jak pise Milan - pokud nekdo trvale posila REJ, tak ho na to upozornit.
Ja bych tipoval ze to je nejaka chyba. Lezi tam TM-D710 (jako OK1MAR-2) a vubec bych se nedivil, kdyby byla nakopla. Za dobu co ji mam ja jsem si jeste nevsiml ze by posilala, nebo a na zaklade ceho by posilala REJ ...
Libor, OK1ALX
OK1COM
Posts: 306
Joined: Sun 08. Mar 2009 3:06:31
Location: Praha-Strašnice
Contact:

Re: Distribuce OK1COM-10

Post by OK1COM »

Dekuji za reakce.
REJ byly opravdu od MAR-2, ale dnes uz nechodi.
ad BF: to ze se posilaji zpravyo tom, ze se nic nedeje, je vice mene kontrola funkcnosti systemu. Krom toho ty zpravy maji stale stejny text a stejne {ID, takze kdyz si ty dva radky nesmazes, tak pri prichodu by ti to nemelo vyskocit jako nova zprava. Alespon tak je to u D710 a D72
ad ALX: NWS bulletiny bych mohl vyzkouset pro zpravy SIGWX GAMET (doufam, ze jsou i pro bezne uzivatele citelne)
ad ALX: o NWS objektech uz jsem uvazoval hned od zacatku, ale z nejakeho duvodu to neslo pouzit, mysim ze se to nezobrazovalo jako WX stanice a uz jsme to resili

JInak 1.6. CHMI bohuzel vypne stary, ale lepsi web, takze pravdepodobne nastane se zpravama problem, protoze na novem webu je to dost neprehledne a blbe se to automaticky zpracovava. Krom toho novy web obsahuje mnoho chyb a nefunkcnich odkazu na starou strukturu stranek, proste des.
OK1COM
Posts: 306
Joined: Sun 08. Mar 2009 3:06:31
Location: Praha-Strašnice
Contact:

Re: Distribuce OK1COM-10

Post by OK1COM »

Pred par dny zmizely objekty OK1COM-10 z mapy na aprs.fi. Neni to zavada na mem serveru, obejky se normalne vysilaji a jsou videt na RF i IS, ale zda se ze administrator aprs.fi zablokoval objekty od zdrojove znacky OK1COM-10, protoze pod jinou znackou se objekt zobrazi.
User avatar
OK1ALX
Posts: 558
Joined: Mon 09. Mar 2009 15:50:19
Jméno: Libor
Location: Hostovlice, JN79RU
Contact:

Re: Distribuce OK1COM-10

Post by OK1ALX »

OK1COM wrote:Pred par dny zmizely objekty OK1COM-10 z mapy na aprs.fi. Neni to zavada na mem serveru, obejky se normalne vysilaji a jsou videt na RF i IS, ale zda se ze administrator aprs.fi zablokoval objekty od zdrojove znacky OK1COM-10, protoze pod jinou znackou se objekt zobrazi.
To je divne, nemuze to mit souvislost s filtry ktere ted jsou na aprs.fi nove? Zkousel jsi mu napsat, treba budeme aspon vedet na cem jsme.
Libor, OK1ALX
OK1COM
Posts: 306
Joined: Sun 08. Mar 2009 3:06:31
Location: Praha-Strašnice
Contact:

Re: Distribuce OK1COM-10

Post by OK1COM »

mejl od Heikki:
Hi,

Thanks for contacting me so that this can be discussed over email.

I have started to filter objects sent by OK1COM-10 because OK1COM-10 was transmitting the largest absolute number of objects in the database, and causing a lot of load to the aprs.fi service when compared to others.

Included in the objects were thunderstrikes, which are very short-lived events, and there are an awful lot of them, and there is no way they could be stored in the aprs.fi service for a long time. If a lot of people started to transmit those, the database would grow from about 200000-300000 stations (over 2-3 years) to millions of stations, and I'd have to go buy a lot of new hardware. Think how many thunderstrikes there are when compared to APRS stations.

I will be happy to consider removing the filter from OK1COM-10 if you can reduce the amount of short-lived objects. I do not see any need to store history of thunderstrikes for 3 years on aprs.fi, it does not serve any purpose.

---
Dal jsem se mu snazil vysvetlit, ze to nemusi archivovat, ale uz to bylo bez odezvy.
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: Distribuce OK1COM-10

Post by ok1mx »

Uvidíme, snad odpoví... V opačném případě by se to dalo řešit přes API a google maps... ale zatím nemám tuchu, kdo by měl náladu se do toho pustit.
User avatar
OK1ALX
Posts: 558
Joined: Mon 09. Mar 2009 15:50:19
Jméno: Libor
Location: Hostovlice, JN79RU
Contact:

Re: Distribuce OK1COM-10

Post by OK1ALX »

Myslim ze je dulezite ze data jdou do RF.
S Hessu jsem uz vminulosti komunikoval take a zdal se mi pristupny k diskuzim, takze verim ze se s nim neco vymysli.
Ovsem vlastni zobrazeni objektu z COM-10 na strankach aprs.cz by nemuselo byt komplikovane, zkusim to nadhodit svemu dvornimu web-mechanikovi :).
Libor, OK1ALX
User avatar
OK1ALX
Posts: 558
Joined: Mon 09. Mar 2009 15:50:19
Jméno: Libor
Location: Hostovlice, JN79RU
Contact:

Re: Distribuce OK1COM-10

Post by OK1ALX »

Rozhodli jsme se s Honzou opet o kontaktovani Hessu a pokusit se nejak vyresit zobrazovani objektu na aprs.fi
Zde je jeho odpoved:

Code: Select all

Hi,


On Thu, 1 Mar 2012, Libor Augustin wrote:

    The last mentioned, the Lighting Detection&Reporting system is the main issue as i have the
    informations from Honza.
    Every new lighting strike reported by the system is expressed by the new object, the object name is
    composed of current date and time, ie. STR260946 (name prefix,day,hour,minute). Because of that naming,
    there is thousands of individual, short lived objects that are stored in database now. Correct me here
    if iam wrong.


That's right.


    1. we keep the current naming and include the special tag at the end of the object comment. This tag
    will tells your system to not store such objects to prevent the overloading or save just for a few
    hours to display it. The tag will be something which we decide together, something you prefer to be and
    something you can then remove from the actual comment to not display it in the station informations
    (same as PHG or DAO).


I get quite a lot of requests for special features needed by individual users or small groups of users worldwide. Unfortunately I do not have enough time to do everything, so I try to concentrate implementing things which benefit large groups of users (on global scale!) so that the time is well spent and benefits as many users as possible. So, I won't do some special tag hack only for you guys - it would need to be a real APRS standard extension which everyone can implement and utilize for other general use cases. It would need to be discussed on the APRSSIG with other implementors.


    2. another idea is to removing any APRS object which transmitted just and only ONE beacon in a life
    after defined duration. Lets say 24 hours or several days (week?). In this case, ANY object or station
    in a world, will not be stored if some of the following examples comes true:
    - station accidentaly transmitted beacon (weird saying but could happen)
    - short lived objects like the lighting strikes
    - there is a beacon, which is not real station and this could happen, when some TNCs are faulty or
    accidentaly decode the packet in a wrong way. The example is here: http://aprs.fi/?call=a%2FCZ3-3. Ii
    is a non existing station, the real station at this QTH is http://aprs.fi/?call=a%2FOK0BCA-1&_s=mb.
    CZ3-3 is state routing path (SSn-N).
    - there might be even more examples ...
    The second idea is more complex solution, not requiring user's attention and everything happens
    automaticaly.


Good idea! aprs.fi already does exactly this (has been doing for a couple years), but it isn't effective enough - a lot of crap comes in more than once, including the lightning strikes. Many APRS packet corruptions are systematic - your example has had 12 different positions stored in the database over time (see http://aprs.fi/info/a/CZ3-3). For the strikes: "STR260946 (name prefix,day,hour,minute)" - a proper thunderstorm will have multiple strikes per minute at different locations, making the object jump around. And there are thunderstorms around the world all the time, making such naming scheme fall over quickly.

aprs.fi, or the APRS-IS in general, does not have a design which would really support worldwide lightning strike information distribution. With some hacks like (1) you might be able to do it for your country, but if a few others would try to do it at the same time, it would break. I would not like to see one object generator doing something that others shouldn't take an example of.

3.

I would recommend you to push lightning information to a network designed to transmit it (I think www.blitzortung.org is a popular distributed lightning receiver network), and keep it there. With some nice KML overlay magic we can then render the information on top of the aprs.fi map without actually polluting the APRS-IS or aprs.fi's database. Here's how you can tell aprs.fi to load a kml file, residing on another web server, on top of the map:

http://aprs.fi/?lat=38.8720&lng=-77.0570&z=15&kml=http%3A%2F%2Fhe.fi%2Fmisc%2Fpentagon.kml

If the lightning data is presented in KML somewhere, I could support a feature to have things like that conveniently listed in the "Overlays" drop-down menu in the top right corner of the real-time map. The 'Weather' item there from NOAA isn't good, some better items would be welcome.

 - Hessu
Z cehoz plyne, ze neni naklonen nejake "individualni" praci a implementaci systemu na vyrazeni nekterych stanic, nebo objektu pomoci nejakeho specialniho oznaceni v textu.
Tudiz od nej zrejme zadne reseni cekat nemuzeme a musime si pomoct nejak sami.

Proto vyvstava otazka co s tim.
Nabizi se jedno reseni, ktere lze pojmout dvemi zpusoby.
- Vysilat blesky i nadale pod znackou OK1COM-10 a vyuzit tak stavajiciho filtru na strane aprs.fi. Tim umoznime i nadale jejich vysilani na RF, avsak nebudou zobrazovany na aprs.fi. A dale presunuti istatnich objektu (METAR, CHMI, TA, SPA ...) na jinou znacku, respektive jine SSID. Toto reseni bude vyzadovat upravu nastaveni igate tak, aby vysilaly objekty z jine znacky (SSID).
- Ponechat vysilani objektu pod OK1COM-10 a presunout blesky na jinou znacku (SSID). V tomto pripade budeme muset Hessu pozadat o nastaveni filtru na novou znacku kde budou nove jen blesky a odstraneni filtru pro OK1COM-10 tak, aby se ostatni objekty (METAR, CHMI, TA, SPA ...) zacaly zobrazovat. Toto reseni bude opet vyzadovat upravu nastaveni igate tak, aby vysilaly blesky z nove znacky (SSID).

Myslim ze Honza se ktomu jeste nejak vyjadri a upresni me.
Libor, OK1ALX
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: Distribuce OK1COM-10

Post by ok1mx »

A nebo na to jít variantou les. t.j. aby se vlk nažral a kozy zůstaly na svém místě.

Což takhle se zkusit zamyslet na tím, že by se "recyklovaly" názvy objektů blesků. Schválně teď nebudu zmiňovat žádná konkrétní čísla, ta se dají najít v historii nebo upravit dle praxe.

V podstatě by šlo o to, že by názvů objektů blesků byl omezený počet. Např.
OK_STR1 - OK_STR 400 (pro poláky kdyby měli chuť a přidali by se tak SP_STR1 - SP_STR400) COM-10 by při každém vyslání nového blesku inkrementoval čítač o 1. Pro Hessu by to mohlo být vyhovující, protože by mu databáze nenabývala nekontrolovaně o hromady objektů, na druhou stranu myslím, že 400 str na jednu bouřku (či den) by mělo ve většině případů stačit.

Pak je možnost opravdu vyhradit jednu CALL která by byla zablokovaná na aprs.fi, po rádiu by to šlo normálně, vidět by to bylo na blitzotnung.net nebo http://www.openaprs.net/ měl li by někdo zájem na to koukat z internetu.
OK1COM
Posts: 306
Joined: Sun 08. Mar 2009 3:06:31
Location: Praha-Strašnice
Contact:

Re: Distribuce OK1COM-10

Post by OK1COM »

To je dobej napad!!
Mozna by stacilo i 100. Protoze vysilani blesku je omezeno na 1 za minutu (kvuli stavajicimu nazvu a prehlceni site). 100=100minut a 100minut stare blesky jsou uz stare. Nebo by se pak dalo snizit cetnost na 30sekund a mohlo by jich byt 200.
Polaky bych neresil.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 13 guests