Musings on BSM filtering

OBeerWANKenobi

This is not the car you're looking for.....
Advanced User
Lifetime Premium Member
Joined
Mar 20, 2018
Messages
3,731
Reaction score
9,551
Location
Right Behind You! (Wisconsin)
I've been thinking about BSM filtering lately and how it and traffic sensor rejection are a double edged sword. Without enough filtering, our detectors become annoying and we either silence them or ignore them on K band but like the boy who cried wolf, when the real wolf hits us with K band, we could be desensitized too much to react quickly enough. With too much filtering we see can see a delay in the alerts which could cause us to miss I/O or Q/T easily and which also reduces the range of our detectors.

So it seems that the discussion is always framed around how to filter offenders out or how to lock them out. Now, there's no doubt that filtering has to be done to get the desired results; however, due to the problems caused by filtering, you can't be too aggressive. Conversely, when the filtering isn't aggressive enough, we wind up with desensitization and annoyance. We also have to be careful that we don't segment out real police radar.

What if we were to reframe the discussion to "locking in" the correct frequencies as well as using filtering? Say that a user can verify a real police frequency by entering it because it's in use in his area or through a double tap of a button when actually being hit by it? Along the same line, we can also quickly check for police radar gun frequencies that aren't close to a "problem bsm" list and alert to those almost immediately.

The easiest way for me to explain this is a bit of pseudo code.

Code:
mhz = detected frequency

sgst = signal strength

pmhz = common police radar frequency list (24.125,24.150)

