Signale/h

Moin,

bei der doch recht heftigen Gewittertätigkeit der letzten Tage beobachte ich mehrere Stationen die weit mehr als 3000 Signale/h empfangen. Wie geht das?
Wenn ich bei meinem Empfänger die Empfindlichkeit erhöhe bekomme ich dauernd "interference mode". Bei optimaler Einstellung komme ich auf max. 2000 Signale/h. Mehr geht quasi nicht.
Ist bei mir was falsch eingestellt oder trickst da jemand den Tracker bzw. den Prozessor aus?
Ich kann mir vorstellen, daß unser Blitzortungsserver damit gut ausgelastet wird.

Schönen Sonntag

Sascha

Dear Sascha,
I try to make here a small draft overview what are the faktors, make effects on the data upoload "performace" of a sensor site. This notes based on my personal experiences, not any "official" knowledge.
1. I use an old, vers. 4 board, but the controller on it the same, as on the newest, and running it with the same 20 Mhz clock frequencies.
Usually I use it with different log/debug options. It seems me, this has effects to the data-preparation" performance of my station. I made a setup, and I can compare the "incomming" signal from the preamp board, and the data, will be upload from my station. I have the consequence, the uploaded possible lightning data rate is: 4-6 detected signals, and only from 1 will be made data and will upload to the server.
This is vizible well, if there is a nearby lightning activity. I can compare this data with the data of our, hungarian "official" local lighning monitor network: sometimes my detected strikes has the similar counts, as can see of this offcial maps.
Hope this link working to this local maps:

2. Maybe, you know, Egon introduced some limitations in the uploaded data, first was the uploaded limit/h from each stations around 3000/h.
Another limitations are in the tracker softwares, this is the Interference mode, introduced at the LT tracker vers 23, and the WT tracker ver 5. It seems me, this controlled by two variables:

// maximal number of strikes per second
// maximal number of seconds with strikes
Maybe the default values of this variables are good for the majority of the cases, but seems me, not in the case, when there are a heavy local activity.

3. This controll tools are effective agains some type of local noises, but it seems me again, there are some type of noises, on which havenot any controll effects. Maybe this types of local noises come continuously, and have periodical characters.

(By the way, I have a small idea, to use the triggering circuit, proposed by richo, to check the "real" visible local strikes with the help of this circuit: I plan to connect it to one channel of the toa board, and I will check the detected data on the same time on vlf and on the visible channel. )

I put here a screenshot about my simple setup:
On the xoscope software oscilloscope you can see the separated 2 channels, the signals come from the preamp board, parallel with the connection to the digital board.
In the right side windows you can see the log of the LT tracker, from the uploaded data blocks. At the case of a local strom, the most strikes consists from not only one flash, but more. On my example you can separate 5 flashes, but on the data log you can see, that from the first two flashes will be made data blocks, but from the next 3 flashes will be generated only one data block. Sometimes the situation is not so good.

best:
t.janos

Hello Sascha & t.janos

You are so right Sascha, how can it be technical possible to upload 21039 stike/h – se attached picture. I can’t figure it out.

Best regards

Arvin

Ofcourse, I dont know, how the reffered station is running, but we can calculate with some default values for some different "setups".
I cited the default control values from the 23-th version of LT:

#define MAX_STR_SEC 12 // maximal number of strikes per second
#define MAX_NONZERO_SEC 6 // maximal number of seconds with strikes

This means, in my interpretation, that this control process will be "active", if the incomming signal produce 12 data buffer contains in a sec. The second parameter says for me, that this "full-mode data creation" will stopp after 6 secs.

Based on this working mode, after this 6 secs long period the software switch on to "iterference mode", and wait some time. In this moment I dont know how long this time, but it is shure, longer than 1 sec.

Now we can suppose a "permanent (lightning) signal activity" around the station. In this case we can calculate the max throughput with this default parameters:
The 1 hour consists of 3600 sec, and if the station produce in all secs 12 data buffer contains, it can be upoload max 43200 data, if the Intereference mode "dont work", means it swiched back immediatly after the default parameters were processed...
If a station running not follow this default parameters, maybe it can produce more data...
But from this caculation we can see only a teorethical value, the software is busy with another tasks, not only to fill the data buffers. And there are another limitations, first of all the speed/troughput of the serial connection to the PC.
In my opinion the "pactical max values" are around the half of this teoretical number...

