On lockouts, automation, storage, and processing required (1 Viewer)

Deacon

TXCTG
Advanced User
Premium Member
Joined
Nov 13, 2016
Messages
8,727
Reaction score
10,539
Awards
0
Location
Hill Country, TX
Rating - 100%
2   0   0
In a couple of other threads today lockouts have been discussed, even if a little off-topic for those threads. It was mostly spawned by the upcoming R7 release and its promise of automatic lockouts, the current understanding that the R3 will probably never get automatic lockout functionality, and how the V1 apps use that dramatically greater processing power and storage capacity of smartphones to handle it. There were questions about how many lockouts do you actually need, what would it take to make automatic lockouts happen, and so on. I wrote a couple of responses and thought I’d consolidate them into one place for reference and for further discussion.


"Only" 2 thousand lockouts? How many do you need jeez lol
If they do it like others, then for automatic lockouts they keep track of every single K-band alert and location. It only becomes a lockout if you encounter the same signal (plus or minus some number of megahertz) in the same place repeatedly over time. So while you may only have a few dozen actual lockouts, they’d need the storage space to keep track of many more signal frequencies and locations. If a BSM alerts, it needs to log it. If a door opener alerts, it needs to log it. If a LEO is throwing K, it needs to log it. Only some of those will actually make it into an actual lockout, but it needs lots of slots to keep track of all the potential lockouts since it can’t/won’t know the difference until it you drive by the location again and it either sees the same signal again or else doesn’t see the signal and thus removes it from the list (to varying degrees of nuance and intelligence depending on the implementation).

So, no, most people don’t literally need 2,000 actual lockouts, but it’s very possible the detector needs a very large number of slots to fill with potential lockouts to keep track of.

I actually run an R3 primarily in my A5, but in my truck and in my fiancée’s car I have V1s hardwired in, so V1Driver is very part-time. Even so, on my phone, V1Driver has 2132 K band records, 816 new records, 181 records that are “learning”, 537 that have been “demoted” over time, all for 190 actual active learned lockouts.

When the R3 was released, it was only allowed 200 lockouts, but they were all manual only. And keep in mind that they only cover a fixed radius, so sometimes if it’s a strong signal source it can take multiple lockouts to cover a single stationary false. V1Driver has 190 actual confirmed lockouts that it’s learned (signals I’ve passed in the same location in the same frequency range on at least 3 different days), and you can see it’s got way more than that it’s actually keeping track of. Later in a firmware update the R3’s number of manual lockouts was increased to 500. For manual lockouts, that’s way more than some people need, but for other people who cover more ground in areas dense with stationary falses even 500 isn’t enough.

Since the R7 will have automatic lockouts in a few months, even 2,000 may be limiting for some people.


Even a huge text file with GPS coordinates, frequency, and maybe the date wouldnt be a large file size. A gigantic text doc could easily be just a few MB's.
You’d essentially need a primitive database, maybe even just a CSV file? I’m not sure how much actual storage the R3 has and how it’s chopped up (one storage chip hard split between firmware and user marks/lockouts or two discrete storage chips or what). But beyond sheer size, you also need the processing power to process adding, incrementing, and removing entries, and also then processing each and every K-band alert through the lockout database before alerting the user. The R3 is probably capable of doing all of that, permitting sufficient time to process it all, but even small delays introduced by the extra data processing routines can “feel” long and reduce the effective range of the detector, at least on K-band.
 

SalmonSurprise

Premium Member
Intermediate User
Premium Member
Joined
Aug 20, 2018
Messages
200
Reaction score
239
Awards
0
Rating - 0%
0   0   0
In a couple of other threads today lockouts have been discussed, even if a little off-topic for those threads. It was mostly spawned by the upcoming R7 release and its promise of automatic lockouts, the current understanding that the R3 will probably never get automatic lockout functionality, and how the V1 apps use that dramatically greater processing power and storage capacity of smartphones to handle it. There were questions about how many lockouts do you actually need, what would it take to make automatic lockouts happen, and so on. I wrote a couple of responses and thought I’d consolidate them into one place for reference and for further discussion.



