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
  #1841 (permalink)  
Old 02-13-2018, 1:04 PM
WX4JCW's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Jun 2006
Location: All Over
Posts: 1,811
Default

Install time 5 Minutes, finally got to listen while in the Chicago area to Starcom21
Perfect Audio Decode- Nice and clean, thanks Boatbod you rock
Attached Images
 
__________________
Jason WX4JCW EMD/FF/EMT RET
Like Johnny Cash's Song I've been everywhere man, ive been everywhere and monitored it
SDS100,XPR7550,SDR
Reply With Quote
Sponsored links
  #1842 (permalink)  
Old 02-13-2018, 5:12 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by WX4JCW View Post
Install time 5 Minutes, finally got to listen while in the Chicago area to Starcom21
Perfect Audio Decode- Nice and clean, thanks Boatbod you rock
Not just me... This is really Max's baby, I just added some stuff around the edges.
Reply With Quote
  #1843 (permalink)  
Old 02-13-2018, 8:22 PM
SDRPlayer's Avatar
Member
   
Join Date: Jul 2016
Location: Victoria, Australia
Posts: 71
Default

and a big thank you to Max also. I recall having a go at OP25 a couple of years back and never managed to get it going smoothly. That's all changed now.
Reply With Quote
  #1844 (permalink)  
Old 02-13-2018, 9:21 PM
Member
   
Join Date: Sep 2007
Posts: 6
Default

I'll give you all kudos as well. I used the older version for a while but really needed it to be more portable. The new version allowed me to install on the first edition Microsoft Surface running Ubuntu 16.04. It runs like a top!
Reply With Quote
  #1845 (permalink)  
Old 02-16-2018, 9:41 AM
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2016
Location: Linden, VA
Posts: 6
Default

I'd like to weigh in with my own kudos to the devs who have worked on op25 and also to everyone who shared their experiences in this long-lived thread. I was itching to monitor some local Phase II systems, and reading through this whole thread got me up and running pretty much without issues. The few minor hiccups I ran across were easily resolved with a few thread searches and some trial and error. As I type this, I'm listening to the Fairfax County Phase II system, so it works!
Reply With Quote
Sponsored links
  #1846 (permalink)  
Old 02-18-2018, 3:03 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

I got some time to look a bit closer at my "lost words" problem. After adding some extra debug, I noticed something that seems odd. For a simple single transmission (not a conversation), it appears that after we return to the control channel, we do an extra bounce back into the voice channel, due to a op=02 (voice channel grant update). I can't say if this is happening every time, but it is happening a lot. Debug log from an example below. Note that I added some extra debug, upped the level of the "tsbk02" message, and lowered the level of "set tgid" (because it was too noisy).

Significant events that I see:

357.730 - received op=00 voice channel grant
357.733 - set freq to voice channel
358.181 - receiving LDUs (note: missed HDU)
364.795 - received TDU15
364.795 - set freq to control channel (772506250)
365.147 - receiving TBSKs
365.343 - received op=02 voice channel grant update
365.344 - set freq back to voice channel again
365.674 - received another TDU15
365.675 - set freq back to control channel again
365.994 - receiving TSBKs

(From my possibly-naive perspective) it seems a bit odd that we get a op=02 TSBK when the voice session is already terminating. I wonder if we can suppress (ignore) it somehow, without side-effects...

Code:
1518985357.730693 NAC 0x1f6 TSBK: op=00 : 00 00 04 17 bc 1e 23 3d 30 16 b9 14
1518985357.730932 NAC 0x1f6 TSBK: op=3a : ba 00 00 31 f1 01 06 16 90 70 0d 16
1518985357.732593 new tgid: 7715 CCSO East prio 2
1518985357.733371 new freq: 774.381250
1518985357.733575 voice update:  tg(7715), freq(774381250), slot(None), prio(2)
1518985357.733779 before set_center_freq(774381250.000000) for target 774381250.000000
1518985357.786277 after set_center_freq()
1518985357.787992 after set_freq sync stuff
1518985357.791257 NAC 0x1f6 TSBK: op=3b : 3b 00 00 be e0 01 f1 16 90 70 36 33
1518985357.791594 NAC 0x1f6 TSBK: op=00 : 00 00 04 17 bc 1e 23 3d 30 16 b9 14
1518985357.791918 NAC 0x1f6 TSBK: op=3c : bc 00 00 31 f1 01 02 17 96 70 29 ce
1518985357.820261 NAC 0x1f6 TSBK: op=05 : 05 90 40 00 00 00 00 00 00 00 27 13
1518985357.820626 NAC 0x1f6 TSBK: op=02 : 02 00 17 bc 1e 23 17 bc 1e 23 f2 ee
1518985357.820865 NAC 0x1f6 TSBK: op=16 : 96 00 00 c0 17 7c ff ff 00 01 5a 7e
tsbk02 grant update: chan 774.381250 7715 774.381250 7715
1518985357.929840 NAC 0x1f6 TSBK: op=3d : 3d 00 03 22 d0 32 0a 25 10 a2 63 a0
1518985357.930188 NAC 0x1f6 TSBK: op=3d : 3d 00 13 25 e0 32 09 15 75 62 1b 36
1518985357.930427 NAC 0x1f6 TSBK: op=30 : b0 00 00 04 2a 24 52 a2 d3 9c 0c c0
1518985358.181919 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985358.371024 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 08 01 9d 70
1518985358.620012 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985358.763678 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985358.944659 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985359.080757 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985359.267966 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985359.515203 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 02 17 96 70
1518985359.654532 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985359.838934 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985359.975684 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985360.222743 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 05 17 c8 70
1518985360.418134 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985360.548765 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985360.733830 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985360.930088 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 08 01 9d 70
1518985361.116028 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985361.258187 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985361.443217 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985361.628607 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 02 17 96 70
1518985361.824880 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985362.010872 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985362.152272 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985362.337678 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 05 17 c8 70
1518985362.525814 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985362.722209 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985362.910839 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985363.100315 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 08 01 9d 70
1518985363.235176 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985363.421922 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985363.618983 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985363.811183 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 02 17 96 70
1518985363.942415 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985364.189143 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=4010006, grpaddr=7715 :  00 00 04 00 1e 23 3d 30 16
1518985364.334381 NAC 0x1f6 LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00
1518985364.510112 NAC 0x1f6 LDU1: LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 05 17 c8 70
1518985364.712461 NAC 0x1f6 LDU2:
1518985364.795243 NAC 0x1f6 TDU3:
1518985364.795465 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=0, grpaddr=7715 :  00 00 04 00 1e 23 00 00 00
1518985364.795543 duid15, tg(7715)
1518985364.795730 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 08 01 9d 70
1518985364.795757 before set_center_freq(772506250.000000) for target 772506250.000000
1518985364.836591 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=0, grpaddr=7715 :  00 00 04 00 1e 23 00 00 00
1518985364.845940 after set_center_freq()
1518985364.846140 after set_freq sync stuff
1518985364.898798 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 02 17 96 70
1518985364.960847 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=0, grpaddr=7715 :  00 00 04 00 1e 23 00 00 00
1518985364.961605 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=34 :  62 00 31 f1 01 05 17 c8 70
1518985365.022687 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=0, lco=0, srcaddr=0, grpaddr=7715 :  00 00 04 00 1e 23 00 00 00
1518985365.147003 NAC 0x1f6 TSBK: op=3d : 3d 00 03 22 d0 32 0a 25 10 a2 63 a0
1518985365.147215 NAC 0x1f6 TSBK: op=3d : 3d 00 13 25 e0 32 09 15 75 62 1b 36
1518985365.147337 NAC 0x1f6 TSBK: op=30 : b0 00 00 04 2a 24 52 a2 d7 5c 19 48
1518985365.158433 NAC 0x1f6 TSBK: op=09 : 09 90 0d c0 00 00 00 00 00 00 16 cc
1518985365.158636 NAC 0x1f6 TSBK: op=39 : 39 00 01 06 16 30 04 16 c0 04 67 f5
1518985365.158757 NAC 0x1f6 TSBK: op=3a : ba 00 00 31 f1 01 06 16 90 70 0d 16
1518985365.280768 NAC 0x1f6 TSBK: op=3b : 3b 00 00 be e0 01 f1 16 90 70 36 33
1518985365.280985 NAC 0x1f6 TSBK: op=3c : 3c 00 00 31 f1 01 02 17 96 70 cd fa
1518985365.281106 NAC 0x1f6 TSBK: op=05 : 85 90 40 00 00 00 00 00 00 00 c3 27
1518985365.343306 NAC 0x1f6 TSBK: op=02 : 02 00 17 bc 1e 23 17 bc 1e 23 f2 ee
1518985365.343519 NAC 0x1f6 TSBK: op=16 : 16 00 00 c0 17 7c ff ff 00 01 be 4a
1518985365.343641 NAC 0x1f6 TSBK: op=33 : b3 00 23 38 40 64 0a 25 15 tsbk02 grant update: chan 774.381250 7715 774.381250 7715
84 ac 7f
1518985365.343817 voice update:  tg(7715), freq(774381250), slot(None), prio(2)
1518985365.344029 before set_center_freq(774381250.000000) for target 774381250.000000
1518985365.393844 after set_center_freq()
1518985365.394041 after set_freq sync stuff
1518985365.405658 NAC 0x1f6 TSBK: op=33 : 33 00 33 a5 80 64 09 15 75 62 75 fc
1518985365.405874 NAC 0x1f6 TSBK: op=30 : 30 00 00 04 2a 24 52 a2 d7 84 b7 09
1518985365.405994 NAC 0x1f6 TSBK: op=09 : 89 90 0d c0 00 00 00 00 00 00 f2 f8
1518985365.476625 NAC 0x1f6 TSBK: op=39 : 39 00 01 06 16 c0 04 16 00 04 4e f7
1518985365.476834 NAC 0x1f6 TSBK: op=3a : 3a 00 00 31 f1 01 06 16 90 70 e9 22
1518985365.476956 NAC 0x1f6 TSBK: op=3b : bb 00 00 be e0 01 f1 16 90 70 d2 07
1518985365.548947 NAC 0x1f6 TSBK: op=3c : 3c 00 00 31 f1 01 05 17 c8 70 b1 67
1518985365.549295 NAC 0x1f6 TSBK: op=05 : 05 90 40 00 00 00 00 00 00 00 27 13
1518985365.549537 NAC 0x1f6 TSBK: op=16 : 96 00 00 c0 17 7c ff ff 00 01 5a 7e
1518985365.674411 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=15 :  4f 00 00 00 00 00 ff ff fd
1518985365.674832 duid15, tg(7715)
1518985365.675495 before set_center_freq(772506250.000000) for target 772506250.000000
1518985365.727631 after set_center_freq()
1518985365.727889 after set_freq sync stuff
1518985365.734326 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=15 :  4f 00 00 00 00 00 ff ff fd
1518985365.791253 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=15 :  4f 00 00 00 00 00 ff ff fd
1518985365.792005 NAC 0x1f6 TDU15:  LCW: ec=0, pb=0, sf=1, lco=15 :  4f 00 00 00 00 00 ff ff fd
1518985365.994426 NAC 0x1f6 TSBK: op=3a : 3a 00 00 31 f1 01 06 16 90 70 e9 22
1518985365.999873 NAC 0x1f6 TSBK: op=3b : 3b 00 00 be e0 01 f1 16 90 70 36 33
1518985366.000118 NAC 0x1f6 TSBK: op=3c : bc 00 00 31 f1 01 02 17 96 70 29 ce
1518985366.114277 NAC 0x1f6 TSBK: op=05 : 05 90 40 00 00 00 00 00 00 00 27 13
1518985366.114625 NAC 0x1f6 TSBK: op=16 : 16 00 00 c0 17 7c ff ff 00 01 be 4a
1518985366.114886 NAC 0x1f6 TSBK: op=3d : bd 00 03 22 d0 32 0a 25 10 a2 87 94
1518985366.175517 NAC 0x1f6 TSBK: op=3d : 3d 00 13 25 e0 32 09 15 75 62 1b 36
1518985366.175867 NAC 0x1f6 TSBK: op=30 : 30 00 00 04 2a 24 52 a2 d7 e8 1a 23
1518985366.176109 NAC 0x1f6 TSBK: op=09 : 89 90 0c 80 00 00 00 00 00 00 68 c7
1518985366.244573 NAC 0x1f6 TSBK: op=39 : 39 00 01 06 16 c0 04 16 00 04 4e f7
Reply With Quote
  #1847 (permalink)  
Old 02-18-2018, 4:51 PM
Homeboys-Scanna's Avatar
Member
   
Join Date: Feb 2008
Posts: 1,683
Default

Question, so I won't have to read 46+ pages of this thread. How do we install the latest version on a VMWare running on Windows 7? Thanks.
__________________
"Copy, 132 and Bush, cover's code 3."
Reply With Quote
  #1848 (permalink)  
Old 02-18-2018, 5:14 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by Homeboys-Scanna View Post
Question, so I won't have to read 46+ pages of this thread. How do we install the latest version on a VMWare running on Windows 7? Thanks.
Once you have VMWare and Ubuntu 16.04 installed, clone your chosen op25 repo and then run the ./install.sh script found in the ~/op25 directory. From there you edit the config files and create a script to start up rx.py with the appropriate options. The answers are all somewhere in those 93 pages that you are trying to avoid reading
Reply With Quote
  #1849 (permalink)  
Old 02-19-2018, 9:42 AM
Member
  Amateur Radio Operator
Amateur Radio
 
Join Date: Aug 2008
Posts: 430
Default

Quote:
Originally Posted by dseven View Post

(From my possibly-naive perspective) it seems a bit odd that we get a op=02 TSBK when the voice session is already terminating. I wonder if we can suppress (ignore) it somehow, without side-effects...
This is a "normal" happening in P25P1. During the interval between the end of a transmission and the cessation of grant messages for that TGID on the CC, the voice channel will send a series of Link Control terminators. I don't know if it's possible to tell based solely on the CC grant messages whether the voice channel is sending voice or terminators. Assuming it's not, then the only reasonable action would be to retune from the CC back to the VC. When using the center frequency option especially, it is common to see several switches back and forth during this interval. When not using the center frequency option the SDR must retune each time. This process should be instantaneous but unfortunately in some cases there can be a delay. In your time logs the delay looks to be ~300 Msec. This latency may be the root cause of the chopped audio, the missing HDU that you reported, etc..........

73

Max
Reply With Quote
  #1850 (permalink)  
Old 02-19-2018, 2:09 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by KA1RBI View Post
This is a "normal" happening in P25P1. During the interval between the end of a transmission and the cessation of grant messages for that TGID on the CC, the voice channel will send a series of Link Control terminators. I don't know if it's possible to tell based solely on the CC grant messages whether the voice channel is sending voice or terminators. Assuming it's not, then the only reasonable action would be to retune from the CC back to the VC. When using the center frequency option especially, it is common to see several switches back and forth during this interval. When not using the center frequency option the SDR must retune each time. This process should be instantaneous but unfortunately in some cases there can be a delay. In your time logs the delay looks to be ~300 Msec. This latency may be the root cause of the chopped audio, the missing HDU that you reported, etc..........

73

Max
I'm not aware of anything in either the GRANT or UPDATE messages that lets you know the voice channel is in the process of being terminated. The only place that information is conveyed is on the voice channel itself via the DUID3 or DUID15 messages.

Unfortunately there's not a whole lot that can be done without causing other issues. Conceivably you could ignore the DUID15 channel release and remain on the voice channel until either framing is lost/another call appears/a timer expires but that's certainly not how the P25 call handling was intended to be implemented by the spec writers. Ignoring the grant/update messages doesn't seem like it would be viable either since these are the only way to determine when a call is being made on a voice channel.

I suspect the solution to your missed words is really related to the time it takes to retune and start decoding. Do you see any difference in tuning time between offset tuning (center freq defined and within range) and hard retuning where the dongle physically has to change frequencies? I tried to examine at this on my system, but I've been having trouble finding enough spare hours in the day to look in to it recently.
Reply With Quote
  #1851 (permalink)  
Old 02-19-2018, 2:52 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Quote:
Originally Posted by boatbod View Post
I'm not aware of anything in either the GRANT or UPDATE messages that lets you know the voice channel is in the process of being terminated. The only place that information is conveyed is on the voice channel itself via the DUID3 or DUID15 messages.
The update TSBK during termination appears to be identical to the one near the start of the session, so presumably there's nothing useful in there :/

Quote:
Unfortunately there's not a whole lot that can be done without causing other issues. Conceivably you could ignore the DUID15 channel release and remain on the voice channel until either framing is lost/another call appears/a timer expires but that's certainly not how the P25 call handling was intended to be implemented by the spec writers
I've been wondering if it might be helpful to hang on the VC for a short while (half a second or so), then return to the CC if nothing else has happened. I've been trying to reverse-engineer the "wait_until" logical to see if it could be adapted/extended to do this.

Quote:
I suspect the solution to your missed words is really related to the time it takes to retune and start decoding. Do you see any difference in tuning time between offset tuning (center freq defined and within range) and hard retuning where the dongle physically has to change frequencies? I tried to examine at this on my system, but I've been having trouble finding enough spare hours in the day to look in to it recently.
I hear that! It's also difficult to get representative test cases when you're relying on traffic from external sources - too much traffic, and it's a lot of work to parse the logs, but when you try to limit it (e.g. whitelisting TGs), they go quiet

I'll try to explore offset tuning today. It's probably not a solution for me (the system I monitor would require more bandwidth than I think the RPi could handle, even if I got a dongle that could cover it).... but it'd be interesting to know.

I'd also be interested to see tuning times from other dongle types....
Reply With Quote
  #1852 (permalink)  
Old 02-19-2018, 4:10 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Hmm, relative tuning (first time I've tried it, I think) died with:

Code:
1519077869.139066 NAC 0x1f6 TSBK: op=00 : 00 00 04 15 d0 1c ed 41 20 4e ad 96
1519077869.139184 NAC 0x1f6 TSBK: op=09 : 89 90 0d c0 00 00 00 00 00 00 f2 f8
1519077869.139710 new tgid: 7405 Pittsburg PD1 prio 3
1519077869.140030 new freq: 771.306250
1519077869.140181 voice update:  tg(7405), freq(771306250), slot(None), prio(3)
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "./rx.py", line 787, in run
    self.callback(msg)
  File "/home/pi/op25/op25/gr-op25_repeater/apps/trunking.py", line 846, in process_qmsg
    self.update_state('update', curr_time)
  File "/home/pi/op25/op25/gr-op25_repeater/apps/trunking.py", line 1104, in update_state
    'sysid':  tsys.ns_syid})
  File "/home/pi/op25/op25/gr-op25_repeater/apps/trunking.py", line 624, in set_frequency
    self.frequency_set(params)
  File "./rx.py", line 409, in change_freq
    if self.demod.set_relative_frequency(self.lo_freq):                 # relative tune successful
  File "/home/pi/op25/op25/gr-op25_repeater/apps/p25_demodulator.py", line 311, in set_relative_frequency
    self.t_cache[freq] = filter.firdes.complex_band_pass(1.0, self.input_rate, -freq - self.if1/2, -freq + self.if1/2, self.if1/2, filter.firdes.WIN_HAMMING)
  File "/usr/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py", line 206, in complex_band_pass
    return _filter_swig.firdes_complex_band_pass(*args, **kwargs)
RuntimeError: firdes check failed: 0 < fa <= sampling_freq / 2
Command line was:

Code:
./rx.py --args 'rtl' --gains lna:25 -f 772.26875e6 -q -1 -S 2048000 -o 0 -d 0 -w -U -T /tmp/trunk.56Phcs.tsv -v10
and trunk file:

Code:
"Sysname"       "Control Channel List"  "Offset"        "NAC"   "Modulation"    "TGID Tags File"        "Whitelist"     "Blacklist"     "Center Frequency"
"cce"   "772.50625"     "0"     "0"     "CQPSK" "/home/pi/my-op25/cce_groups.tsv"       ""      "1010,7005,7006,7007,7008,7009,7055,7056,10224"   772.26875
Reply With Quote
  #1853 (permalink)  
Old 02-19-2018, 5:28 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Code:
        elif params['center_frequency']:
            relative_freq = center_freq - freq
            if abs(relative_freq + self.options.offset) > self.channel_rate / 2:
                self.lo_freq = self.options.offset                                      # relative tune not possible
                self.demod.set_relative_frequency(self.lo_freq)                         # reset demod relative freq
                self.set_freq(freq + offset)                                            # direct tune instead
Shouldn't that take into account the width of the signal to be decoded? Otherwise, it seems that up to half of the signal could be cut off ... I think ...
Reply With Quote
  #1854 (permalink)  
Old 02-19-2018, 8:00 PM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by dseven View Post
Hmm, relative tuning (first time I've tried it, I think) :
and trunk file:

Code:
"Sysname"       "Control Channel List"  "Offset"        "NAC"   "Modulation"    "TGID Tags File"        "Whitelist"     "Blacklist"     "Center Frequency"
"cce"   "772.50625"     "0"     "0"     "CQPSK" "/home/pi/my-op25/cce_groups.tsv"       ""      "1010,7005,7006,7007,7008,7009,7055,7056,10224"   772.26875
I think you might be missing the quotes around that center frequency.

Quote:
Originally Posted by dseven View Post
Code:
        elif params['center_frequency']:
            relative_freq = center_freq - freq
            if abs(relative_freq + self.options.offset) > self.channel_rate / 2:
                self.lo_freq = self.options.offset                                      # relative tune not possible
                self.demod.set_relative_frequency(self.lo_freq)                         # reset demod relative freq
                self.set_freq(freq + offset)                                            # direct tune instead
Shouldn't that take into account the width of the signal to be decoded? Otherwise, it seems that up to half of the signal could be cut off ... I think ...
You may be right about that, but it'd have to be really close to the limit to get cut off. Practically speaking the center frequency tuning appears to work fine as currently implemented.
Reply With Quote
  #1855 (permalink)  
Old 02-19-2018, 9:19 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Quote:
Originally Posted by boatbod View Post
I think you might be missing the quotes around that center frequency.
The quotes are only required (by csv.reader) if the value contains special characters.

Quote:
You may be right about that, but it'd have to be really close to the limit to get cut off. Practically speaking the center frequency tuning appears to work fine as currently implemented.
After getting that earlier exception, I changed my sample rate to 2560000 (which the RPi3 seems to be handling OK so-far, BTW), and it's been working since. I just tried to change it back to 2048000, and now it won't even get the CC - just a bunch of:

Code:
p25_framer::rx_sym() tuning error +1200
I change sample rate back to 2560000, and it works again. Removing the center frequency, with the sample rate at 2048000, also works. Hmmm!
Reply With Quote
  #1856 (permalink)  
Old 02-20-2018, 6:26 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by dseven View Post
The quotes are only required (by csv.reader) if the value contains special characters.



After getting that earlier exception, I changed my sample rate to 2560000 (which the RPi3 seems to be handling OK so-far, BTW), and it's been working since. I just tried to change it back to 2048000, and now it won't even get the CC - just a bunch of:

Code:
p25_framer::rx_sym() tuning error +1200
I change sample rate back to 2560000, and it works again. Removing the center frequency, with the sample rate at 2048000, also works. Hmmm!
Sometimes changing the sampling rate sometimes can cause the tuning to be far enough off that the Gardner-Costas loop locks at 90deg to where it should. When this happens you see the +/- 1200 tuning error messages.

I recommend going into the mixer plot (#5) and tweak the fine tuning to re-center the display, then use the value in parentheses after the tuned frequency with the -d command line option at startup. NOTE: you shouldn't need any more than about +/- 350 to make it work. If the fine tune is outside this range you should adjust ppm correction by +/- 1 instead.

ETA: if you tuning is a wee bit off center that could explain why it might be taking longer to lock and decode after a frequency change.
Reply With Quote
  #1857 (permalink)  
Old 02-20-2018, 8:14 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Quote:
Originally Posted by boatbod View Post
Sometimes changing the sampling rate sometimes can cause the tuning to be far enough off that the Gardner-Costas loop locks at 90deg to where it should. When this happens you see the +/- 1200 tuning error messages.
Why would that matter for relative tuning more than for regular (center) tuning?

Quote:
I recommend going into the mixer plot (#5) and tweak the fine tuning to re-center the display, then use the value in parentheses after the tuned frequency with the -d command line option at startup. NOTE: you shouldn't need any more than about +/- 350 to make it work. If the fine tune is outside this range you should adjust ppm correction by +/- 1 instead.
I can't do plots on the headless RPi :/

I did try to look at fine-tuning a bit ago, but didn't find it helpful, so stopped using it (just using PPM of -1). I put my fine-tuning of 360 back in, and now it seems to be finding the CC, but it's crashing with the "firdes check failed" RuntimeError again.

Quote:
ETA: if you tuning is a wee bit off center that could explain why it might be taking longer to lock and decode after a frequency change.
I did experiment with that, but couldn't find a fine-tuning value that made it noticeably better.
Reply With Quote
  #1858 (permalink)  
Old 02-21-2018, 6:57 AM
Member
  Premium Subscriber
Premium Subscriber
 
Join Date: Mar 2007
Location: Talbot Co, MD
Posts: 992
Default

Quote:
Originally Posted by dseven View Post
Why would that matter for relative tuning more than for regular (center) tuning?
It shouldn't, but I have seen instances where just changing the sampling rate to a smaller number caused a loss of lock on the control channel and then I had to adjust fine tune to get it back. It seems that if tuning is off just enough, the costas loop can't lock in, or locks at the wrong phase. Once it's locker properly however, tuning can be off consideraly and it will stay locked until retuning.

Quote:
Originally Posted by dseven View Post
I can't do plots on the headless RPi :/
If you have another linux box you should be able to make it work. When you ssh in to the rpi3, use the command "ssh -X" to have the X display backhauled to your local terminal.
Quote:
Originally Posted by dseven View Post
I did try to look at fine-tuning a bit ago, but didn't find it helpful, so stopped using it (just using PPM of -1). I put my fine-tuning of 360 back in, and now it seems to be finding the CC, but it's crashing with the "firdes check failed" RuntimeError again.



I did experiment with that, but couldn't find a fine-tuning value that made it noticeably better.
I'm not in a place I can look at the firdes error right now, but it seems like one of the parameters being passed in must not be getting set correctly under some circumstances.
Reply With Quote
  #1859 (permalink)  
Old 02-21-2018, 7:16 PM
SDRPlayer's Avatar
Member
   
Join Date: Jul 2016
Location: Victoria, Australia
Posts: 71
Default

I have had the same loss of lock issue when changing to a smaller sample rate with sdrtrunk on linux. Thanks for the explanation. Hasn't happened with OP25 which continues to run like a dream.
Reply With Quote
  #1860 (permalink)  
Old 02-21-2018, 7:30 PM
dseven's Avatar
Member
  Premium Subscriber
Premium Subscriber
Amateur Radio Operator
Amateur Radio
 
Join Date: Sep 2008
Location: SF Bay / Delta, CA
Posts: 225
Default

Quote:
Originally Posted by boatbod View Post
I recommend going into the mixer plot (#5) and tweak the fine tuning to re-center the display, then use the value in parentheses after the tuned frequency with the -d command line option at startup. NOTE: you shouldn't need any more than about +/- 350 to make it work. If the fine tune is outside this range you should adjust ppm correction by +/- 1 instead.
Here's the plot from a VM (same dongle) with zero fine-tuning. Looks pretty well centered to me ... ?
Attached Images
 
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 7:57 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, 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