Newest Version Continues to Fumble UIDs

[Dewey3]

This is a continuation from https://github.com/robotastic/trunk-recorder/issues/760, which I hope is ok to re-open here since the original is now so far down the list. (If it is a problem, my sincerest apologies and I will delete this issue) Anyway, I just finished building

Trunk-Recorder: 4.6.0
commit 767455ba297292ec563676d319c80f9f213f5f67 (master)
describe LTS-219-g767455b
Author: tadscottsmith <78445808+tadscottsmith@users.noreply.github.com>
Date: 2023-07-12 11:49:39 -0400
Include TDMA slot number in transmission_sink(). (#835)

and believe it or not, it is still missing the transmitting UIDs when transmissions are right behind each other. What happens is that while the conversation itself continues fine, the UID does not change, but continues to show the first/prior UID. The last time the UID changes worked correctly on the very busy Prince George's Co, MD system (https://www.radioreference.com/db/sid/6341) was version

Trunk-Recorder: 4.3.2
commit 10a276385124ef48e7ad6a3493236082c360ec0e (master)
describe 2.1.2-1474-g10a2763
Author: Luke Berndt <lukekb@gmail.com>
Date: 2022-09-15 22:19:36 -0400
Update README.md

when @tadscottsmith figured out the problem, and contributed a fix. While I will try the new updates every few releases, I still run the 9/15/2022 v4.3.2 version since it correctly keeps up with the UIDs no matter how busy the system. Please don't take this as a complaint as I can keep running the 9/15/2022 v4.3.2 as I do now, but I just want those on the coding side to know that I still see this issue. I'm sorry that I can't do more in helping solve it, but the coding and understanding the code parts are well above my feeble brain.

[robotastic]

Thanks for capturing this - the good news is that I can sort of receive the PGC system in DC, so I can try doing some debugging.

[theficus]

I can help verify any fixes here as well. The system I scan here in Seattle is also P25P2 and is super busy (I have to run 16 recorders just to keep up). I've also observed similar behavior.

[tadscottsmith]

Can someone grab like 30 seconds of I/Q recording where this is happening? I can look some more, but don't have access to a P25P2 system.

[Dewey3]

Can someone grab like 30 seconds of I/Q recording where this is happening? I can look some more, but don't have access to a P25P2 system.

I don't know how to create/generate an IQ file, but willing to try to if given the steps. I can also install the latest TrunkRecorder and open up the RPi for testing the way you did last time if that is better, or at least helps.

[xmleger]

Not sure if this is related to a similar behavior that I have been seeing with my analog trunking (Smartnet) and analog conventional channel systems. They seem to capture the source (UID) info for the first transmitting unit, but none of the following source data is listed in the json for additional unit transmissions on that same audio capture file. The P25 conventional system I have running DOES capture all UIDs for transmissions.

Looks like I am currently running commit: 2c7a39f0fc67d299b100221e276d04798823a2cf

I tried running on a newer commit with similar behavior noted.

[tadscottsmith]

@Dewey3 There's been a lot of work done on a preview branch for v5.0. One of the things being worked on is a fix that should hopefully address this issue. If you have some time, would you be willing to test the test/tdu-test branch to see if it helps address this issue? I know you monitor a very buy system that frequently sees this issue.

I believe something similar to this would help you build a system on the test branch.

mkdir trunk-build
git clone https://github.com/robotastic/trunk-recorder.git
cd trunk-recorder
git checkout test/tdu-test
cd ../trunk-build
cmake ../trunk-recorder
make -j$(nproc)

[theficus]

I'll give this a try as well as I monitor a very busy system too (tens of thousands of calls a day) and have observed this issue.

[theficus]

I'll give this a try as well as I monitor a very busy system too (tens of thousands of calls a day) and have observed this issue.

Well... that didn't work 🤣.

When I tried this build it just would not lock onto a control signal. I had to revert back to the master branch to get recordings working again. I've attached a log in case there's anything useful here.

01-08-2024_1937_00.copy.txt

Cc: @tadscottsmith

[taclane]

Well... that didn't work 🤣.

[2024-01-08 19:37:30.494182] (info)   Rate: 2148000
...
[2024-01-08 19:37:31.625494] (info)      Xlating Channelizer single-stage decimator - Decim: 89 Resampled Rate: 24134.8 Lowpass Size: 431
[2024-01-08 19:37:31.625746] (info)      Channelizer ARB - Symbol Rate: 24000 Resampled Rate: 24134.8 ARB Rate: 0.994413

Would you be willing to try running this at a sample rate of 2160000 or 2400000?

It's possible rates that can't cleanly divide down in the channelizer end up having problems. As a quick test, I set one of mine to 2485000 and it suddenly had issues receiving on the control channel.

It shouldn't at all be a concern to bump up the signal rate. Part of the magic in the 5.0 improvements is that it should be a lot more efficient with a 2.4 MHz source than 4.7 could be with a 2.148 MHz source.

[theficus]

Sure, I'll give it a shot. I just can't go above 2400000 because any higher and my RTL-SDRs crap out. :)