Maybe this calculations have mistakes, but we can see near similar values at some stations at the everyday practice.
If I see right the situation, we havenot too much possibilities to investigate this problems in more details. We dont have access to the raw uploaded data, maybe it willnot be stored for long time at the server side.
If we would like to check the uploaded data in each time, we have the Signal analysis site , but in the reffered case I dont have data about this. My list finished at 254.-th member, Rosstal.
t.janos

Hallo Jungs,

ich habe gestern mal den Tracker beobachtet und dabei schön verfolgen können, wie der Störmodus meine Station langsam aber sicher "abgeschaltet" hat.
Die Signale wurden immer mehr und der Störmodus blieb immer länger aktiv. Ab einem Zeitpunkt X ging der Störmodus gar nicht mehr aus. Als Folge davon wurden auch keine Signale mehr an den Server gesendet. (Signale/h: von über 5000 runter auf 0)
Dabei hatte ich rings um mich herum in sehr kleiner Entfernung sehr starke Gewitteraktivität.

Sind die Gewitter weiter entfernt von meiner Station, bekomme ich auch schon mal 6000 Signale/h hin, ohne das der Störmodus meine Station "abschaltet".
Woran kann das liegen:
Wenn der Störmodus blockt, legt er meine Station für 6 Sekunden lahm.
3600 / 6 = 600 Zeitfenster von 1 Sekunde
Innerhalb dieser Sekunde können max. 12 Signale (nach Erklärung von Janos) gesendet werden, bevor der Störmodus aktiv wird
Daraus folgt: 600 x 12 = maximal 7200 Signale/h

Soweit die graue Theorie ...

Moin,

Olivier das setzt aber voraus, daß während des aktiven Störmodus keine weitere Aktivierung/Verlängerung erfolgt.
Ich war ja gestern "mitten drin". Bei unveränderter Empfindlichkeit war der Störmodus fast dauernd aktiv und ich war bei ca. 1500 S/h.
Ich habe dann die Empfindlichkeit einen Hauch zurückgenommen, sodaß der Störmodus nur noch ca. 1/min anging. Das ergab max 2000 S/h.
Fazit: Ich komme nie über 2000 S/h weil dann der Störmodus überwiegt.
Mein momentaner Gedanke ist, die Widerstände des preamp R2 und R7 von 1k auf 2,2K zu ändern. Die Potis stehen z.Zt. auf ca. 25% und ich brauche sie nur scharf angucken um die Verstärkung zu ändern. Eventl. kann ich mich dann besser an die Einschaltschwelle des Störmodus rantasten.

Grüße von der Küste

Sascha

Dear Oliver, Sascha,
thank you for your estimations/calculations of the working state of your stations. In or discussion it is more interesting the case, what you analyzed, when a real lighning acitivity is close to the sensor station, instead of our "gray" theories.
But you can think about the "heterogen" setups in our network: there are in use different board versions, with different firmwares, different host systems, and dont forget, there are in use previous, old tracker versions too. This versions, before the LT 23 and the WT 5.20 there havenot this control mechanisms, based on the data creation limitations...
Ofcourse it is possible to modify the reffered default values and behaviour of the uploading characters, maybe, Sascha noted this in the first post. This is specially true to the linux version, but this isnot a good strategy on the "system level": in this case, we havenot any good overview, how our network working...

If we think about the question "Why need we such control mechanisems?" we can conculde, this need because the stations working in different local noise situations,
and sometimes there havenot a good, "commonly acceptable" adjustments. This is, why it is so important, what Oliver desrcibed his "best practice" with the basic adjustments, in the thread Einstellen der Systemempfindlichkeit.
t.janos

Hallo Jungs,

ich habe in den letzten Tagen auch mit der Verstärkung herumgespielt und dabei folgende Beobachtungen gemacht:
Bei einer Potieinstellung von 36% habe ich normalerweise ganz passable Werte (Blitzqoute 30-40%, Signalquote 20-30%).

Bei einem starken Gewitter mit einer Entfernung < 50 km:
Bei meiner normalen Potieinstellung gehen die Signale/h allmälich in die Höhe bis ca. 6000 Signale/h. Der Störmodus fängt an zu arbeiten und fährt meine Station runter bis auf fast 0 Signale/h. Blitz- und Signalquote nehmen natürlich ab.
Verringere ich jetzt die Verstärkung auf 8% der Potieinstellung, geht der Störmodus wieder zurück. Die gesendeten Signale nehmen wieder zu bis auf einen Wert von ca. 1800 Signale/h. Die Blitzquote beträgt ca. 10% und die Signalquote liegt irgendwo bei 2-3% - also alles andere als gute Werte.

Man kann sagen, dass ich mit meiner Verstellung der Verstärkung die Station wieder online gebracht habe.
Auf der anderen Seite habe ich aber mit meinem Handeln den Störmodus überlistet. Dieser hat ja meine Station "abgeschaltet" und somit verhindert, dass ich jede kleine Entladung als Signal an den Server gesendet habe. Durch die Verringerung der Verstärkung sende ich zwar brauchbare Signale, aber auch über 90% nicht brauchbare Signale. Das liegt aber in der Natur der Sache: ein Blitz kann aus vielen Entladungen bestehen - uns interessiert die Hauptentladung.

Wie gesagt, dass sind Beobachtungen an meiner Station und daraus kann man keinesfalls allgemeingültige Aussage machen. Man müsste das mit Beobachtungen anderer Stationsbetreiber mal abgleichen und diskutieren ...
Dabei muss man aber auch Janos Argumente berücksichtigen (PCB-Version, Antennentyp, Firmwareversion etc.).
(Während ich diesen Text schreibe, läuft ein weiterer Test an meiner Station: die Verstärkung wurde wieder von 8% auf 28% hochgedreht. Als Folge davon ist der Wert für Signale/h von 5500 auf 3200 zurück gegangen, bei gleichbleibenden Wert für "durchschnittliche Siganle pro Station" von Tobis Grafiken. Die Gewitteraktivität hat sich allerdings um ca. 50 km von mir entfernt. Könnte auch ein Grund für die abnehmende Anzahl an Signalen sein ...)

It seems me, this problems we can investigate min in two levels:
1. On the local level, at our sensor stations, it would be best, if we can detect all the real strikes. If we want to get a realistic "picture" (statistics) about a real storm, around and nearby us, we need a continuously working sensors, and we need to record all the possible signals. In this case, the built in control, or limitation isnot our "friend".
2. On the network level the relationship beetwen this "heterogen components" get another contexts:
If there are more then 4-5 sensor stations, working in the same time, and produce continouosly data come from "not-real-lightning" events, we can see some patters, or distributions of the strikes, what are not realistic, and only production of the stations with overrun data uploads.
With the control tools, or built in limitations, we can see the final result, produced continuously by our network, as a time-to-time captured sample of the real signals. In this network level, the overview is good: if there are somewhere a heavy lightning activity, on our maps we can follow this. In this context it is not the first question, are there all the possible strikes was recorded or not.
t.janos

Hallo Janos,

alle möglichen Signale aufzeichnen (="to record all the possible signals") geht mit dem TrackerLog.
Als Einzelstation kann man aber nur feststellen, dass ein Signal da ist. Eine Einzelstation kann nicht feststellen, welchen Ursprung das Signal hat.

Hi, dear Olivier,
I know that the each stations canot produce the same result, as the network server can. But the server, when calculate the localtions, can choose only from the data, what was uploaded from the sensor stations. If our system select (drastically) the data at the each sensors, the result willnot be more fullfilled.
Here is my case with some numbers:
Yesterday evening was a heavy front on south part of our country. The official hungarian lightning detection network at met.hu use 7 sensor stations, and detected 18174 strikes in 1 hour time frame, 19.00-20.00 UTC, as you can see on the attached screenshot.
The blitzortung network used more than 150 sensor stations in this time (I didnot checked the exact numberot the working stations) and detected, practicaly on this geographical location 612 strikes, practically in double time frame, beetween 18.17-20.17 GMT, as you can see on the attached picture.
And on this time, I see on my "simple setup", that my station sensed a huge amount of strikes, but was rejected a signiphicant parts of it, because of the control mechanisems, and wasnot accepted at the server, as a data for the calculations, because the time stamps.
My "simple setup" means, I connected the sound output of the preamplifier board to my soundcard, and I run on this signals a 2 channel software oscilloscope, and in the same time I follow the generated log of the toa board. The tracker run with the -vs log option, to write out only the uploaded data blocks.
On the case of the attached screenshot you can see 5 possible strikes, from the first 2 were generated data block, but from the next 3 signal was made only 1 data block, but this case is a good example, if you follow this processes, you will see, the majority of the local signal willnot cause detected data blocks...
This is, what I said, there are differences on local, sensor level and on the network level.
t.janos

