added basic csq functionality

[W3AXL]

added an optional parameter to the config json file

per channel, you can specify a "csqLeveldBFS" parameter which is the squelch threshold in dBFS (the same unit SDR sharp uses). A value of 0, or the parameter missing entirely, will result in open squelch.

See below:

"channels" : [
    {
      "outFifo" : "test.out",
      "chanCenterFreq" : 100000000,
      "csqLeveldBFS" : -60
    }
  ]

There's probably a much better way to calculate dBFS from I/Q sample RMS values, but I just did it experimentally by taking two known points measured in SDRSharp (the noise floor and a constant FM signal) and working backwards from the raw RMS sample values to get the proper scaling factors.

Still todo is adding in some basic predelay/hysteresis to eliminate the leading squelch break.

[lilrags16]

if you would like to guide me a little, I would love to assist with the CTCSS implementation. I have made it in python, and I know at the C level it would be much faster. Might be a good time to start learning C

[lilrags16]

@pvachon I can confirm @W3AXL pull is in working order. It does seem to have some room for optimization. I had some 14 channels running on the master build at about 80% CPU. With 4 channels on this pull with the CSQ enabled, I am at 71%. I am sure moving up from my 2009 relic of a CPU (AMD Athlon II X3 425) would help....

Great work Patrick!

[pvachon]

Very cool, thanks for the patch and @lilrags16 thanks for testing.

I can't quite land this yet -- there are a few issues we'll need to address (some stylistic things, a few issues that will prevent autovectorization by the compiler and more specifically the performance issue @lilrags16 raised). I'll throw together a code review when I get time over the course of the next day or so.

[W3AXL]

I'm by no means a pro software engineer. Performance hits didn't even cross my mind. There's definitely some areas where that could be improved as well. I'm doing a decent amount of floating point calculations every run through the demod algorithm and I'm sure that's not the best for keeping CPU usage low.

[W3AXL]

I cleaned up the code a bit and got rid of the floating point & sqrt calculations inside the sample loop. Hopefully that settles things down a bit. I couldn't see much difference in CPU usage between my latest commit and the original base branch with a single RX thread.

[lilrags16]

@W3AXL I will build it and test. Very thankful for your work! Overnight I had my system that has been using multiFM for about a year running your pull, and it has really improved the squelch ability's.

[W3AXL]

~~In today's episode of "hardware engineer tries to code" I'll be attempting a basic open delay to prevent the leading squelch tail.~~

Nevermind, that's going to involve messing with a lot of things higher up in the processing chain that I don't really feel inclined to disturb. We'll let things sit here until pvachon takes a look at what I've done so far.

[lilrags16]

@W3AXL, While I don't know C and I am pretty shakey in DSP, I have a couple questions maybe know.

From my knowledge, floating point takes longer than integer math. Is there really a need to have any floats involved in the dBfs math?

Maybe only using int is an option that could yield in some lower stress on the CPU?

I am just a "dumb" firefighter who chooses to moonlight in web systems, and is much stronger in DBs than this field of software

[pvachon]

Apologies for taking so long to review. Made a few suggestions (also to ensure that CSQ-related changes don't impact e.g. use of digital modes, performance-wise). I'd like to research how to implement squelch using a moving average (or some other similar construct) without having to pre-crunch through the sample buffers, too.

[lilrags16]

@W3AXL any updates?

[W3AXL]

FYI, it's been quite a while since I've poked around this project, but I'm back at it again and hope to get a more robust CSQ fleshed out this week.

My current plan is to rework the CSQ algorithm to use a noise-power based squelch so that it functions independent of SDR gain. More research to be done on the most efficient algorithm to do so, but it should turn out to be much better than the hacky level-based squelch I implemented with this PR. Closing this PR for now.