1 hour ago
Out-thinking this, I believe. 
If by “Packets” you mean Signals... yep, those numbers can and will change hourly, daily, seasonally, and sometimes dramatically without you changing a thing.
First question is always:
Where’s the lightning?
When looking at any station in near-real-time, the location and amount of lightning matters enormously, as does the population of other stations participating in those strokes. That is one reason the numbers can move around so much even when your receiver itself has not changed.
If by “packets” you literally mean UDP data traveling from the controller to the server, that is a different issue. Yes, packets can be lost, although normally that is relatively rare. Delay getting there is normal; delay large enough to materially affect things is much less common.
We recently had a very useful example because we happened to have two co-located Blitzortung stations to compare directly:
https://forum.blitzortung.org/mybb/showt...3#pid28113
We found an apparent difference of roughly 4 milliseconds between them. Four milliseconds is an eternity in lightning-location language. In that case the evidence pointed toward something in the local network path.
If something like that is occurring somewhere beyond your own network, of course, there is essentially nothing you can do about it.
But before chasing a server-side “Factor X,” I think there is another important distinction:
Used is not really a station-success meter, nor is it a measure of successful packet delivery.
Signals and Valid occur earlier in the chain. Valid signals are then considered by the processing system; Involved are signals associated with actual detected strokes, and Used are the Involved signals actually selected for the location calculation.
So a Used count changing from 3,000 to 500 does not, by itself, mean that anything has deteriorated at your station.
The Selected Region statistics can vary dramatically with lightning activity, station location, the processing region, and which other stations are available at the moment.
As for optimizing the receiving system, most of what an operator really needs is in the two attached PDFs... more or less. I’m still refining some of the presentation, but the basic concepts are there. Which is why some 'instructions' might seem shotgun, do this do that... station environments are unique... take the two documents, keep it simple, realize that once it leaves your network, you have zero control.
The BlitzView notes are probably the document most directly relevant to the statistics you are looking at. They also explain why stability matters so much, including gain, timing, trigger level, sieve behavior, and the danger of trying to optimize while the station itself is constantly changing settings automatically.
The other PDF is more background on why I tend not to approach lightning reception like conventional narrow-band RF “tuning.” Lightning is a transient impulse phenomenon; the receiver is sampling an impulse-energy/time signature rather than hunting for some nice repeating carrier frequency.
As a one-time Air Force Electronic Warfare Shop technician, followed by about 30 years in consumer electronics, radio and television, I’d gently suggest that some alternate thinking becomes very valuable when getting acquainted with this lightning-location hobby.
I came into it wanting to measure, isolate, adjust and solve everything too.
That approach is useful — but only up to a point.
A tremendous amount of what you see in Blitzortung statistics is controlled by lightning location, propagation, network geometry, the other stations available at that moment, and what the servers need from them. Those are things completely outside your station.
The sooner we admit how much of this is outside our control, the sooner we can quit beating the tar out of ourselves trying to “fix” every statistical change.
If by “Packets” you mean Signals... yep, those numbers can and will change hourly, daily, seasonally, and sometimes dramatically without you changing a thing.
First question is always:
Where’s the lightning?
When looking at any station in near-real-time, the location and amount of lightning matters enormously, as does the population of other stations participating in those strokes. That is one reason the numbers can move around so much even when your receiver itself has not changed.
If by “packets” you literally mean UDP data traveling from the controller to the server, that is a different issue. Yes, packets can be lost, although normally that is relatively rare. Delay getting there is normal; delay large enough to materially affect things is much less common.
We recently had a very useful example because we happened to have two co-located Blitzortung stations to compare directly:
https://forum.blitzortung.org/mybb/showt...3#pid28113
We found an apparent difference of roughly 4 milliseconds between them. Four milliseconds is an eternity in lightning-location language. In that case the evidence pointed toward something in the local network path.
If something like that is occurring somewhere beyond your own network, of course, there is essentially nothing you can do about it.
But before chasing a server-side “Factor X,” I think there is another important distinction:
Used is not really a station-success meter, nor is it a measure of successful packet delivery.
Signals and Valid occur earlier in the chain. Valid signals are then considered by the processing system; Involved are signals associated with actual detected strokes, and Used are the Involved signals actually selected for the location calculation.
So a Used count changing from 3,000 to 500 does not, by itself, mean that anything has deteriorated at your station.
The Selected Region statistics can vary dramatically with lightning activity, station location, the processing region, and which other stations are available at the moment.
As for optimizing the receiving system, most of what an operator really needs is in the two attached PDFs... more or less. I’m still refining some of the presentation, but the basic concepts are there. Which is why some 'instructions' might seem shotgun, do this do that... station environments are unique... take the two documents, keep it simple, realize that once it leaves your network, you have zero control.
The BlitzView notes are probably the document most directly relevant to the statistics you are looking at. They also explain why stability matters so much, including gain, timing, trigger level, sieve behavior, and the danger of trying to optimize while the station itself is constantly changing settings automatically.
The other PDF is more background on why I tend not to approach lightning reception like conventional narrow-band RF “tuning.” Lightning is a transient impulse phenomenon; the receiver is sampling an impulse-energy/time signature rather than hunting for some nice repeating carrier frequency.
As a one-time Air Force Electronic Warfare Shop technician, followed by about 30 years in consumer electronics, radio and television, I’d gently suggest that some alternate thinking becomes very valuable when getting acquainted with this lightning-location hobby.
I came into it wanting to measure, isolate, adjust and solve everything too.
That approach is useful — but only up to a point.
A tremendous amount of what you see in Blitzortung statistics is controlled by lightning location, propagation, network geometry, the other stations available at that moment, and what the servers need from them. Those are things completely outside your station.
The sooner we admit how much of this is outside our control, the sooner we can quit beating the tar out of ourselves trying to “fix” every statistical change.
