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).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.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.
JBV1 and V1 Driver apps offer auto-muting options.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.
JBV1 uses frequency, direction, and maybe other factors to auto-lockout alerts.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.
Use Time Mute set to Immediately, and then choose your punch through setting.
No, not when set to Immediately.But isn't this feature tied to Native K band muting which is manual? Trying to understand how to automate the entire muting process.
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.