SDR Squelch not Much Improvement.

[JamesWest]

Way back when SDR burst upon the radio scene I remember reading about all the amazing features we were going to be seeing in the future. And we have.

But one thing I noticed is setting the squelch level is just the same with SDR# or SDRPlay or any of my other apps as it is with my analog radios. Not too smart. Sort of retro.

In fact you can "see" all the information that is being lost because the squelch level is set incorrectly. But why do I still need to set a level at all? or why does it still exhibit the hysteresis that will not open the squelch gate when you set the level for the weaker of the two stations?

Why is there not some sort of signal processing the "sees" all the signals and opens the squelch in a 2021 sort of way, not like Radio Shack 1968.

 

[boatbod]

I'd offer my opinion that most SDR power squelch implementations are less usable than the old analog squelch because you cannot rely on the noise floor to be at any particular level. I've messed with gnuradio squelch for Boatbod op25's analog smartzone trunking capability, and while it works, it is persnickety to set up reliably.

 

[JamesWest]

yes this is part of it.

but i am sure this has something to do with not being able to ID noise and then compare it to differences that show up in the form of a signal. the same is true with processing audio.

some video codecs compare before and after frames and look for changes. very little change in the frames, very big compression or processing.

the same could work for a squelch plugin? i'm not the guy to answer this and i am thinking this would have been done long ago if it is possible. i just want my SDR flying car i was promised.

I'd offer my opinion that most SDR power squelch implementations are less usable than the old analog squelch because you cannot rely on the noise floor to be at any particular level. I've messed with gnuradio squelch for Boatbod op25's analog smartzone trunking capability, and while it works, it is persnickety to set up reliably.

 

[slicerwizard]

IMHO, if squelch logic is affected by the noise floor level, the logic is wrong. The I/Q dot behaves differently in the presence of a signal vs no signal, so logic should focus on that.

 

[boatbod]

IMHO, if squelch logic is affected by the noise floor level, the logic is wrong. The I/Q dot behaves differently in the presence of a signal vs no signal, so logic should focus on that.

Seems like that would require some knowledge of the modulation scheme. I've not doubt a really good squelch could be coded if you customize it for that specific signal type. How many cpu cycles are you prepared to dedicate to squelching?

 

[slicerwizard]

Seems like that would require some knowledge of the modulation scheme. I've not doubt a really good squelch could be coded if you customize it for that specific signal type.

Hm, most analog signals are FM, some are AM, digital signals are generally FM. Their I/Q dots behave much differently than noise's I/Q dot.

How many cpu cycles are you prepared to dedicate to squelching?

Well, TRUNK88 had dongle analog squelch back in late 2012 and it was developed on an Intel Atom powered netbook. It ran fine on older stuff - Celeron, etc. - so squelch needn't be a CPU hog. IIRC, detecting the Motorola disconnect word used more CPU and even it wasn't a big deal.

 

[lwvmobile]

detecting the Motorola disconnect word used more CPU and even it wasn't a big deal.

I mean, if you are already trunk tracking, I can't imagine that detecting the end sequence on a voice call would be any more intensive compared to what you're already doing. In EDACS for example, the dotting sequence can easily be detected by looking for 0xAAAAAAAAAAAAAA, and its just a simple matter of setting squelch to 0db to close the call.

Another thing to think about is that handheld radios from the 90s also had to be able to detect these things, so I wonder what kind of CPU those things were using. Motorola 6809?

 

[boatbod]

I mean, if you are already trunk tracking, I can't imagine that detecting the end sequence on a voice call would be any more intensive compared to what you're already doing. In EDACS for example, the dotting sequence can easily be detected by looking for 0xAAAAAAAAAAAAAA, and its just a simple matter of setting squelch to 0db to close the call.

Another thing to think about is that handheld radios from the 90s also had to be able to detect these things, so I wonder what kind of CPU those things were using. Motorola 6809?

First off, I doubt any subscriber radio from the 90s was using SDR, and secondly you guys are making it sound so darned simple and easy to accomplish. If that were the case, why isn't the internet full of examples of how to code a high performance squelch using SDR?

 

[lwvmobile]

First off, I doubt any subscriber radio from the 90s was using SDR

I don't believe I ever mentioned that they were using SDRs. I was referring to the type of CPUs they would be using to decode the control channel in old handheld radios, and those primitive CPUs being able to decode the disconnect word.

If that were the case, why isn't the internet full of examples of how to code a high performance squelch using SDR?

I don't believe I ever mentioned this. I was replying Slicer Wizard about detecting the disconnect word and similar, and mentioned the dotting sequence on EDACS as my own personal example, and when its detected, it would just be a matter of setting the squelch to a very high value to terminate the call, i.e. 0 dB. Likewise, when a call is detected on the control channel, just tune and set the squelch to a very very low value, i.e. -150dB. I never said anything about using power squelch or performance squelch.

 

[TomLine]

I'd like to see a SDR squelch in software that has customizable features. Speed, attack, input, etc. Kids writing code for these may never have tuned an old fashioned squelch by ear either to have a good grasp of how important and easy that should be to operate.

 

[slicerwizard]

I mean, if you are already trunk tracking, I can't imagine that detecting the end sequence on a voice call would be any more intensive compared to what you're already doing. In EDACS for example, the dotting sequence can easily be detected by looking for 0xAAAAAAAAAAAAAA, and its just a simple matter of setting squelch to 0db to close the call.

Squelch logic was on the voice SDR while the CC SDR was still decoding the 3600 bps stream, so it was an additional load.

Another thing to think about is that handheld radios from the 90s also had to be able to detect these things, so I wonder what kind of CPU those things were using. Motorola 6809?

I would expect that most of the signal processing and digital decoding was handled in custom chips. Portables had to run all day on a single charge, after all.

First off, I doubt any subscriber radio from the 90s was using SDR, and secondly you guys are making it sound so darned simple and easy to accomplish. If that were the case, why isn't the internet full of examples of how to code a high performance squelch using SDR?

I can't speak for the Internet and I don't know what logic is in use out there. I do remember that one of the basic receiver programs (rtl_fm?) at some point used a RF power based squelch, but it had an integer overflow bug - on very strong signals, sqrt(I*I+Q*Q) was overflowing due to the magnitude of the I and Q values. And the sqrt operation wasn't really needed - I*I+Q*Q already provides a value that can be tested against a threshold (assuming you don't overflow).

I'm no signal processing expert and I have no idea what the recommended squelch methods / best practices are. To keep the CPU load down in TRUNK88, I just counted zero crossings in the voice SDR's channel filtered I stream. Noise loves zero crossings, signals not so much.

Another CPU friendly cheat is to use a delay line to look ahead in time. You can have a very fast / more accurate squelch if the logic is looking at the front of the delay line and the squelching is acting on the back of the delay line. Users may or may not have an issue with the introduced delay in the audio stream though.

I'd like to see a SDR squelch in software that has customizable features. Speed, attack, input, etc. Kids writing code for these may never have tuned an old fashioned squelch by ear either to have a good grasp of how important and easy that should be to operate.

Those are parameters that are typically hard coded into SDR offerings. The designer/coder has to come up with values that are "ok" and then bake them in. They could be exposed as tweakable adjustments.

 

[TomLine]

I've been trying to find out about programming and methods being used by the SDR software guys and not coming up with much. Google just hands me video on "how to use your squelch" by guys with 30 days experience with radio. Watching AM 11 meter for example, the quality of the signals, width, general appearance varies a lot. Noise baseline stays pretty constant, but I don't think the coders are letting that be used as baseline. Maybe the processors are getting quicker and the programmers are sampling too fast.

Squelch logic was on the voice SDR while the CC SDR was still decoding the 3600 bps stream, so it was an additional load.


I would expect that most of the signal processing and digital decoding was handled in custom chips. Portables had to run all day on a single charge, after all.


I can't speak for the Internet and I don't know what logic is in use out there. I do remember that one of the basic receiver programs (rtl_fm?) at some point used a RF power based squelch, but it had an integer overflow bug - on very strong signals, sqrt(I*I+Q*Q) was overflowing due to the magnitude of the I and Q values. And the sqrt operation wasn't really needed - I*I+Q*Q already provides a value that can be tested against a threshold (assuming you don't overflow).

I'm no signal processing expert and I have no idea what the recommended squelch methods / best practices are. To keep the CPU load down in TRUNK88, I just counted zero crossings in the voice SDR's channel filtered I stream. Noise loves zero crossings, signals not so much.

Another CPU friendly cheat is to use a delay line to look ahead in time. You can have a very fast / more accurate squelch if the logic is looking at the front of the delay line and the squelching is acting on the back of the delay line. Users may or may not have an issue with the introduced delay in the audio stream though.


Those are parameters that are typically hard coded into SDR offerings. The designer/coder has to come up with values that are "ok" and then bake them in. They could be exposed as tweakable adjustments.

 

[KA1RBI]

IMHO, if squelch logic is affected by the noise floor level, the logic is wrong.

This matches my thinking as well (haha, FWIW). A very quick survey of a couple of SDR apps that are close to hand, however, reveals use of the RF-power threshold method seems most popular.

Hm, most analog signals are FM, some are AM, digital signals are generally FM.

Classic analog radios implemented squelch via a totally different method. ("Noise Squelch" - there is a reasonably good writeup on this in wikipedia). In this method there is no I/Q (as it's done post-demod)... Essentially it looks for quieting in the voice band above, say, 4 KHz, where there is likely little/no signal energy. In this system AM signals work as well as FM, they simply appear as carriers without frequency deviation.

Very ancient versions of OP25 in fact used an RF-power threshold squelch gate (with all the attendant problems). It may still be desirable to mute the speaker when "digital" signals are being received, but for reception, demodulation, and decoding of digital types (P25 et al). it's harder to justify having a squelch gate block in the flow graph - it might save some CPU cycles to keep the digital demod from operating on noise, but a digital signal is either there or it's not and the squelch gate is not the best way to make that determination.....

A digital/SDR implementation of the noise squelch would certainly be within the realm of possibility. It would need to have the equivalent of the squelch threshold control knob, it could also have other knobs such as logic to mitigate flapping and so forth...

Max

 

[TomLine]

How about dual or triple squelch. One knob could control audio based on SDR signal identification or carrier presence, and a second could use good old fashioned audio or signal level when something peaks out above the average noise level. Sometimes multiple modes and signal widths present themselves on a given frequency and one tool may not be enough. I'd use 11 meter for experimentation since there are so many types and quality of signals there, opening to digital and fm soon.

What SDR software development software modules are the coders using? Is there one box that says "squelch" with various variables to tweak?