All calls on P25 Phase 2 system shows logs with: Freq: 0.000000 MHz Not Recording: no source covering Freq

[steve-horvath]

Trunk Recorder Version: 4.7.1
System: https://www.radioreference.com/db/sid/11280 Site ID 7
Hardware: Single Noelec RTL-SDR, with a 0 ppm offset

config.json:

    "ver": 2,
    "sources": [{
        "center": 142395000,
        "rate": 2148000,
        "ppm": 0,
        "agc": true,
        "gain": 22,
        "debugRecorders": 0,
        "digitalRecorders": 4,
        "driver": "osmosdr",
        "device": "rtl=0"
    }],
    "systems": [{
        "control_channels": [142800000],
        "type": "p25",
        "shortName": "LMRN",
        "squelch": -60,
        "talkgroupDisplayFormat": "id_tag",
        "hideEncrypted": false,
        "modulation": "qpsk",
        "digitalLevels": 0,
        "compressWav": false,
        "audioArchive": false,
        "callLog": true,
        "analogLevels": 15
    }],
    "defaultMode": "digital",
    "logFile": true,
    "logLevel": "trace",
    "captureDir": "/home/steve/PSRN/RECORDINGS/",
    "controlWarnRate": 10,
    "frequencyFormat": "mhz"
}

Logs, running in trace log level: https://drive.google.com/file/d/1B2JCHwuUCzrCgc2EGUyqnMnxmT28zCUz/view?usp=sharing

Issue:
Any time a transmission is detected on the system, the Call Grant message shows a frequency of 000.0000MHz, and the error messages show Freq: 0.000000 MHz Not Recording: no source covering Freq.

[Dewey3]

Just a shot in the dark, but what if you tried changing your rate from 2148000 to 2048000.

[steve-horvath]

Just a shot in the dark, but what if you tried changing your rate from 2148000 to 2048000.

I tried that, and there is no change:

[2024-04-16 08:56:50.109766] (trace)   TSBK: opcode: $0
[2024-04-16 08:56:50.109968] (debug)   tsbk00   Chan Grant      Channel ID:  5753       Freq:   0.000000 MHz    ga    2067      TDMA -1 sa 213994       Encrypt 0       Bandwidth: 0
[2024-04-16 08:56:50.111270] (error)   [LMRN]   0C      TG:       2067 (                      -)        Freq:   0.000000 MHz    Not Recording: no source covering Freq
[2024-04-16 08:56:50.174098] (trace)   nac ad7 type 7 size 12 mesg len: 12

[Dewey3]

Another shot in the dark. Based on your first post, I assume that you are trying to capture the Cedarville site in Grey Co. If so, I see three other sites in Grey Co, what happens if you add those to you control channels?

[steve-horvath]

Another shot in the dark. Based on your first post, I assume that you are trying to capture the Cedarville site in Grey Co. If so, I see three other sites in Grey Co, what happens if you add those to you control channels?

I am actually trying to get Site 7, which is Hamilton, from Burlington.

all the other local sites are too weak to get any decode.

[Dewey3]

In that case, you are missing a control channel. Have you tried entering the second control channel?

[tadscottsmith]

Are you able to receive that site with a physical scanner or any other software? Trunk-recorder is not seeing any IDEN_UP messages advertising the bandwidth plan. That being said, there's a special IDEN_UP message that's used for 136 MHz to 172 MHz and 380 MHz to 512 MHz, so it's possible that trunk-recorder isn't decoding the special message correctly.

[tadscottsmith]

I am very curious about those TSBK: opcode: $5 messages. It seems that maybe Motorola has a vendor specific implementation of that code that relates to traffic channels. Can you record like 15-30 seconds of IQ from that system?

https://trunkrecorder.com/docs/DEBUG#recording-off-an-rtl-sdr

[steve-horvath]

I am very curious about those TSBK: opcode: $5 messages. It seems that maybe Motorola has a vendor specific implementation of that code that relates to traffic channels. Can you record like 15-30 seconds of IQ from that system?

https://trunkrecorder.com/docs/DEBUG#recording-off-an-rtl-sdr

Here's a link to download the Compact iq file: https://drive.google.com/file/d/1RynSGp8U3xZ1-DDvtD2E4EAoBasvEXHl/view?usp=sharing

[tadscottsmith]

I'm not seeing any control channel data in that file, but it's probably my fault. Can you share what exact rtl_sdr command you used?

[steve-horvath]

I'm not seeing any control channel data in that file, but it's probably my fault. Can you share what exact rtl_sdr command you used?

I tried it too, and didn't get valid data decoded either. to record it I used:
rtl_sdr -f 14280000 -s 2048000 -g 32 site_7.iq

[tadscottsmith]

Oh, I think you missed a zero on the end of the frequency. It also might not work if you center it right on your control channel. Can you try rtl_sdr -f 142395000 -s 2400000 -g 32 site_7.iq ? About 10 seconds should be plenty.

[steve-horvath]

Oh, I think you missed a zero on the end of the frequency. It also might not work if you center it right on your control channel. Can you try rtl_sdr -f 142395000 -s 2400000 -g 32 site_7.iq ? About 10 seconds should be plenty.

I tried it again with:
rtl_sdr -f 142395000 -s 2400000 -g 32 17_04_site_7.iq

Available here:
https://drive.google.com/file/d/10l_sK9kxbkR862Qffcl4qig9X2NjeDMP/view?usp=sharing

I still can't get trunk-recorder to decode it, I just get p25 decode errors, but if I convert it to complex iq I can play it back in gqrx, and the spectrum looks ok.

[tadscottsmith]

I was able to use that one. Is it possible there is just no activity on that site yet? During the over an hour duration of your original logging, it seems there was only about 5 radios that did anything on the system. I am trying to dig in and verify, but it could be that the system is not advertising the band plan because there are no radios actively requesting it.

Alternatively, it could be that this system is programmed in way such that all of the channel to frequency mapping needs to be on the radio side and I don't believe that trunk-recorder supports this yet. I'm still digging.

