2 Jul
2017
2 Jul
'17
5:15 p.m.
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
2 Jul
2 Jul
7:30 p.m.
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
7:52 p.m.
New subject: rx.py progress [5 Attachments]
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(a)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
3 Jul
3 Jul
11:56 p.m.
New subject: rx.py progress [1 Attachment]
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?
4 Jul
4 Jul
7:30 p.m.
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
2494
days inactive
2496
days old
4 comments
3 participants
participants (3)
-
ikj1234i＠yahoo.com [op25-dev] -
John Ackermann N8UR jra＠febo.com [op25-dev]
-
kb9mwr＠yahoo.com [op25-dev]