Two Tone Sequential Detection

[Dygear]

In an effort for the general detection of tones from multiple vendors (General Electric's Type 99 or Motorola's Quik-Call I and Quik-Call II), I propose the following. As these systems use either a single tone, or sequential tones for a defined length of time supporting all of them generically should look something like this.

"channels": [154115000: [{"TTS": [{"len": 1000, "tone": 1122.5}, {"len": 2000, "tone": 1395}]}]]

• TTS - Two Tone Sequential
  • len - Length of Tones in Milliseconds
  • tone - Tone to detect in Hz.

My comment on #100 follow the same format for the channel array.

[lightstormdev]

Great feature to add. We also broadcast the tones on P25 trunked system. So having the ability to detect the tones on the P25 trunked system is beneficial.

Is the TTS analyzing the recorded wav file after its recorded?

I would like this array to be similar to how talkgroups are looked up. CSV file containing Name, Tone A, Tone B. Our system currently had about 15-20 toneout per frequency.

[Dygear]

I'd prefer that the tone analysis to be done while the audio is being demodulated so it can be placed within the JSON / WebSocket / API information. I didn't think the P25 uses audible tones, my understanding was this was done at the protocol level.

My reason for making it apart of the channels array, and making it "subordinate" to the channel it's on is to make for a more efficient tone parser. Where it only has to look for the following tones on this frequency.

[johann8384]

P25 doesn't use audible tones, but some of us using P25 transmit audible tones for....reasons...

[vabiro]

I'm getting the impression that there are systems that - despite "...reasons..." continue to use audible tones over P25 to identify radios. This is probably to accommodate legacy systems. This sounds - pardon the pun - like an easy way to work with those systems, Being P25 police is not what the application does. After all, we are trying to monitor the system rather than build them.

[johann8384]

Yeah, that's what I was trying to say, we are still broadcasting the tones for various reasons. One of them is that fire department dispatches still happen on VHF pagers so we have patches to VHF from talkgroups to the FD repeaters for those.

[kg6uyz]

The p25 radio system I maintain utilizes analog channels patched to talkgroups for cross mode interoperqbility. We page on the analog side of that patch for the fire departments, tones dont go out on digital. Though we have the capability to have those tones go out the trunked talkgroup should we need them to.

Motorola has released a new feature that allows digital two tone decode on a p25 talkgroup.

On Thu, Sep 6, 2018, 11:20 Jonathan Creasy notifications@github.com wrote:

Yeah, that's what I was trying to say, we are still broadcasting the tones for various reasons. One of them is that fire department dispatches still happen on VHF pagers so we have patches to VHF from talkgroups to the FD repeaters for those.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/141#issuecomment-419193285, or mute the thread https://github.com/notifications/unsubscribe-auth/AcyLzHO3MGOTukRtfU9K7V3XJAHePaWrks5uYWdrgaJpZM4P50vh .

[mikewren]

Hi all - I am also very interested in this functionality. Both for kicking off shell scripts based on the presence of specific tones, and also for potentially muting or editing the resultant wav file to omit tones.

Maybe a bounty/reward might help kickstart this feature? :)

[Dygear]

Especially now that TTD was bought by IAmResponding.

[ZeroChaos-]

I'd love to necromance this issue. If anyone has a place I can add to a feature bounty, I will gladly do that. Honestly I can't even seem to do two tone decoding in linux at all and it would be a great feature in my mostly analog area

[leee]

The only bounty/reward that I'm aware of that trunk-recorder has participated in is the Broadcastify Calls one.

If you wish to donate to the principal, and find trunk-recorder useful or meaningful in some way, you should absolutely sponsor robotastic on GitHub. This obviously holds no contract for completion of tasks and projects, but as said here:

Sponsorship will help keep me focused on maintaining Trunk Recorder and also encourage me to build an updated version. Having "Customers" will create a good feeling of obligation.

🙂

Contributions are always welcome of course! QCII detection (and in general, PL detect) shouldn't require full FFT or audio event detection. An efficient technique for computing single bin DFT would be the Goertzel algo. I think something like this might be better done in post-processing (as in uploadScript), but if you really wanted to do this within trunk-recorder, gnuradio provides gnuradio/fft/goertzel.

An "extension" of this problem could also be true audio event detection of console tones, but some of these tones get a lot more complex than just Alert Tone 1 (straight tone). Console tone SED could turn into an interesting ML project, especially to make it small-footprint/low-power.

[robotastic]

Good question on how to get this solved. I am fully supportive!! ... but don't know much about Tones and how to detect them. The good news, is that with v4.0, the WAV file sink can now capture metadata information about a call transmission being recorded and pass it to be written into the JSON file. This means that could pass the final analog & digital audio through some sort of detector and write that to the JSON.