[taclane]

Either 2160000 or 2400000 is fine.

The goal is mostly to just get an even multiple of 24000, but both of those are "standard" rates generally suggested by RTL drivers.

[theficus]

I tried 2400000 and I'm getting the same error :(

[2024-01-08 21:06:52.146669] (error)   [psern025] Retuning to Control Channel: 853.825000 MHz
[2024-01-08 21:06:52.146861] (info)      - System Source 1 - Min Freq: 852.756250 MHz Max Freq: 855.056250 MHz
[2024-01-08 21:06:52.170373] (info)      Xlating Channelizer single-stage decimator - Decim: 100 Resampled Rate: 24000 Lowpass Size: 481
[2024-01-08 21:06:52.170488] (info)      Channelizer ARB - Symbol Rate: 24000 Resampled Rate: 24000 ARB Rate: 1
[2024-01-08 21:06:52.316015] (error)   [psern025]        Control Channel Message Decode Rate: 1/sec, count:  3
[2024-01-08 21:06:55.142554] (error)   [psern025] Retuning to Control Channel: 854.287500 MHz
[2024-01-08 21:06:55.142742] (info)      - System Source 1 - Min Freq: 852.756250 MHz Max Freq: 855.056250 MHz
[2024-01-08 21:06:55.143034] (error)   [psern025]        Control Channel Message Decode Rate: 0/sec, count:  0
[2024-01-08 21:06:58.099967] (error)   [psern025] Retuning to Control Channel: 851.887500 MHz
[2024-01-08 21:06:58.100154] (info)      - System Source 0 - Min Freq: 850.850000 MHz Max Freq: 853.150000 MHz
[2024-01-08 21:06:58.116437] (info)      Xlating Channelizer single-stage decimator - Decim: 100 Resampled Rate: 24000 Lowpass Size: 481
[2024-01-08 21:06:58.116565] (info)      Channelizer ARB - Symbol Rate: 24000 Resampled Rate: 24000 ARB Rate: 1
[2024-01-08 21:06:58.261543] (error)   [psern025]        Control Channel Message Decode Rate: 0/sec, count:  0
[2024-01-08 21:06:59.233799] (error)   P25 Parse error, s:  s0: 0 s1: 0 shift: 0 nac: 0 type: 65535 Len: 0
[2024-01-08 21:07:00.292556] (error)   P25 Parse error, s:  s0: 0 s1: 0 shift: 0 nac: 0 type: 65535 Len: 0

2160000 fails as well. :(

Back to master branch, same config, everything's fine.

[Dewey3]

Thanks @tadscottsmith and @taclane ! I may not be able to do a complete test until this weekend, but I hope to install this build when I get home today. Sorry for the delay until the weekend (day job), but I will be back to you both.

[Dewey3]

I'm having the same problem... I can't get a lock on the control channel. I've tried 240000 and 216000, no joy. I even tried 2040000 since that is divisible by 24000 and I believe close to the Nooelec RTL-SDR dongle 2.4 MSPS sample rate (if that matters).

[theficus]

For what it's worth I'm also using Nooelec RTL-SDR dongles. Very strange issue.