There is another post of a user trying to monitor the same system with a radio (doesn't specify the type), but indicating they are getting no activity on the Hamilton site as well.

http://forums.radioreference.com/threads/psrn-general-discussion.462531/post-3991850

[tadscottsmith]

@steve-horvath are you comfortable building from source? If so, can you run this test branch in trace mode for a while and get some logs? This should print out some more detailed information on the band plan and channels in use. It won't fix anything yet, but it should give some more detailed logs.

https://github.com/tadscottsmith/trunk-recorder/tree/band-plan

[steve-horvath]

@steve-horvath are you comfortable building from source? If so, can you run this test branch in trace mode for a while and get some logs? This should print out some more detailed information on the band plan and channels in use. It won't fix anything yet, but it should give some more detailed logs.

https://github.com/tadscottsmith/trunk-recorder/tree/band-plan

built, and I let it run overnight, to try and get new radios affiliating. Logs are here:
https://drive.google.com/drive/folders/19nzCWdBAvaQvq7P9G2fCzgOQ_C5MccnD?usp=sharing

[tadscottsmith]

Unfortunately it doesn't appear that it used the updated code. It might be that you need to explicitly switch to the band-plan branch. Can you try this which should help you build the new test version in a trunk-test directory?

git clone https://github.com/tadscottsmith/trunk-recorder.git trunk-test
cd trunk-test
git checkout band-plan
git pull
mkdir build
cd build/
cmake ../
make -j$(nproc)

[steve-horvath]

logs from band-plan branch are here:
https://drive.google.com/file/d/1hGIEwqn3VN5K5fsDMhEBmwhsmQX3ZXNG/view?usp=sharing

Let me know if you need longer logs, I have left it running

[tadscottsmith]

I just pushed a new commit to my test branch that should have the custom band plans for Hamilton. Do you want to update it and see how it works? I'm not sure how familiar you are with git, but something like this should get you the latest version.

cd trunk-test (or whatever directory you're using)
git checkout band-plan
git pull
cd build/
cmake ../
make -j$(nproc)

[steve-horvath]

that is looking much better:

[2024-04-24 16:56:09.975342] (debug)   tsbk05   Unit To Unit Answer Request     sa 2048 Source ID: 12582912
[2024-04-24 16:56:10.007129] (trace)   [LMRN]   3C      TG:       2056 (                    MTO)        Freq: 142.215000 MHz     Stopping Call because of Recorder  Rec last write: 5.14879 State: idle
[2024-04-24 16:56:10.007467] (info)   [LMRN]    3C      TG:       2056 (                    MTO)        Freq: 142.215000 MHz    Concluding Recorded Call - Last Update: 4s      Recorder last write:5.14909    Call Elapsed: 11
[2024-04-24 16:56:10.007691] (info)   [LMRN]    3C      TG:       2056 (                    MTO)        Freq: 142.215000 MHz    Stopping P25 Recorder Num [0]   TDMA: true      Slot: 0 Hz Error: 26
[2024-04-24 16:56:10.008025] (info)   [LMRN]    3C      TG:       2056 (                    MTO)        Freq: 142.215000 MHz    - Transmission src: 213991 pos:  0.00 length:  4.00
[2024-04-24 16:56:10.031156] (trace)   setting silence_frame_count 0 to d_silence_frames: 0
[2024-04-24 16:56:10.032156] (trace)   [LMRN]   4C      TG:       2056 (                    MTO)        Freq: 142.215000 MHz     Wrote: 640 of 640
[2024-04-24 16:56:10.038806] (trace)   nac ad7 type 7 size 12 mesg len: 12

[tadscottsmith]

That looks great. You should have audio! If you want to let it run for a while and make sure it doesn't explode, I'll work on getting something submitted so users can input their own custom band plans when necessary.

[steve-horvath]

That looks great. You should have audio! If you want to let it run for a while and make sure it doesn't explode, I'll work on getting something submitted so users can input their own custom band plans when necessary.

I have verified audio works, and it uploads to rdio-scanner. I will put it on my production server, and let it run long-term tomorrow. Thank you.

[slvp25]

I have recently started seeing more and more "Freq: 0.000000 MHz Not Recording: no source covering Freq" errors in my logs. There are very few channels that actually come through with a frequency and decoded audio, and they seem to consistently be limited to specific agencies.

I tried pulling the band-plan branch above, but was unable to figure out the offsets to build the custom bandplan in p25_parser.cc

I was thinking maybe it is a side effect of encryption, but I have seen messages about encrypted calls in the past. This seems like the problem described in this thread, where it is just not explicitly assigning a frequency.

I am currently decoding the Alamosa and Monte Vista towers on the Colorado statewide P25 DTRS.

Any suggestions are welcome. I am able to build from source or provide any log/debug output you need. I could be barking up the wrong tree here as well.

[2024-06-15 00:48:58.220768] (debug) tsbk00 Chan Grant Channel ID: 131 Freq: 0.000000 MHz ga 8087 TDMA -1 sa 699920 Encrypt 0 Bandwidth: 0
[2024-06-15 00:48:58.220833] (error) [SLVP25ALA] 93C TG: 8087 ( Alamosa PD) Freq: 0.000000 MHz Not Recording: no source covering Freq

Example log output when a 0.0000 Mhz call happens.

[kb2ear]

try

  BandPlan temp_bandplan = {
      0,              // id;
      -45000000, // offset;
      6250,        // step;
      851006250,            // frequency;
      false,
      0, // tdma;
      12.5};

    bandplans[0][0] = temp_bandplan;

    temp_bandplan = {
      1,              // id;
      30000000, // offset;
      6250,        // step;
      762006250,            // frequency;
      false,
      0, // tdma;
      12.5};

     bandplans[0][1] = temp_bandplan;

[slvp25]

Thank you for your help. I ran it with the bandplan you provided and it works for the 0.0mhz talk groups, but now I've lost the "normal" channels. The odd thing is that only some of the talkgroups on the system use this method, and the remainder are all assigned a frequency by the control channel.

From looking at the changes to the code, it looks like the traditional "channel" code has been replaced with the bandplan code you added, and I'm guessing the two methods are mutually exclusive at this point. Is it possible to run both types of channel mapping at the same time?

I could theoretically set up two servers, one with the custom code that only captures the 0.0mhz calls, and the other one set up traditionally with the main codebase. Then I could pipe the data over to the audio source and combine them to upload/broadcast as a single channel.

[tadscottsmith]

@slvp25 can you grab like 30 seconds of logs at the trace level? It's possible there's a different issue with your system.

[slvp25]

I will try to get some recordings tonight or tomorrow, do you need anything specific in the logs, like a failed 0.000mhz call?

The only thing that I noticed from watching it is that the channel 131 is consistently referred to in the 0.0000 mhz calls.

There shouldn't be anything private in the logs, do you want it as an attachment here in the forums?

Thanks again for your help.

[tadscottsmith]

Are you sure you're on the band-plan branch? If you are, you should see the debug/trace channels displayed similar to Chan Grant Channel ID: 00-0131 so that they explicitly list the band plan ID and channel ID. I am mostly interested to see if the control channel for that system is sending IDEN_UP messages with the bandplans announced, or if you are running into another issue.

[slvp25]

When I run trunk-recorder --version it shows the Custom Hamilton as the branch and warns that my changes were not committed at compile time.

I'm on the road now, so I don't have access to the server (I didn't port forward for ssh).

I will get the debug to you as soon as I'm able.

But, like I said, your Hamilton branch works for the channels that report 0.0mhz as the frequency. But only for those. It then ignores the normal frequency assigned calls, which about 75% of the talkgroups use.

I don't know if you plan to patch it to allow both to work simultaneously, because it looks like you pulled out all the normal channels[] code and replaced it with the bandplans[] code. I assume this means your patch is mutually exclusive of the two styles of frequency assignment.

Worst case I can run two systems, one to run traditionally, and the other that only receives the bandplan channels. It's a hack, but it may work. I'll have to run two copies of trunk-recorder pushing to the same upload/playback scripts.

[tadscottsmith]

I'm not really following. The entire system should use the same band plan, but if your control channel is broadcasting IDEN_UP information it might be overwriting the manual plans. When you can get a copy of your config.json (sanitized) and trace log, I can try to figure out what's going on. Note that it will need to be trace and not debug since the IDEN_UP info is only displayed at the trace level.

[slvp25]

I had some time to test it this weekend and I have some new information.

So far I have been running multiple systems. In order to provide clean log output I simplified my config file to only run one system (Alamosa, CO tower). It has run perfectly with the Hamilton code for about 2 days now.

This morning I put the second system (Monte Vista) back in, and the "0.000000 no source covering frequency" messages came back.

I'm currently setting up a second server to capture only Monte Vista and will get traces from that system. As it stands now, with the main trunk code it will decode 2 talkgroups, and with the Hamilton code it is completely silent.

[tadscottsmith]

That makes a lot of sense. The system number is hard-coded in the patch. You'll probably either need to have Alamosa listed first in your config or adjust the patch to enter the system numbers according. For example bandplans[0][1] is system number 0 and the band plan with ID 1. I'd still be interested in seeing some trace output from Alamosa to confirm they aren't sending the band plans over the air.

[slvp25]

Alamosa seems to be working perfectly when it is the first or only system. I still seem to be missing some calls on the Monte Vista tower. Specifically, I haven't seen any Monte Vista PD calls in a long time.

Here are the attachments from the Monte Vista tower. I did see a lot of trace traffic about channels, including some iden messages. I don't really know what I'm looking at though, so hopefully you can interpret it. Thank you again for your help with this.

config_mv_hackrf_sanitized.json

06-24-2024_1000_00.log

talkgroups-slvp25mv-upload.csv

[tadscottsmith]

Monte Vista seems to be advertising correctly and matches what you manually entered for Alamosa:

[2024-06-24 10:01:40.179866] (trace)   tsbk3d iden id 0 toff -45 spac 6.25 freq 851.006
[2024-06-24 10:01:40.487129] (trace)   tsbk3d iden id 1 toff 30 spac 6.25 freq 762.006

There are two calls that are started and appear to have correct frequencies:

[2024-06-24 10:00:15.798030] (info)   [SLVP25MV]        1C      TG:       8112 (                 CSP 5B)        Freq: 851.537500 MHz    Starting P25 Recorder Num [0]   TDMA: false     Slot: 0 QPSK: true
[2024-06-24 10:01:11.912380] (info)   [SLVP25MV]        2C      TG:       8112 (                 CSP 5B)        Freq: 851.537500 MHz    Starting P25 Recorder Num [0]   TDMA: false     Slot: 0 QPSK: true

I don't see any missed calls or anything that looks out of the ordinary for Monte Vista. Is it possible the PD went encrypted? It should still show up in the logs, but wouldn't be recorded.