P25 Phase II System - TG's showing as "Encrypted" yet arent

[crazdmnd]

Great work so far to all involved here. I managed to get trunk recorder up and running relatively painlessly on OSX Sierra 10.12, using a single RTL-SDR (for now) However, every talkgroup is appearing as "Encrypted", even though they really arent encrypted talk groups. Any thoughts? Here's a log:

[2017-08-22 21:16:09.528904]: [LCDPS] Started with Control Channel: 1.54392e+08 [2017-08-22 21:16:09.539688]: P25 Recorder Initial Rate: 512000 Resampled Rate: 51200 Initial Decimation: 4 Decimation: 10 System Rate: 48000 ARB Rate: 0.9375 [2017-08-22 21:16:09.539865]: P25 Recorder Taps - initial: 373 channel: 1163 ARB: 775 Total: 2311 [2017-08-22 21:17:27.733992]: [LCDPS] TG: 1548 Freq: 1.53852e+08 Not Recording: ENCRYPTED [2017-08-22 21:17:39.805978]: stopping flow graph

Files are saving correctly, but either empty or only 44 bytes...however i'm assuming this is due to the "ENCRYPTED" flag? I did a test run on a conventional channel and it recorded properly.

Here's my config.json:

{ "sources": [{ "center": 154200000.0, "rate": 2048000, "squelch": -75, "error": 0, "gain": -0, "antenna": "TX/RX", "digitalRecorders": 4, "driver": "osmosdr", "device": "", "modulation": "QPSK" }], "systems": [{ "control_channels": [154392500], "type": "p25", "shortName": "LCDPS", "talkgroupsFile": "LawrenceP25.csv", "callLog": "true" }], "logFile": "true", "captureDir": "/Users/bmelcer/truncrec/" }

The system i'm monitoring is here: https://www.radioreference.com/apps/db/?siteId=25961

Below is my talkgroup file which according to startup log appears to read correctly.

1538,602,D,LA Co EMA,County EMA,EMA,1 1539,603,D,LA Local EMA,Local EMA,EMA,1 1540,604,D,LA Hazmat,Hazmat,EMA,1 1542,606,D,LA PubSafety,Public Safety,EMA,1 1543,607,D,LA Disaster,Disaster,EMA,1 1534,5fe,D,LA EMS Resp1,EMS Response 1,EMS,1 1535,5ff,D,LA EMS CMD,EMS Command,EMS,1 1536,600,D,LA EMS OPS 1,EMS Operations 1,EMS,1 1537,601,D,LA EMS MCI,EMS Mass Casualty Incident,EMS,1 1541,605,D,LA Hospitals,Hospitals,EMS,2 1564,61c,D,LA AIR 340,Air Operations,EMS,2 1517,5ed,D,LA Fire Disp,Fire Dispatch,Fire,1 1518,5ee,D,LA North FD,North Fire,Fire,1 1519,5ef,D,LA South FD,South Fire,Fire,1 1520,5f0,D,LA FD Resp 3,Fire Response 3,Fire,1 1521,5f1,D,LA FD Resp 4,Fire Response 4,Fire,1 1522,5f2,D,LA FD Resp 5,Fire Response 5,Fire,1 1523,5f3,D,LA NCFD RESP,New Castle Fire Response,Fire,1 1524,5f4,D,LA FD LowPri,Fire Low Priority,Fire,1 1525,5f5,D,LA FD NE OPS,Fire Northeast Operations,Fire,1 1526,5f6,D,LA FD NW Ops,Fire Northwest Operations,Fire,1 1527,5f7,D,LA FD SE Ops,Fire Southeast Operations,Fire,1 1528,5f8,D,LA FD SW Ops,Fire Southwest Operations,Fire,1 1529,5f9,D,LA FD S Ops,Fire South Operations,Fire,1 1530,5fa,D,LA FD NC Ops,New Castle FIre Operations,Fire,1 1531,5fb,D,LA Fire Cmd,Fire Command,Fire,1 1532,5fc,D,LA FD Water,Water Operations,Fire,1 1533,5fd,D,LA FDTraffic,Traffic Operations,Fire,1 1544,608,D,LA DCNR,Department of Conservation and Natural Resources ,Govt,3 1545,609,D,LA Interstat,Interstate ,Govt,3 1546,60a,D,LA Schools,Schools ,Govt,3 1549,60d,D,LA NE Muni,North East Municipal ,Govt,3 1550,60e,D,LA NW Muni,North West Municipal ,Govt,3 1551,60f,D,LA SE Muni,South East Municipal ,Govt,3 1552,610,D,LA SW Muni,South West Municipal ,Govt,3 1553,611,D,LA S Muni,South Municipal ,Govt,3 1554,612,D,LA NC Muni,New Castle Municipal ,Govt,3 1555,613,D,LA CW Muni,Countywide Municipal ,Govt,3 1547,60b,D,LA Training1,Training 1,Interop,3 1548,60c,D,LA Training2,Training 2,Interop,3 1556,614,D,LA APB,APB,Interop,3 1557,615,D,LA Cty Wide,Countywide,Interop,3 1558,616,D,LA MA Law,MA Law,Interop,3 1559,617,D,LA MA Fire,MA Fire,Interop,3 1560,618,D,LA MA Med,MA Med,Interop,3 1561,619,D,LA MA EMA,MA EMA,Interop,3 1562,61a,D,LA MA Comm,MA Comm,Interop,3

