Open lordmorgul opened 9 months ago
Continuous Tone Coded Squelch System on compatible radios. These tones are created by the transmitter to provide the receiver with a recognizable continuous tone to determine if squelch should be opened for the current signal. Repeaters use this to determine if transmitter is apparently intending to open the repeater squelch (has the input tone), and repeaters transmit a tone (either pass-thru from input, or different tone) to allow those radios listening to the repeater to recognize the transmission of the known repeater on the frequency rather than just having signal opened squelch. This is also called Privacy Codes, or Privacy Tones, and may have numbering assigned to the tone frequencies that differs for brand of the radio.
The CTCSS feature is intended to do three things:
The filter processing involves a splitter to two paths (tone identification and remaining signal). The signal path has a highpass filter cutting off the tones while the tone identification path has a low pass filter cutting off all signal except the tones.
Priority channel assignment could be enabled to use tone identification in decision to prioritize. Rather than frequency only, if the priority channel was defined to have a tone, the channel would not be priority unless both the frequency and tone matched. To do that the channel would have to be assigned to a demodulator already and on subsequent scanner passes the channel could be deprioritized if the tone that was detected and saved in channel metadata does not match the expected filter tone.
It looks like my Family Radio Service (FRS) radio does CTCSS so I thought maybe I could use that for testing the future CTCSS code in ham2mon. But I also see that FRS is NBFM and not WBFM:
https://en.wikipedia.org/wiki/Family_Radio_Service
See "Technical information" at that link.
Based on what I have seen was the thought that CTCSS decoding in ham2mon will be a WBFM function? For my testing do you think it will be valid to use the FRS radio to confirm things are working with CTCSS in ham2mon?
The CTCSS should be able to turn on for any demodulator type of the receiver. The way that CTCSS is used is identical on NBFM and WBFM, and some single sideband (SSB) signals. It is basically identical usage on FRS, GMRS, PMR, Business Band (red/blue/green etc), amateur 2m/70cm and other services. On FRS and GMRS radios you’ll find Privacy Codes or PL function; this is just CTCSS but instead of tone frequencies the radio has codes for the tones. Different brands have different mapping of tone code to tone frequency which is confusing but its just a different way to indicate to the user which tone is being used.
I know this code needed more work on the RF side to verify correct behavior of the filters so I will try to get some time setup to do that.
The CTCSS processing code in branch lordmorgul:ham2mon:wbfm_ctcss_processing was partially tested working, it needs refactored into this fork to work.
It currently does remove the tone from the audio file saved, which is one shortcomings of using ham2mon with tones and picking up repeater inputs or outputs containing tones. The audio file can have loud audible tones in it.
Selective recording of the active channel when a tone is present, and not recording when the tone is not present, is implemented but was not fully functional. More testing of this is needed to verify behavior and make corrections.
Tones should be implemented per defined priority channel; each demodulator would have to include a tone variable that can be changed on the fly as that demodulator is re-assigned to a channel (only if matching a priority channel which has a tone assigned, and cleared if it is assigned to a channel for which no tone is assigned). The current implementation has a single tone selection for the interface and all demodulators use it. That works only for the Use Case 4 repeater monitoring, and does not work for monitoring multiple repeater frequencies.