Skip to content

Add CTCSS decoder and alias support#2344

Closed
msullivan1993 wants to merge 2 commits intoDSheirer:masterfrom
msullivan1993:feature/ctcss-alias
Closed

Add CTCSS decoder and alias support#2344
msullivan1993 wants to merge 2 commits intoDSheirer:masterfrom
msullivan1993:feature/ctcss-alias

Conversation

@msullivan1993
Copy link

  • Adds CTCSS/PL decoder to SDRTrunk
  • Detects all 43 standard CTCSS tones (67.0-254.1 Hz)
  • Uses Goertzel algorithm for efficient detection
  • Integrates into existing alias system used by DCS for streaming

Full disclaimer.. most of this work was done by Claude Opus. I am not a coder by any stretch of the word. Tested extensively on my personal server with no issues with send to Rdio Scanner server. Unknown if any changes need done for Calls, OpenMHz, etc.

@someengineer1
Copy link

Awesome to see, unfortunately I'm not in a position to test this yet (I had moved to trunk recorder for everything and not running a DE in linux). But will try to get some time to test it out. Would be awesome if this makes it into 0.6.2.

@msullivan1993
Copy link
Author

Awesome to see, unfortunately I'm not in a position to test this yet (I had moved to trunk recorder for everything and not running a DE in linux). But will try to get some time to test it out. Would be awesome if this makes it into 0.6.2.

So far I have had no issue using a test build with this and the NAC aliasing. However I still have the issue of it capturing audio in the entire clip (IE distant P25 channel operating, then analog traffic comes up, so you still hear digital audio in the voice clip) so while snowmageddon is going on, I'm gonna play a bit with Claude and either A. Add the ability to trim and only record when alias is matched, or B. add PL, and while I'm at it DPL NAC and CC as channel filters, so it only captures audio when squelch and tone both match.

I'm no coder, but if my utility bills are going to pay for power for these datacenters being put in.. by god I'm gonna put them to use! lol

@someengineer1
Copy link

My setup is pretty simple, I have conventional P25 frequencies and totally separate conventional analog with CTCSS/PL tones. I'm not familiar with the issue you're referencing but I also haven't been following the updates since 0.6.1 too closely.

0.6.1 actually worked pretty much perfectly for me, the P25 decoding on my simulcast system was superior to trunk recorder, but eliminating the static bursts on the analog frequencies was more important. Have you tried your code with the latest nightly or only against the master/0.6.1?

@msullivan1993
Copy link
Author

My setup is pretty simple, I have conventional P25 frequencies and totally separate conventional analog with CTCSS/PL tones. I'm not familiar with the issue you're referencing but I also haven't been following the updates since 0.6.1 too closely.

0.6.1 actually worked pretty much perfectly for me, the P25 decoding on my simulcast system was superior to trunk recorder, but eliminating the static bursts on the analog frequencies was more important. Have you tried your code with the latest nightly or only against the master/0.6.1?

I built it off the latest master build, so it has all the features of the Nightly like the new NBFM squelch control (MASSIVE difference) and new P25 decoder. I had a couple other people test my test build so far, one did something combining some files from the old P25 decoder because they were having some issues with P25 but I have no idea what they were having issues with. I've not had any issues with P25 but DMR has been acting odd for me.

Decoding-wise everything seems to be doing fine but, again if a WVSIRN voice channel is active on the same frequency, you'll hear the raw data from that then the analog audio, and that's just annoying me.

@someengineer1
Copy link

I built it off the latest master build,

Ah, ok, I'm not great at Github so I was thinking that was the release (0.6.1) and not nightly, but makes sense. I'm a hardware guy with just enough knowledge to figure out software. Going to try and get a chance to get an old laptop set up to test this out. All my frequencies are either analog or digital with just a single thing on each (well except a Motorola Smartnet which obviously I use different software for) so shouldn't have any issues with the interference.

Now I just have to get google to remind me how to compile a java app.

@Randesign
Copy link
Contributor

Randesign commented Jan 31, 2026

I'm testing this and it's not working as expected. I'm running your most recent code as of 31-Jan-2026 which includes all of your commits to date.

While the CTCSS decoding appears to accurately decode the PL tone, I'm not able to get it to squelch audio that doesn't match the tone. For example if I set a tone of 110.9 to a channel that is receiving a tone of 179.9, the audio is still present. I expect it to be muted like it would on a traditional scanner radio. I've tried switching Require Alias Match on the channel tab and it doesn't seem to make a difference.

There are also some GUI issues.

The first is that when adding a tone identifier to an alias, it's grabbing a value from somewhere else and pre-populating the dropdown field, but it's stating just above it that it's invalid and no tone selected. I have to select a different tone, then select my desired tone again.

Screenshot from 2026-01-31 14-40-22

The next GUI issue is looking at the Now Playing window.

I'm not sure what your intention is for what is supposed to be displayed, but it's displaying an alias from a unrelated channel in the From column.

Screenshot from 2026-01-31 16-02-47

And perhaps the CTCSS tone should be logged to the Event tab below it for trouble shooting purposes.

@msullivan1993
Copy link
Author

I'm testing this and it's not working as expected. I'm running your most recent code as of 31-Jan-2026 which includes all of your commits to date.

While the CTCSS decoding appears to accurately decode the PL tone, I'm not able to get it to squelch audio that doesn't match the tone. For example if I set a tone of 110.9 to a channel that is receiving a tone of 179.9, the audio is still present. I expect it to be muted like it would on a traditional scanner radio. I've tried switching Require Alias Match on the channel tab and it doesn't seem to make a difference.

There are also some GUI issues.

The first is that when adding a tone identifier to an alias, it's grabbing a value from somewhere else and pre-populating the dropdown field, but it's stating just above it that it's invalid and no tone selected. I have to select a different tone, then select my desired tone again.
Screenshot from 2026-01-31 14-40-22

The next GUI issue is looking at the Now Playing window.

I'm not sure what your intention is for what is supposed to be displayed, but it's displaying an alias from a unrelated channel in the From column.
Screenshot from 2026-01-31 16-02-47

And perhaps the CTCSS tone should be logged to the Event tab below it for trouble shooting purposes.

I noticed this as well. I was working on a fix that adds Alias Matching (tone squelch, basically) but it kind of broke decoding for me on a few PL's when I shortened the block time up, I haven't had a chance to roll back the changes since I've been in bed the last few days sick (I've been using a test build that was before those changes)

I'll probably work on it tonight and see if I can get it to work better. Again, I'm no coder, most of the work is being done with Claude AI, but this takes some load off Dennis and fixes known issues that I and others have had.

As for the GUI.. yes, I saw that too, but if you go to another PL and back, it selects just fine. Probably a bug that's been there since Dennis added DPL originally. I'll try to make a fix for that too while I'm at it.

As for the non-matching alias.. since you have everything in one Alias list, it's grabbing an alias that matches that PL. The only fix I found for that was that I had to create separate Alias lists for each individual channel (royal PITA I know) since the Alias list appears to be not an "AND" function, more of an "OR" function (it will pass audio to that TG with any of the added aliases) it does make it difficult. (Maybe add that as a pull request too? That might fix it)

I considered adding this as a channel decode feature as well, just haven't started working on it yet. I might do that as well so there is both options.

@Randesign
Copy link
Contributor

I noticed this as well. I was working on a fix that adds Alias Matching (tone squelch, basically) but it kind of broke decoding for me on a few PL's when I shortened the block time up, I haven't had a chance to roll back the changes since I've been in bed the last few days sick (I've been using a test build that was before those changes)

I'll probably work on it tonight and see if I can get it to work better. Again, I'm no coder, most of the work is being done with Claude AI, but this takes some load off Dennis and fixes known issues that I and others have had.

As for the GUI.. yes, I saw that too, but if you go to another PL and back, it selects just fine. Probably a bug that's been there since Dennis added DPL originally. I'll try to make a fix for that too while I'm at it.

As for the non-matching alias.. since you have everything in one Alias list, it's grabbing an alias that matches that PL. The only fix I found for that was that I had to create separate Alias lists for each individual channel (royal PITA I know) since the Alias list appears to be not an "AND" function, more of an "OR" function (it will pass audio to that TG with any of the added aliases) it does make it difficult. (Maybe add that as a pull request too? That might fix it)

I considered adding this as a channel decode feature as well, just haven't started working on it yet. I might do that as well so there is both options.

I have never used the DCS decoder (there is nothing around here that uses it), so I'm not familiar with the signal flow and associated logic.

It seems to me that the Alias is the best place to set the tones as opposed to Channel. There are cases here where the US Forest Service operates a half dozen repeaters on the same VHF frequency, with each repeater using a different PL tone. Ideally I'd only want to monitor/record two of those repeaters, so I guess setting up 2 different aliases would be the approach. Those two aliases would be in the same alias list.

I see the problem with trying to keep the logic flow similar to a trunked radio system. It would probably necessitate separate alias lists with each channel. On the other hand, one needs to assign a NBFM channel to a unique talkgroup so it seems like a collection of channels is acting like a virtual trunked radio system feeding a single alias list. I haven't looked at the code, so I don't know what the best approach would be without causing a massive re-write to the logic.

@msullivan1993
Copy link
Author

I noticed this as well. I was working on a fix that adds Alias Matching (tone squelch, basically) but it kind of broke decoding for me on a few PL's when I shortened the block time up, I haven't had a chance to roll back the changes since I've been in bed the last few days sick (I've been using a test build that was before those changes)
I'll probably work on it tonight and see if I can get it to work better. Again, I'm no coder, most of the work is being done with Claude AI, but this takes some load off Dennis and fixes known issues that I and others have had.
As for the GUI.. yes, I saw that too, but if you go to another PL and back, it selects just fine. Probably a bug that's been there since Dennis added DPL originally. I'll try to make a fix for that too while I'm at it.
As for the non-matching alias.. since you have everything in one Alias list, it's grabbing an alias that matches that PL. The only fix I found for that was that I had to create separate Alias lists for each individual channel (royal PITA I know) since the Alias list appears to be not an "AND" function, more of an "OR" function (it will pass audio to that TG with any of the added aliases) it does make it difficult. (Maybe add that as a pull request too? That might fix it)
I considered adding this as a channel decode feature as well, just haven't started working on it yet. I might do that as well so there is both options.

I have never used the DCS decoder (there is nothing around here that uses it), so I'm not familiar with the signal flow and associated logic.

It seems to me that the Alias is the best place to set the tones as opposed to Channel. There are cases here where the US Forest Service operates a half dozen repeaters on the same VHF frequency, with each repeater using a different PL tone. Ideally I'd only want to monitor/record two of those repeaters, so I guess setting up 2 different aliases would be the approach. Those two aliases would be in the same alias list.

I see the problem with trying to keep the logic flow similar to a trunked radio system. It would probably necessitate separate alias lists with each channel. On the other hand, one needs to assign a NBFM channel to a unique talkgroup so it seems like a collection of channels is acting like a virtual trunked radio system feeding a single alias list. I haven't looked at the code, so I don't know what the best approach would be without causing a massive re-write to the logic.

That's why I had considered doing both. I have a select few channels that use different PL's on output but they're few and far between.

Yes, you'll probably need to do the separate alias lists regardless for your configuration, and use the Stream as Talkgroup to send where needed.. and I hate it too, but doing it that way I've had no issues other than the excess captured radio traffic, and that's what I'm hoping to work on tonight.

@Randesign
Copy link
Contributor

@msullivan1993 Are you still working on this? I'm thinking of writing my own version of the CTCSS implementation.

@msullivan1993
Copy link
Author

@msullivan1993 Are you still working on this? I'm thinking of writing my own version of the CTCSS implementation.

Yes, I finally got around to working on it tonight. Just made a new PR #2380 to combine this and channel-level CTCSS into one PR.

closing this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants