OP25 Monitor multiple talkgroups at once

Status
Not open for further replies.

Dunkuts

Member
Joined
Jan 27, 2017
Messages
4
Has anyone had any luck getting OP25 to monitor more then one talkgroup at a time with an RTL dongle? I have OP25 setup and decoding the local system one talk group at a time currently. All of the channels fall within a 2mhz spread, so only one dongle should be needed.

I am trying to emulate what is being done on RepeaterPage but using an RTL-SDR instead of a USRP. The directions talk about making modifications to usrp_rx.py but no where is that file present after installing OP25. I was also trying to locate the gnuradio OP25 block to create a custom gnuradio flowchart to handle the multiple VFOs but it does not appear to be in the git repository.

Ideally I would like to configure OP25 similar to how SDRTrunk works, but with more then 2 outputs. SDRTrunk works well on this system with an Airspy, but the RTL lacks the sensitivity to get a good decode with SDRTrunk. Somehow the RTL dongle works perfectly well with OP25 however.

I also tried to configure Unitrunker but since it is a P25 Phase 1 LSM system DSDPlus can not handle the decode.

Has anyone gotten this to work who can provide some insight into the next step?
 

AZScanner

Member
Joined
Dec 19, 2002
Messages
3,342
Location
Somewhere in this room. Right now, you're very col
You need to use Logging mode. Logging mode will sit on the control channel and whenever a talkgroup goes active it fires up a logging "worker" to decode the talkgroup and write the audio to a wav file. It's not a trivial matter to get this working right, and OP25 likes to bomb out on me after a while (I'm sure it's because I don't have the center frequency quite right) but the script below is what I use to make OP25 log all traffic on Simulcast B of the Pima County system using just one dongle.

Code:
source ~/target/setup_env.sh
cd ~/pybombs/src/gr-op25/op25/gr-op25_repeater/apps
for (( ; ; ))
do
./scope.py --args "rtl=0" -N 'LNA:46' -f 853.925e6 -S 2400000 -q 0 -v 0 -2 -L 6 -T pcwin_sim_b.tsv
sleep 10
done

An explanation of the parameters:
"rtl=0" = where Linux sees the dongle
-N 'LNA:46' = the amount of gain to use
-f The control channel frequency (always follow this with e6 so it knows you mean megahertz)
-S 240000 - Samples per second.
-q 0 - PPm offset. I'm using the NooElec that comes in a metal enclosure and found it needs no PPM correction.
-v 0 Log Verbosity (if I remember correctly)
-L 6 The number of loggers to run. Too many loggers = poor decoding and 0 byte wave files. Not enough loggers gives you an error message to that effect when you run out. You'll need to play with this setting for a while to find a good balance based on your processor and the volume of traffic on the system itself.
-T Trunktrack using this file.

This is a shell script I run in Bash as Sudo. I then have other scripts that take the finished wav files, move them to another folder and then I have some PHP code I've wrapped around the whole thing to create an online "scanner" of sorts. Still very much a work in progress, but I hope to publicly release something soon.

You've gotten as far as following the system with OP25 so that's the biggest hurdle right there - setting up logging is not too much more challenging from that point. For more tips, pointers and far better knowledge of OP25 and Linux than I have, check out the SDR forum and read up on my VirtualBox thread - TONS of great info in there from some awesome folks who helped greatly to get me this far with it. Definitely look into how OP25 uses those TSV files - problems in that file will translate to headaches for you. ;)

Edited to add: Another tip - if you are running OP25 in a VM then forget trying to run a logger unless you have an absolute BEAST of a machine. Mine runs on a dedicated Intel Nuc i7 with 8 GB of ram and a 1TB harddrive. Set me back about a grand, but well worth it - I have the equivalent of 6 digital scanners for the price of 2 :)

-AZ
 
Last edited:

CanesFan95

Active Member
Joined
Feb 14, 2008
Messages
3,011
Location
FL
Hmmm, I use DSD+ on a local P25 mixed Phase 1 and 2 simulcast system and DSD+ seems to decode Phase I OK (but not great). Are you saying DSD+ does not properly decode simulcast P25 like the all the crappy scanners?
 

Dunkuts

Member
Joined
Jan 27, 2017
Messages
4
Thanks, that will get me one step closer to my uberscaner. I was looking into the logging feature earlier, but I did not see a way of playing the files it recorded. Looks like ill have to figure out a script to convert them to mp3 for storage and then play them back in some sort of order.

The TSV file was a bit of a hassle, but much easier to cut and paste from raidoreference then to edit the XML for SDRTrunk. I read through most of the OP25 virtual thread, and helped with the initial setup. I was able to get OP25 and SDRTrunk to both run smoothly in a VMware VM, but id rather keep my main box free. The extra layer in the USB stack also seemed have an adverse effect on the decoding.

Ive got SDRTrunk/OP25 running on physical box with a quad core i5 with 4 gig of ram pretty smoothly right now with a bit more CPU room to spare. I like the idea of the NUC, opens up the option of a vehicle mounted super scanner....
 

Dunkuts

Member
Joined
Jan 27, 2017
Messages
4
Hmmm, I use DSD+ on a local P25 mixed Phase 1 and 2 simulcast system and DSD+ seems to decode Phase I OK (but not great). Are you saying DSD+ does not properly decode simulcast P25 like the all the crappy scanners?

The issue with DSD and my local P25 Phase one is that it is a LSM simulcast system. If you use the fast track version and only monitor a single channel I think it works fine. The issue is when you add unitrunker to the mix. It pipes the FM audio to DSD but you loose the AM data in the original signal. The AM signal data is what makes the P25 system simulcast system work.

I think it works by the data being transited as the FM signal and timing is the AM signal. Decoding with just the FM leads to very stuttered decoding. The scanners are not using the FM only signal so they are able to decode it without issue. The same effect should apply if you pipe a discriminator tapped scanner into DSD, you end up with only half the signal.

That may not be how it works, but it is what I was able to piece together from various posts.
 

br0adband

Member
Joined
Apr 8, 2005
Messages
1,567
Location
Springfield MO
Homeboys-Scanna: You just posted a question about P25 Phase I and Phase II reception and LSM related issues in another thread you created so I provided an answer there you should take a peek at:

http://forums.radioreference.com/ge...ptions-p25-phase-ii-simulcast-monitoring.html

DSD+ is only for P25 Phase I (hopefully someday the devs can add P25 Phase II support) and if you're serious about monitoring Phase II (and Phase I of course) then the answer lies in that post I made in the other thread - yes, even LSM-based systems can be monitored with great levels of success.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
Hmmm, I use DSD+ on a local P25 mixed Phase 1 and 2 simulcast system and DSD+ seems to decode Phase I OK (but not great). Are you saying DSD+ does not properly decode simulcast P25 like the all the crappy scanners?
He said Unitrunker plus DSD+. That doesn't work well for PSK signals. Doesn't matter whether they're simulcast or not. PSK optimization (-mp) in DSD+ helps, but still isn't great.

You're using the latest DSD+ with FMPA/FMP24 and TCP linking and that does handle PSK signals.
 

Dunkuts

Member
Joined
Jan 27, 2017
Messages
4
slicerwizard is correct, my comments were about the public release, not the fast track.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
The OP25 log-all-talkgroups-simultaneously-to-disk feature is described in the wiki page

SignalScopePage

Annoyingly this doesn't work for systems spanning more than 2.4 MHz when using the RTL. A system with a 2 MHz span should fit nicely. The worst mismatch of all occurs if attempting to log a 700/800 mixed system. OP25 will work though with these systems, but only in "conventional" trunk-call-following mode, not in disk-logging mode.

The files that are generated are 16-bit WAV format (mono) at 8,000 Hz. Since they contain codec-(de)compressed data they may or may not re-compress well in other codecs.....

Max
 
Status
Not open for further replies.
Top