-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
more frequent background queries only if lightning detected within set range #156
Comments
Was thinking about the same thing. There could be different update frequencies for the "notification" alarm then the "signaling" alarm - and switch to faster background queries if anything is in the range of notification alarms. Or perhaps checking for something like number of strikes/min within 1500km and switching to faster updates on certain thresholds. |
I would favor configuring 2 update rates, one to be in effect if there have been no strikes in the last hour within the notification distance, and the other if there has been at least one. The tricky part is to ensure a relatively high update rate so that the notification of nearby lightning is not delayed. Of course, cells have to form somewhere, so long intervals are intrinsically a little risky, but it seems to me that 30m/2m intervals with a notication distance of 100km would be a reasonable thing to try out. |
@gdt: in different regions different approaches will work better or worse. From the users/meteorological pov 2-3 "watch" perimeters would be nice. Rather than relying on a single stroke threshold for a small area it might be better to watch a slightly larger perimeter with a configurable strikes threshold. There might be 2-3 perimeters Don't know what the |
Sure, that's entirely reasonable. In the northeast US, basically there are days with no lightning, and days that storms come through. But 3 ranges, 3 update rates, and 2 stroke count thresholds (for the two outer rings) sounds totally fine to me as more general. |
If lightning is detected within a set range then the background query frequency would increase. Once lightning is no longer detected within a set range queries could drop back to less frequent intervals of 60 or 90 minutes. This would allow for more timely alerts during lightning events but drop back to more battery friendly behavior when no lightning is within a set range. The 2 ranges could be based on the 'notification distance limit' and the 'signaling distance limit'.
The text was updated successfully, but these errors were encountered: