Op25, randomly stops outputing audio

[iloverf]

I recently started using Op25 to monitor a simulcast P25 system in my area. While I have it working for the most part, I'm still having a few problems. The main problem I'm trying to troubleshoot is:

I'll be scanning through my talkgroup whitelist, I'm receiving transmissions just fine, I'll notice I haven't heard anything in a while and look over at Op25, the UI is stopping on active TGs & the terminal window that op25 was launched from is scrolling the tell tale lines indicating decoded transmissions, but I'm not hearing any audio. If I click on another tab (I've been told to leave Op25 on the Constellation tab for my particular p25 system, unless I'm checking something) such as Datascope, and then back to Constellation, this almost always restores audio. (and then the problem happens again).

Any ideas whats going on here?

 

[iloverf]

After playing around and observing this behavior longer, it appears that if I leave everything alone op25 starts outputting audio from received transmissions again after some time.

 

[AggieCon]

I've been thinking about this, and I'll see if I can replicate it myself.

For me, most of the time it is jumping from conversation to conversation non-stop. Sometimes there might be a slight delay (max 5-10 seconds) before it returns to the CC and finds a new call. I'll have to confirm with UniTrunker, but I think the system you monitor might be on conversation mode instead of per call mode (i.e. the voice channel is held for a few seconds in case there is a follow up call on the same talkgroup, rather than a new channel being assigned for each and every call).

Send me your current whitelist, and I will run it tomorrow. I'll run UniTrunker too so I can have an idea of the system activity.

 

[PiccoIntegra]

I haven't come across this problem before, unless there is a tuning issue. Which system/site are you monitoring, and what command line are you using?

 

[iloverf]

E-mailed you my whitelist, Aggie.

I'm starting op25 with:

./scope.py --args rtl=0 -f 855.85e6 -o 10000 -N LNA:46 -S 2000000 -V -2 -T txw.tsv

The random sample rate is from when I was trying to improve audio quality and was just trying different sample rates. The problem also occurs with my previous sample rate of 2048000.

 

[PiccoIntegra]

I'm not seeing 855.85 on any of the TxWARN sites. Which one are you monitoring?

 

[iloverf]

I'm monitoring the Montgomery County simulcast TXWARN system. I got the scopy.py params from AggieCon, and it worked for me. But you're right, I'm not seeing that particular frequency listed on radioreference... I'll wait for him to chime in!

 

[PiccoIntegra]

Try this:

./scope.py --args='rtl=0' -f 853.8375e6 -o 10000 -N 'LNA:46' -S 960000 -V -2 -T txw.tsv

Your RTL doesn't have enough bandwidth(8.2MHz) to cover that site, so run a lower sample rate. Running it at higher sample rate doesn't give you any advantage in this case. An Airspy R2 might cover that site without re-tuning the receiver, 8.2MHz is pushing it though..

 

[AggieCon]

Alright, I am scanning it, and I have your whitelist in. By the way, did you change the file name? I think in the trunking file I sent you, the whitelist was called w1.tsv.

I think the frequency in the script is just a random frequency in the vicinity of the systems I scan. It is my understanding that the software utilizes the frequency listed in the trunking file. Is there a reason having it not match is bad? Obviously, when you scan multiple trunked systems/sites, it is impossible for all of the control channels to match the one in the script.

How long would you estimate these holds are?

Sure, mine might hand on a call for a few seconds, maybe 5-10 at most, but nothing like minutes.

The folks at the airport sure like to talk... EMERGENCY SOMEONE LEFT THEIR PHONE ON A PLANE.

 

[AggieCon]

Well, she got her cell phone back.

If UniTrunker is correct, the system does hold some of the calls on the same voice channel, at least with the MCSO calls.

Are you running the branch I told you about or the original install?

If anything, I might be missing a few calls on OP25 because it is missing the CC command, but I don't know that for sure yet. I'm using a crap antenna for OP25 and my best antenna for UniTrunker. Even with that setup, OP25 is going almost perfectly, yet UniTrunker is having a hard time getting out of the red. So the UniTrunker output can't be trusted fully.

 

[iloverf]

AggieCon,

I made a new whitelist, named it whitelist.tsv and changed the whitelist parameter in txw.tsv.

I'm using the TXWARN.sh you gave me to launch, the only thing that is different is I removed the -q PPM adjustment and made my own whitelist.

The period of time where no calls are audible is not the few second delay you see before op25 switches from the active voice channel back to the cc. That is pretty predictable (and nice, it lets you hear a rapid fire series of transmissions on a single channel before beginning to scan again). When my problem occurs, I'll look over and I see the Op25 display cycling through active TGs, with no audio, for minutes at a time until I tab over and back to Constellation. If I leave it long enough, transmissions become audible again.

I'll have to watch i closer and see if I can get some ballpark times for the above to happen in. I am running the newer branch you told me about.

Yeah, the big emergency at IAH earlier was a bag of Ambien found in front of the restrooms.

 

[iloverf]

Just happened after Op25 running for about 8 minutes... I switched tabs and audio was restored, this was after I watched Op25 cycle through 6-7 active TGs with no audio heard.Nothing unusual logged in the terminal window when the problem is occurring.

 

[iloverf]

And this past time I just let it go, took about 3 minutes of cycling through active TGs and audio finally returned. From everything I'm seeing during this time Op25 is receiving transmissions (op25 stops on 4-5 different TGs, repeatedly) terminal window output is indicative of decoded transmissions...

Weird, I suppose it could be something funky with virtualization or my Linux distro...

 

[AggieCon]

So there's another aspect to this problem that I think might be related. I know of at least two OP25 users experiencing this.

Medziatkowicz35 said:

I just all of a sudden got like people talking even though nothing showed up. Like it was queued and all came at once. Is that normal?

He has been having a heck of a time getting the audio to function properly.

iloverf said:

I'm also noticing that after I leave op25 running for some time, I'll notice that I'm listening to an impossibly rapid-fire string of radio comms (dispatch, replies from units, replies from dispatch, etc) which to me seems like a built up buffer of transmissions playing out of synch of real time. If that makes any sense...

Any ideas on this?

 

[natedawg1604]

And this past time I just let it go, took about 3 minutes of cycling through active TGs and audio finally returned. From everything I'm seeing during this time Op25 is receiving transmissions (op25 stops on 4-5 different TGs, repeatedly) terminal window output is indicative of decoded transmissions...

Weird, I suppose it could be something funky with virtualization or my Linux distro...

Very few people have reported success with Virtualization & OP-25, you may want to consider getting a dedicated linux box (I use a dual-boot machine).

 

[PiccoIntegra]

So there's another aspect to this problem that I think might be related. I know of at least two OP25 users experiencing this.

The virtual environment seems to be the common denominator here. Sorry, I don't recommend that type of setup, so I don't have any suggestions.

 

[AggieCon]

I run in a virtual environment and do not experience their problem.

I still haven't dissected all of the OP25 code.

Is there a diagram or description of the data flow?

I'm wondering if the audio is being held up somewhere at a decoder, or if it is a problem with the virtualization client not passing the audio.

Thanks for the help, though.

 

[PiccoIntegra]

The way GNU Radio works is each connected block gets processed based on a shared schedule. There isn't anything in the chain in OP25 that gets queued. If things are getting clogged up and delayed, then there is some memory/swap space/cpu deficiency going on.

Your answer will not be in the code, it'll be in the VM configuration.

 

[natedawg1604]

I run in a virtual environment and do not experience their problem.

I still haven't dissected all of the OP25 code.

Is there a diagram or description of the data flow?

I'm wondering if the audio is being held up somewhere at a decoder, or if it is a problem with the virtualization client not passing the audio.

Thanks for the help, though.

What setup are you running?

 

[AggieCon]

My host PC is Windows 10 (gag) 64 bit. 32 GB Ram. i7 @ 3.5. SSD, video card, etc.

Using VM Ware Player 12.

Ubuntu 14.04.

Again, I'm not having the problem. One of the folks having the problem has a very similar virtualization setup to me, and, another, iloverf was using virtualbox but, I think, switched to VM Ware Player. I am not sure what version of linux he has.