RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Computer Aided Monitoring and Programming > Software Defined Radio


Software Defined Radio - A forum for general discussion of software defined radio (SDR) receiver equipment.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #61 (permalink)  
Old 07-05-2017, 8:03 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: Klein, TX
Posts: 87
Default

Quote:
Originally Posted by KA1RBI View Post
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
That works just fine , now if we can work past this freeze up where the channel timer counter keep counting but it stops refreshing or tuning.
Reply With Quote
Sponsored links
  #62 (permalink)  
Old 07-05-2017, 8:14 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: Klein, TX
Posts: 87
Default

Quote:
Originally Posted by mrlindstrom View Post
That works just fine , now if we can work past this freeze up where the channel timer counter keep counting but it stops refreshing or tuning.
I left it running for a while after one of those "freezes" and it finally came back to life on its own. Not sure what is causing it, but I was also watching the Gnuplot window and can see it re-tuning to the different control channels, but the list of voice frequencies never changes until it comes of the "freeze"
Reply With Quote
  #63 (permalink)  
Old 07-05-2017, 8:42 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

If the system times out (-2 sec) trying to decode the control channel it will retune to the next one in the list. Sounds like the "freeze" is really loss of signal or at least it quits decoding for some reason. Wonder if your tuning is of just a wee bit?
Reply With Quote
  #64 (permalink)  
Old 07-05-2017, 9:44 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: Klein, TX
Posts: 87
Default

Quote:
Originally Posted by boatbod View Post
If the system times out (-2 sec) trying to decode the control channel it will retune to the next one in the list. Sounds like the "freeze" is really loss of signal or at least it quits decoding for some reason. Wonder if your tuning is of just a wee bit?
I think the tuning if fine, but all I really have to go by is the plot:
Reply With Quote
  #65 (permalink)  
Old 07-06-2017, 6:28 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by mrlindstrom View Post
I think the tuning if fine, but all I really have to go by is the plot:
That plot looks nice and tight.
Reply With Quote
Sponsored links
  #66 (permalink)  
Old 07-06-2017, 7:45 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 383
Default

Quote:
Originally Posted by mrlindstrom View Post
That works just fine , now if we can work past this freeze up where the channel timer counter keep counting but it stops refreshing or tuning.
well, something's going on but we'll need to zero in on what, exactly. First, it's normal for the "tsbks" counter to stop increasing during the interval when OP25 is tuned to a voice call. Only when it's sitting on the CC with no voice activity will the tsbks count increase. Also, it could be hunting for a CC and tuning through the list of CCs in the trunk TSV file.

Before proceeding further it would be good to rule out both of these. For the first, it can be observed by direct inspection whether this is the case or not (look at the lower left side of the rx.py page to see if there's an active call). The second question can be ruled out by (temporarily, for testing) removing all but the "active" CC from the trunk TSV file. If it's neither of these things we'll have some additional tests to run....

What exactly does the gnuplot window look like during a "freeze"?

Max
Reply With Quote
  #67 (permalink)  
Old 07-06-2017, 8:34 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: Klein, TX
Posts: 87
Default

Quote:
Originally Posted by KA1RBI View Post
well, something's going on but we'll need to zero in on what, exactly. First, it's normal for the "tsbks" counter to stop increasing during the interval when OP25 is tuned to a voice call. Only when it's sitting on the CC with no voice activity will the tsbks count increase. Also, it could be hunting for a CC and tuning through the list of CCs in the trunk TSV file.

Before proceeding further it would be good to rule out both of these. For the first, it can be observed by direct inspection whether this is the case or not (look at the lower left side of the rx.py page to see if there's an active call). The second question can be ruled out by (temporarily, for testing) removing all but the "active" CC from the trunk TSV file. If it's neither of these things we'll have some additional tests to run....

What exactly does the gnuplot window look like during a "freeze"?

Max
There are only 2 different CC's in the trunk file, and the second one definitely isn't as close as the first so the signal isn't as good. But during the "freeze" the plot will alternate between the image I posted earlier and these other two:




Here is an example of the channel timers continuing to count for unknown reasons:

Reply With Quote
  #68 (permalink)  
Old 07-06-2017, 11:10 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by mrlindstrom View Post
There are only 2 different CC's in the trunk file, and the second one definitely isn't as close as the first so the signal isn't as good. But during the "freeze" the plot will alternate between the image I posted earlier and these other two:




Here is an example of the channel timers continuing to count for unknown reasons:

TGs# 591 & 651 were seen just 0.4 seconds prior to the screen shot being taken, so I would conclude that it appears to be both receiving and continuing to decode. Perhaps I'm not fully understanding your issue?
Reply With Quote
  #69 (permalink)  
Old 07-06-2017, 2:11 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: Klein, TX
Posts: 87
Default

Quote:
Originally Posted by boatbod View Post
TGs# 591 & 651 were seen just 0.4 seconds prior to the screen shot being taken, so I would conclude that it appears to be both receiving and continuing to decode. Perhaps I'm not fully understanding your issue?
I think I may just be misunderstanding the point of those timers. Will it always show channels it has seen even if no traffic is currently on them and that is what the timer is showing (how long since the last signal?)
Reply With Quote
  #70 (permalink)  
Old 07-06-2017, 2:21 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 383
Default

Quote:
Originally Posted by mrlindstrom View Post
But during the "freeze" the plot will alternate between the image I posted earlier and these other two:
Neither of these constellations is as good as the first but both are nonetheless distinctive LSM constellations. It looks like there might be some channels in the system served via different subsets of transmission towers than others? Additionally in the first of these two it's clearly not properly phase locked - this could indicate a slight, remaining tuning error and it's possible it might be related to a PPM error in the RTL being slightly more inaccurate at 850 than at 770 MHz?

But the significant issue/question is what is going on during the "freeze" periods... To clarify, you're saying the "tsbks" count stops increasing during the freeze? If so that suggests OP25 is tuned to what it thinks is a voice channel, which should be confirmed by looking in the lower-left corner of the screen... As far as the frequency list is concerned it appears that some of the system frequencies are rarely used - that's why the "seconds ago" value is comparatively large. These values are all aged according to the most recent appearance in CC grant messages - updates though are only seen when tuned to the CC, not to a VC.
Reply With Quote
  #71 (permalink)  
Old 07-06-2017, 5:17 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by mrlindstrom View Post
I think I may just be misunderstanding the point of those timers. Will it always show channels it has seen even if no traffic is currently on them and that is what the timer is showing (how long since the last signal?)
Over time, op25 monitors the control channel and builds a listing of active voice frequencies and the last two most recently seen TGIDs using those frequencies. The timer tells you how long ago the frequency was last used and a total count of how many times it was used. Depending on radio system configuration, some frequencies in the pool may be used a lot more than others. On my local phase 2 system for example, one of the frequencies has been used nearly 500,000 times while the next busiest has only be used 139,000 times.
Reply With Quote
  #72 (permalink)  
Old 07-11-2017, 7:13 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 383
Default

Quote:
Originally Posted by kb9mwr View Post
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.
kb9mwr - how are you making out? Is the audio working at this point? Are you running on the R PI?

Max
Reply With Quote
  #73 (permalink)  
Old 07-12-2017, 4:09 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 86
Default

Thanks for checking up Max. Works good, just had another local guy successfully replicate what I did today.
I could use some pointers on what is needed to get this thing to start the rx.py process at boot (as I plan to use this headless). Is it just me or does Debian have a picky environmental policy?
Reply With Quote
  #74 (permalink)  
Old 07-13-2017, 6:28 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 86
Default

Nevermind, I should have picked up quicker that the 2>stderr.2 from the rx.sh script was basically preventing a proper background process and redirect to /dev/null.
Reply With Quote
  #75 (permalink)  
Old 07-13-2017, 8:37 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by kb9mwr View Post
Nevermind, I should have picked up quicker that the 2>stderr.2 from the rx.sh script was basically preventing a proper background process and redirect to /dev/null.
Perhaps it would be worth thinking about syslog as a logging destination instead of stderr?
Reply With Quote
  #76 (permalink)  
Old 07-14-2017, 2:04 PM
Newbie
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2016
Location: Green Bay,WI
Posts: 1
Default

Here's a quick and dirty startup script to run at boot

In the rx.sh script remove the 2>stderr.2

#!/bin/bash
cd /home/pi/op25/op25/gr-op25_repeater/apps
nohup ./listen.sh > /dev/null 2>&1 &
nohup ./rx.sh > /dev/null 2>&1 &


then add the script to /etc/rc.local


-Brent
Reply With Quote
  #77 (permalink)  
Old 07-15-2017, 7:32 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 86
Default

My observations are that the Pi with OP25 sometimes misses very short or very quick response transmissions. Seems like it just can’t switch fast enough back and forth between the control channel and any given voice trunk on the system. I have tried various sample rates thinking this would lessen the processor load and help this. I'd be curious to hear from others running OP25 on single board computers.

I am half tempted to try a different board. I am not sure what would be the best. The Rock65/Pine64 Media Board Computer looks like something maybe worth considering.
Reply With Quote
  #78 (permalink)  
Old 07-16-2017, 9:56 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by kb9mwr View Post
My observations are that the Pi with OP25 sometimes misses very short or very quick response transmissions. Seems like it just can’t switch fast enough back and forth between the control channel and any given voice trunk on the system. I have tried various sample rates thinking this would lessen the processor load and help this. I'd be curious to hear from others running OP25 on single board computers.

I am half tempted to try a different board. I am not sure what would be the best. The Rock65/Pine64 Media Board Computer looks like something maybe worth considering.
I think the only way to tell this for sure would be to run two systems on the exact same codebase in parallel and figure out if one missed a transmission that the other caught. I've done that with my two PC based systems (one an old i5 and one a newer i7) and found it very rare for either to miss, but it does happen sometimes. Pi 3B on it's way to me this week - will report what I find out.

As an aside, are you using relative tuning (center freq) or is the RTL retuning every time?
Reply With Quote
  #79 (permalink)  
Old 07-16-2017, 2:06 PM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Apr 2003
Location: Green Bay, WI
Posts: 86
Default

I was having it tune every time. Thanks for the tip. Took a while, but adding -o 12.5e3 made a big difference.

I made a blog entry to help the next person who attempts to install and run this on a Pi.
http://kb9mwr.blogspot.com/2017/07/l...simulcast.html

Last edited by kb9mwr; 07-16-2017 at 2:29 PM..
Reply With Quote
  #80 (permalink)  
Old 07-16-2017, 8:01 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 520
Default

Quote:
Originally Posted by kb9mwr View Post
I was having it tune every time. Thanks for the tip. Took a while, but adding -o 12.5e3 made a big difference.

I made a blog entry to help the next person who attempts to install and run this on a Pi.
Advancing Ham Radio.. different ideas: Listening to local 700 MHz Simulcast public safety cheaply
I think you'll find that "-o 125000" is Offset, not Center Frequency (relative tuning) which is the last parameter in trunk.tsv.
- - - -
My much anticipated Pi3 Model B surprised me by arriving today (thanks Amazon!) and it is now up and running op25 with audio decode to the on-board headphone jack. It works pretty well and plays uninterrupted sound (no glitches!) but the cpu is basically maxed and the on-board audio hardware has quite a lot of background noise compared to a pc. Lowing the rtl sample size from 1440000 to 960000 helped reduce cpu impact (from 120% when idling on the control channel down to 94%) and eliminated the occasional "O" that appeared before. Needless to say that was without any gnuplots and running headless with no gui.

Note: Using the current raspbian-jessie release I found several required libraries/packages were missing from the build dependencies and had to be installed using apt-get before I was able to successfully compile and run the code.
Code:
libboost-all-dev
liblog4cpp5-dev
swig
cmake
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 4:58 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2015 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions