2015-07-23, 12:09
Some quick thoughts:
It occurs to me from observation that, while not processed as a stroke, IC and CC discharges are in fact received by my station, both H and E components.
Hence, perhaps, one reason the 'interference mode' paradigm at the controller, especially for 'nearby' storms.
They contribute to many of my 'signals', outside of my normal local 'junk', which I struggle mightily to minimize. Last year, another operator and I compared signals in real time, over an extended time, and, certain signals, were easily recognizable as same 'sferic', but were classed as 'junk'... yet we observationally concluded they were the same signal, not local, and were sferics, of some type. No, Dave and I do not have documentation concering those observations... but we solved an interesting 'anomaly' that puzzled us both at the time.
Since IC and CC and other sferics apparently aren't recognized by the server, Steph's proposed 'bias' or 'emphasis', I think, might apply to that. How to do it is beyond my ken.
Another factor is the longer delayed 'skywave' components.. (e.g.: 4+ reflection) many of which are 'rejected by the server because of the delay, or distortion being too far out of sync with the 'detecting' time stamp.. yet they are the same stroke, but classed as 'noise',... this is resolved by 'reduced gain' and range locally, obviously. Which, I think, is part of the reason for Egon's paradigms... in general, to 'push' the majority of stations in the 'center' of a region into a more efficient, let us say, <1500 km range. While at the same time encouraging 'edge' regional stations to support 'less dense' regions, with higher gains, etc. Those 'edge' stations would necessarialy have longer range, more signals, perhaps a significantly lower 'effectivity'... in order to help support network development.
For network efficiency, as opposed to station effectivity, it is not necessary for me, in a dense region, being in the center, to detect signals >1500 km... other stations handle that... if I'm sending only skywaves from those signals, and they are way beyond the 'time frame' for locating, distorted, delayed, then that, for network, is "junk". Matter of fact, for network efficiency, I'd be better off to reduce to <800 km, and stop sending my extraneous signals, of no locating or detecting use. But the computation then implies that 689 is a very 'ineffective' station.
From a network standpoint, even a 'reporting region' standpoint... as has been mentioned, this system not only punishes those with lots of 'bad' signals, and have resorted to 'run and be damned', but also those who have spent hours, energy, and frustration, in order to achieve the best 'local' operation, and the best overall 'network' contribution,... simply because of what would amount to an inability of the basic server algorithms at this time, to discriminate lightning types, polarities, etc
Perhaps we spend top much time overall, concerning ourselves with the 'right hand column' on the participant's page, and downplaying the importance of the,. to me, more important, from the network's effictivity, of the preceeding 2 columns.
Now, the above thoughts concern true 'atmospheric' reception. They don't apply to local noise, etc, which we also may put too much emphasis. Some of us, like I, have to simply live with a higher 'signal' count many times, therefore 'less effectivity', in order to actually provide meaningful network usable signals. But if I failed to mitigate as much as possible my transmission of the junk, than that's my fault. If I can't mitigate the junk, than I must make my station as efficient, as effective, as possible, and this may mean the "3rd column" long range 'does not apply to me', and pay more attention to my own 'localized' data, and operating restrictions....
Yeah, don't specifically like that,... like to be number one... but that appears to be the most effective, most efficient, way for me to approach this.
Some food for thought papers, FWIW:
http://onlinelibrary.wiley.com/doi/10.10...02790/full
http://onlinelibrary.wiley.com/doi/10.10...14736/full
Cheers!
Mike
It occurs to me from observation that, while not processed as a stroke, IC and CC discharges are in fact received by my station, both H and E components.
Hence, perhaps, one reason the 'interference mode' paradigm at the controller, especially for 'nearby' storms.
They contribute to many of my 'signals', outside of my normal local 'junk', which I struggle mightily to minimize. Last year, another operator and I compared signals in real time, over an extended time, and, certain signals, were easily recognizable as same 'sferic', but were classed as 'junk'... yet we observationally concluded they were the same signal, not local, and were sferics, of some type. No, Dave and I do not have documentation concering those observations... but we solved an interesting 'anomaly' that puzzled us both at the time.
Since IC and CC and other sferics apparently aren't recognized by the server, Steph's proposed 'bias' or 'emphasis', I think, might apply to that. How to do it is beyond my ken.
Another factor is the longer delayed 'skywave' components.. (e.g.: 4+ reflection) many of which are 'rejected by the server because of the delay, or distortion being too far out of sync with the 'detecting' time stamp.. yet they are the same stroke, but classed as 'noise',... this is resolved by 'reduced gain' and range locally, obviously. Which, I think, is part of the reason for Egon's paradigms... in general, to 'push' the majority of stations in the 'center' of a region into a more efficient, let us say, <1500 km range. While at the same time encouraging 'edge' regional stations to support 'less dense' regions, with higher gains, etc. Those 'edge' stations would necessarialy have longer range, more signals, perhaps a significantly lower 'effectivity'... in order to help support network development.
For network efficiency, as opposed to station effectivity, it is not necessary for me, in a dense region, being in the center, to detect signals >1500 km... other stations handle that... if I'm sending only skywaves from those signals, and they are way beyond the 'time frame' for locating, distorted, delayed, then that, for network, is "junk". Matter of fact, for network efficiency, I'd be better off to reduce to <800 km, and stop sending my extraneous signals, of no locating or detecting use. But the computation then implies that 689 is a very 'ineffective' station.
From a network standpoint, even a 'reporting region' standpoint... as has been mentioned, this system not only punishes those with lots of 'bad' signals, and have resorted to 'run and be damned', but also those who have spent hours, energy, and frustration, in order to achieve the best 'local' operation, and the best overall 'network' contribution,... simply because of what would amount to an inability of the basic server algorithms at this time, to discriminate lightning types, polarities, etc
Perhaps we spend top much time overall, concerning ourselves with the 'right hand column' on the participant's page, and downplaying the importance of the,. to me, more important, from the network's effictivity, of the preceeding 2 columns.
Now, the above thoughts concern true 'atmospheric' reception. They don't apply to local noise, etc, which we also may put too much emphasis. Some of us, like I, have to simply live with a higher 'signal' count many times, therefore 'less effectivity', in order to actually provide meaningful network usable signals. But if I failed to mitigate as much as possible my transmission of the junk, than that's my fault. If I can't mitigate the junk, than I must make my station as efficient, as effective, as possible, and this may mean the "3rd column" long range 'does not apply to me', and pay more attention to my own 'localized' data, and operating restrictions....
Yeah, don't specifically like that,... like to be number one... but that appears to be the most effective, most efficient, way for me to approach this.
Some food for thought papers, FWIW:
http://onlinelibrary.wiley.com/doi/10.10...02790/full
http://onlinelibrary.wiley.com/doi/10.10...14736/full
Cheers!
Mike