What would be really helpful, is if someone could find a good Gnuradio based example of taking in audio with a tone and having it decode the correct info from it. I think I should be able to work that example code into Trunk Recorder pretty easily. I would then need some help with testing and debugging, since I don't have anything nearby.

No donations needed for me to work on this... more a function of finding someone with the skill and background to put together a rough POC.

[Dygear]

I can probably do that. I’ll dust off my GNURadio install and see what I can bake up.

Sent from my iPhone

On Sep 1, 2021, at 22:34, Luke Berndt @.***> wrote:

 Good question on how to get this solved. I am fully supportive!! ... but don't know much about Tones and how to detect them. The good news, is that with v4.0, the WAV file sink can now capture metadata information about a call transmission being recorded and pass it to be written into the JSON file. This means that could pass the final analog & digital audio through some sort of detector and write that to the JSON.

What would be really helpful, is if someone could find a good Gnuradio based example of taking in audio with a tone and having it decode the correct info from it. I think I should be able to work that example code into Trunk Recorder pretty easily. I would then need some help with testing and debugging, since I don't have anything nearby.

No donations needed for me to work on this... more a function of finding someone with the skill and background to put together a rough POC.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ZeroChaos-]

Tone detection (including the requested tone tone but also ctcss) can be detected fairly easily with a little audio processing knowledge. Tones are quite literally just a solid audio tone for a set amount of time. Two tone signals are two solid tones, one after another, and I think "five tone" systems are the same but with 5. The only difference between ctcss detection and tone detection is that ctcss is below the highpass filter that most sane systems are using while the two and five tone signaling are not.

A really base intro is here for anyone who wants it http://genave.com/two-tone-paging/

The intro also covers some other systems which are used in other parts of the world, some of which are already covered by multimon-ng

[aaknitt]

Fidelity of tones sent over a P25 system will vary greatly depending on the vocoder used by the transmitter. Older vocoders treated tones no differently than voice, resulting in pretty bad tone distortion. AMBE+ codecs that are now in use will detect tones in the incoming analog transmit audio stream and treat them differently in how they get encoded. The receiver using the same codec will then synthesize the analog tone itself for use in the receive audio stream. Based on this thread it looks like the boatbod OP25 fork should support reception of the newer codecs' method of encoding tones.

All that is to say that even if trunk-recorder were to implement audio tone detection it may not work well on systems still using the older vocoders.

OP25 feeding the paging talkgroup audio to TTD should work if the transmitter is using the newer vocoders, though I haven't tried this since the P25 system I monitor doesn't do 2-tone paging on it.

[ZeroChaos-]

While this is a good point for older digital systems, most of the systems that use two/five tone paging are analog afaik.

[dboune]

I work with a non-profit project called Watch Duty. We are working on a project involving rpi + trunk recorder, and we work with analog systems most often in what we do. We want to incorporate two-tone detection. It looks like we will be able to do this using the WAV sink as described above, but it would be wonderful if that were built into trunk-recorder. This comment is just a show of support for this feature. If possible we will try to contribute something in one way or another.

[aaknitt]

I work with a non-profit project called Watch Duty. We are working on a project involving rpi + trunk recorder, and we work with analog systems most often in what we do. We want to incorporate two-tone detection. It looks like we will be able to do this using the WAV sink as described above, but it would be wonderful if that were built into trunk-recorder. This comment is just a show of support for this feature. If possible we will try to contribute something in one way or another.

For now, you can use the simplestream plugin of trunk-recorder to send "live" audio (not a pre-recorded WAV file) from selected talkgroups or conventional channels to pulseaudio, which can then feed the audio into an external two-tone decoding program like TwoToneDetect or FD Tone Notify.

Documentation on how to send audio from the simplestream plugin to pulseaudio can be found here.

It's a bit of hair-pulling to get it all working initially, but it's been done successfully.

[dboune]

@aaknitt Thank you Andy! I'll check that out. I hadn't seen FD Tone Notify so I appreciate the mention.

[tdduarte]

Can this work with “zello work” the paid ver of zello?

-Tony

On Sep 11, 2022, at 6:23 PM, Andy Knitt @.***> wrote:

 I work with a non-profit project called Watch Duty. We are working on a project involving rpi + trunk recorder, and we work with analog systems most often in what we do. We want to incorporate two-tone detection. It looks like we will be able to do this using the WAV sink as described above, but it would be wonderful if that were built into trunk-recorder. This comment is just a show of support for this feature. If possible we will try to contribute something in one way or another.

For now, you can use the simplestream plugin of trunk-recorder to send "live" audio (not a pre-recorded WAV file) from selected talkgroups or conventional channels to pulseaudio, which can then feed the audio into an external two-tone decoding program like TwoToneDetect or FD Tone Notify.

Documentation on how to send audio from the simplestream plugin to pulseaudio can be found here.

It's a bit of hair-pulling to get it all working initially, but it's been done successfully.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.