Any thoughts?

[robotastic]

Can you give the “status-socket” branch a try? I have fixed a few things in their… not sure if it will make a difference, but worth a try.

On Aug 22, 2017, at 9:25 PM, crazdmnd notifications@github.com wrote:

Great work so far to all involved here. I managed to get trunk recorder up and running relatively painlessly on OSX Sierra 10.12, using a single RTL-SDR (for now) However, every talkgroup is appearing as "Encrypted", even though they really arent encrypted talk groups. Any thoughts? Here's a log:

[2017-08-22 21:16:09.528904]: [LCDPS] Started with Control Channel: 1.54392e+08 [2017-08-22 21:16:09.539688]: P25 Recorder Initial Rate: 512000 Resampled Rate: 51200 Initial Decimation: 4 Decimation: 10 System Rate: 48000 ARB Rate: 0.9375 [2017-08-22 21:16:09.539865]: P25 Recorder Taps - initial: 373 channel: 1163 ARB: 775 Total: 2311 [2017-08-22 21:17:27.733992]: [LCDPS] TG: 1548 Freq: 1.53852e+08 Not Recording: ENCRYPTED [2017-08-22 21:17:39.805978]: stopping flow graph

Files are saving correctly, but either empty or only 44 bytes...however i'm assuming this is due to the "ENCRYPTED" flag? I did a test run on a conventional channel and it recorded properly.

Here's my config.json:

{ "sources": [{ "center": 154200000.0, "rate": 2048000, "squelch": -75, "error": 0, "gain": -0, "antenna": "TX/RX", "digitalRecorders": 4, "driver": "osmosdr", "device": "", "modulation": "QPSK" }], "systems": [{ "control_channels": [154392500], "type": "p25", "shortName": "LCDPS", "talkgroupsFile": "LawrenceP25.csv", "callLog": "true" }], "logFile": "true", "captureDir": "/Users/bmelcer/truncrec/" }

The system i'm monitoring is here: https://www.radioreference.com/apps/db/?siteId=25961 https://www.radioreference.com/apps/db/?siteId=25961 Below is my talkgroup file which according to startup log appears to read correctly.

1538,602,D,LA Co EMA,County EMA,EMA,1 1539,603,D,LA Local EMA,Local EMA,EMA,1 1540,604,D,LA Hazmat,Hazmat,EMA,1 1542,606,D,LA PubSafety,Public Safety,EMA,1 1543,607,D,LA Disaster,Disaster,EMA,1 1534,5fe,D,LA EMS Resp1,EMS Response 1,EMS,1 1535,5ff,D,LA EMS CMD,EMS Command,EMS,1 1536,600,D,LA EMS OPS 1,EMS Operations 1,EMS,1 1537,601,D,LA EMS MCI,EMS Mass Casualty Incident,EMS,1 1541,605,D,LA Hospitals,Hospitals,EMS,2 1564,61c,D,LA AIR 340,Air Operations,EMS,2 1517,5ed,D,LA Fire Disp,Fire Dispatch,Fire,1 1518,5ee,D,LA North FD,North Fire,Fire,1 1519,5ef,D,LA South FD,South Fire,Fire,1 1520,5f0,D,LA FD Resp 3,Fire Response 3,Fire,1 1521,5f1,D,LA FD Resp 4,Fire Response 4,Fire,1 1522,5f2,D,LA FD Resp 5,Fire Response 5,Fire,1 1523,5f3,D,LA NCFD RESP,New Castle Fire Response,Fire,1 1524,5f4,D,LA FD LowPri,Fire Low Priority,Fire,1 1525,5f5,D,LA FD NE OPS,Fire Northeast Operations,Fire,1 1526,5f6,D,LA FD NW Ops,Fire Northwest Operations,Fire,1 1527,5f7,D,LA FD SE Ops,Fire Southeast Operations,Fire,1 1528,5f8,D,LA FD SW Ops,Fire Southwest Operations,Fire,1 1529,5f9,D,LA FD S Ops,Fire South Operations,Fire,1 1530,5fa,D,LA FD NC Ops,New Castle FIre Operations,Fire,1 1531,5fb,D,LA Fire Cmd,Fire Command,Fire,1 1532,5fc,D,LA FD Water,Water Operations,Fire,1 1533,5fd,D,LA FDTraffic,Traffic Operations,Fire,1 1544,608,D,LA DCNR,Department of Conservation and Natural Resources ,Govt,3 1545,609,D,LA Interstat,Interstate ,Govt,3 1546,60a,D,LA Schools,Schools ,Govt,3 1549,60d,D,LA NE Muni,North East Municipal ,Govt,3 1550,60e,D,LA NW Muni,North West Municipal ,Govt,3 1551,60f,D,LA SE Muni,South East Municipal ,Govt,3 1552,610,D,LA SW Muni,South West Municipal ,Govt,3 1553,611,D,LA S Muni,South Municipal ,Govt,3 1554,612,D,LA NC Muni,New Castle Municipal ,Govt,3 1555,613,D,LA CW Muni,Countywide Municipal ,Govt,3 1547,60b,D,LA Training1,Training 1,Interop,3 1548,60c,D,LA Training2,Training 2,Interop,3 1556,614,D,LA APB,APB,Interop,3 1557,615,D,LA Cty Wide,Countywide,Interop,3 1558,616,D,LA MA Law,MA Law,Interop,3 1559,617,D,LA MA Fire,MA Fire,Interop,3 1560,618,D,LA MA Med,MA Med,Interop,3 1561,619,D,LA MA EMA,MA EMA,Interop,3 1562,61a,D,LA MA Comm,MA Comm,Interop,3

Any thoughts?

— 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/132, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG53G5gK-zPl3kkUU05PM-IHrmQ2Bc5ks5sa3-ggaJpZM4O_YDY.

[crazdmnd]

i'm not a git expert, but i believe i properly checked out and rebuilt off the status-socket branch...it appears to have done something, as i'm now seeing affiliation messages, and did manage to record a couple of the talkgroups randomly...but now they are showing unencrypted again.

[2017-08-22 22:10:44.830960] (info) P25 Recorder Taps - initial: 311 channel: 1551 ARB: 775 Total: 2637 [2017-08-22 22:10:44.897059] (info) P25 Recorder Initial Rate: 512000 Resampled Rate: 64000 Initial Decimation: 4 Decimation: 8 System Rate: 60000 ARB Rate: 0.9375 [2017-08-22 22:10:44.897112] (info) P25 Recorder Taps - initial: 311 channel: 1551 ARB: 775 Total: 2637 [2017-08-22 22:10:44.956540] (info) P25 Recorder Initial Rate: 512000 Resampled Rate: 64000 Initial Decimation: 4 Decimation: 8 System Rate: 60000 ARB Rate: 0.9375 [2017-08-22 22:10:44.956592] (info) P25 Recorder Taps - initial: 311 channel: 1551 ARB: 775 Total: 2637 [2017-08-22 22:10:44.983251] (info) [LCDPS] Started with Control Channel: 1.54392e+08 [2017-08-22 22:10:45.027153] (info) P25 Trunking - SysNum: 0 [2017-08-22 22:10:45.027258] (info) P25 Recorder Initial Rate: 512000 Resampled Rate: 51200 Initial Decimation: 4 Decimation: 10 System Rate: 48000 ARB Rate: 0.9375 [2017-08-22 22:10:45.027422] (info) P25 Recorder Taps - initial: 311 channel: 1163 ARB: 775 Total: 2249 [2017-08-22 22:10:46.687709] (info) [LCDPS] Decoding System ID 338 WACN: 781824 NAC: 344 [2017-08-22 22:10:52.711095] (info) tsbk2c Unit Registration Response sa 56294 Source ID: 56294 [2017-08-22 22:11:02.380038] (info) [LCDPS] TG: 1548 Freq: 1.53852e+08 Not Recording: ENCRYPTED [2017-08-22 22:11:03.014170] (error) [LCDPS] Control Channel Message Decode Rate: 8.33333/sec, count: 25 [2017-08-22 22:11:19.848909] (info) [LCDPS] TG: 1503 Freq: 1.54122e+08 Not Recording: ENCRYPTED [2017-08-22 22:11:22.411924] (info) [LCDPS] TG: 1547 Freq: 1.53852e+08 Starting Recorder on Src: Total recs: 0 [2017-08-22 22:11:22.412016] (info) - Starting P25 Recorder Num [0] TG: 1547 Freq: 1.53852e+08 TDMA: true Slot: 1 [2017-08-22 22:11:27.525895] (info) [LCDPS] TG: 1503 Freq: 1.53852e+08 Not Recording: ENCRYPTED [2017-08-22 22:11:29.010554] (info) [LCDPS] TG: 1547 Freq: 1.53852e+08 Ending Recorded Call - Last Update: 4s Call Elapsed: 7 [2017-08-22 22:11:29.011184] (info) - Stopping P25 Recorder Num [0] TG: 1547 Freq: 1.53852e+08 TDMA: true Slot: 1 [2017-08-22 22:11:34.566146] (info) [LCDPS] TG: 1547 Freq: 1.53852e+08 Starting Recorder on Src: Total recs: 0 [2017-08-22 22:11:34.566234] (info) - Starting P25 Recorder Num [0] TG: 1547 Freq: 1.53852e+08 TDMA: true Slot: 1 [2017-08-22 22:11:36.013633] (error) [LCDPS] Control Channel Message Decode Rate: 8.66667/sec, count: 26 [2017-08-22 22:11:39.012595] (error) [LCDPS] Control Channel Message Decode Rate: 4.66667/sec, count: 14 [2017-08-22 22:11:41.000838] (info) [LCDPS] TG: 1547 Freq: 1.53852e+08 Ending Recorded Call - Last Update: 4s Call Elapsed: 7 [2017-08-22 22:11:41.001263] (info) - Stopping P25 Recorder Num [0] TG: 1547 Freq: 1.53852e+08 TDMA: true Slot: 1

[crazdmnd]

didnt mean to close.

Did a little more testing. I redid my talkgroup.csv file, made sure it was sorted properly on TGID...ran through a bunch of non-encrypted TG's and they all appear to trigger a record now.

[robotastic]

Cool - In the TG file you could try setting the priority number above 100 on all the encrypted TGs so they are not recorded... although they shouldn't be recorded already. To switch branches, type git checkout status-socket in the trunk-recorder directory.

[nkwood]

I don't know if it is relevant to this issue, by just in case anyone searching comes across this: I believe last time I looked trunk-recorder decided if something is encrypted based on whether or not the p-bit (protected? privacy?) is set in the TSBK that sets up a call, rather than the ALGID set in the HDU or LDU2. It is not uncommon to have the p-bit set on a call, but have both encrypted and non-encrypted transmissions, or even all non-encrypted transmissions on a call with the p-bit set. Just FYI.

I worked on having trunk-recorder flag individual transmissions as encrypted rather than calls, but I haven't picked up that code in a while and need to rebase it onto robotastic's latest status-socket branch.

[crazdmnd]

thanks guys---I did some extensive testing last night--it appears trunk recorder is properly flagging the encrypted / unencrypted calls and recording as such. in fact, i dont even have the encrypted tg's in my csv file...but regardless thanks to you all I got it working pretty good on my mac; I also got it working on a raspberry pi3, so far successful but am having garbling issues which I'm wondering if they are related to the lack of horsepower on the pi3 to receive decode and write at the same time. conventional recordings sound great, tdma ones are garbled but recorded.

[Treehouseman]

I'll just go ahead and leave the way it works down here. So the system looks for the encrypted flag in the grant packet for calls, now this takes effect over whatever the talkgroup is set to in the csv file IIRC, you can still have the priority set to 100 to negate recording at all, but if it's not set or the talkgroup is not in the csv, default is to not record the call (at least last time I looked at the code).

Now if you bypass that and record the calls still (I always do), you find that the flag is set when the call STARTS, I've found that some people despite using an encrypted group, don't put their radio in secure mode. This results in various portions of a call being unencrypted. This is due to the call joining, that 3 second delay before ending the call, if somone else pipes up on the same group on the same radio it'll join the calls, but if the first call was encrypted it'll still get attached if the second person is unencrypted.

