RPi 3 & RTL-SDR/OP25?

[KA1RBI]

Thanks! Started a new folder from scratch and did the checkout first, that got it.

just to note, the new rx.py version has enough changes in it that it won't run correctly using an install of the "old" version of OP25. Accordingly, I recommend that you do a "sudo make uninstall" from the "build" directory of your previous installation. Then do a full build/install of the new version (after checking out the "max" br)...

Max

 

[kb9mwr]

Thanks for the help Max. I added the offset. The only errors I am seeing in the logs are the usual gnu plot related ones. So I believe it to be on frequency. (I have even tried a second RTL-SDR stick that I have) The tsbks number never really changes. I have tried outdoor antennas and indoor. It makes very little difference. I am right smack dab in the middle of 3 or 4 of the simulcast towers. So I really shouldn't have a signal strength issue. It comes in great on my XTS-2500 no matter where I am in the house.

I changed it to fsk4/datascope and here is a picture from that.

Update:
I changed the sampling rate and now I have the four groups and increasing tsbks and voice freq info!

Thanks, I am overjoyed

 

[mrlindstrom]

Just curious, but are there any plans to try to allow op25 to control multiple sdr devices to allow it to truly trunk track? We have some systems around here that have channels in the 770-774 range and the 851-854 range and op25 only seems to like to dial in to the 700mhz channels when watching for traffic.

 

[KA1RBI]

Just curious, but are there any plans to try to allow op25 to control multiple sdr devices to allow it to truly trunk track? We have some systems around here that have channels in the 770-774 range and the 851-854 range and op25 only seems to like to dial in to the 700mhz channels when watching for traffic.

When scanning a trunked system in which the range of frequencies exceeds the width of the sampling window, it doesn't do much good to use a "center frequency" since anything outside of the band will fail. If you set the center frequency to zero (or omit) OP25 will fall back to a mode where it retunes the SDR each time the rx frequency needs to be changed, i.e., whenever there is a switch between the CC to/from a VC. (In this way OP25 works exactly as would a conventional scanner when in trunked operation).

I think there may have been a bug somewhere perhaps in the drivers that caused this switching to be very slow, but it seems to be much better now using current drivers and the latest OP25.

I'd expect the 700/800 systems to work OK now as well. If not, it would be good to do a proper diagnosis and comparison of the 700/800 system versus a system that isn't spread across multiple bands, using a center frequency of zero in both cases...

To answer the original question, there aren't currently plans - it's definitely not trivial to do...

Max

 

[mrlindstrom]

When scanning a trunked system in which the range of frequencies exceeds the width of the sampling window, it doesn't do much good to use a "center frequency" since anything outside of the band will fail. If you set the center frequency to zero (or omit) OP25 will fall back to a mode where it retunes the SDR each time the rx frequency needs to be changed, i.e., whenever there is a switch between the CC to/from a VC. (In this way OP25 works exactly as would a conventional scanner when in trunked operation).

I think there may have been a bug somewhere perhaps in the drivers that caused this switching to be very slow, but it seems to be much better now using current drivers and the latest OP25.

I'd expect the 700/800 systems to work OK now as well. If not, it would be good to do a proper diagnosis and comparison of the 700/800 system versus a system that isn't spread across multiple bands, using a center frequency of zero in both cases...

To answer the original question, there aren't currently plans - it's definitely not trivial to do...

Max

If I omit the center frequency or set it to 0, this is what I end up with:

gr-osmosdr 0.1.1 (0.1.1) gnuradio 3.7.2.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
Using device #1 Realtek RTL2838UHIDIR SN: 00000002
Found Rafael Micro R820T tuner
main: exception occurred
main: exception:
Traceback (most recent call last):
  File "./rx.py", line 642, in <module>
    if tb.process_qmsg(msg):
  File "./rx.py", line 601, in process_qmsg
    js = self.trunk_rx.to_json()
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 100, in __getattr__
    return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'trunk_rx'

Traceback (most recent call last):
  File "./rx.py", line 649, in <module>
    if tb.kill_sink:
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 100, in __getattr__
    return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'kill_sink'

 

[boatbod]

Update:
I changed the sampling rate and now I have the four groups and increasing tsbks and voice freq info!

yay! Glad it's working now.

Just curious, but are there any plans to try to allow op25 to control multiple sdr devices to allow it to truly trunk track? We have some systems around here that have channels in the 770-774 range and the 851-854 range and op25 only seems to like to dial in to the 700mhz channels when watching for traffic.

My variation of rx.py has changes to the relative tuning code so that it never fails to tune if outside the receive window. If a center frequency is defined and it can tune relative, it will do so, otherwise it will retune the receiver itself so it's basically seamless. The version of rx.py in the repository doesn't do that yet, and will fail if it tries to tune outside the range.

If I omit the center frequency or set it to 0, this is what I end up with:

gr-osmosdr 0.1.1 (0.1.1) gnuradio 3.7.2.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
Using device #1 Realtek RTL2838UHIDIR SN: 00000002
Found Rafael Micro R820T tuner
main: exception occurred
main: exception:
Traceback (most recent call last):
  File "./rx.py", line 642, in <module>
    if tb.process_qmsg(msg):
  File "./rx.py", line 601, in process_qmsg
    js = self.trunk_rx.to_json()
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 100, in __getattr__
    return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'trunk_rx'

Traceback (most recent call last):
  File "./rx.py", line 649, in <module>
    if tb.kill_sink:
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 100, in __getattr__
    return getattr(self._tb, name)
AttributeError: 'top_block_sptr' object has no attribute 'kill_sink'

I believe you have a corrupt trunk.tsv file. The center frequency is the very last field; if you are trying to eliminate the center frequency I suggest deleting every white space/tab character following the blacklist filename and you should be ok. You might also make sure there is no blank line below the one with the valid data on it.

 

[kb9mwr]

yay! Glad it's working now.

Yeah, I was hopeful that was all I needed. I still have a nice climbing tsbks and see the voice channels... but have yet to hear a peep with the netcat method. Till I hear something with it, I'm not even sure it makes sense to move to trying the socksaudio thing.

I can play a .wav fille and hear that fine.

./rx.py  --args 'rtl' --gains 'lna:49' -f 772.63125e6 -T trunk.tsv -q 0 -D cqpsk  -o 50000 -S 1000000 -P constellation -w 2> stderr.2
And in another terminal:
nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

I do occasionally get a connection closed, listening again message but that is it.

 

[boatbod]

./rx.py  --args 'rtl' --gains 'lna:49' -f 772.63125e6 -T trunk.tsv -q 0 -D cqpsk  -o 50000 -S 1000000 -P constellation -w 2> stderr.2
And in another terminal:
nc -kluvw 1 127.0.0.1 23456 | aplay -c1 -f S16_LE -r 8000

I do occasionally get a connection closed, listening again message but that is it.

When I used netcat, this was the command line that worked best for me:

nc -kluv 127.0.0.1 23456 | aplay --period-size=32 --buffer-size=1024 -c 1 -f S16_LE -r 8000

You appear to have an additional "w 1" in the "-kluv" sequence.

 

[KA1RBI]

have yet to hear a peep with the netcat method.

is your system p2/tdma? I need to fix the readme file, which fails to mention that for phase 2/tdma you need to add the "-2" option to rx.py... Other wise if the system is p1 fdma, I'll have some other tests for you - lmk...

Max

 

[kb9mwr]

No its not, its a Phase 1, P25, Simulcast system.

 

[KA1RBI]

No its not, its a Phase 1, P25, Simulcast system.

OK let's have you do the following, for test purposes. It should produce a large amount of formatted "hex" output. To use this, run rx.py as before, and instead of the usual netcat and aplay combo, let's have you do this:

nc -kluv 127.0.0.1 23456 | od -v -t x1

This should produce large amounts of "hex" output. If not let me know. If so, CTRL-C that command, and then do

nc -kluv 127.0.0.1 23456 | cat > temp.raw

the temp.raw file is (almost) in the form of a .WAV file (16-bit, mono, 8K rate). The presence, length, and content of that file is the same as what would have been played by the "aplay" command:

cat temp.raw | aplay -c1 -f S16_LE -r 8000

Max

 

[KA1RBI]

If I omit the center frequency or set it to 0, this is what I end up with:

Traceback (most recent call last):

I've been unable to duplicate this here, it's possible it's just a race condition, or it's possible there's something more involved. In order to hopefully rule out the race condition, I've pushed a possible fix for this crash to the 'max' branch of the repo. It's pure python, so no rebuild should be needed. Could you try

git pull origin max

and then try again. It should be perfectly legal to specify a zero/empty center frequency!

Max

 

[kb9mwr]

OK let's have you do the following, for test purposes. It should produce a large amount of formatted "hex" output. To use this, run rx.py as before, and instead of the usual netcat and aplay combo, let's have you do this:

nc -kluv 127.0.0.1 23456 | od -v -t x1

This should produce large amounts of "hex" output. If not let me know. If so, CTRL-C that command, and then do

Its not.

 

[boatbod]

Its not.

It's not trunking. There is nothing showing up at the bottom of the curses terminal screen where I'd expect it to say "Frequency xxx.xxxxxx" or a TGID and tag name. The screen is displaying exactly what it would if you ran the system without the -T trunk.tsv command line option. It must be some issue with command line parameters or something like that. Most odd.

ETA: I've been trying to reproduce what might be wrong, and the only partial success I've had borking the config by setting the control channel frequency to 0 inside trunk.tsv. Even then on my system it eventually recovers and starts working.

Here is an example of my terminal screen after it's been running for a while. No voice was playing at the time, but you'll note there are lists of tgid's in the "voice frequency" lines along with duration and count. The bottom of the screen shows the control channel frequency.

 

[kb9mwr]

My bad, you are right I had the wrong shell script called to start rx.py (which had -T omitted)

However when I do add -T trunk.tsv, then the constellation goes to heck, and acts like its not decoding the control channel, back to none of the expected stuff on the terminal screen.

So something must be wrong with my trunk.tsv file. I checked the tabbing, and that is correct.
(This is the system I am trying to monitor https://www.radioreference.com/apps/db/?sid=7511)

Edit: I took out the center freq just left "" and now its working! (Getting the hex voice dumps)
Its so incredibly close to intelligible audio on Pi2 (with the sockaudio mod)... I am sure it will work fine on a Pi3 (just ordered one).. Thanks Max and boatbod.. this is a great piece of software. Has a learning curve, but anything cool usually does.

 

[mrlindstrom]

I've been unable to duplicate this here, it's possible it's just a race condition, or it's possible there's something more involved. In order to hopefully rule out the race condition, I've pushed a possible fix for this crash to the 'max' branch of the repo. It's pure python, so no rebuild should be needed. Could you try

git pull origin max

and then try again. It should be perfectly legal to specify a zero/empty center frequency!

Max

It no longer seems to crash, but now I just have a blank screen and this is the stderr.2:

gr-osmosdr 0.1.1 (0.1.1) gnuradio 3.7.2.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
Using device #1 Realtek RTL2838UHIDIR SN: 00000002
Found Rafael Micro R820T tuner
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

However, if I run it with my normal -f parameter, it runs just fine.

 

[boatbod]

The trunk.tsv file entries look ok except I'd dump the center frequency stuff you have tacked on the end, at least for now anyway. Try removing the command line offset (-o 50000) and see if that gets you back on frequency.

If you are able to run my latest code, the FFT plot (-P fft) will show you exactly where you are tuned with a line and writes a "Tuned to xxx.xxxxxx" at the top of the screen. Unfortunately you'll have to pull all the code changes to make that feature work, since it requires changes to both rx.py and gr_gnuplot.py, and in turn those require sockaudio.py and that needs supporting library changes.... cascading effect! In absence of this, we have to assume you are tuned correctly as long as "tsbks" are increasing steadily. If they are not, then maybe the scrambled constellation is indeed indicating you have lost the tune.

 

[KA1RBI]

However, if I run it with my normal -f parameter, it runs just fine.

Ah, OK. could you post the command line you're running when it's not working

 

[mrlindstrom]

Ah, OK. could you post the command line you're running when it's not working

./rx.py --args rtl=1 -N LNA:46 -S 1024000 -f 0 -q -1 -V -T trunk.tsv -P constellation -w -2 2> stderr.2

 

[KA1RBI]

./rx.py --args rtl=1 -N LNA:46 -S 1024000 -f 0 -q -1 -V -T trunk.tsv -P constellation -w -2 2> stderr.2

ok that looks like the problem. For silly historical reasons the frequency must be present and valid even when using -T - even though the trunk CC frequency(s) in the trunk TSV override the -f value the -f must still be present.

So, let's have you go back to giving a valid frequency via "-f", and change the "Center" frequency in the trunking TSV to zero...

Max