Anyway to Add Sensitivity Settings on K band?

Tallyho

Premium Plus
Lifetime Premium
Advanced User
Joined
Mar 21, 2013
Messages
3,340
Reaction score
6,646
Other manufacturers allow for sensitivity settings, particularly on K band.

Is this possible with the V1 and if not what would it take from VR to open it up for app setting development?
 

InsipidMonkey

Essential Monkey
ModSec
Premium Plus
Lifetime Premium
Corgi Lovers
Advanced User
Joined
Mar 22, 2017
Messages
8,130
Reaction score
18,912
Location
New England
Other manufacturers allow for sensitivity settings, particularly on K band.

Is this possible with the V1 and if not what would it take from VR to open it up for app setting development?
You can already kind of do it similar to the Escort implementation using K band muting logic (eg mute under 6 lights), and JBV1 could mute all K band under a specified strength. Beyond that, to actually change the sensitivity of the detector would require some re-engineering on VR's part (or at least a firmware update).

Rather than lowering sensitivity as a band-aid fix, I hope they spend their R&D time optimizing filtering so sensitivity adjustments are not needed.
 

NVR2FST

Premium Plus
Lifetime Premium
Advanced User
Joined
Aug 1, 2011
Messages
1,739
Reaction score
1,625
Location
Somewhere in cyberspace.
Other manufacturers allow for sensitivity settings, particularly on K band.

Is this possible with the V1 and if not what would it take from VR to open it up for app setting development?
You can mute K band alerts using the V1's knob (tedious), using the Valentine Research app (limited effectiveness) or using JBV1 (very effective). Sensitivity, per se, cannot be reduced AFAIK.
 

Tallyho

Premium Plus
Lifetime Premium
Advanced User
Joined
Mar 21, 2013
Messages
3,340
Reaction score
6,646
You can already kind of do it similar to the Escort implementation using K band muting logic (eg mute under 6 lights), and JBV1 could mute all K band under a specified strength. Beyond that, to actually change the sensitivity of the detector would require some re-engineering on VR's part (or at least a firmware update).

Rather than lowering sensitivity as a band-aid fix, I hope they spend their R&D time optimizing filtering so sensitivity adjustments are not needed.

Thanks for the suggestions. This could work if I can tie it to a profile, which is itself tied to a GPS based setting.

For example, if every time I drive by a fixed location K band false, it activated the profile with mute under 6 lights, and turned that profile off after 200 feet, that would work. Essentially I want to Auto-toggle between profiles but do so in a very compressed geographic area.

I'd also like to think that both are possible solutions and that the more ideal fix doesn't take away from a less than ideal fix in the meantime, aka, "don't let the perfect be the enemy of the good".

@InsipidMonkey Do you know what exactly would require changing to adjust sensitivity?

If I were to make such a request to VR, I'd like to know the technical term for the feature that they would need to tweak or implement.
 
Last edited:

NVR2FST

Premium Plus
Lifetime Premium
Advanced User
Joined
Aug 1, 2011
Messages
1,739
Reaction score
1,625
Location
Somewhere in cyberspace.
Thanks for the suggestions. This could work if I can tie it to a profile, which is itself tied to a GPS based setting.

For example, if every time I drive by a fixed location K band false, it activated the profile with mute under 6 lights, and turned that profile off after 200 feet, that would work. Essentially I want to Auto-toggle between profiles but do so in a very compressed geographic area.

I'd also like to think that both are possible solutions and that the more ideal fix doesn't take away from a less than ideal fix in the meantime, aka, "don't let the perfect be the enemy of the good".
JBV1 and V1 Driver apps offer auto-muting options.
 

Tallyho

Premium Plus
Lifetime Premium
Advanced User
Joined
Mar 21, 2013
Messages
3,340
Reaction score
6,646
JBV1 and V1 Driver apps offer auto-muting options.

Yes but isn't this based on signal frequency? I don't trust signal frequency based lock outs as they overlap with legitimate signals. I'm starting to think I'd rather bypass frequency and use something like signal strength instead but it doesn't seem like there is a solution for that within the API environment.

Alternatively, another idea is that tying two pieces of information together instead of just one, those being a sensitivity setting with a geographically based setting, circumvents and resolves this frequency issue.
 
Last edited:

DChiJEllis

Moderator Emeritus and Lifetime RDF Contributor
ModSec
Premium Plus
Lifetime Premium
Corgi Lovers
Advanced User
Joined
Jul 31, 2016
Messages
2,535
Reaction score
3,929
Location
Trollstigen, Lysevegen og Atlanterhavsveien
Anything that let's people natively miss an alert, Mike V will probably say no to. He's already very against GPS integration as being a way for people to miss an alert. So I doubt he's going to give people theability to squelch signals within the device. Offboard muting via an app is probably as much as you're going to get.
 

NVR2FST

Premium Plus
Lifetime Premium
Advanced User
Joined
Aug 1, 2011
Messages
1,739
Reaction score
1,625
Location
Somewhere in cyberspace.
Yes but isn't this based on signal frequency? I don't trust signal frequency based lock outs as they overlap with legitimate signals. I'm starting to think I'd rather bypass frequency and use something like signal strength instead but it doesn't seem like there is a solution for that within the API environment.

Alternatively, another idea is that tying two pieces of information together instead of just one, those being a sensitivity setting with a geographically based setting, circumvents and resolves this frequency issue.
JBV1 uses frequency, direction, and maybe other factors to auto-lockout alerts.
cbb44fc4d1b2d7ddfca54c222b89cda1.jpg

Circles are lockout areas.
 
Last edited:

Tallyho

Premium Plus
Lifetime Premium
Advanced User
Joined
Mar 21, 2013
Messages
3,340
Reaction score
6,646
Use Time Mute set to Immediately, and then choose your punch through setting.

But isn't this feature tied to Native K band muting which is manual? Trying to understand how to automate the entire muting process.
 

barry

PSL +5
Intermediate User
Joined
Mar 4, 2012
Messages
467
Reaction score
590
Location
Alabama
Yes but isn't this based on signal frequency? I don't trust signal frequency based lock outs as they overlap with legitimate signals. I'm starting to think I'd rather bypass frequency and use something like signal strength instead but it doesn't seem like there is a solution for that within the API environment.

Alternatively, another idea is that tying two pieces of information together instead of just one, those being a sensitivity setting with a geographically based setting, circumvents and resolves this frequency issue.

Wouldn't "Statistical Analysis" or "Deep Analysis" (under Lockouts>Advanced Settings) help here? If I interpret these options correctly, Statistical Analysis and Deep Analysis bring signal strength into the decision whether to alert or not for an auto-locked out signal. Of course, the auto lock-out was already based upon gps location and signal frequency. While not exactly what you were asking about, this does bring two pieces of information together (actually, I guess it's three) when deciding to alert or not.
 

Discord Server

Latest threads

Latest posts

Forum statistics

Threads
93,036
Messages
1,418,447
Members
23,671
Latest member
Ronin
Top