If you want to only remove encrypted calls you have to make it so that it doesn't join calls, then it'll only dump ones that don't send the encrypted flag.

[robotastic]

I will have to go back and check the code. It was supposed to base the encryption status off the initial P25 Grant Message for the call. I am not sure if it checks the subsequent grant messages if a new person starts talking but forgets to switch the knob on the radio to encrypted. It shouldn't be basing the encryption status off the talkgroup file.

On Thu, Aug 24, 2017 at 12:58 PM, Treehouseman notifications@github.com wrote:

I'll just go ahead and leave the way it works down here. So the system looks for the encrypted flag in the grant packet for calls, now this takes effect over whatever the talkgroup is set to in the csv file IIRC, you can still have the priority set to 100 to negate recording at all, but if it's not set or the talkgroup is not in the csv, default is to not record the call (at least last time I looked at the code).

Now if you bypass that and record the calls still (I always do), you find that the flag is set when the call STARTS, I've found that some people despite using an encrypted group, don't put their radio in secure mode. This results in various portions of a call being unencrypted. This is due to the call joining, that 3 second delay before ending the call, if somone else pipes up on the same group on the same radio it'll join the calls, but if the first call was encrypted it'll still get attached if the second person is unencrypted.

If you want to only remove encrypted calls you have to make it so that it doesn't join calls, then it'll only dump ones that don't send the encrypted flag.

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

[crazdmnd]

if it helps, the system i'm working off of encrypts on a talkgroup level, so non-encrypted calls would never be comingled on a talkgroup.

back to my garbling issue; i've taken a 2 or 3 day detour buildling op25 successfully on the rpi3--and same problem - garbling. so its something specific to the driver or the horsepower (or lack thereof) on the PI.

[robotastic]

Hmm.. does it work fine on a regular, intel based Linux box? I wonder if it has something to do with the ARM chip.

On Fri, Aug 25, 2017 at 12:47 AM, crazdmnd notifications@github.com wrote:

if it helps, the system i'm working off of encrypts on a talkgroup level, so non-encrypted calls would never be comingled on a talkgroup.

back to my garbling issue; i've taken a 2 or 3 day detour buildling op25 successfully on the rpi3--and same problem - garbling. so its something specific to the driver or the horsepower (or lack thereof) on the PI.

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

[crazdmnd]

not sure--i thought of doing it in a virtualbox on my mac. the recordings clearly sound as if they are encypted yet recorded; but they're not and I can confirm that. i was on the same thought as you, and that was going to be my next experiment. until i managed to get op25 working fine now; i've tried to mirror all of the settings over to trunk-recorder but still no dice. here's the details of my op25 config if it helps at all:

./rx.py --args 'rtl' --gains 'lna:35' -f 154.3925e6 -D cqpsk -S 960000 -2 -V -q -1 -T lcdps.tsv -w 2> stderr.2 and of course my tsv files; but trunk-recorder seems to be beautifully picking everything up as well as jumping between the TG's and all. and recording...just garbled end result.

[0lav]

I have the same issue as you Crazdmnd of garbled audio recordings on a phase 2 system using RPI3. Have you made any progress getting it to work?

[dougdever]

Anyone else ever figure out the phase 2 audio issues? Both with an Intel Atom box and an Intel Xeon box I've noticed it multiple RTL-SDR dongles. CC decode is rock solid. Normally I'd say it sounded almost like the RX was slightly off-frequency, but it isn't and it is decoding Phase 1 FDMA just fine. I'm almost wondering if the timing is slightly off on the RX... Either way, I don't believe it is a hardware problem unless a limitation of the dongle. Only way I could test that would be to throw an airspy at it.

[robotastic]

@dougdever - hmm... under the hood is OP25 and codec it uses doesn't do the cleanest decode of Phase 2. Could you share a file?

[dougdever]

I spun up a new Intel Atom box running ubuntu 16.04 LTS desktop (my other boxes are all very minimal 16.04 server builds). Sounds better. It's not as nice as a phase 1 system, but it works. shrug

[jareklupinski]

After I've checked out everything else and I'm still getting garbley audio, reducing the sample rate on my voice capture source did the trick, turns out I was overloading the CPU with too many channels all processing a needlessly large bandwidth of signal, and it manifested as clear but garbled speech.

[robotastic]

Phase 2 stuff should be working on Pis now.