integration with "stand-alone" radar detectors?

[green]

Just before I sink a bunch of time into proof of concept for something that was already considered and rejected for whatever reason that is not yet obvious to me, I guess I'll ask here first

We all know that these radar detectors (I have uniden r3 ATM) have various sounds to alert us of danger. You could set separate sounds per different bands and some of them can even speak out frequencies. the stronger the signal, the more frequently the alert sounds.

So the idea is to activate phone microphone to listen in on these alerts and record them in an app, after some research it looks like fft-based approach should be relatively easy to implement to tell different types of alerts and timing them would allow deducing the signal level. Some speech recognition (local (variability is low so should be doable with some struggles) or "in the cloud") would even allows us to record the frequencies hit at least for the Ka-band.

Obvious upsides include:

1. crowd sourcing false alert maps
2. automatic crowdsourcing of LEO presence without relying on V1 units that have the necessary machinery to report it (and cost $$$)
3. (if the use of external audio cable mutes in-build RD speaker - to be tested) - then sound alerting could be offloaded to the phone and that way you can have various automatic muting implemented in the phone bringing this and other functionality for detectors that don't have the capability. - this also removes the concern about loud music drowning the alerts and such.

Sounds good, right? But if that works and takes off - there's even more potential upsides, e.g. if Uniden (and perhaps others after them?) add a firmware option for (we'll call it) "digital" alert sound that would encode exact signal type, strengths and whatever other info that might be available (e.g. direction) - this would further improve the abilities without much investment on the RD maker front.

Additionally after reading about project SEAL and a potential patent trouble - I read the patent in question and I think this approach works around the patent nicely:

• The patent centers around radar detector that is then communicating with computers and "upgrade devices" by radio waves - so audio should be fine ("the invention features a radar detector having a wireless device interface comprising a radio compliant with one or more of Bluetooth, Zigbee, 802.11, and wireless personal area network communication protocols")
• The patent talks about how upgrade device could silence the alerts from the Radar detectors based on various criteria - with RD always alerting (into the audio cable, and also the onboard display) and never being silenced - this also seems ok when the actual sounds are produced by the phone based on both RD input and other sources.
• IANAL but the whole phone thing being totally separate from the RD and having a one way input-only link seems to run contrary to the very integrated system discussed in the patent.

So am I out of my mind?

 

[NVR2FST]

Hopefully, the experts will chime in. [emoji1696]

 

[SquirrelMaster]

Howdy, @green !
First of all, let me address the important question here:

So am I out of my mind?

I really hope so, that way you'll fit in with the rest of us on rdf

We all know that these radar detectors (I have uniden r3 ATM) have various sounds to alert us of danger. You could set separate sounds per different bands and some of them can even speak out frequencies. the stronger the signal, the more frequently the alert sounds.

So the idea is to activate phone microphone to listen in on these alerts and record them in an app, after some research it looks like fft-based approach should be relatively easy to implement to tell different types of alerts and timing them would allow deducing the signal level. Some speech recognition (local (variability is low so should be doable with some struggles) or "in the cloud") would even allows us to record the frequencies hit at least for the Ka-band.

This has been done t some extent. @ferius developed an app which uses your phone's microphone to listen to a RD and datalog for testing. It doesn't discriminate between alert tones but its a step towards what you are talking about:

RD test - an utility for testing radar detectors and more

As many of you may have noticed, @Vortex was using a new application for conducting his recent "V2G2 vs. others" testing. Today I'm publishing this app, so everyone can take advantage of using it. The goal of the application is to automate as much of the radar detectors testing process as...

www.rdforum.org

(if the use of external audio cable mutes in-build RD speaker - to be tested) - then sound alerting could be offloaded to the phone and that way you can have various automatic muting implemented in the phone bringing this and other functionality for detectors that don't have the capability. - this also removes the concern about loud music drowning the alerts and such.

I think there are real-world issues that would really hinder this such as the bluetooth audio profiles implemented in most cars, having to connect your phone up to the rd every time over aux (can cause issues if the app dies/is killed and the detector has no way to sound an alert), as well as other small things such as cabin noise, convertible drivers, etc.

Sounds good, right? But if that works and takes off - there's even more potential upsides, e.g. if Uniden (and perhaps others after them?) add a firmware option for (we'll call it) "digital" alert sound that would encode exact signal type, strengths and whatever other info that might be available (e.g. direction) - this would further improve the abilities without much investment on the RD maker front.

The way the audio is implemented in the Unidens would not make this possible. They would need to redo their audio hardware to enable something like that. The issue is they currently have a flash space with pre-recorded alerts. They are not auto-generated on the fly. They would need to either have something that can auto generate those alert tones with the encoded data or encode that data and mix it in with the alert tones on the fly.

It would be easier for them with just a firmware change to bitbang the mute and alert lines on the RJ12 jack in a uart sort of fashion and allow external dongles with BLE to be connected.
Would they do any of those options? Probably not.





TL;DR
Not sure how well it would work but something much less mature than your overall idea is currently being used to facilitate RD testing. Could be a good starting point: https://www.rdforum.org/threads/98120/post-1412396

 

[green]

This has been done t some extent. @ferius developed an app which uses your phone's microphone to listen to a RD and datalog for testing. It doesn't discriminate between alert tones but its a step towards what you are talking about:

Thanks for the link. I am surprised it was not integrated into highway radar at least in some form since it seems to be the obvious next step (was the SEAL project going to depend on this and then got dropped?)

I think there are real-world issues that would really hinder this such as the bluetooth audio profiles implemented in most cars, having to connect your phone up to the rd every time over aux (can cause issues if the app dies/is killed and the detector has no way to sound an alert), as well as other small things such as cabin noise, convertible drivers, etc.

not sure how bluetooth profiles play a role here. Also was mostly thinking dedicated "in car" phone here that seems to be a really common approach.
Sure if the app dies we have a problem, so just need to make sure it's really robust

As for cabin noise - if you use audio cable that is not a concern for obvious reasons.

They would need to either have something that can auto generate those alert tones with the encoded data or encode that data and mix it in with the alert tones on the fly

pretty much. think of it as old-style modem of sorts. It could also incorporate a "pilot" tone that the phone would use to know when the "connection" is lost/RD is dead and such.

and allow external dongles with BLE to be connected.

that might be problematic in the view of the patent though.

bitbang the mute and alert lines on the RJ12 jack

that would be ok wrt patent because it won't be "wireless" too But then you need a new special cable and interfacing with the phone and such - so complexity is high and the uptake probably would be low as the result.

 

[SquirrelMaster]

Sorry, I saw this while driving the other day and forgot to reply.

Thanks for the link. I am surprised it was not integrated into highway radar at least in some form since it seems to be the obvious next step (was the SEAL project going to depend on this and then got dropped?)

We never know. It may one day be but in the state it was last in (It worked very well don't get me wrong. Definitely an awesome app) it needed a perfect scenario. Best results were had with windows up, music down, and the RD tone being the loudest, most shrill one. I believe the phone had to be close by too.

I ended up trying to use it in a very loud V10 car and I couldn't get it to reliably work. Went to a quieter car and it worked a treat.

not sure how bluetooth profiles play a role here. Also was mostly thinking dedicated "in car" phone here that seems to be a really common approach.
Sure if the app dies we have a problem, so just need to make sure it's really robust

As for cabin noise - if you use audio cable that is not a concern for obvious reasons.

My thought with the bl profiles was the microphone being driven by the car's headset audio profile but I think that most modern day phones you can force from an app which microphone or audio input to use so disregard that haha. Plus android auto streams car mic audio well without doing that.

My concern was having the infotainment system stuck in "call mode" just to make this work if your phone is paired.

Audio cable would work great but that ties back into the app/phone not dying and leaving your detector screaming at ray charles.
That also has the issue of requiring an action every time you get in the car and want to use the app; you can't just leave the phone in your pocket, you have to plug it in each time.

pretty much. think of it as old-style modem of sorts. It could also incorporate a "pilot" tone that the phone would use to know when the "connection" is lost/RD is dead and such.

Yeah I get the operation. I just doubt the ability (or even willingness) of manufacturers to include that with current hardware.

that would be ok wrt patent because it won't be "wireless" too But then you need a new special cable and interfacing with the phone and such - so complexity is high and the uptake probably would be low as the result.

Yeah definitely. But a new power plug would be easy (relatively speaking). Would basically be an accessory or something can be tapped inline to it.

Hopefully @ferius can chime in on how well the radartest app does with picking up the alert tones and if this is a feasible idea/app. @Vortex I know you use the RadarTest app. What do you think? Could the performance be worthy of being used for this idea?

Maybe a compromise; a dedicated hardware backpack (I am a hardware guy so I may be biased here )... For example, it can be some thin base plate that mounts to the bottom of a detector and plugs into the audio jack. It then only listens to that and has its own speaker output.
Basically a hardware version of your app idea hahaha. Would give the benefit of being more robust (IMO) but the drawback of being an extra bit of hardware rather than a phone that everyone already has in their pocket.



@green The patent did screw over seal but there is a new project called SABRE introduced. It is an api/sdk for building plugins that can work with Highway Radar. Maybe worth looking into...
It is laid out in this thread: https://www.rdforum.org/threads/102737/post-1481677


I do like the idea and think it would be neat to see but I am personally just not sure how well it would work in practice/how robust it would be. I see it really requiring a best case scenario to work well. I am curious to hear your further thoughts or even help out if you wanted to work on it

 

[green]

I ended up trying to use it in a very loud V10 car and I couldn't get it to reliably work. Went to a quieter car and it worked a treat.

it depends on implementation. if the old one was just looking for a ramp up in volume then that of course would be unreliable.

fft seems to allow us to more accurate classification of radar detector sounds by their specific frequency "signature".

here's a spectrogram of a quiet k-band (volume 2, the quietest sound pattern that's just a "Bleep") in a moving noisy car at the max signal strength (approaching a sign displaying your speed):

here's a default Ka band double-chime + the "KA band" announcement at startup - again very visible frequency telltale.

This is not an area I specialize in, but this all seems to be doable so I intend to spend some time on trying to make it work. Of course it'll work bet with a cable, but if you can hear it in a moving car, the phone should be able to hear it with external microphone too.

Would basically be an accessory or something can be tapped inline to it.

The problem here is you basically need support from the RD vendors from the get go though.

 

[ferius]

Hey, sorry for a bit delayed response. Here are my thoughts on this.

@green, great idea, and with a proper effort it is totally implementable. Fortunately, as @SquirrelMaster mentioned, I have some experience with that kind of stuff. However, there are couple issues with that approach.

The first issue is actually detecting and classifying the alert tone. There are two possible approaches here.

• The first is listening to the phone's mic. This actually will work quite well on Uniden detectors, for example, as their tones are very clearly detectable on the spectrogram. At the same time, Escort's detectors are terribly difficult to detect, even using your eyeballs looking at the spectre. And it is even harder to distinguish them from ambient noise (that was quite an issue for me with RD Test).
• Another possible approach is, as it was mentioned above, is connecting the detector directly to the phone using a line cable. In this case, we won't have any issues with detecting and classifying the signal. However, in this case we heavily rely on the phone to relay the sound, as the detector won't use an external speaker in this case. What if the app hangs, the bluetooth is improperly configured (e.g. a driver switches to the radio), or the phone is set to the minimum volume. This all makes the system much less reliable. Also, not everyone will be happy connecting the phone to the RD every time they drive.

Now, let's suppose we did manage to reliably detect and classify the alert sound. The next question is what can we do with that.

Reporting police automatically isn't an option, as there are rolling Ka, laser falses, etc. We also don't know the directional information to submit the report.

Another approach is to use the alert sound detection to trigger the reporting dialog. This works much better, however, there will still be many false activation which may become quite annoying. From my personal experience about 80-90% of Ka detection I encounter are the rolling ones. Also, if we use the location of the first detection as the reporting location, the it will be waaay off the actual location. R7, for example, can pick up the alerts miles away from the source.

So, if the SEAL project would have been alive now, this would have definitely been an option to consider. The SEAL alerts could display the entire region of the signal, and there were some plans on detecting rolling alerts. However, with the classic crowdsourced services it doesn't add much benefit.

Starting a SABRE alert now is just one tap, or even a voice command. So do the extra hassle of connecting the RD to the phone, and occasional false reporting prompts worth that? IMO, they don't. Also, properly implementing that kind of sound processing isn't very easy. RD Test uses quite a simple acoustic model without any classification, thought it still took me about a week to research, implement, and tune it.

 

[green]

(hm, this turned out to be a rather long reply)

At the same time, Escort's detectors are terribly difficult to detect

Well, so there's be a supported list of detectors that play along easily? Some data is better than no data.

Reporting police automatically isn't an option, as there are rolling Ka, laser falses, etc. We also don't know the directional information to submit the report.

Well, there are certain things still possible:

• If we assume all Ka are non-false, we can detect rolling Ka just fine by their properties for the most part (e.g. if it stays with us for a long time - it's going same direction as us, if it ramps up very fast and then ramps down, probably was oncoming, very different from I/O).
• K of course has a ton of falses, but in my recent observations we still can "throw away" a bunch.
  • e.g. stuff that ramps to strength 3 fast and then quickly dies down is likely a BSM - no need for a dialog on this one.
  • C/O ramps up much slower and stays at full strengths longer (I finally saw one C/O K in GA today).
  • Sure, Distant I/O in K diapason would be compromised, but something is better than nothing esp. if this something is not ridden with false positives.

Also, if we use the location of the first detection as the reporting location, the it will be waaay off the actual location. R7, for example, can pick up the alerts miles away from the source

Well, since we can get signal strength from sound (R7 varies pause between beeps so you can tell signal strength quite easily), so only area with full strength would be reported and after some testing we can also determine if it's like the middle of the area or some such to be somewhat more accurate.

Not full strength signals don't need to be reported because localization is unknown, could be a distant I/O or whatnot (esp. without direction), could be reported as a vague "distant signal" for the heat maps or the like.

If this takes off then we might be able to get Uniden people to actually encode useful info on the audio channel (kind of a long shot of course)

So, if the SEAL project would have been alive now, this would have definitely been an option to consider

So since I missed most of it - what is the problem with SEAL if you remove the parts that rely on the patent (i.e. wireless radio connection to a radar detector that seems to be a centerpiece of the patent)?

Starting a SABRE alert now is just one tap, or even a voice command. So do the extra hassle of connecting the RD to the phone, and occasional false reporting prompts worth that?

assuming it adds ability to report things with zero interaction - sure, at least in my opinion. You can have multiple layers of reporting: human input, audio devised from (supported) RDs, a plugin for wireless radio-equipped detectors (whoever decides to make those and risk the patent run-in encounter, I guess. though for pure "into the cloud" reporting I think patent does not apply all that much, esp on a disjointed system where different entities create/own different parts of the "stack"?)

For "best" results you probably want more than a single button target type anyway. e.g. ability to tell apart "this is where the police is hidden" vs "this is where we see the roadside disco" (= measurement was earlier) vs "unmarked vehicles sighting" vs "we see the chase brigade here waiting for reports from above", ...
Sure, not everybody would want to report such details too, so I don't know how to make an easy UI that would allow people to report this or not as they desire, but seems useful to have ability for all these types.

RD Test uses quite a simple acoustic model without any classification, thought it still took me about a week to research, implement, and tune it.

Well, a week is not bad I guess. Though no classification? The uniden tones seem to be easy to classify and I am trying to throw together a prototype to do just that + the voice recognition of spoken frequency on the Ka band (more data = better). Looks to be totally workable even for me with no prior DSP experience.
If you already have code that does that - using it seems like a no-brainer? Just add extra goodies for people that chose to participate in this extra reporting to incentivize it

I agree that audio cable adds some complexity and fragility but making it an option still has its benefits for people that would find the tradeoffs acceptable.

 

[ferius]

If we assume all Ka are non-false, we can detect rolling Ka just fine by their properties for the most part (e.g. if it stays with us for a long time - it's going same direction as us, if it ramps up very fast and then ramps down, probably was oncoming, very different from I/O).

The terrain also plays quite an important role here. There is essentially no difference between an opposite rolling C/O on a long stretch, and a stationary C/O on a curvy road.

• K of course has a ton of falses, but in my recent observations we still can "throw away" a bunch.
  • C/O ramps up much slower and stays at full strengths longer (I finally saw one C/O K in GA today).

Same as speed signs and door openers. Also, areas with multiple falses (e.g. near malls) will also be treated similarly to C/O.

Well, since we can get signal strength from sound (R7 varies pause between beeps so you can tell signal strength quite easily), so only area with full strength would be reported and after some testing we can also determine if it's like the middle of the area or some such to be somewhat more accurate.

That is true, no doubt. However, R7, for example, doesn't have the best ramp-up, so the signal can easily stay at full power for a mile or so.

If this takes off then we might be able to get Uniden people to actually encode useful info on the audio channel (kind of a long shot of course)

Oh, I'm so much doubtful about this TBH.

So since I missed most of it - what is the problem with SEAL if you remove the parts that rely on the patent (i.e. wireless radio connection to a radar detector that seems to be a centerpiece of the patent)?

assuming it adds ability to report things with zero interaction - sure, at least in my opinion. You can have multiple layers of reporting: human input, audio devised from (supported) RDs, a plugin for wireless radio-equipped detectors (whoever decides to make those and risk the patent run-in encounter, I guess. though for pure "into the cloud" reporting I think patent does not apply all that much, esp on a disjointed system where different entities create/own different parts of the "stack"?)

So since I missed most of it - what is the problem with SEAL if you remove the parts that rely on the patent (i.e. wireless radio connection to a radar detector that seems to be a centerpiece of the patent)?

The patents are waaay too wide and cover pretty much everything. Audio connection is too unreliable to drive the entire SEAL project.

For "best" results you probably want more than a single button target type anyway. e.g. ability to tell apart "this is where the police is hidden" vs "this is where we see the roadside disco" (= measurement was earlier) vs "unmarked vehicles sighting" vs "we see the chase brigade here waiting for reports from above", ...
Sure, not everybody would want to report such details too, so I don't know how to make an easy UI that would allow people to report this or not as they desire, but seems useful to have ability for all these types.

Not to go into much details, but there is a very good reason why I chose the old open-source version of Waze as a basis for the SABRE protocol. That protocol doesn't support any additional information, such as classification "roadside disco / speed trap". In future, I'll possibly add this, but not now.

Well, a week is not bad I guess. Though no classification? The uniden tones seem to be easy to classify and I am trying to throw together a prototype to do just that + the voice recognition of spoken frequency on the Ka band (more data = better). Looks to be totally workable even for me with no prior DSP experience.
If you already have code that does that - using it seems like a no-brainer? Just add extra goodies for people that chose to participate in this extra reporting to incentivize it

At this point I don't have even that much time as I had while working on RD test. For classification we need a completely different approach, the RD test one won't work as it has other goals.

I agree that audio cable adds some complexity and fragility but making it an option still has its benefits for people that would find the tradeoffs acceptable.

So, the question is how many people are ready to accept these tradeoffs? TBH, I don't think there are a lot. I personally won't accept this (also, I'm not a bit fan of spending a lot of time on features I won't use).

Anyway, Highway Radar will get an integration with Theia, where there will be no necessity for such hacks. Regarding capturing sound, my biggest concern is that I don't think I can create a sufficiently reliable algorithm for parsing the data within a reasonable time frame. By "sufficiently reliable" I mean reliable enough, so I want to use it on everyday basis.

If you'd like to jump into this and build a module for recognizing the RD current state by the ambient sound yourself, I'll be happy to support that initiative. If you manage to detect the current RD state reliably enough, I'll be more than happy to integrate it into Highway Radar.

 

[green]

Same as speed signs and door openers. Also, areas with multiple falses (e.g. near malls) will also be treated similarly to C/O.

yes. Though I imagine you can tell server-side when something is a populated area = more likely to false.

Audio connection is too unreliable to drive the entire SEAL project.

I agree. that's why layered approach seems to be best.

Not to go into much details, but there is a very good reason why I chose the old open-source version of Waze as a basis for the SABRE protocol. That protocol doesn't support any additional information, such as classification "roadside disco / speed trap". In future, I'll possibly add this, but not now.

I see. Well, I just hope you have enough future compat in the protocol to bring the other stuff in once ready.

So, the question is how many people are ready to accept these tradeoffs? TBH, I don't think there are a lot. I personally won't accept this (also, I'm not a bit fan of spending a lot of time on features I won't use).

I agree audio cable might not be a widely popular option esp. early on. This is why I was mostly trying to concentrate on open audio as the first step too. I guess in the end we'll see how successful I am in getting the sound decoding working in noisy environment because that is the biggest gating factor.

Anyway, Highway Radar will get an integration with Theia, where there will be no necessity for such hacks

Well, sort of.
Theia still does not exist incustomer hands and won't exist for at leat 3 months. We don't know how widely available it would be an dhow many would agree to get it at whatever price it'll appear. Meanwhile uniden products are already widely available. They do miss certain online integration that many owners likely would find welcome.

Thanks for your opinion. It's back to the android studio then for me then I guess.

 

[mikedotd]

@green FWIW I played around with the same idea of using a phone's mic to pickup RD beeps, and at least for me it seemed possible to detect the specific frequencies that are used on Escort and V1's for each band (obviously no other encoded info), even in a moving car with the radio playing. That was just with an android spectrum analyzer like you showed above. Sample rate was important, and that would crank up the CPU cycles, but I imagine that sort of processing is becoming more and more efficient with each new phone chipset (for me this was like 5-6 years ago).

Unfortunately I didn't have the chops to write my own FFT, or even repurpose an existing open source one I had found; the math and code was a bit over my head.

I look forward to your findings.