I've wanted to do this for a long time but wanted a very stable base to work with first.
Little background:
Escort, as I understand, uses fixed "Segments" and tags a lockout to be in a specific Segment. I never liked this because it could land right on the boundary of two segments. In the long run that doesn't hurt (much) but you'd probably end up with two lockouts as its frequency wiggles.
In V1Driver they are not fixed segments. Each Lockout is centered in the Tolerance you set.
V1Driver, uses a slightly finer tolerance than Escort does (by Default), but you can't directly compare it; partly because of the Fixed Segments you might lockout 2 segments unnecessarily even on a stable False, which won't happen in V1Driver. It has Dynamic Segments (sort of).
When reading comments on YaV1 and my own experience with it I found YaV1 (default) tolerance a bit tight. I think this made some users impatient and they would start using Manual Lockouts (as I did and I hate manual lockouts). So by default V1Driver users a default tolerance wider than the default Tolerance that YaV1 uses. Of Course both apps can be changed. But most users don't change it.
I chose a default value that was a compromise of being reasonably "safe" and lock things out at a reasonable rate. I figured anything finer than Escort would be reasonably safe.
Any way, now onto the new stuff:
What if you didn't have to choose a rigid tolerance for all locations at all or worry about it?
Not all falses are alike, some are very stable, some gradually drift, some wiggle a lot.
Even as things stand with V1Driver or YaV1, you can set the tolerance very tight and just wait it out and eventually it will lock out everything. But you could get falses for quite some time, which defeats the purpose of GPS Lockouts. Because you may tune K band out (in some stuburn locations) by the time it's fully learned.
Welcome to “Statistical Tolerancing” per lockout !!
What V1Driver will now allow you to do is collect statistical errors on each GPS Lockout PIN. It will use standard statistics (that you can adjust) to determine if a new candidate hit is a statistical “Outlier” for that specific lockout rather than use a fixed tolerance for all lockouts. If a particular GPS Lockout wiggles a lot, it’s tolerance will be calculated high. If a GPS Lockout it stable the tolerance will be calculated tight.
Once enough statistics are gathered you can view the Tolerance that will be used by clicking the info on a GPS Lockout Pin.
You can set how statistically tight you want things in "Standard Deviations". The Default is 3 Standard Deviations.
You can also choose how many samples are needed to start applying the Standard Deviation Logic. The Default is 14 Samples (that means a minimum of 14 days (using other defaults)).
The gist of this new scheme is, it learns fairly quickly (safer than Escort and basically no change in current behavior), but now, over time, as it collects statistics, it will tighten things up a LOT and minimize the lockout range. It SHOULD remain just as quiet but run with MUCH narrower ranges where it can.
You can turn this all off by setting the number of Samples to Collect to 0 !!
Another bonus to this method is if a GPS Lockout gradually drifts, the model will gradually move with it. It does that now by creating a new PIN when it goes out of tolerance and the old PIN will get demoted. But now it will gradually move with it. It’s only when suddenly something is statistically an outlier (e.g. a LEO is within the former fixed tolerance) and it will now cease muting it (and start a new GPS Lockout if it remains consistent).
In practice, I'll be honest, I don't know how well this will work (and why it's in Beta only and may be a long Beta Cycle). I think it should work well. The hardest part here is verifying it's behaving correctly. I may add more hooks to help with that.
Little background:
Escort, as I understand, uses fixed "Segments" and tags a lockout to be in a specific Segment. I never liked this because it could land right on the boundary of two segments. In the long run that doesn't hurt (much) but you'd probably end up with two lockouts as its frequency wiggles.
In V1Driver they are not fixed segments. Each Lockout is centered in the Tolerance you set.
V1Driver, uses a slightly finer tolerance than Escort does (by Default), but you can't directly compare it; partly because of the Fixed Segments you might lockout 2 segments unnecessarily even on a stable False, which won't happen in V1Driver. It has Dynamic Segments (sort of).
When reading comments on YaV1 and my own experience with it I found YaV1 (default) tolerance a bit tight. I think this made some users impatient and they would start using Manual Lockouts (as I did and I hate manual lockouts). So by default V1Driver users a default tolerance wider than the default Tolerance that YaV1 uses. Of Course both apps can be changed. But most users don't change it.
I chose a default value that was a compromise of being reasonably "safe" and lock things out at a reasonable rate. I figured anything finer than Escort would be reasonably safe.
Any way, now onto the new stuff:
What if you didn't have to choose a rigid tolerance for all locations at all or worry about it?
Not all falses are alike, some are very stable, some gradually drift, some wiggle a lot.
Even as things stand with V1Driver or YaV1, you can set the tolerance very tight and just wait it out and eventually it will lock out everything. But you could get falses for quite some time, which defeats the purpose of GPS Lockouts. Because you may tune K band out (in some stuburn locations) by the time it's fully learned.
Welcome to “Statistical Tolerancing” per lockout !!
What V1Driver will now allow you to do is collect statistical errors on each GPS Lockout PIN. It will use standard statistics (that you can adjust) to determine if a new candidate hit is a statistical “Outlier” for that specific lockout rather than use a fixed tolerance for all lockouts. If a particular GPS Lockout wiggles a lot, it’s tolerance will be calculated high. If a GPS Lockout it stable the tolerance will be calculated tight.
Once enough statistics are gathered you can view the Tolerance that will be used by clicking the info on a GPS Lockout Pin.
You can set how statistically tight you want things in "Standard Deviations". The Default is 3 Standard Deviations.
You can also choose how many samples are needed to start applying the Standard Deviation Logic. The Default is 14 Samples (that means a minimum of 14 days (using other defaults)).
The gist of this new scheme is, it learns fairly quickly (safer than Escort and basically no change in current behavior), but now, over time, as it collects statistics, it will tighten things up a LOT and minimize the lockout range. It SHOULD remain just as quiet but run with MUCH narrower ranges where it can.
You can turn this all off by setting the number of Samples to Collect to 0 !!
Another bonus to this method is if a GPS Lockout gradually drifts, the model will gradually move with it. It does that now by creating a new PIN when it goes out of tolerance and the old PIN will get demoted. But now it will gradually move with it. It’s only when suddenly something is statistically an outlier (e.g. a LEO is within the former fixed tolerance) and it will now cease muting it (and start a new GPS Lockout if it remains consistent).
In practice, I'll be honest, I don't know how well this will work (and why it's in Beta only and may be a long Beta Cycle). I think it should work well. The hardest part here is verifying it's behaving correctly. I may add more hooks to help with that.
Last edited:
