Adding DCS

[robotastic]

No description provided.

[taclane]

7b85068 Tone-related functions have been removed from global_structs.h and re-homed into a new tone_manager.

This should also help with troubleshooting/compiling in the future as global_structs.h is widely included across the whole project.

[taclane]

98a5d58 The new custom squelch block residing at gr::blocks::ctcss_squelch_ff runs some risk of collision with stock gnuradio blocks that may be included by other gnuradio headers.

Even if that collision is unlikely, OOT blocks should follow gr::projectname::blockname conventions instead of using the default gnuradio blocks namespace.

There are other OOT t-r blocks to transition to gr::trunkrecorder::, but we can start with these two within the scope of the PR.

[taclane]

742550a - Remove vestigial code regarding a previous notched-reference implementation that is no longer present, as well as references to a non-existent CTCSS_DETECTOR_V2.md.

While otherwise unused, dominant_snr_db and top_three were retained to display in the CTCSS debugging output instead of being removed.

N_CTCSS is now only defined once, instead of having to match in two separate locations.

[taclane]

e864c5a - Removed mutex from CTCSS and DCS main work() loops. This should reduce some delays in squelch functionality by not having to process the whole inbound sample buffer before triggering functions to mute or unmute the audio.

Guards remain where appropriate, such as between reset() and get_verdict().

[taclane]

8b10b13 - When an explicit CTCSS or DCS tone was set, a side analysis was conducted on the unselected mode for debugging purposes. For this to have useful value, it would require simultaneous use of CTCSS and DCS tones in the same transmission, which is an improbable configuration to use as a default.

Even for debugging purposes, the non-indicated tone type would never clear the other squelch, so the additional resource cost doesn't have the ability to do thing it might purport to address (e.g. notify the user that a DCS-only channel was enabled by a specific CTCSS tone).

This does not change search mode, which will continue to analyze both tones separately and report back the highest confidence winner.

[taclane]

b8a0756 - CTCSS behaved largely the same regardless of whether it was gating on a single tone, or operating in an open search mode. It would lead to odd scenarios where short transmissions would successfully open squelch, but the detection algorithm would be unable to finish scoring the probable tone.

This eliminates search in single-tone/single-frequency configurations. If the received CTCSS tone opens squelch, it does not need additional scoring as it already is the correct tone. This should speed up tone recognition for short duration calls, and ensure that they send the tone data downstream upon conclusion.

[taclane]

02bc53d - Bring DCS to functional parity with the CTCSS decoder where it has a better split between single-code gating and open search.

When a code is input into the channel.csv, only the indicated code and its cyclic alias will be recognized (e.g. D023N and D047I have identical bitstreams). Previously, the DCS block recognized the indicated code and its inverse (e.g. D023N and D023I) as well as both cyclic aliases (D047I and D047N).

Single-code enabled channels should no longer "latch on" to incorrect, but otherwise valid DCS codes and get stuck that way.

When in search mode, the existence of a valid DCS code should always take precedence over probable CTCSS tones detected by the gnuradio block. This is for multiple reasons:

• DCS and CTCSS should not be in concurrent use
• the odds of a random bitstream being present and generating a DCS match is very low
• DCS transmission at 134.4 baud unavoidably deposits some energy into the CTCSS detection bins near 67 Hz causing false positives. This is also true for the "end of call" 101010101... pattern which may cause false positives for the 131.8 and 136.5 Hz tones. Short duration DCS calls may otherwise be judged a CTCSS call based on scoring mechanics.

[taclane]

56b40d5 - Per ongoing reports in discord, squelch options seem to have issues with interference from adjacent channels.

Initial investigation shows that the filter used by the channelizer is likely too wide and shows overlap with neighboring channels. This small edit should establish a passband across the center +/- 5200 Hz, and establish a stop band at the boundary, not a couple kHz inside the next channel.