robotastic
Calls combining
I see mention of this issue with regular P25 I/II and looks like it may have been resolved for that.
But with both Conventional P25 (single frequency, no control channel) and smartnet (trunk with control channel and analog voice channels), calls rely solely on the calltimeout value and do not segment when the Unit ID changes. Interestingly, the metadata/json output does swap the unit id mid-recording, so it is recognizing the change in Unit ID.
This also happens on conventional analog using a CTCSS "tone". Not as surprising here, but I was under the impression that CTCSS should allow for detection of when the transmitting source changes, and possibly even have a unit ID of some sort embedded.
I mentioned this on the discord, but figured I'd log it as an actual issue. This may also relate to some of the issues I see with people talking about different talkgroups getting merged into one call on smartnet too. I haven't seen that particular issue but I'm only monitoring a few talkgroups on smartnet and only one of them is heavily active.
With smartnet, you'd think the "GRANT" (and possibly "UPDATE") control messages would be used, but it could even just use the unit ID.
Other software I've used previously (SDRTrunk for Conventional P25 and Unitrunker for Smartnet) both split up the call every time the unit ID changes.
Not sure how big or little of a deal this would be to implement, and/or if this is a bug or just a limitation?
I've improved it by setting the conventional P25 and analog calltimeout to 0, but they still merge quite a few calls when the other party is quick to respond. With smartnet, anything below 1 on the calltimeout results in calls getting heavily fragmented, so I've got a second instance of TR running that system with timeout 1.
Here are a couple examples of combined call logs. You can see TR distinguishes the two calls and the length of each, but they are sent as a single recording. It even knows that call 2 started at position 4.32 which is when the first call ended. So I guess if the talkgroup never changes (as is the case with P25 conventional) it won't split the calls even though the unit ID changes? This is with the calltimeout set to 0.
Example 1 (P25 Conv) Mar 24 05:50:25 scanner trunk-recorder[12308]: [2025-03-24 05:50:25.004378] (info) [Police] 0C TG: 1 Freq: 470.587500 MHz - Transmission src: 336 pos: 0.00 length: 4.32 errors: 4 spikes: 1 Mar 24 05:50:25 scanner trunk-recorder[12308]: [2025-03-24 05:50:25.004503] (info) [Police] 0C TG: 1 Freq: 470.587500 MHz - Transmission src: 12 pos: 4.32 length: 1.44 errors: 2 spikes: 1 Mar 24 05:50:25 scanner trunk-recorder[12308]: [2025-03-24 05:50:25.004992] (info) [Police] 2C TG: 1 Freq: 470.587500 MHz Starting P25 Recorder Num [0] TDMA: false Slot: 0 QPSK: true Mar 24 05:50:25 scanner trunk-recorder[12308]: [2025-03-24 05:50:25.027339] (info) [Police] 0C TG: 1 Freq: 470.587500 MHz Rdio Scanner Upload Success - file size: 38399
Example 2 (P25 Conv) Mar 24 05:52:51 scanner trunk-recorder[12308]: [2025-03-24 05:52:51.001088] (info) [Police] 4C TG: 1 Freq: 470.587500 MHz - Transmission src: 333 pos: 0.00 length: 2.34 errors: 3 spikes: 1 Mar 24 05:52:51 scanner trunk-recorder[12308]: [2025-03-24 05:52:51.001190] (info) [Police] 4C TG: 1 Freq: 470.587500 MHz - Transmission src: 12 pos: 2.34 length: 0.72 errors: 90 spikes: 7 Mar 24 05:52:51 scanner trunk-recorder[12308]: [2025-03-24 05:52:51.001435] (info) [Police] 5C TG: 1 Freq: 470.587500 MHz Starting P25 Recorder Num [0] TDMA: false Slot: 0 QPSK: true Mar 24 05:52:51 scanner trunk-recorder[12308]: [2025-03-24 05:52:51.018282] (info) [Police] 4C TG: 1 Freq: 470.587500 MHz Rdio Scanner Upload Success - file size: 22159
Here is an example for Smartnet. This one had a call from a car and a response from dispatch, but it only recognized the unit ID of the car and kept it for the whole time. It didn't see the change, even though there was a control message in there changing it. On this system I have calltimeout set to 1 since any less and it fragments calls.
Mar 24 05:57:16 scanner trunk-recorder[11958]: [2025-03-24 05:57:16.916525] (info) [State] 30C TG: 33200 Freq: 856.962500 MHz Starting Analog Recorder Num [0] Squelch: -60 Max Dev: 5000 Gain: 2.54648 Mar 24 05:57:27 scanner trunk-recorder[11958]: [2025-03-24 05:57:27.010889] (info) [State] 30C TG: 33200 Freq: 856.962500 MHz Concluding Recorded Call - Last Update: 3s Recorder last write:2 Call Elapsed: 11 Mar 24 05:57:27 scanner trunk-recorder[11958]: [2025-03-24 05:57:27.011340] (info) [State] 30C TG: 33200 Freq: 856.962500 MHz - Transmission src: 55042 pos: 0.00 length: 8.99 Mar 24 05:57:27 scanner trunk-recorder[11958]: [2025-03-24 05:57:27.063065] (info) [State] 30C TG: 33200 Freq: 856.962500 MHz Rdio Scanner Upload Success - file size: 112534