bmhz = problem bsm list (BSM's that are on likely police radar frequencies like some GM, etc)

umhz = list of user verified police frequencies these would be user "locked in" as opposed to locked out.

if (mhz is within +/- 5 of umhz AND mhz is not within +/- 5 of bmhz) OR (mhz is within +/- 5 of pmhz AND mhz is not within +/- 5 of bmhz) OR ( sgst is greater than percentage) then
    Alert immediately
else
    Run filtering routine
end if
So, I guess I'm proposing to attack the problem from both ends. What should be filtered out and what should be alerted to immediately.

I've had a few other ideas along the same sort of concept like an 80/20 rule or something where we'd say that 80% of the police radar is within 20% of so and so part of K band. Apply less filtering to this area.


Anyway, as I said, just some musings but if they haven't thought of it already, it might help some manufacturers to think outside the box. They could more heavily filter non problem areas and more lightly filter likely radar this way.

I'd be interested to hear what kind of comments or ideas others may have as well.
 

Tallyho

Premium RDF Member
Advanced User
Premium Member
Joined
Mar 21, 2013
Messages
2,946
Reaction score
5,242
This is a difficult nut to crack and Jon basically said it comes down to processing power and technical algorithm writing skills.

To my knowledge, everything within K band frequency is a problem area so how does this address that conundrum?
 

LazerBoi64

Learning to Drive
General User
Joined
Oct 9, 2017
Messages
35
Reaction score
26
But...what about valid signals from PD guns that are off-frequency, either through misalignment or temperature shifting. And conversely (which could probably be more likely) non-valid signals from door openers, etc. that are not at all calibrated and off frequency and have drifted into the important frequency ranges? The newer RDs have the edge for sure with all of their DSP horsepower, but it's still a fast moving target with new radar models coming out and more complex modulation schemes. My thoughts.
 

OBeerWANKenobi

This is not the car you're looking for.....
Advanced User
Lifetime Premium Member
Joined
Mar 20, 2018
Messages
3,731
Reaction score
9,551
Location
Right Behind You! (Wisconsin)
This is a difficult nut to crack and Jon basically said it comes down to processing power and technical algorithm writing skills.

To my knowledge, everything within K band frequency is a problem area so how does this address that conundrum?
We still filter and the more processor HP we have, the faster it can be done. I guess I'm thinking more on the algo side here. What's a new way to look at the problem algorythmically. Writing pseudo code or a flow chart is much easier than writing the actual algo but it could start as a basis. The cool part about thinking about it this way is that you don't need to know any code at all, just logic.

But...what about valid signals from PD guns that are off-frequency, either through misalignment or temperature shifting. And conversely (which could probably be more likely) non-valid signals from door openers, etc. that are not at all calibrated and off frequency and have drifted into the important frequency ranges? The newer RDs have the edge for sure with all of their DSP horsepower, but it's still a fast moving target with new radar models coming out and more complex modulation schemes. My thoughts.
That's why I'm talking of locking in known police frequencies on the user level as opposed to locking out falses. Did you read what I wrote? I even put in a +/- 5 variation on locked in frequencies for fluctuation. The modulation would still need to be taken care of with filtering of course but any data, like modulation, could be used by the algorithm to alert sooner or later.
 
Last edited:

cihkal

Pure Energy
Advanced User
Premium Member
Joined
Apr 21, 2014
Messages
3,416
Reaction score
6,002
This is a difficult nut to crack and Jon basically said it comes down to processing power and technical algorithm writing skills.

To my knowledge, everything within K band frequency is a problem area so how does this address that conundrum?
Interesting thing about the Pro M, speaking of Jon, is it has a 8bit 24MHz processor from what I saw. The R has a 16bit 400MHz DSP and two 32bit 50MHz processors... a lot more brain power.

Oddly enough the M doesn't give a sense of being bogged down like the R does in high BSM noise conditions, or when digging up difficult to detect MRCT scenarios.

The added custom circuitry in the M, we'll call it a hardware solution rather than firmware (digital) one, seems to work better at this point.

Sent from my Pixel using Tapatalk
 

OBeerWANKenobi

This is not the car you're looking for.....
Advanced User
Lifetime Premium Member
Joined
Mar 20, 2018
Messages
3,731
Reaction score
9,551
Location
Right Behind You! (Wisconsin)
Interesting thing about the Pro M, speaking of Jon, is it has a 8bit 24MHz processor from what I saw. The R has a 16bit 400MHz DSP and two 32bit 50MHz processors... a lot more brain power.

Oddly enough the M doesn't give a sense of being bogged down like the R does in high BSM noise conditions, or when digging up difficult to detect MRCT scenarios.

The added custom circuitry in the M, we'll call it a hardware solution rather than firmware (digital) one, seems to work better at this point.

Sent from my Pixel using Tapatalk
This is a great point and makes me think that better algos could account for much of the difference.

But what gives you the sense of being bogged down? The heartbeat? Does the ProM have something similar to the R series heartbeat to know if it's filtering?
 

SquirrelMaster

Has a subscription with CHP
SysOp
Advanced User
Lifetime Premium Member
Joined
Dec 3, 2015
Messages
2,699
Reaction score
5,123
Location
Liberal California
So in an idea situation, you segment only K band signals that are known to be in that area. Like the uniden scanner GPS option that automagically changes frequencies (or in this case, bands).
Then if you get hit by a drifting K band gun, you just use that in your defense. "Hey gun wasn't properly calibrated".....

But in all seriousness, I think that maybe a way to better filter BSMs would require gps data to be used in the algorithm, not just for red light cameras and low speed muting...... Thinking something along the lines of when a K band alert comes in, detect how quickly it increases in power based on your speed. A signal getting significantly stronger, at a quicker rate than some predefined (or learned) normal could mean a lower power BSM unit that you are approaching. A K signal that is increasing as you get closer but not as rapidly while you are at the same speed as the previous BSM alert could mean a more powerful signal such as an actual K band gun.

Just a simple thought to an extremely more complex issue.
 

LazerBoi64

Learning to Drive
General User
Joined
Oct 9, 2017
Messages
35
Reaction score
26
We still filter and the more processor HP we have, the faster it can be done. I guess I'm thinking more on the algo side here. What's a new way to look at the problem algorythmically. Writing pseudo code or a flow chart is much easier than writing the actual algo but it could start as a basis.


That's why I'm talking of locking in known police frequencies on the user level as opposed to locking out falses. Did you read what I wrote? I even put in a +/- 5 variation on locked in frequencies for fluctuation. The modulation schemes would still need to be taken care of with filtering of course.
Yes I did read it. But it unless you're privvy to what tolerance is used by each radar's self-test routine it's kind of a shot in the dark. I wholeheartedly agree it's a non-trivial matter and the random environmental factor just increases the uncertainty and begs the question of whether or not the uncertainty increases so much that frequency ranges overlap.
 

OBeerWANKenobi

This is not the car you're looking for.....
Advanced User
Lifetime Premium Member
Joined
Mar 20, 2018
Messages
3,731
Reaction score
9,551
Location
Right Behind You! (Wisconsin)
Yes I did read it. But it unless you're privvy to what tolerance is used by each radar's self-test routine it's kind of a shot in the dark. I wholeheartedly agree it's a non-trivial matter and the random environmental factor just increases the uncertainty and begs the question of whether or not the uncertainty increases so much that frequency ranges overlap.
Agreed, so what I'm proposing is to treat those signals that fall outside of whatever predefined tolerance is ultimately decided upon the same way they are being treated now. They basically have to meet the normal filtering criteria. What's different about what I wrote above is that if it falls within our predefined tolerance of a "locked in" signal, it alerts immediately without extended filtering. This would allow filtering to be a little more aggressive in the first and less likely scenario but more wide open in the second.

The real police radar may again drift out of the locked in signal but it could be locked in again at some point in the future, meanwhile, it's treated like any other signal.
 

Tallyho

Premium RDF Member
Advanced User
Premium Member
Joined
Mar 21, 2013
Messages
2,946
Reaction score
5,242
Agreed, so what I'm proposing is to treat those signals that fall outside of whatever predefined tolerance is ultimately decided upon the same way they are being treated now. They basically have to meet the normal filtering criteria. What's different about what I wrote above is that if it falls within our predefined tolerance of a "locked in" signal, it alerts immediately without extended filtering. This would allow filtering to be a little more aggressive in the first and less likely scenario but more wide open in the second.

The real police radar may again drift out of the locked in signal but it could be locked in again at some point in the future, meanwhile, it's treated like any other signal.
I think I'm understanding your approach better. So you're suggesting that by "filtering in" a known signal it bypasses filtering altogether?

Could this use a GPS to provide an additional data point?
 

hiddencam

Premium RDF Member
Advanced User
Premium Member
Joined
Oct 29, 2010
Messages
11,529
Reaction score
24,913
Love the "Lock in" idea. I'd be tempted to use such a feature for every legit K band source I see so there's no chance of ever locking it out. The YaV1 white list was one of the awesome things about that app, but that was linked to the specific area you logged it. It might make sense to Lock In for a bigger region, perhaps programmable regions across the US. I dig your general 80/20 idea, and will pass this along to Uniden if/when they make contact with us. The upcoming Netradar FW (Monday 11th) will have segment 5 as 24.095-24.205 which is a large number of BSMs, so that'll be cool to use. I've never seen a legit K band threat in that range. I will be turning that segment off. Would be nice to have the option to merely heavily filter that segment rather than completely ignore it though.
 

OBeerWANKenobi

This is not the car you're looking for.....
Advanced User
Lifetime Premium Member
Joined
Mar 20, 2018
Messages
3,731
Reaction score
9,551
Location
Right Behind You! (Wisconsin)
I think I'm understanding your approach better. So you're suggesting that by "filtering in" a known signal it bypasses filtering altogether?

Could this use a GPS to provide an additional data point?
Yes, basically that's what I'm saying. It also could give an opportunity to increase filtering on the other likely offending signals while adding negligible risk for doing so. Delaying the alert on a signal is much less risky than completely locking it out which has been the other proposed solution until now.

I suppose it could use GPS, though I haven't thought about how that might be of benefit.
 

Discord Server

Latest threads

Forum statistics

Threads
77,521
Messages
1,181,200
Members
19,830
Latest member
NoAl
Top