Anyway to Add Sensitivity Settings on K band?

[Tallyho]

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]

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]

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]

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.

 

[NVR2FST]

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]

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.

 

[DChiJEllis]

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]

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.

Circles are lockout areas.

 

[johnboy00]

Use Time Mute set to Immediately, and then choose your punch through setting.

 

[Tallyho]

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.

 

[johnboy00]

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

No, not when set to Immediately.

 

[barry]

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.