Hallo Janos,

ich verstehe was Du aussagen willst. Die Frage muss aber zuerst lauten: "Was wollen wir aufzeichnen: Blitze (engl.: flash) oder Entladungen (engl.: stroke)?
Unsere Antennen empfangen Signale von Entladungen (engl.: stroke). Ein Blitz (engl.: flash) kann aus 30-40 Entladungen (engl.: stroke) oder auch weniger z.B. nur 10-20 Entladungen (engl.: stroke) bestehen. Wir können aber nicht zweifelsfrei sagen, ob die 21. Entladung (engl.: stroke) zum ersten Blitz (engl.: flash) oder schon zum nächsten Blitz (engl.: flash) gehört.

Wenn ich nun die zwei "Blitzortungen" (engl,.: lightning detection) vergleiche, dann fällt der Faktor 29,696 auf, um den die Signale bei Blitzortung.org weniger sind. Nun könnte man einfach die Behauptung aufstellen, dass die eine Seite die Entladungen (engl.: stroke) und die andere Seite die Blitze (engl.: flash) aufzeichnet. Sicherlich ein sehr einfache Erklärungsmethode und ob sie richtig ist, weiß ich nicht. Aber möglich wäre es ...

Bei dem Vergleich der beiden "Messwerke" sollte man auch den finanziellen Hintergrund nicht vergessen. Blitzortung.org ist privat und hat bestimmt nicht das Budget einer staatlichen/kommerziellen Messeinrichtung.

EDIT: Bei den Anzahl Entladungen eines Blitzes gibt es unterschiedliche Angaben. Die Einen sprechen von 3-4 Entladungen und die Anderen geben über 40 Entladungen an.

Moin,

ich kann Janos Aussagen nur bestätigen.
Mein Boltek-System hatte gestern im Nahbereich dramatisch mehr Blitze registriert als TOA.
Ich vermute auch den Faktor Rechenzeit spielt dabei eine Rolle.
Wie lange braucht denn unser Prozessor für eine Blitzberechnung? Dazu kommt bei einem Empfangsradius von ca. 2000km noch die Gleichzeitigkeit von Blitzereignissen die unser Prozessor irgendwann auch als Störung auslegt.
Das Gleiche gilt ja auch für den Zentralserver der die Blitze berechnen muss.
Die Korrelation der Daten braucht ja auch seine Zeit. Ich vermute mal bei mehr als 50 S/sek ist da Schluss.
Mein Boltek zeigte gestern mehr als 200 S/min im Nahbereich an.
Daher ist für mich klar, daß TOA nicht alle Blitze berechnen kann.

Doch zurück zu meinem Problem.
Ich habe jetzt die Widerstände getauscht. Jetzt kann ich die Empfindlichkeit besser einstellen.
Ich komme trotzdem nicht über 2000 S/h hinaus, da sonst der Störmodus überwiegt.
Eventl. liegt es an meinem alten PCB 4 Board, allerdings mit neuem Proz. und aktueller Firmware.
Vielleicht ist bei dieser Kombi der Störmodus zu empfindlich.

Grüße

Sascha

Hier ist ein schönes Beispiel für den Unterschied "Blitz" und "Entladung"
Blitz vs. Entladung

@saschaho:
Sascha, mir ist nicht ganz klar, warum Du unbedingt deine Signale/h erhöhen willst, obwohl Du relativ gute Quoten hast ...
Ich kämpfe eher damit, dass bei einem Gewitter meine Signale/h unverschämt hoch sind (bei gleichzeitigen miesen Quoten) ...

Hi Olivier,
I aggreed with you, my example need more explanation and interpretations.
We can aggree in some basics:
all the two networks measure the same physical phenomens, but not the same mathods and not the same parts of it.
We measure on VLF frequncies, our sensors most sensitive to the cloud-to-ground discharges, means we detect the bigger type of lightning strikes. Each sensor stations in our network reach all lightning event in 2000 km ranges...
The hungarian local network (supported by the eu-wide euclid) use sensors, working on the UHF (?) frequnecy ranges, and most sensitive to the cloud-to-cloud strikes, if my knowledge is correct, this are more often happened in a heavy storm front.
Another signiphicant difference between the two networks, that the met.hu sensor sites were "optimized" geographically, and its sensitivity ranges concentrate to the Charpatian basin. If you look into the picture, you can see this "configurations" on and around our country. The blitzortung network is a voloutair based community, each new stations come up, where somebody new member joined the community...
One of a "professional" network, maybe have some description, or "protokoll", how can adjust the sensors in a standard way, and maybe, there are regular services, which control this adjustments, or can correct its remotly.
It seems, we canot be compare the two networks in the sizes of the measured territories.: The local hungarian network dont able to produce any data to the eu continent, only for the 500x500 km2 territory. The blitzortung network produce for every 1 minute fressh data for all the European continent.
You noticed the importance of the budget differences: it is important, and has effects to our network in some aspects, but in this case, I think, we can count with it not in the first row.
(I will study a little more your example about the differences of stokes and discharges/flashes).

I dont want to say summary, or conclusion, but I think, our network produce a good overview to the euroean-wide scale.
t.janos

Zitat von Olivier

@saschaho:
Sascha, mir ist nicht ganz klar, warum Du unbedingt deine Signale/h erhöhen willst, obwohl Du relativ gute Quoten hast ...
Ich kämpfe eher damit, dass bei einem Gewitter meine Signale/h unverschämt hoch sind (bei gleichzeitigen miesen Quoten) ...

Ja, wenn die Gewitter ausserhalb eines 500km Radius liegen, ansonsten überwiegt sehr schnell der Störmodus.
Daher meine Frage am Anfang wie es einigen Stationen gelingt auf sogar mehr als 10000 S/h zu kommen.

MfG

Sascha

Ok, I can add this remarks too:
We can search the way, or methods, or devices, what can help to measure more accuratly the storms nearby our locations. Maybe we can use our existing devices, adjusted to this aims, maybe we can use anothers, in first row I would vote to the LR devices.
Sascha bought, and start to use a Boltek device....I will wondering to his experiences. I havenot too much, well based knowledge about this devices, but I have the feeling, this way isnot the best approaches for us.

I took some short visit on this pages, proposed by Olivier:

I think, this isnot a cheap alternative for us. Not cheap at all, and I have some questions in the usefullness of this devices, as our alternatives.
This new company offers a new software for the Boltek devices, called "personal lightning detectors", it sells this devices on the same or little higher prices as the Boltek, and combined with the Lightning/2000 or the MesoTrack software.
My basic problem with this "personal devices", that they dont produce data about the lightning locations, or directions, but measure, maybe on two different channels with limited antena/sensor designes, and make some calculations/filtering, we dont know, what happened exactly inside the new (and the old) softwares. Finally we can see some points on maps, representing the events around us. Based on the published two pictures on this page,

it seems me to make differences between this two termins, "flashes and strokes", they use only to "clarify", why they make something postporocessing in their software inside. This devices dont produce timestamps on the similar accuracy, as we use.

This is my opinion based on the first quick look around, mybe can refine it, and it would be good to get/collect more informations about this devices, methods, and softwares.
t.janos

@ Janos:
Ich wollte auf gar keinen Fall BOLTEK bewerben - für mich ist das System einfach zu teuer (habe ja auch noch andere Hobbys, die auch Geld kosten). Über die Qualität kann ich nichts sagen.

@saschaho:
Bei 10.000 Signalen würde ich zuerst mal nachschauen, wie die Werte für Signale/h ohne Gewitteraktivität aussehen. Im Frühjahr gab es eine Station, die zu bestimmten Zeiten ca. 1.800 Signale/h hatte, ohne das ein Gewitter (auch in größerer Entfernung) aktiv war.
Bei einem Vergleich seiner eigenen Station mit anderen Station sollte man immer vorsichtig sein. Ich bin sogar der Meinung, dass ein direkter Vergleich gar nicht möglich ist.
Natürlich schaut man immer über den Tellerrand und das ist auch gut so. Ich z.B. orientiere mich an drei, vier Stationen aus der Umgebung. Dabei schaue ich hauptsächlich, ob das Trendverhalten gleich ist oder ob es signifikante Unterschiede gibt.

Moin,

habe die Ursache für meinen frühen Störmodus gefunden.
http://www.wetter-board.de/index.php?page=Thread&threadID=46349

Grüße

Sascha