Stopping recording when talk group changes on voice channel

[rosecitytransit]

A while back, I think they changed the configuration on the radio system I monitor and now there's sometimes very little time between calls on the same frequency. As a result, both calls sometimes recorded into one file (the second call also correctly gets its own recording). I made a waterfall heatmap using heatmap.py and highlighted a couple examples of it happening. The numbers correspond to calls here.

Note that I keep calls open through the post-voice TDU, etc frames because I prefer to keep conversations together rather than record by transmission (so it's easier to find interesting stuff) and since the unit-unit calls don't correctly continuously show on the control channel like they probably should.

I see there's #564 and #626 but I'm wondering if it would instead be possible to stop recording based on checking the talk group in the voice channel metadata.

Specifically, I'm wondering if it would be possible to get the talk group from the call into p25p1_fdma.cc to compare with grpaddr and block processing if they don't match (e.g. prevent the process_voice(A); that happens right after that process_LCW section happens.

trunk-recorder/lib/op25_repeater/lib/p25p1_fdma.cc

Line 464 in 5d3da98

uint16_t grpaddr = (lcw[4] << 8) + lcw[5];

I know one option would probably be to add a talk group field to rx_status like I added last_update.

Also, the ideal would be that a call with the new talk group is searched for/set up, in case a control channel message for it is missed.

Thanks!

[robotastic]

I would check out the current version of TR and maybe try the no-overlap branch. The current approach is to use TDUs to separate the transmissions, but keep them joined together in a conversation. I tried also to use the SRC / GRP ID from the voice channel, but it is either sent out weird, decoded wrong on SmartNET digital channels, and it resulted in transmissions started and stopping weird places.

The call control has changed a bit too. The block that recorder wav files now handles keeping track of each of the transmissions. The same info can be passed along as TAGs, the way src_id and TDUs are being handled.

[rosecitytransit]

Thanks for responding! It is true that I haven't touched things in quite a while and am still using v3.3, though I am starting to play with the current version and am willing to upgrade.

Do you know of a good way to get the call talk group into p25p1_fdma.cc so I can try doing this myself? Should I just use rx_status? I know that given your shift to recording by transmission, this may something just for me (and anyone else who finds it).

Also, given your last comment on #564, is the voice channel processing (for at least P25) still slower than control channel processing? If they're pretty much in sync, or at least the voice processing has reached the TDUs hang time, you could just immediately end the call when the frequency reuse is seen.

[rosecitytransit]

An update: the talk group does appear to be decoding correctly on the voice channel. When I turn on OP25 debugging*, I get (excerpted):

[2022-03-08 04:15:19.555316] (debug)   tsbk00	Chan Grant	Channel ID:   489	Freq: 772.056250 MHz	ga    1761	TDMA -1	sa 217	Encrypt 0	Bandwidth: 12.5
03/08/22 04:15:20.042086 [0] NAC 0xe27 LDU1: LCW: ec=0, pb=0, sf=0, lco=0 : 00 00 00 00 06 e1 00 00 d9, srcaddr=217, grpaddr=1761
[2022-03-08 04:16:12.146132] (debug)   tsbk00	Chan Grant	Channel ID:   489	Freq: 772.056250 MHz	ga    1769	TDMA -1	sa 21218	Encrypt 0	Bandwidth: 12.5
03/08/22 04:16:13.727038 [0] NAC 0xe27 LDU1: LCW: ec=0, pb=0, sf=0, lco=0 : 00 00 04 00 06 e9 00 52 e2, srcaddr=21218, grpaddr=1769
[2022-03-08 04:18:01.156451] (debug)   tsbk00	Chan Grant	Channel ID:   489	Freq: 772.056250 MHz	ga    1765	TDMA -1	sa 22207	Encrypt 0	Bandwidth: 12.5
03/08/22 04:18:02.302323 [0] NAC 0xe27 LDU1: LCW: ec=6, pb=0, sf=0, lco=0 : 00 00 04 00 06 e5 00 56 bf, srcaddr=22207, grpaddr=1765

This is using the current master branch and GNU Radio v3.8.3.1-16-g9d94c8a6 (I do plan to upgrade that when I upgrade trunk-recorder, as well as try the no-overlap branch). I see I'll need additional cases for unit-unit call LCOs.

*by setting this to 10 here (ideally this would be connected to the config, or the fprints would be switched to Boost logging):

trunk-recorder/trunk-recorder/recorders/p25_recorder_decode.cc

Line 89 in 36aae6b

int verbosity = 0; // 10 = lots of debug messages

[rosecitytransit]

Well, I've been trying out the no-overlap branch, and it seems to address the issue without any loss of (not-yet-processed) audio. So I'll work on upgrading, say thank you for having the branch and go ahead and close this.

Actually there has been one case where back-to-back calls (but same talk group as well as frequency) were recorded separately on the version I'm using but together with the no-overlap branch. But that's not that bad and I can maybe address that.

[robotastic]

that's awesome to hear.... I will go work on getting this branch merged in

[rosecitytransit]

Well, now the issue I have is that when I turn on my fix for keeping calls open until they actually end (by uncommenting the section here:

trunk-recorder/trunk-recorder/call.cc

Lines 370 to 379 in 9e3e1f5

	int Call::since_last_update() {
	/*long last_rx;
	if (get_recorder() && (last_rx = recorder->get_rx_status().last_update)) {
	BOOST_LOG_TRIVIAL(trace) << "temp.last_update: " << last_rx << " diff: " << time(NULL) - last_rx;
	return time(NULL) - last_rx;
	//last_update = temp.last_update;
	} else {*/
	BOOST_LOG_TRIVIAL(trace) << "last_update: " << last_update << " diff: " << time(NULL) - last_update;
	return time(NULL) - last_update;
	//}

) radio IDs don't get saved (as in only ever one entry in the JSON srcList object). I've tried making some changes to p25p1_fdma.cc but have not found a workable solution. I know it may be due to the shift to recording by transmission and call concluder changes.

While I would kind of like to upgrade, I know one idea would be to just back port the no-overlap commit to the version I'm using now.

Edit: I've switched back to playing with the master branch (as of eae2fa9), turned on the workaround above and it seems like it may be working. It even stopped recording on talk group change (got Stopping call because of overlapping Freq and Call completed - putting recorder into state Completed - we had samples messages). Going to let it run and see how it goes.

[rosecitytransit]

I might partially implement this and do a PR by tracking changes of the source and group within OP25, even if not connected to the ones in the call object/on the control channel