Pàgines: 1 2 3 [4] 5 
|
 |
|
Autor
|
Tema: Un any de detector de llamps (Llegit 1977 vegades)
|
boira
Cumulonimbus Calvus
 Desconnectat
Gènere: 
Missatges: 2406
|
Sembla que això dóna, si no m'ho miro malament, la posició calculada per cada llamp dins d'una reixa de 1000 x 1000 (el mapa).
Crec que el sistema calcula la direcció per les 2 antenes creuades de camp magnètic (incertessa de 180º) + 1 de camp elèctric que donaria el sentit (resol els 360º) i a l'hora proporciona la polaritat del puls. La distància l'estima per l'intensitat del puls, d'aquí la necessitat de la correcció de sensibilitat/azimut, punt bastant crític de l'invent
Potser per un sistema multisensor seria millor treballar només per direccions 
Hi ha algun lloc on el programa dongui aquesta informació? (Per no estar desfent càlculs).
(Què se li envia al www.blitzortung.de ? )
Continuarà ...
|
|
|
|
|
En línia
|
|
|
|
syntonic
Visitant
|
Exactament aquest arxiu en cas de Nexstorm (amb altre programari, no ho sé)
|
|
|
|
|
En línia
|
|
|
|
|
|
|
|
boira
Cumulonimbus Calvus
Desconnectat
Gènere:
Missatges: 2406
|
Potser per un sistema multisensor seria millor treballar només per direccions Segur. Biltzortung treballa amb direccions, i quan dues estacions resolen, és un llamp. Strikestar va més lluny, i només resol un llamp quan tres estacions a més de 100 km entre elles resolen en un mateix punt de manera coïncident.
Tres estacions donen 3 interseccions i el programa deu considerar el centre en un intent de corregir errors.
També havia llegit en algun lloc que quan un llamp és bastant a prop la direcció no es pot resoldre. Suposso que per saturació de la recepció en algun dels eixos.
De cara a les interseccions, no sé a partir de quina distància s'ha de considerar l'esfericitat. Clar, que si no es complica massa el millor seria fer-ho sempre. (Cas de les línies de direcció corbes a http://www.blitzortung.de/index.php?station=2&mode=10&map=6&lang=e). (S'haurà de repassar lo de la navegació ortodròmica i el cercle màxim).
De totes maneres, donats dos fitxers de llamps, com aparellem els llamps entre fitxers ? Sé de sistemes professionals que afegien algun "timestamp", però quan aquest a més es fa servir per resoldre distàncies calen resolucions de us i s'han de sincronitzar els receptors. (Abans via LORAN i ara GPS). Fora del nostre abast i menys des d'un PC/güindous.
Potser si hi ha una certa seqüència de llamps amb un certs espais mesurables entre descàrregues (ms, s, ), a partir dels temps entre descàrregues podem establir una correlació entre dues seqüències ? Tot i poguent-se donar, per exemple, diferències de distància de 300 km entre el llamp i dues estacions, això només afectaria en 1 ms i no seria massa significatiu dins la seqüència (que petin dos llamps diferents a dos extrems del territori dins el mateix ms no és impossible però no sembla massa probable)
|
|
|
|
|
En línia
|
|
|
|
syntonic
Visitant
|
Amb això de llamps molt propers no m'hi he trobat, la direcció sembla funcionar sempre, però potser és degut a que l'antena està protegida per parets de pedra de 60 cm de gruix i no arriba a saturar.
El Nexstorm dóna a cada llamp un timestamp, però evidentment el problema és que per internet obtenir una sincronització del rellotge amb precisió de nanosegons és una quimera. Suposo que el sistema és comparar sèries de llamps i establir llavors una correlació. En la pràctica blitzortung admet rellotges fora d'hora fins a 20 minuts, per això deuen fer servir algun sistema alternatiu.
L'esfericitat segur que cal contemplar, essent que, sobretot de nit, les antenes capten senyals a alguns milers de quilòmetres de distància.
Per altra banda es podria contemplar el que deia de situar els nuclis de tempestes detectats - això seria molt més factible ja que la tolerància és d'uns quants minuts com a mínim. El que passa és que llavors quedem limitats a Nexstorm i Boltek obligatòriament (i per tant Windows, com a mínim de moment).
|
|
|
|
|
En línia
|
|
|
|
boira
Cumulonimbus Calvus
Desconnectat
Gènere:
Missatges: 2406
|
Si hem d'aprofundir i entrar en massa tecnicismes potser seria millor que ens enviéssim directament correus entre els interessats i deixar el fòrum per comentaris més genèrics i de més possible interès general.
No sé, com ho veieu ?
|
|
|
|
|
En línia
|
|
|
|
syntonic
Visitant
|
Si hem d'aprofundir i entrar en massa tecnicismes potser seria millor que ens enviéssim directament correus entre els interessats i deixar el fòrum per comentaris més genèrics i de més possible interès general.
No sé, com ho veieu ?
Per una part sí, però per altra banda igual s'enganxa algú que sinó no s'en enteraria... no ho sé. A mi m'ha passat de saltar a algun tren en marxa d'aquesta manera. Potser fer un fil específic i qui no vulgui que no hi entri - "qui no vulgui pols que no vagi a l'era". Potser també hi ha gent a qui li agrada seguir les coses des de l'ombra?
|
|
|
|
|
En línia
|
|
|
|
boira
Cumulonimbus Calvus
Desconnectat
Gènere:
Missatges: 2406
|
Si hem d'aprofundir i entrar en massa tecnicismes potser seria millor que ens enviéssim directament correus entre els interessats i deixar el fòrum per comentaris més genèrics i de més possible interès general.
No sé, com ho veieu ?
Per una part sí, però per altra banda igual s'enganxa algú que sinó no s'en enteraria... no ho sé. A mi m'ha passat de saltar a algun tren en marxa d'aquesta manera. Potser fer un fil específic i qui no vulgui que no hi entri - "qui no vulgui pols que no vagi a l'era". Potser també hi ha gent a qui li agrada seguir les coses des de l'ombra?
Doncs seguim per aquí. Al menys és necessari durant aquesta fase i mentre el tren estigui buit.
Unes quantes coses:
[1] El Nexstorm escriu una estructura de dades en memòria compartida per cada descàrrega que es pot llegir des d'una altra aplicació.
Veieu, en el manual APPENDIX D – FLASHGATE IPC-1 SPECIFICATION (Strike data)
En aquesta estructura hi diu, entre altres coses, Rawbearing. Potser estaria bé partir d'això. No seria massa complicat llegir-ho i crear, si s'escau, el "nostre fitxer d'intercanvi". Potser entenen tot això deixem una porta oberta a altres sensors.
Recomanen llegir l'estructura, com a mínim cada 15 ms. O sigui, no s'esperen en general 2 descàrregues en aquest període. (Per lo del 1 ms / 300 km comentat abans).
Estaria bé que em fessis arribar: Source code for a sample FlashGate client written in Borland C++ Builder 5 is provided on the NexStorm CD-Rom, \src folder. Suposo que ho deus tenir.
[2] - Lo de la correlació va semblant més evident. No sé si la polaritat també podria ser part de l'info a verificar per la correlació.
Si fem [1] també podríem tenir, si convé, un timestamp més fi de 1 s. Si a sobre sincronitzem els PC de les estacions receptores en algun servidor horari i no hi ha massa segons de diferència, la finestra de dades per la correlació s'estrenyiria. (De fet això només seria problema de volum de dades / temps de procés, no de mètode).
[3] - A la que hi hagi informacions .DAT en el sistema actual i des d'ubicacions diferents, estaria bé comparar-les per veure la viabilitat de [2]
[4] - Està clar que haurem de treballar per l'intersecció dels dos cercles màxims. Tocarà repassar la trigonometria esfèrica. (L'últim programa que vaig fer d'això corria en un ZX-81 ! )
|
|
|
|
|
En línia
|
|
|
|
syntonic
Visitant
|
T'he enviat un enllaç per privat - no tinc massa clar si puc penjar públicament aquest exemple. Suposo que sí, però més val anar amb compte amb aquestes coses.
Si algú més hi vol donar una ullada, que m'ho digui. Profilàcticament ho envio a alguns que han mostrat interès...
|
|
|
|
|
En línia
|
|
|
|
Pàgines: 1 2 3 [4] 5 
|
|
|
|
|
