So, first: I'm quite convinced there is something broken in building the components using the build-gnuradio script. Something in incompatible between the gnuradio, gr-osmosdr, and rtlsdr repositories (and/or my computer and/or Linux Mint 18.1 and/or the RTL-SDR.com dongle).
So this time I did it with Max's install.sh in the latest commit, and after installing the needed packages (build-essentials, swig, python-numeric, and gnuplot-x11) got a successful build, and have the rx.py app running -- I think.
The problem is, I can't tell if anything's happening. The main window has a single line at the top showing NAC, WACN, SYUSID, tsbks and a single line at the bottom showing the frequency. The NAC value appears to be read from the trunk.tsv file. Neither has changed since I started the program several minutes ago.
The stderr.2 output shows a "set trunk_cc to 853600000" command about every 6 to 7 seconds, but nothing else. The audio pipe is running but I haven't heard a peep. Sunday morning is quiet, but it shouldn't be *this* quiet!
I've tried running the plot modes (including the undocumented 'fft') but none of them indicate any organized data -- the constellation is just noise, the fft shows a spectrum but without the control channel (most of the time), and the symbol display is just noise. All the plots throw various errors into the stderr.2 file.
I've had this RTL-SDR.com dongle working with the old version of op25, on a difference computer, and I know that I have a very strong control channel signal available. So I don't think there's an RF issue. I also tried using a hackrf on this box and had the same results. In each case, the initialization seems to go fine, with the frequency, gain, and sample rate being set without error.
I'm just not sure what to do next...
Thanks, John
Hi John
we need to do a better job of documenting the process of initial acquisition of the system. The process itself could be made easier, as could 1,000 other things...
Could you post the command line you're running, and if possible post a screen print of the 'datascope' and 'constellation' plots...
The best approach usually has been to first get the control channel coming in well in manual tuning mode (i.e., no -T parameter), then (and only then) to try to get voice decode working. In rx.py the way you'll know when the CC is tuned correctly is the number in the upper-right corner of the page (TSBKs) should be increasing steadily. Assuming you have the correct CC frequency, the most common troubles tuning are: not using the proper PPM correction (-q parameter), failing to add an offset (I usually use -o 50000), incorrect RTL gain setting via the --gains (-N) parameter, incorrect use of FSK4 mode on an LSM P25 system (and vice-versa, using the CQPSK mode on a C4FM P25 system)... Tuning in the CQPSK mode is fussier than in FSK4 mode, and messages should get written to the stderr file in the event of a slight mistuning...
Max
Hi Max --
Attached are several screenshots from a recent run. The first run used "-P constellation" and you can see the gnuplot output, as well as the error messages in the console where I'm tailing stderr.2
The second run disabled the gnuplot output and the -T command. The console window remained empty with no output. Note the sample rate error that's partially on the console screen and partially in the stderr.2 output.
I suspect that sample rate is the crux of the issue, as KB9MWR also noted this morning. Sometimes, I see the sample rate being set correctly but most of the time get the errors shown in the screenshots: it appears that the -S parameter is not being caught, the default 320000 rate is used, and that's failing as invalid. (I normally use 250000 as the rate, but have tried with 1000000 and get the same results).
Hope this helps.
John ----
On 07/02/2017 01:30 PM, ikj1234i@yahoo.com [op25-dev] wrote:
Hi John
we need to do a better job of documenting the process of initial acquisition of the system. The process itself could be made easier, as could 1,000 other things...
Could you post the command line you're running, and if possible post a screen print of the 'datascope' and 'constellation' plots...
The best approach usually has been to first get the control channel coming in well in manual tuning mode (i.e., no -T parameter), then (and only then) to try to get voice decode working. In rx.py the way you'll know when the CC is tuned correctly is the number in the upper-right corner of the page (TSBKs) should be increasing steadily. Assuming you have the correct CC frequency, the most common troubles tuning are: not using the proper PPM correction (-q parameter), failing to add an offset (I usually use -o 50000), incorrect RTL gain setting via the --gains (-N) parameter, incorrect use of FSK4 mode on an LSM P25 system (and vice-versa, using the CQPSK mode on a C4FM P25 system)... Tuning in the CQPSK mode is fussier than in FSK4 mode, and messages should get written to the stderr file in the event of a slight mistuning...
Max
I have a question about rx.py. I run it with: ./rx.py --args 'rtl' -N LNA:49 -f 772.63125e6 -S 2560000 -q 0 -V -T trunk.tsv 2>stderr.1 tail -F stderr.1 (by the way it would be great it this would output to the screen better)
All I ever see is: NAC 0x4a1 WACN 0x1 SYSID 0x1 0.000000/0.000000 tskbs 3
Frequency: 772.631250
It it safe to assume when there is traffic on the system, I should be seeing more on that screen? Or at least that it sees the WACN, etc?
looking into the "invalid sample rate" issue, from your screen print we see "Invalid sample rate: 320000 Hz"
it initially appears to be coming from this code in src/librtlsdr.c: /* check if the rate is supported by the resampler */ if ((samp_rate <= 225000) || (samp_rate > 3200000) || ((samp_rate > 300000) && (samp_rate <= 900000))) { fprintf(stderr, "Invalid sample rate: %u Hz\n", samp_rate); return -EINVAL; }
which simply indicates that 320,000 isn't allowed.
In your command you had -s 1000000 - it's easy to miss (I missed several times) but in OP25 the "S" needs to be capitalized!!!!!
Also, to eliminate OP25, you can retry using the CLI program "osmocom_fft -s 1000000". It should be possible to get at least as far as the spectrum showing reception of the trunk CC....
Max
-
ikj1234i＠yahoo.com [op25-dev] -
John Ackermann N8UR jra＠febo.com [op25-dev]
-
kb9mwr＠yahoo.com [op25-dev]