my OP25 boatbod system won't decode

[n8zuz]

I started this thread with an error then I realized my system was still using the SDRs.

I have had my OP25 system running for a year and a half. WGBecks has been a big help. Lately my system won't decode my P25. I ran an "rtl_test" and the output is below:
Found 3 device(s):
0: Nooelec, NESDR SMArt v5, SN: 00000006
1: Nooelec, NESDR SMArt v5, SN: 00000005
2: Realtek, RTL2838UHIDIR, SN: 00000003

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 zero-copy buffers
lost at least 36 bytes

I let this run a few minutes and no errors are popping up.

I have done a complete update
cd op25
git pull
./rebuild.sh
sudo systemctl restart op25-rx

with no change. I rebooted a few times and nothing.

My serial number 5 SDR is my P25 system, the serial number 6 is my analog fire channel, and the SN 3 is my ADSB Exchange SDR.

I have listened to my control channel on the analog scanner and it's transmitting data.

Any advice of what I should look for next?

Sorry to those who got the first post then I edited it all to this.

 

[n8zuz]

I'm not sure if this output helps too?

$ ps -aux | grep python
root 608 0.0 0.4 39920 18476 ? Ss Mar26 0:00 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
adsbexc+ 1108 0.4 0.3 22028 12936 ? S< Mar26 13:43
opey 751887 35.0 3.1 207916 123708 ? D 21:36 0:00 /usr/bin/python3 ./multi_rx.py -c fire.json -v 1
opey 751888 25.5 0.6 48288 25836 ? D 21:36 0:00 /usr/bin/python3 ./rx.py --nocrypt --args rtl=00000005 --gains lna:25 -S 1000000 -q -0 -v 1 -2 -T trunk.tsv -V -w -u 23450 -M meta.json -l http:0.0.0.0:8080
opey 751920 41.0 0.6 42816 25876 ? D 21:36 0:00 /usr/bin/python3 ./audio.py -u 23450 -x 2 -s
opey 751922 40.0 0.6 42816 25880 ? D 21:36 0:00 /usr/bin/python3 ./audio.py -u 23460 -x 2.5 -s
opey 751931 0.0 0.0 9032 712 pts/0 S+ 21:36 0:00 grep --color=auto python

 

[wgbecks]

Jeff,

Can you still connect to your HTTP Console? If so, look at your FFT plot to check if the SDR is getting a good signal. It would be helpful
to set the logging verbose to -v11 then restart op25 and let the logfile accumulate data for about a minute then post your results.

Feel free to call or email if you'd like.

Bill

 

[n8zuz]

 

[wgbecks]

Signal looks pretty good but it doesn't look like its decoding trunk signaling blocks that makes me
suspect the RFSS NAC may have been changed or that the value in your trunk.tsv file did.

Edit your trunk.tsv file and set the NAC to 0x0 then restart op25 (rx.py) and see if you start getting any TSBKS incrementing?

 

[n8zuz]

Hi Bill,
I changed my NAC to 0x0 and it started working. Now I have:


I had my NAC in the trunk.tsv file as 0x1a4 but it looks like it may have changed to 0x1a9 from the above. Am I seeing that correctly? Is there any problem keeping it 0x0 as it passed decoded audio. I wasn't able to see if it is giving me the TGIDs or not.

 

[maus92]

Hi Bill,
I changed my NAC to 0x0 and it started working. Now I have:
View attachment 139116

I had my NAC in the trunk.tsv file as 0x1a4 but it looks like it may have changed to 0x1a9 from the above. Am I seeing that correctly? Is there any problem keeping it 0x0 as it passed decoded audio. I wasn't able to see if it is giving me the TGIDs or not.

You can leave the NAC at 0x0, but there is an offhand chance that an unwanted / distant signal may be processed from time to time. I would change the NAC to the site's currently configured value, 0x1a9.

 

[boatbod]

NAC 0x0 is good as long as you only need the one line in trunk.tsv.

 

[n8zuz]

Thank you Bill and the rest for the help. The system NAC change was certainly the problem. How dare they change the NAC and not inform me? Haha.

Since I am in very rural WY and I'm only 11 miles from the tower and I'm just using a poor magmount antenna in the house on the fridge (because it's a strong signal as the tower is up on a bluff and I'm in the valley), I don't think I will have a distant signal issue but it's good to know that could happen. It's good to know if in the future if I need another line in the trunk.tsv file to change the NAC. Good info.

 

[wgbecks]

Hi Bill,
I changed my NAC to 0x0 and it started working. Now I have:
View attachment 139116

I had my NAC in the trunk.tsv file as 0x1a4 but it looks like it may have changed to 0x1a9 from the above. Am I seeing that correctly? Is there any problem keeping it 0x0 as it passed decoded audio. I wasn't able to see if it is giving me the TGIDs or not.

Hi Jeff,

It's very possible that WyoLink made some rearrangement of RFSS NAC's for any number of technical reasons that may include resolution
of interference between sites during periods of enhanced propagation.

Anyway, it won't harm anything to leave the NAC set at 0x0 so long as you continue to use rx.py to receive WyoLink. However, it would be necessary to configure the correct NAC is you were to migrate over to using multi_rx.py to monitor the system in that it doesn’t support
the 0x0 option as does rx.py.

Bill

 

[boatbod]

Hi Jeff,

It's very possible that WyoLink made some rearrangement of RFSS NAC's for any number of technical reasons that may include resolution
of interference between sites during periods of enhanced propagation.

Anyway, it won't harm anything to leave the NAC set at 0x0 so long as you continue to use rx.py to receive WyoLink. However, it would be necessary to configure the correct NAC is you were to migrate over to using multi_rx.py to monitor the system in that it doesn’t support
the 0x0 option as does rx.py.

Bill

Boatbod multi_rx.py supports NAC 0x00, and since it's not a primary key (like it is in rx.py) you can actually use it in more than one trunking system definition.

 

[wgbecks]

Boatbod multi_rx.py supports NAC 0x00, and since it's not a primary key (like it is in rx.py) you can actually use it in more than one trunking system definition.

Sorry @boatbod. I wasn't aware NAC 0x0 had been added to multi_rx.py.