If they do it like others, then for automatic lockouts they keep track of every single K-band alert and location. It only becomes a lockout if you encounter the same signal (plus or minus some number of megahertz) in the same place repeatedly over time. So while you may only have a few dozen actual lockouts, they’d need the storage space to keep track of many more signal frequencies and locations. If a BSM alerts, it needs to log it. If a door opener alerts, it needs to log it. If a LEO is throwing K, it needs to log it. Only some of those will actually make it into an actual lockout, but it needs lots of slots to keep track of all the potential lockouts since it can’t/won’t know the difference until it you drive by the location again and it either sees the same signal again or else doesn’t see the signal and thus removes it from the list (to varying degrees of nuance and intelligence depending on the implementation).

So, no, most people don’t literally need 2,000 actual lockouts, but it’s very possible the detector needs a very large number of slots to fill with potential lockouts to keep track of.

I actually run an R3 primarily in my A5, but in my truck and in my fiancée’s car I have V1s hardwired in, so V1Driver is very part-time. Even so, on my phone, V1Driver has 2132 K band records, 816 new records, 181 records that are “learning”, 537 that have been “demoted” over time, all for 190 actual active learned lockouts.

When the R3 was released, it was only allowed 200 lockouts, but they were all manual only. And keep in mind that they only cover a fixed radius, so sometimes if it’s a strong signal source it can take multiple lockouts to cover a single stationary false. V1Driver has 190 actual confirmed lockouts that it’s learned (signals I’ve passed in the same location in the same frequency range on at least 3 different days), and you can see it’s got way more than that it’s actually keeping track of. Later in a firmware update the R3’s number of manual lockouts was increased to 500. For manual lockouts, that’s way more than some people need, but for other people who cover more ground in areas dense with stationary falses even 500 isn’t enough.

Since the R7 will have automatic lockouts in a few months, even 2,000 may be limiting for some people.



You’d essentially need a primitive database, maybe even just a CSV file? I’m not sure how much actual storage the R3 has and how it’s chopped up (one storage chip hard split between firmware and user marks/lockouts or two discrete storage chips or what). But beyond sheer size, you also need the processing power to process adding, incrementing, and removing entries, and also then processing each and every K-band alert through the lockout database before alerting the user. The R3 is probably capable of doing all of that, permitting sufficient time to process it all, but even small delays introduced by the extra data processing routines can “feel” long and reduce the effective range of the detector, at least on K-band.
I agree with most of what you are saying. The only thing I would point out is the processesing that you speak of when manipulating the GPS database is not something that needs real-time priority, like say querying the very short list of confirmed GPS lockouts. I think there are many ways you could handle this in software that would prevent the GPS lockout feature from introducing delays in detection.
 

Transporter

ModWight Transporter
Intermediate User
Premium Member
Joined
Jul 3, 2018
Messages
1,892
Reaction score
2,334
Awards
0
Location
In front of you but behind a Rabbit
Rating - 100%
1   0   0
Total number of Lockouts needed is going to be different for many different Drivers, but one group of Drivers needs many more than the causal RD user. That group are the Drivers that drive loads of miles plus interacts with multiple decent size cities. I have thousands of Lockouts due to Atlanta, Macon, Chattanooga, Savannah, Charlotte, Greenville, Columbia, and the surrounding metro areas of those cities plus many more. Add the local radar speed limit signs, school zones, gas stations, strip malls, CVSs, etc near home and the total number needed climbs quickly.

Now that means for some that a limit on the total number could be an issue. But the real question that hasn't been answered yet is, "How does/will the R7 handle actual Lockouts"? Will it be frequency accurate enough, GPS location accurate enough, plus signal strength knowledgeable enough to auto store lockouts that will not accidentally cover up a future actual K Band police radar encounter? Escort has failed this with poor lockout logic.

Since the Lockouts are based on GPS already, there is no need to query a huge list in a data base, only the closest recorded Lockouts (say 10 or 20) from the database need to be scanned for Quiet Ride usage based on current GPS location. Processing power should concentrate on frequency accuracy, signal strength, and source location plus reviewing a short "list" of prior logged signals to compare if the current signal has been recorded enough times to justify now being made an Auto Lockout.

I am a big fan of how @johnboy00 is handling manual and auto lockouts in JBV1.
.
 

DrHow

Premium Member
Intermediate User
Premium Member
Joined
May 18, 2018
Messages
1,686
Reaction score
2,262
Awards
0
Rating - 100%
1   0   0
In a couple of other threads today lockouts have been discussed, even if a little off-topic for those threads. It was mostly spawned by the upcoming R7 release and its promise of automatic lockouts, the current understanding that the R3 will probably never get automatic lockout functionality, and how the V1 apps use that dramatically greater processing power and storage capacity of smartphones to handle it. There were questions about how many lockouts do you actually need, what would it take to make automatic lockouts happen, and so on. I wrote a couple of responses and thought I’d consolidate them into one place for reference and for further discussion.



If they do it like others, then for automatic lockouts they keep track of every single K-band alert and location. It only becomes a lockout if you encounter the same signal (plus or minus some number of megahertz) in the same place repeatedly over time. So while you may only have a few dozen actual lockouts, they’d need the storage space to keep track of many more signal frequencies and locations. If a BSM alerts, it needs to log it. If a door opener alerts, it needs to log it. If a LEO is throwing K, it needs to log it. Only some of those will actually make it into an actual lockout, but it needs lots of slots to keep track of all the potential lockouts since it can’t/won’t know the difference until it you drive by the location again and it either sees the same signal again or else doesn’t see the signal and thus removes it from the list (to varying degrees of nuance and intelligence depending on the implementation).

So, no, most people don’t literally need 2,000 actual lockouts, but it’s very possible the detector needs a very large number of slots to fill with potential lockouts to keep track of.

I actually run an R3 primarily in my A5, but in my truck and in my fiancée’s car I have V1s hardwired in, so V1Driver is very part-time. Even so, on my phone, V1Driver has 2132 K band records, 816 new records, 181 records that are “learning”, 537 that have been “demoted” over time, all for 190 actual active learned lockouts.

When the R3 was released, it was only allowed 200 lockouts, but they were all manual only. And keep in mind that they only cover a fixed radius, so sometimes if it’s a strong signal source it can take multiple lockouts to cover a single stationary false. V1Driver has 190 actual confirmed lockouts that it’s learned (signals I’ve passed in the same location in the same frequency range on at least 3 different days), and you can see it’s got way more than that it’s actually keeping track of. Later in a firmware update the R3’s number of manual lockouts was increased to 500. For manual lockouts, that’s way more than some people need, but for other people who cover more ground in areas dense with stationary falses even 500 isn’t enough.

Since the R7 will have automatic lockouts in a few months, even 2,000 may be limiting for some people.



You’d essentially need a primitive database, maybe even just a CSV file? I’m not sure how much actual storage the R3 has and how it’s chopped up (one storage chip hard split between firmware and user marks/lockouts or two discrete storage chips or what). But beyond sheer size, you also need the processing power to process adding, incrementing, and removing entries, and also then processing each and every K-band alert through the lockout database before alerting the user. The R3 is probably capable of doing all of that, permitting sufficient time to process it all, but even small delays introduced by the extra data processing routines can “feel” long and reduce the effective range of the detector, at least on K-band.
To back up the thought. The R3 heartbeat does show change in activity when coming into marked lockout spot. Don’t know if that shows it does use IOPS on the CPU and hits storage for look up? I guess it has to do that as soon as it sees a k band anyway. But it see,s to flicker more in the lockout area.
 

Deacon

TXCTG
Advanced User
Premium Member
Joined
Nov 13, 2016
Messages
8,727
Reaction score
10,539
Awards
0
Location
Hill Country, TX
Rating - 100%
2   0   0
Since the Lockouts are based on GPS already, there is no need to query a huge list in a data base, only the closest recorded Lockouts (say 10 or 20) from the database need to be scanned
For a gas station in the middle of nowhere, sure. What about for a CVS in the middle of a jungle of stationary falses? Remember, you’re not just checking lockouts. You’re checking ALL recorded K-band hits within whatever given area, every BSM, every cop, every grocery store next to the CVS, all of it. You’re thinking in more human logic than machine logic, I think. And keep in mind we’re dealing with a primitive radius, here, with no mapping data and an understanding of where you’re going on which road, and a CVS positioned on the corner throwing K straight down two different roads at that intersection. And with the R7’s sensitivity, some of those radii will need to be pretty huge. I bet that there are some CVS falses in the flatlands of the Midwest that can be seen for a long way away.

Sure, there are some tricks you can use to narrow down the scope of what all gets processed, but it’s not universally low cost to the processors even then. The faster the processors (and more memory, faster storage, etc), the less it will have an impact, but we’re not talking quad core snapdragons here.
 

Transporter

ModWight Transporter
Intermediate User
Premium Member
Joined
Jul 3, 2018
Messages
1,892
Reaction score
2,334
Awards
0
Location
In front of you but behind a Rabbit
Rating - 100%
1   0   0
For a gas station in the middle of nowhere, sure. What about for a CVS in the middle of a jungle of stationary falses? Remember, you’re not just checking lockouts. You’re checking ALL recorded K-band hits within whatever given area, every BSM, every cop, every grocery store next to the CVS, all of it. You’re thinking in more human logic than machine logic, I think. And keep in mind we’re dealing with a primitive radius, here, with no mapping data and an understanding of where you’re going on which road, and a CVS positioned on the corner throwing K straight down two different roads at that intersection. And with the R7’s sensitivity, some of those radii will need to be pretty huge. I bet that there are some CVS falses in the flatlands of the Midwest that can be seen for a long way away.

Sure, there are some tricks you can use to narrow down the scope of what all gets processed, but it’s not universally low cost to the processors even then. The faster the processors (and more memory, faster storage, etc), the less it will have an impact, but we’re not talking quad core snapdragons here.


My thought is you might be WAY overthinking LockOuts. Most of those are already processed! All that needs processed is the new signal IE Frequency, Signal Strength, location/heading (for arrow units). Then a quick check of the already recorded signals right on top of that location, not the whole DB. Plus BSMs get dropped quickly because no other signal matches up with them again. Additionally, the detector is dealing with the new signal info while if one is smart and running an App, the App is dealing with the DB and the comparisons which is again the main reason to run an App, so as to get ALL that burden off the RD so the RD only needs to deal with active signals!

I watched in awe as JBV1 dealt with a Walmart strip center with 4 entrances, 2 gas stations, a CVS, a DQ, a Subway, a bank, plus a strip center on the side street with 8 tenants with motion doors. The fourth time I pasted the Walmart, not a peep out of my V1!
.
 

Deacon

TXCTG
Advanced User
Premium Member
Joined
Nov 13, 2016
Messages
8,727
Reaction score
10,539
Awards
0
Location
Hill Country, TX
Rating - 100%
2   0   0
Well, sure, a smartphone is going to dwarf any detector in processing capabilities. Make no mistake, I am an advocate of the way more powerful options available in an app you set once and forget (or not if you feel like interacting with it I guess). But few detectors offer such a thing, and Uniden R3 and R7 certainly do not. Yes, an app can do so much more so much faster, but that’s not what we’re talkkng about here.

When the detector itself is doing it, it’s limited by processing speed and storage (and most likely memory). And with the R7, we’re talking about what’s shaping up to be the most sensitive windshield mount detector you can buy, which means those lockout radii need to be huge, or else it’s going to be using up finite slots for every lockout. But that’s not great to block out a giant 70MHz chunk from the heart of K-band over an enormous area.

Solving the problem requires a lot of thought and nuance. People say “I don’t need 2,000” lockouts, and it’s probably true that most don’t, but it needs lots of slots to handle every single K-band signal it comes across, and it needs to process every one of those next time you go through there, and maybe the time after that. There’s a Dollar General not too far from my house that closes and therefore shuts down its automatic door opener. You can’t just remove it because one time you drove by it after hours.
 

benzr

Been there done that !! Original V1 user !!
Advanced User
Joined
Apr 23, 2012
Messages
4,626
Reaction score
5,077
Awards
0
Location
FLA
Rating - 100%
1   0   0
Total number of Lockouts needed is going to be different for many different Drivers, but one group of Drivers needs many more than the causal RD user. That group are the Drivers that drive loads of miles plus interacts with multiple decent size cities. I have thousands of Lockouts due to Atlanta, Macon, Chattanooga, Savannah, Charlotte, Greenville, Columbia, and the surrounding metro areas of those cities plus many more. Add the local radar speed limit signs, school zones, gas stations, strip malls, CVSs, etc near home and the total number needed climbs quickly.

Now that means for some that a limit on the total number could be an issue. But the real question that hasn't been answered yet is, "How does/will the R7 handle actual Lockouts"? Will it be frequency accurate enough, GPS location accurate enough, plus signal strength knowledgeable enough to auto store lockouts that will not accidentally cover up a future actual K Band police radar encounter? Escort has failed this with poor lockout logic.

Since the Lockouts are based on GPS already, there is no need to query a huge list in a data base, only the closest recorded Lockouts (say 10 or 20) from the database need to be scanned for Quiet Ride usage based on current GPS location. Processing power should concentrate on frequency accuracy, signal strength, and source location plus reviewing a short "list" of prior logged signals to compare if the current signal has been recorded enough times to justify now being made an Auto Lockout.

I am a big fan of how @johnboy00 is handling manual and auto lockouts in JBV1.
.
Im siding with transporter on this one

TRUST ME he knows


Posted from my iPhone using the RDF Mobile App!
 

Deacon

TXCTG
Advanced User
Premium Member
Joined
Nov 13, 2016
Messages
8,727
Reaction score
10,539
Awards
0
Location
Hill Country, TX
Rating - 100%
2   0   0
Since it’s so simple and cheap to do, maybe Attowave/Uniden just have the world’s worst firmware developers.
 

RoverTtx

Learning to Fly
Beginner User
Joined
Mar 20, 2018
Messages
165
Reaction score
155
Awards
0
Location
Broke
Rating - 0%
0   0   0
Since it’s so simple and cheap to do, maybe Attowave/Uniden just have the world’s worst firmware developers.
I don't think anyone here said it was simple or cheap. However, even if it was possible on the current chipset Uniden may want to only build that feature on the r7 as an incentive to buy it.
 

woopies

Lurking
Intermediate User
Joined
Jul 25, 2014
Messages
436
Reaction score
656
Awards
0
Location
10280 Alliance Road, Cincinnati, OH
Rating - 0%
0   0   0
Autolockouts can cause a decrease in performance. How much performance? We will have to wait and see since its heavily contingent on implementation. Let's assume you have 2000 records, 70mhz cpu, with queue GPS. (Note: I'm purposely making this the worst case i.e. Edge case). Each detected signal results in either BSM and/or GPS compute time. Once a signal is detected not as BSM, then it will have to query the GPS chip and has to wait for GPS to respond (note this is based on the bus speed, far slower than the CPU). If the GPS chip times out (in a tunnel) then that's a lot of wasted clock cycles that the detector could have used to alert. If the GPS chips sends back the coordinates then it will have to pull from the database. Assuming it's sorted some how where you can pull batch of records closest to your current location (note that the CPU has to load it into internal memory which is orders of magnitude faster than external memory). In this case let's make it 10 records it has to check. Each record holds direction, strength, radius, frequency, etc. In the worst case it checks all 10 and fails thus not a false. Again wasting valuable alert time. As you guys can see its pretty dynamic and the way you implement makes a huge difference. You can do some hardware caching, and hash tables to reduce a lot of wasted clock cycles; however, this requires a lot of forethought. What makes it worst is searching the db linearly... pushing 2000 records would suck.
 
Last edited:

Stealthbull

Learning to Fly
Beginner User
Joined
Oct 11, 2018
Messages
118
Reaction score
145
Awards
0
Rating - 100%
1   0   0
Autolockouts can cause a decrease in performance. How much performance? We will have to wait and see since its heavily contingent on implementation. Let's assume you have 2000 records, 70mhz cpu, with queue GPS. (Note: I'm purposely making this the worst case i.e. Edge case). Each detected signal results in either BSM and/or GPS compute time. Once a signal is detected not as BSM, then it will have to query the GPS chip and has to wait for GPS to respond (note this is based on the bus speed, far slower than the CPU). If the GPS chip times out (in a tunnel) then that's a lot of wasted clock cycles that the detector could have used to alert. If the GPS chips sends back the coordinates then it will have to pull from the database. Assuming it's sorted some how where you can pull batch of records closest to your current location (note that the CPU has to load it into internal memory which is orders of magnitude faster than external memory). In this case let's make it 10 records it has to check. Each record holds direction, strength, radius, frequency, etc. In the worst case it checks all 10 and fails thus not a false. Again wasting valuable alert time. As you guys can see its pretty dynamic and the way you implement makes a huge difference. You can do some hardware caching, and hash tables to reduce a lot of wasted clock cycles; however, this requires a lot of forethought. What makes it worst is searching the db linearly... pushing 2000 records would suck.
After reading these posts, (thanks) I have a renewed appreciation of all the RD companies that have worked so hard on BSM issues and Arrows and have sacrificed some range to do so (due to prossesing time) it’s not a cheap easy task to say the least.

I also see that building a RD that has limited functions to process information can be a Range King (O/Redline/R3) but also then become a BSM nightmare unless changes in segmentation is done, which defeats the purpose of a RD to protect on all bandwidths.


And increased DB could cause addition headaches for city driving if Newer style RDs don’t have massive amounts of processor power on board to deal with so many addition BSM alerts.
Thanks again.
 

DrHow

Premium Member
Intermediate User
Premium Member
Joined
May 18, 2018
Messages
1,686
Reaction score
2,262
Awards
0
Rating - 100%
1   0   0
Autolockouts can cause a decrease in performance. How much performance? We will have to wait and see since its heavily contingent on implementation. Let's assume you have 2000 records, 70mhz cpu, with queue GPS. (Note: I'm purposely making this the worst case i.e. Edge case). Each detected signal results in either BSM and/or GPS compute time. Once a signal is detected not as BSM, then it will have to query the GPS chip and has to wait for GPS to respond (note this is based on the bus speed, far slower than the CPU). If the GPS chip times out (in a tunnel) then that's a lot of wasted clock cycles that the detector could have used to alert. If the GPS chips sends back the coordinates then it will have to pull from the database. Assuming it's sorted some how where you can pull batch of records closest to your current location (note that the CPU has to load it into internal memory which is orders of magnitude faster than external memory). In this case let's make it 10 records it has to check. Each record holds direction, strength, radius, frequency, etc. In the worst case it checks all 10 and fails thus not a false. Again wasting valuable alert time. As you guys can see its pretty dynamic and the way you implement makes a huge difference. You can do some hardware caching, and hash tables to reduce a lot of wasted clock cycles; however, this requires a lot of forethought. What makes it worst is searching the db linearly... pushing 2000 records would suck.
IOPS baby! What he shows above indicates depending on how the system is written, what is offloaded, and what hardware, many IOPS could be needed for what seems to be simple transactions. IOPS required affected by the CPU compute, bus stricture, memory and storage access.
 

woopies

Lurking
Intermediate User
Joined
Jul 25, 2014
Messages
436
Reaction score
656
Awards
0
Location
10280 Alliance Road, Cincinnati, OH
Rating - 0%
0   0   0
IOPS baby! What he shows above indicates depending on how the system is written, what is offloaded, and what hardware, many IOPS could be needed for what seems to be simple transactions. IOPS required affected by the CPU compute, bus stricture, memory and storage access.
Yeah it's easier said than done since you have to redo the whole architecture. We always advocate more range......now we have it. What next? Better BSM detection :D. Seeing how most of the R7 platform is based on the R3 platform, we can assume that filtering won't be as good and GPS will only play a small part in reducing falses while taking an overall performance hit (again depending on how they implement the GPS auto-lockouts).
 

Deacon

TXCTG
Advanced User
Premium Member
Joined
Nov 13, 2016
Messages
8,727
Reaction score
10,539
Awards
0
Location
Hill Country, TX
Rating - 100%
2   0   0
Those are some pretty big assumptions. Hardware has changed between the R3 and the R7, too.
 

woopies

Lurking
Intermediate User
Joined
Jul 25, 2014
Messages
436
Reaction score
656
Awards
0
Location
10280 Alliance Road, Cincinnati, OH
Rating - 0%
0   0   0
Those are some pretty big assumptions. Hardware has changed between the R3 and the R7, too.
The main issue when changing hardware is the idea that it will be better--especially increasing cpu frequency. However, it's quickly limited when paired with slower peripherals and unoptimized code.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 0)

Donation drives

RDF Server & License Fees (APR 2019) (ACTIVE)

This donation drive covers the server and licensing fees for RDF for the month of April 2019...
Goal
$468.00
Earned
$445.00
This donation drive ends in

Latest threads

Social Group Activity

Forum statistics

Threads
80,695
Messages
1,207,228
Members
18,535
Latest member
bjevers
Top