[op25-dev] OP25 -- can't even resolve the NAC

historical

It appears that you're trying to monitor a Motorola Type II SmartZone
system. op25 doesn't do that. It only does P25 and some DMR.

    ~iain

On Tue, Apr 14, 2020 at 10:19 AM Louis Wilen <louiswilen at gmail.com> wrote:
>
> I am in Montgomery County, MD trying to use OP25 to monitor the police and fire system.
>
> The platform is a Raspberry Pi 3b with the OS and all known drivers up-to-date.
>
> GQRX hears and shows a strong signal on the primary control channel frequency, 853.8625. GQRX also shows a strong signal on alternate control channel 853.6875.  (I got the control channels from RadioReference.com.)
>
> Also, I can turn in local FM, VHF ham radio, etc. stations reliably with GQRX. The audio is excellent. So my dongle appears to be fine.
>
> Using a standalone scanner, I’ve verified the primary control channel frequency is what I have specified as the current control channel, 853.8625.
>
> I’m trying to find the NAC by running:
>
> ./rx.py –args “rtl” -N ‘LNA:47’ -S 2400000 -f 853.8625e6 2>stderr.2
>
> And that gives nothing on the OP25 console screen except “Frequency 853.862500(0)” in the bottom left corner. This should give me the NAC and other info in the upper left of the screen, but that area is blank.
>
> Even though I know the control channel is on 853.8625 (based on my standalone scanner), I figured that I'd try the above command but specify the alternate, 853.6875e6, as the control channel frequency. That gives me the following in the upper left corner:
>
> NAC 0x8e2 WACN 0xbee00 SYSID 0x8e0 853.687500/808.687500 tsbks 114
>
> That looks sort of good. But if I then use the secondary control channel and NAC 0x8E2 in the trunk.tsv file, the OP25 console screen still does not show any voice activity.
>
> The OP25 spectrum plot (option 1 plot) does show the peak for the control channel that I’ve selected.
>
> And I still don’t know why I can’t get the NAC or any meaningful OP25 console data for the primary control channel to appear since I know it’s the control channel that is in use, based on watching my standalone scanner.
>
> The stderr file does not show anything that seems abnormal. Here it is when specifying the primary control channel in the rx.py command line:
>
> —————————————————-
>
> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4
>
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
>
> Using device #0 Realtek RTL2838UHIDIR SN: 00000001
>
> Found Rafael Micro R820T tuner
>
> [R82XX] PLL not locked!
>
> [R82XX] PLL not locked!
>
> Using two-stage decimator for speed=2400000, decim=25/4 if1=96000 if2=24000
>
> Project 25 IMBE Encoder/Decoder Fixed-Point implementation
>
> Developed by Pavel Yazev E-mail: pyazev at gmail.com
>
> Version 1.0 (c) Copyright 2009
>
> This program comes with ABSOLUTELY NO WARRANTY.
>
> This is free software, and you are welcome to redistribute it
>
> under certain conditions; see the file “LICENSE” for details.
>
> p25_frame_assembler_impl: do_imbe[0], do_output[0], do_audio_output[0], do_phase2_tdma[0], do_nocrypt[0]
>
> metadata update not enabled
>
> Allocating 15 zero-copy buffers
>
> Flowgraph completed. Exiting
>
> —————————————————-
>
> My dongle is very stable and appears to be 'on frequency'.  Still, I've tried using offsets and changing the frequency a bit to no avail.
>
> So what I’m mainly looking for is the NAC for the system at this point. Once I get that to appear on the screen when specifying the primary control channel on the command line, everything else should hopefully fall into place.
>
> Any suggestions would be appreciated.
>
> Louis
> W3VVV
>
>