Skip to content
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

Open
jamorris opened this issue Jul 7, 2017 · 4 comments

Comments

@jamorris
Copy link

jamorris commented Jul 7, 2017

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'.

@xandro0777
Copy link

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.

@gdt
Copy link

gdt commented May 16, 2019

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.

@xandro0777
Copy link

@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

@gdt
Copy link

gdt commented May 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants