trunk-recorder
trunk-recorder copied to clipboard
robotastic
Add Support for Digital Coded Squelch
I'm using this software to record some conventional channels. The radio network uses digital coded squelch (DCS) so that receivers don't hear a bunch of non-verbal traffic that is transmitted over the channel (morse code for the station ID, etc.). Unfortunately, using your software, it captures all this non-verbal transmission as well.
What are the chances of getting a feature added that allows us to put a receive squelch code in the config file (usually 3-digit octal), so that it only records audio when the DCS is present?
Thanks!
I looked into this a little while ago and I think it might be possible. I found a project that already implemented most of the code: https://bitbucket.org/holiman/gnuradio-dcs I will add this on to the list of features to add.
Awesome, thanks! One thing to keep in mind: it will have to be able to detect the presence of the DCS even if it appears in the middle of an ongoing transmission (i.e. can't just check once when a new transmission starts, then ignore the rest of the transmission if it doesn't have it).
This along with tone squelch is the would make this an almost competle system for me. Recording the DCS / TSQ values would be very handy. I actually have a frequency that is used by two different departments that are active in the same area, but the 2nd department uses a different tone. So it would be cool if we could setup the system like this ...
"systems": [{
"type": "conventional",
"channels": [151070000: [{"DCS": 071}], 154115000: [{"TSQ": 100.0], 154570000: [{"TSQ": 151.4}]]
}, {
"type": "conventional",
"channels": [460175000: [{"DCS": [315, 243]}], 461175000: [{"DCS": 516}], 467725000: [{"DCS": 043}]]
}]
And the tones that were detected and present within the waveform, it would be perfect if this information also exposed to the outlets (JSON, API, WebSocket).
@robotastic You had mentioned you had looked into this a while back. Any luck with implementing it? It would be an amazing enhancement for conventional systems, so it wouldn't capture all of the unwanted traffic.
While not DCS, it looks like GNURadio does have built in support for CTCSS squelch, so I gave a shot at adding it: https://github.com/robotastic/trunk-recorder/compare/master...CrimeIsDown:ctcss-squelch
So far it's been working pretty well, after spending a while trying to get the correct level value needed by the block. It's configured via the talkgroupsFile for the system, like so:
1,151.4,A,ChiPD Zone10,Police Dispatch Zone 10,Law Dispatch,Police,1
2,110.9,A,ChiPD Zone 3,Police Dispatch Zone 3,Law Dispatch,Police,1
The PL tones are put into the second column of the CSV, then the parser detects the analog mode and sets the tone value. I'm not sure if using the CSV file is the best place to put it, I was thinking about the syntax mentioned above but changing the channels value from a simple array to key-value pairs might be backwards-incompatible.
So, a question to all: what would be your ideal way to specify the CTCSS tone for a frequency?
Interesting! The Talkgroups CSV could use a good redefinition - there are some fields there that are not being used, so not the end of the world if it needs to change. I can also update OpenMHz and finally make them align so it is the same file for both.
Any news/progress on this? CTCSS & DCS decoding and squelch would be quite useful for the conventional systems that I monitor.
Same here. Trying to make Trunk and Rdio-Scanner my goto for everything. CTCSS is my last piece of the puzzle.
A PL/CTCSS squelch/gate already exists in gnuradio, and there's at least one DPL/DCS module (I think already linked here) out of tree.
But as was already covered in this thread, providing PL/DPL support is a lot more than just adding those blocks and conditionally connecting them within analog_recorder. There's the matter of config formatting and parsing:
- as part of the frequency array,
- or as part
talkgroupsFiles as specified earlier, - perhaps with frequency information too, so instead of keying "talkgroups" by index, they're keyed by the file.
Additionally, there's the matter of how to introduce this change as a non-breaking feature, or to bump config format version and treat it as breaking, etc.
Therefore, this issue is effectively blocked (or must be worked in lockstep) on just that: a robust discussion on the future of config handling; as well as the possibility of tooling this in with the new proposed plugins system from last year. Along with the work for adding support for this in, of course.
The last four comments in this issue have been bumps only, with at least another four in the rest of the issue also bumping for this. I don't think there's lack of awareness or a misunderstanding that having PL/DPL support would be a wonderful enhancement to have. Please be mindful of how bumping adds noise to issue threads.
I'll add to the bounty for TCS and DCS.....
On Thu, Feb 17, 2022 at 2:28 AM Steve Myers @.***> wrote:
Is there a way I could start a bounty for this future?
— Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/100#issuecomment-1042649576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3W5JOXHL4X4JAS6ZJQWRDU3SPRJANCNFSM4DCCD3MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
Would post-processing the WAV files to detect CTCSS and DCS content and add it to the JSON data be acceptable, or is gating what's getting recorded in real time needed?
If the wav is "post processed" at the concatenation stage then both could pretty easily be done. Config options would be default all (like now) or specified code(s) only (and discard the rest during concatenation)
For me, actual CTCSS and/or DCS squelch on the recorder itself would be key, so that it can run without a squelch threshold.
On Thu, Feb 17, 2022 at 7:02 PM Andy Knitt @.***> wrote:
Would post-processing the WAV files to detect CTCSS and DCS content and add it to the JSON data be acceptable, or is gating what's getting recorded in real time needed?
— Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/100#issuecomment-1043658118, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADAVQND44ZTKTKHAUBPWQLU3WECVANCNFSM4DCCD3MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
https://app.bountysource.com/issues/42586221-add-support-for-digital-coded-squelch
Nice - yea, it would be great if someone is able to pull something together. I would definitely welcome a solid PR here. I would need help testing it out because I don't have any systems near me that use it.
For those that missed it, there is a fork with CTCSS working in the comments above. I think moving the config for the CTCSS from the talkgroups.csv file to the config.json file as @Dygear suggests probably makes sense. So CTCSS is doable, just needs some work to tidy it up and get a PR in. DCS may be tougher. The bitbucket repository linked above for DCS in gnuradio is no longer active. I've emailed the author to see what the status is. I did a DCS decoder a long time ago (in LabView of all things?!) but I don't remember any of it, I'd have to do a lot of memory refreshing. And I'm not yet competent in gnuradio. Its feature set seems to largely consist of raising my blood pressure at the moment, but I'm trying :-)
DSC block for gnuradio is now here:
https://github.com/holiman/gr-dcsinfo
I believe this just reports the detected code, so more work would need to be done to use it to gate audio.
Question - Could we add the tone info as a field in the "talkgroup" file? I was thinking of creating a custom format that would just be for conventional channels. That would keep the info out of the config file. #630
I would still prefer an option for detecting the tone and not gating on it. Another common scanner feature is to gate on any tone but not none.
There are a few issues in the area I am in where it is 90% conventional analog (with some p25 sprinkled in). In a lot of cases we are stuck with around 240 T-Band channels which are closely split between cities and towns in a region. It's not odd to be in areas where these overlap - making the need for tone detect like this to work properly while being recorded. For example - I might want agency A on frequency A. Agency B shares Frequency A. Agency B starts talking - however - let's say they are heard at -100dbm. Agency A is at -75dbm shows up mid transmission - I'm more concerned about the voice traffic for Agency A than I am for B. If the detection / gate isn't done right and at the time of recording (I'm thinking of how a radio uses COR w/PL/DPL) it had mixed audio - then the feature is not going to work right. Hopefully I explained this right - as a consumer of the application I would only care about Agency A in this case - and would not care about B (and more so because the signal might not be as good where I am).
Couldn't we just start a new call if the recorder detects a change in PL/DPL?
Over in https://github.com/robotastic/trunk-recorder/pull/630, I'm trying to imagine a future where conventional channels can be organized into "virtual talkgroups" for the purpose of meta-data and handling. Instead of strictly gating the channel, I'm kinda partial to letting the recorder record everything, and then using some analogous method to the trunked side to figure out if the call should be ignored.
Like in the example above, a theoretical conventional.csv like this could tell TR to only record the call if it catches a certain tone.
TG, FREQ, TONE, ALPHA, Description, Tag, Group, Record?
300, 462275000, 94.8 PL, Town A Police, Town A Police Dispatch, Police, Town A, True
325, 462275000, 151.4 PL, Town B DPW, Town B Trash Dispatch, DPW, Town B, False
350, 462275000, CSQ, Town A, Town A No Tones, -, Town A, False
Taclane has probably the most correct answer here, with that csv file format. Flexibility being the goal where as I might want to ignore getting audio without a PL / DPL tone attached to it, it's entirely valid that other people would want that. Or at least for that information to propagate for the rest of the interfaces to have an option of handling it.
@taclane - hmm... I really like this approach, but I will have to see if something like this could work. The way things are currently setup is quite a bit different. There is a basic hierarchy of System -> Call -> Recorder -> Wav sink. Each Call is dedicated for specific Talkgroup. This works fine now a Conventional system where the Call / Recorder stay on a single freq, and the TG is just that "Channel".
For approaches, it might be possible to have the recorder "reset" the call it is under. This would change the Talkgroup for the call and also start a new .wav file.
Question on Tones - are they unique for each frequency, or would you want a Tone.csv file? Would the 94.8 PL tone only be Town A Police on 462275000 or would it also be the same police on 463000000?