Blitzortung.org Forum

The new efficiency ratio is simply wrong

Yes, thats correct !

But without the "denominator", poor performing station will be pushed up, if they sending a lot of signals (and maybe a few more strokes). Thats not good for the network.



You see the difference ?  I find the red graphic fair. It doesn't denominate good performing station, but suppresses heavy signal-jammer. And it also shows good performing stations with less signals at the right side in the graph, not only on the left side.

Thomas

(2015-07-21, 17:04)Knickohr Wrote: [ -> ]But without the "dominator", poor performing station will be pushed up, if they sending a lot of signals (and maybe a few more strokes). Thats not good for the network.

Hi Thomas,

But as the screenshot I posted shows; A station with Less strikes and more signals is ranked higher. The 2 stations I compared here are only 10km apart. 
[attachment=2142]
I agree with Kriu. This can not be right.

Its depends on how less and how more

Thomas

(2015-07-21, 18:54)Knickohr Wrote: [ -> ]Its depends on how less and how more

Thomas

I attached a screenshot. So you can see how less and how more...

Gerhard

It has something to do with this :

"This is the old effectivity value multiplied by the factor min (Strikes / Signals(s), Signals(s) / Strikes)."

Thomas

(2015-07-21, 19:26)Knickohr Wrote: [ -> ]It has something to do with this :

"This is the old effectivity value multiplied by the factor min (Strikes / Signals(s), Signals(s) / Strikes)."

Thomas

Read that.... it is posted in this thread.
Or do you think sending more signals and less strikes is better?? I guess you know better...

I hope Egon, or one of the developers finds time to reply

Gerhard

(2015-07-21, 19:26)Knickohr Wrote: [ -> ]It has something to do with this :

"This is the old effectivity value multiplied by the factor min (Strikes / Signals(s), Signals(s) / Strikes)."

Thomas

Read that.... it is posted in this thread.
Or do you think sending more signals and less strikes is better?? I guess you know better...

I hope Egon, or one of the developers finds time to reply

Gerhard

Hi Folks,

I am really impressed by your ambition to analyze the effectivity in such detail.

If we find a more useful computation, I will change it, no problem, but I need arguments not only suggestions to improve own stations.


Let us recal the  notations and the original value I have used in the past.

The values consider the last hour.

Strikes (x,s) = number of strikes computed by our network in a rage of x km to station s

Hits (x,s) =  number of strikes computed by our network in a range of x km to station s at that station s was involved

Signals (s) = number of signals of station s

Strikes() = total number of strikes computed by our network in the region to that the station sends data (note that some border stations send strikes to several regions)

min (x,y) = minimum of x and y

The old values for the effectivity of a station S were:

Effecitivity S = Hits (50km, S) / Strikes (50km)
Effecitivity M = Hits (500km, S) / Strikes (500km)
Effecitivity L = Hits (5000km, S) / Strikes (5000km)

The disadvantages are the following:

1.) A station S with very very low Hits (5000km, S) can easily get an Effectivity L of 100% if it is placed in a region where all computations can only be done with the help of this station (for example, a border position). Stations in densely populated areas usually get lower values.

2.) If Signals (s) increases, then often Hits (5000km, S) also increases a little bit. Some stations have tenfold its Signals (s) only to increase its effectivity by 1 percent. This increases the load of our servers significantly


So I have added the additional factor:

min (Strikes / Signals (s), Signals (s) / Strikes)

And now your suggestions for a more adequate computation of an effectivity.

(2015-07-23, 06:27)Egon Wrote: [ -> ]And now your suggestions for a more adequate computation of an effectivity.

No suggestion, I agree with Egon. I have advantages for all my stations. case 1 (Namibia) and case 2 (Germany). Heavy signal-jammer should be suppressed.

Thomas

My proposal:
[attachment=2146]

For each range (50,500,5000)

Red axis * (Blue axis * emphasis factor)
emphasis factor since red axis is more important than blue axis.


(Station_Strikes / Station_Signals) * ((Total_Strikes / Station_Strikes) * Emphasis)

But is it really a problem? I think a team member could contact those 5% that are very bad.

Steph,

it's not possible, to go "over" the red axis. If this happens, a station would detect more than one strike with only one signal !

But an good idea. Maybe we can set the emphasis factor dynamically, if me measure/calculate the distance a station (strike/signal) to the red axis. If I know well, i'ts is called "normalization". But we also should take care of the number of detected stroke a station have, too.

Let me do some experiences

Thomas

The results would be much more realistic, if we would measure the strike current and correlate it with the signal strength and distance of the station. That's possible, but so far I hadn't the time to implement the algorithm for that.

(2015-07-23, 11:13)Knickohr Wrote: [ -> ]it's not possible, to go "over" the red axis. If this happens, a station would detect more than one strike with only one signal !

Yes, the red axis has a maximum value of 1.

(2015-07-23, 11:21)Tobi Wrote: [ -> ]The results would be much more realistic, if we would measure the strike current and correlate it with the signal strength and distance of the station. That's possible, but so far I hadn't the time to implement the algorithm for that.

Would be very interesting. But could also be difficult, because the EM-Field isn't radiated and propagated isotropic. While the propagation can be estimated with a bunch of formulas, the radiation pattern is more or less random. Though, it differs only a few dB.


And it would only adress the sensitivity, not the SNR.

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

Hmmm ...

(Station_Strikes / Station_Signals) this is the red axis
(Station_Strikes / Total_Strikes) this is the blue axis

(Station_Strikes / Station_Signals) * (Station_Strikes / Total_Strikes) this is the efficiency in lightningmaps.org !

Maybe we have to put some weighting to this both axises ?

For example :

( 2x (Station_Strikes / Station_Signals) + 1x (Station_Strikes / Total_Strikes) ) /3 *100

This will double the weighting for the location ratio.



Hmmm, looks like every station is efficient

Edit : Played a little bit with the weighting and found, the best weighting is NO weighting (see plot) The only different now is the + operator, not using the *

Thomas

Just to be sure: Signals() regroups only the junk or the strokes are also counted in that var?

In the English, the term Egon's using is "Effectivity" on the 'Participants page".  
"Efficiency" is used on LMO.  The difference in terms can be either significant, or similar...

I note most of the posts, and even the thread title is the term
"Efficiency"  ... as in "Skillful use of energy or industry to accomplish desired results with little waste of effort

"Effective" as "successful in producing a desired or intended result".

So two stations at the same location:
Both stations send the same 100 strokes, with good data, good GPS, etc.
Station X sends 200 signals
Station Y sends 150 signals
to produce the exact same result - accurate detection with good data of a lightning stroke-
Both stations have the same "effectivity" -ability to achieve a desired result.

BUT  X is less "efficient" than station Y which sends fewer signals.
That is, both stations send good info about 100 strokes, X should have the same "Effectivity" as "Y"  but certainly less "efficiency".

So, if those definitions were adopted, the whole issue might be changing the term from "Effectivity" to "Productivity" or similar,
meaning "the effectiveness of productive effort, as measured in terms of the rate of output per unit of input".

Mike

Mike, I use the term efficiency as given in the table view from lightningmaps.org.

OK; maybe its better to use effectivity

Thomas

(2015-07-23, 17:10)Knickohr Wrote: [ -> ]Mike, I use the term efficiency as given in the table view from lightningmaps.org.

OK; maybe its better to use effectivity

Thomas

Yes, that's the confusion, I think... the original post inquired about LMO "Efficiency", which Tobi computes differently, but the thread seemed to devolve to the "Paricipants" BO page "Effectivity" computation....

Tobi once told me something similar to, " there was no real way to arbitrarily compute" the matter under discussion, or that's what I understood him to say...  especially when this sentence is taken out of context from that discussion...  I think there's a post here where Tobi explained that, can't find it, and I could be wrong.. but it's different than Egon uses, or was.

I think when Egon looks at the main BO server, he's concerned about too many signals from too many stations, and would like to increase 'productivity' by decreasing the 'input', if possible, and a couple of other 'motives'... remember that last year, a "push toward"  station quality was 'hinted' at, and this is part of that, I think.

I can set my gains and thresholds right at the point of 'Interference Mode" and increase my total stroke detection by sending thousands of signals, but that does nothing to help "Network Efficiency"... has nothing to do with my station's "effectiveness" (I can detect strokes)... and certainly lowers "productivity" and "efficiency" .... The little circuit boards are "effective" at a high percentage, but doing useless work and forwarding that extra effort to the server, so to speak.

Mike