Lightning Strike Trend (storm is approaching or departing)

[jhrucker]

I’m working on a gauge that shows the lightning strike distance from my tempest. From the API I can get: avgStrikeDistance, strikeCount, and as a summary: strikeCount1h, strikeCount3h, strikeLastDist, strikeLastEpoch.

But none of those tell me if the storm is approaching or departing? I can compare the current strike to the previous strike but that is not reliable as the strikes jump all over the place. It would be awesome if there was some type of property based on weatherFlows AI that could let us know if the storm is approaching or departing.

Maybe it is there in another field and I have missed it??

Has anyone else worked out a way to tell if a storm is approaching or departing based on lightning information?

[93ben]

@GaryFunk sums this up well… Tempest Complete System International Shipping Update

[jhrucker]

I get that it is not easy and my station’s data alone is probably not enough to make a determination. But the weatherFlow cloud has a ton more data then just my station’s lightning strike data. I was thinking they could do the number crunching on the back end and push it out to the stations in the path of a storm.

Heck If I just print the lightning strike data from a storm my tempest observed, I can tell when the storm was first detected, got the closest, and left. But I can only see that after I have all the data from that storm. I’m looking for something that can make predictions as it occurs.

I’m going to run my report again and add the barometric pressure and see if that can help me calculate if the storm is approaching or departing.

[jhrucker]

Here is a plot of a storm my tempest observed last month. The top graph shows the lightning distance in miles, and the second graph is the barometric pressure.

You can see a clear trend at the beginning that shows the storm approaching (distance getting smaller and smaller). But once the storm gets here it seems to bounce all over the place. That is probably what is really happening. As the front passes tons of concentrated lightning then hits are detected all over the place. Also the barometric pressure is the highest at the point the lightning seems to be the closest.

This is just one storm. Need to do some more analysis.

[sunny]

I suggest you use the 5 nearest strikes, if the average distance of those is getting significanly less over time the storm is getting closer, if it is getting bigger, the storm is departing. Note that it doesn’t mean the storm will go over your location, it might be passing by at 15km distance. Just a suggestion, you could invent a different algorithm.

[jhrucker]

I think I have something that is going to work for my needs. When lightning is first detected I flag it is as approaching. Once the lightning is overhead (within 5 miles) I then flag all strikes as overhead / departing.

My goal is to give the observer of the gauge some type of indication as to where the storm is. If they look at the gauge and see that the needle is on the left side of the gauge they know it is approaching. If the needle is on the right side of the gauge they know it has approached and is either departing of hovering overhead.

Here is my GitHub repo based on the weather flow API:

WallGauge-GaugeApps/weatherFlowDataGetter

[sunny]

interesting, more informative than just “15 miles”. Weatherflow could use some of this programming tech to say instead “15 miles and departing”.
Just wondering how you handle multiple storms like this:

[jhrucker]

I had a similar storm to that in one of my test runs. It first appears as a distant 25 mile strike, approaches and then departs and then another cluster of lightning approaches and departs over and over.

As the algorithm stands now the gauge would show the first initial 25 miles of strikes on the approaching side of the gauge face. Once it detects a strike 5 Miles or closer it would flip over and show all remaining strikes on the overhead / departing side. Yes it would miss the fact that another cluster is approaching and show it on the overhead / departing side. But I would argue that it is still useful as the algorithm stands. An observer of the gauge could draw the conclusion that if a strike is on the approaching side of the gauge, the storm is most likely just getting here for the first time.

I agree it would be awesome if whetherflow would calculate the lightning cluster direction for us.

[sunny]

of course it would be hard to know that another is approaching but you might be able to detect the second storm at 1:15. You might get inspiration from something I suggested to David in my post from july 17 [App] Better control over lightning strike alerts

[jhrucker]

That is an awesome thread! I like how the zones are setup and the alerts are sent. “sunny zones” smile.

I think I’m going to table the lightning gauge for now and focus on the easy stuff. I want to get something I can hang on the wall and start testing.

[Newlife]

really amazing Thread.

Wondering if it could be possible using a kind of triangulation.
For example. I dont know if the timestamp includes a kind of unique way to identify the time for all the tempest system but…
A tempest system had a strike count and it is inside two “Distance circle” (minimum and max distance),
With another system near the first tempest system could be possible to calculate the average position of the strike. With three or four system the calculation could be better. collecting them and positioning on a map these datas could let the “cloud” knows where and when the strike happened and in which direction it moved.

Each system could also determined where it happened and wich is the direction based on the cardinals.

It is just a simple idea. but could be implemented?

[vreihen]

The internal timing of the station hardware is nowhere near the synchronized accuracy needed for ToF lightning detection. Plus, as I have written a gazillion times, the AS3935 lightning detector chip should be considered “for entertainment purposes only” consumer electronics grade, and not instrument-grade.

If you’ve got 3-4 years to spare, feel free to add your name to the Blitzortung waiting list to purchase one of their ToF lightning receivers…only available in kit form…soldering required…

[jhrucker]

@Newlife

With another system near the first tempest system could be possible to calculate the average position of the strike. With three or four system the calculation could be better. collecting them and positioning on a map these datas could let the “cloud” knows where and when the strike happened and in which direction it moved.

I really like this idea. I would think it is possible if they have enough stations in the area. If you only plotted strikes that were close to a station on a map you could get an idea of where the storm is. I think this will happen eventually as more and more people install the detectors.

[eric]

You have to stop dreaming that the Tempest devices will one day be able to do that. It has no GPS to get an accurate timestamp needed to calculate even the beginning of accurate distance, even with 50 stations around. It just was not made for that and misses the most basic part, a GPS receiver …

read page 11 of this document

[jhrucker]

The stations don’t need a GPS to get a location and we don’t need sub microsecond accuracy. The lat and long of the station is entered during time of install and the stations don’t move. If a station can report a lighting strike within a few miles with a reasonable amount of accuracy, that is useful information. If you have enough stations reporting these strikes to the cloud you can plot the strikes. Yes there will be stations that are not setup correctly (wrong location) but if you get enough data points you can weed them out. I agree that a standalone tempest weather station or just a few of them could not do this. But it is a whole different story when you have hundreds of stations within range of one storm.

When I think about what the tempest can do it is from the perspective of the cloud data not a single device.

[vreihen]

@jhrucker

If a station can report a lighting strike within a few miles with a reasonable amount of accuracy,

The AS3935 chip does not have this resolution. It reports distance to strikes in range bands. Plus, you are trying to force a 3D event to fit on a 2D plane.

With the limited range of the AS3935, altitude is a variable when one end of a lightning bolt may be 7+ miles in the air.

Blitzortung actually included an AS3935 on one of their older boards (System Red?) IIRC, and not seeing it on their current System Blue boards is proof enough to me that it is not useful as a scientific instrument. Maybe as an alert for soccer moms to get their kids off the pitch as a t-storm approaches, but even in that application I would only use it in combination with other alert tools and follow the (recently-debatable) 30-30 rule as a minimum…

[sunny]

if there are many strikes like in a really big storm, using a detector with a nondeterministic processing time, it is almost impossible to know if the detectors are actually reporting on the same strike.

[vreihen]

On a side note, I love the fall and winter in NY State because I can crank my Blitzortung receiver to “11” with no nearby thunderstorms. Last week, I detected strikes in Algeria (Africa), the Black Sea north of Turkey, and Albania:

I also detected strikes in eastern Spain and the southwest corner of France…