Lightning reports (tempest)

I get warnings from both Air units and both Tempest devices.

I’m usually sitting on my spot when lightning strikes. Sometimes I have to remind the family, Your on my spot.

2 Likes

Guess we’ll see when my production Tempest someday arrives.
Thanks for the explanation !

1 Like

Technically of course yes, but everybody (almost) based their solutions around the concept of local UDP data having enough to calculate everything derived, so (theoretically) we could run without any connectivity off our LAN once the tunings from CL were stable for our sensors.

2 Likes

The thought has crossed my mind a few times to use the web copy as a pseudo Davis archive logger for back-filling missing records. The only WeeWX station driver that implements this is the Davis one, which not-so-coincidentally was the inspiration for WeeWX and its LOOP versus ARCHIVE packets.

The whole point of WeeWX is to capture, display, archive, and report on the station’s output locally. There is even a whole lecture in the developer’s guide about only reporting items that the hardware emits. If it isn’t supported by the hardware, WeeWX itself will try to derive the missing values based on what it has at a level above the driver in the software stack.

The sample sensor-map distributed with the driver pulls all wind from rapid_wind packets, and calculates the summaries from that and not obs_sky (or obs_st). All of the other fields like temp/hum/pressure/solar come from obs_air/obs_sky (or obs_st). This works well for everything but rain and lightning, as @vinceskahan has pointed out.

As I had written in the WeeWX thread last weekend, they added official support for storing lightning data from AS3935-type devices as of a few months ago. A few users lucky to be near t-storms tested sample sensor_map entries to capture the evt_strike UDP data, and the counts were so far off (low) in many cases where people were even questioning whether evt_strike packets were being sent by UDP. Long story short, I was going to provide updated sample sensor_map setups that captured evt_strike and push it out as the next point release. I now feel obligated to also include a multi-paragraph explanation about why the UDP lightning data will probably never match the Tempest app’s data (to save having to answer this “bug report” every day), my usual lecture about the AS3935 being intended for consumer electronics and not scientific instruments, and of course a legal disclaimer that lightning data is provided for entertainment purposes only,and not to be used as a sole source of information for life-or-death decisions…

5 Likes

I’m going to mark David’s explanation as ‘solution’ but leave this one open for futher commentary.

2 Likes

Gotcha - that definitely keeps it simple.

Good idea! Feel free to point out how we (WeatherFlow) see the Tempest hardware as just one piece in a much larger system of weather data, a concept that may be unfamiliar to owners of other personal weather station hardware. It’s really a hybrid software-hardware platform (though marketing does not love that mouthful, so they are not using it!).

A good point as well - the AS3935 is great for it’s size and cost, but it’s definitely not a professional lightning sensor. The weaknesses of it are part of what drove our development of the “enhanced lightning” system described above.

Speaking of the “consumer vs. professional” distinction reminds me to mention that we do intend to develop and support a line of more commercial-grade (“professional” if not “scientific”) weather sensor hardware, including a better stand-alone lightning sensor. That’s still a ways off, but it’s on our roadmap. For now, we’re staying focused on the consumer market.

3 Likes

400+ strikes yesterday as a cluster of strong thunderstorms moved through our area. I have every reason to believe the number was real and not an embellishment. Since my Tempest now appears to be fully calibrated, I’m convinced this is a nice upgrade from the Sky/Air combo.

I haven’t gotten a good handle on rainfall accuracy, but I’m sure that will remain the weak point.

At any rate, color me impressed overall. :slight_smile:

2 Likes

Hello – I’ve read through all of this thread last night and again this morning. I’m still a bit confused. Lots of lightning strikes last night and I did not pick up a single strike via “obs_st” – the fields stay at “0”. Also “evt_strike” never fires off. This is for my new Tempest I got a few days ago. Just trying to understand how I capture that data. Someone in this thread pointed out that all the UDP data we got via Air and Sky we still get with Tempest. My question is how do we capture it (lightning) via UDP? Or can we? Thanks – JP

Hi JP. Any lightning the as3935 sensor in your Tempest detects will be seen in the UDP broadcast. But you will, in general, see more & better lightning information via WS & REST thanks to the “Tempest is more than hardware” concept described above. You can expect the hardware to improve over time because of the same concept (as we collect more data we can tune your lightning sensor). If you continue to see minimal-to-no lightning when you think you should be seeing it, you either have a siting issue (more likely) or a hardware issue (less likely). Feel free to open a support ticket and someone from our kick-ass customer service team will help you figure out what the issue is and how to address it.

1 Like

Thank you for taking the time to reply. I was seeing plenty of lightning via REST last night so I do not think it is a hardware or sighting issue.

Back to UDP – how do I see the lightning data? If it’s “obs_st” it did not register as the lightning fields were “0” – all other data came in. If the reporting period is 1 minute I presume it will have to have a strike at the reporting time to register via “obs_st” (not sure about that - just guessing). If it’s via “evt_strike” that never transmitted last night for the Tempest (works for the old Air and Sky).

Is there another string to catch via UDP for lightning?

Thanks
JP

Does this also apply to the Air or am I reading this incorrectly?

I think the point you’re missing is that Lightning is a ‘manufactured’ observation available only on the WF servers…it will ‘never’ be in the UDP broadcasts with a value matching what WF does on their servers to construct a calculated set of values.

Your personal gear reports what it sees, right or wrong, but that is a ‘tiny’ part of what WF uses to construct what you see in their mobile app and the other API interfaces that use the strike data they aggregate and tweak on their end only.

Thank you for your reply. I think I understand that. Where I’m lost is where do you see lightning via UDP in any form (value) for tempest?

Look at obs_st in the UDP API reference elements 14+15
(https://weatherflow.github.io/SmartWeather/api/udp/v119/)

The evt_strike is at the top of the same file.

You were looking in the right place: obs_st & evt_strike

OK – thanks. Does “obs_st” fire on an event or like once a minute. If it’s once a minute or so, does the strike need to occur then or are the strikes stored and then reported when “obs_st” broadcasts? The reason I ask is the values were “0” all night. I had nearly 800 strikes last night (I have a Boltek 250).

Regarding “evt_strike” that did not broadcast at all.

Thanks again
JP

obs_st is the one-minute observation message and will contain the strike count (and average distance) for that reporting interval.

evt_strike is an event-driven message: one per strike.

If you’re seeing 0’s for strike count in obs_st that also explains why you’re not seeing any evt_strike messages (and vice-versa).

1 Like

I’d say the Tempest is a lot better. I just watched a lightning strike and all four devices reported it. The top two are from a Tempest and the bottom two from an Air.

Hmmm – but I was getting lightning last night via the phone app as well as my app connecting via REST. But not UDP … Maybe I do need to drop in a trouble ticket?? Does that make sense?

sigh - I have to reiterate that yes it makes sense. You will not see the same thing via UDP as you will see via the API that query WF’s servers. That’s not to say you won’t detect ‘some’ strikes, but you won’t catch them all. This and other threads on the topic indicate that sometimes the disparity is massive.

(if there are any Tempest users in the every-day-it-seems storms hammering the Philly area, it would be fascinating to see how your UDP data is vs. the crowd-sourced corrected info WF’s app reports)