Thanks for the quick replies. Attached are:

1. trunk.tsv and the local talkgroup list montgomery.tsv

2. Screenshot of the console after starting, using -v 255.

3. Screenshots of spectrum, datascope, constellation, and traffic.

Here is the command line I'm using: ./scope.py --args 'rtl' -f 853.5e6 -N 'LNA:35' -o 17e3 -V -v 255 -S 2480000 -q 0 -T trunk.tsv

My RTL-SDR.com dongle seems to be just about on frequency; it has a TCXO. I've messed with PPM correction as well as fine tuning and, though I'm not sure just what I should be looking for, changing those in either direction tends to result in tuning error messages.

I am not sure if Montgomery County is C4FM or CQPSK. Radio Reference seems to indicate C4FM; I've mainly used that, but tried CQPSK a couple of times with no "traffic" shown in either case.

Thanks!

John ---- On 06/09/2017 09:44 AM, 'wa8wg' wa8wg@centurytel.net [op25-dev] wrote:

John,

You should normally get an error message when starting scope.py if your trunk.tsv if your trunking system occupies more bandwidth than is supported by the sample rate capability of your SDR. Maybe you could post your trunk.tsv for a look see? However, it sounds like your constellation doesn’t look the best. Is scope showing the P25 frames being decoded and does it indicate any errors on those frames? I have my op25/GNU Radio running on Ubuntu 14.04 virtualized in Oracle VIrtualBox on my Windows 10 laptop.

Bill, WA8WG

William G. Becks, WA8WG

N7027 Shady Lane Circle

Porterfield, WI 54159

Telephone: 715.735.0131

E-Mail: wa8wg@centurytel.net mailto:wa8wg@centurytel.net

*From:*op25-dev@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *Sent:* Friday, June 9, 2017 7:28 AM *To:* op25-dev@yahoogroups.com *Subject:* [op25-dev] OP25 setup once built

Hi --

After looking at the archives, I think I may need to use a different software branch, but here's where I stand:

1. Downloaded OP25 from the oscomcom site.

2. Built without any problems on Mint 17.04 with Gnuradio 3.7.11.

Computer is an i7 laptop with 8GB RAM. I'm using an RTL-SDR dongle for now; I can try a USRP but wanted to start with the simpler hardware.

3. Cobbled up .tsv files for local P25 system (Ohio MARCS-IP,

Montgomery County site, C4FM). This site has 30 channels and the 2.4 msps rate of the dongle can't catch them all, but I am covering the control channel pllus several more channels.

4. Scope.py seems to run fine with all windows looking proper.

Selecting some tabs causes timeout errors on the console, but those stop when I switch tabs..

5. I seem to be tuned to the control channel (853.600) and see a

not-terrible constellation.

6. But I don't see any traffic decoding, much less get any audio (I

know that the 30 channels at this site are spread over a bandwidth greater than the RTL-SDR dongle can provide; I can bring a USRP to the game but for now would be happy just to decode control data.

I'd appreciate any help, particularly on what the scope.py command line should look like. And should I be using a version other than what is on the Osmocom site?

Thanks much,

John Ackermann N8UR jra@febo.com mailto:jra@febo.com

Thanks much. I think I was confusing (or was confused by) the way the Radio Reference database provided the site information. The statewide network number is 0x343, but there's also an individual site ID (0x25A). I mistakenly took the site ID as the NAC. Easy to fix.

You're talking about LSM, which I don't recognize. The modulation options appear to be C4FM and CQPSK. I assume that LSM == CQPSK?

I'll play around with these suggestions later today. Thanks!

John ----

On 06/09/2017 11:37 AM, ikj1234i@yahoo.com [op25-dev] wrote:

ok the console window indicates you're receiving on a NAC of 0x343 whereas the traffic tab shows a NAC of 0x25A. (with respect to these two NACs, your trunk.tsv is totally daft). This is certainly one problem. At the stage you're at you should forego the trunk TSV and use manual mode until the trunk CC is properly acquired.

Separately the datascope indicates a very strong LSM signal (i.e., not C4FM), so you'll need to use the constellation tab for normal ops. If you stay on the datascope tab it will (incorrectly) use the C4FM demod, this is a legacy of scope.py. Based on that constellation any attempt to use C4FM will fail miserably, it's pretty nasty and a really good example of why C4FM demods won't work well on LSM.

One other thing is that your datacscope tab isn't centered vertically, it suggests the tuning is slightly below where it should be tuned. This can be adjusted using the -q pa rameter and fine tuned using the slider...

Max

Thanks!

I've tried rebuilding the trunk.tsv file from scratch and it seems that if I call it, almost no matter what it contains, I don't get any traffic. If I don't call it, I decode the control channel just fine.

I wonder if there might be an issue with my installation, because although I did "make install" and saw a bunch of stuff loaded into /usr/local/lib and usr/local/share, nothing went into /usr/local/bin. I have to run scope.py from within ~/op25/op25/gr-op25_repeater/apps; if I try to copy and run it from elsewhere, it fails with complaints about modules not being found. Therefore, I wonder where it's looking for the .tsv files, and whether there might be something more fundamentally broken.

Thanks again for the help.

John ----

On 06/09/2017 01:02 PM, Brett Friermood brett.friermood@gmail.com [op25-dev] wrote:

On Fri, Jun 9, 2017 at 10:55 AM, John Ackermann N8UR jra@febo.com mailto:jra@febo.com [op25-dev] <op25-dev@yahoogroups.com mailto:op25-dev@yahoogroups.com> wrote:

You're talking about LSM, which I don't recognize.  The modulation
options appear to be C4FM and CQPSK.  I assume that LSM == CQPSK?

Correct, LSM (Linear Simulcast Modulation) is Motorola's version/name for CQPSK, similar to PL (Private Line) for CTCSS, and ASTRO for Project 25 digital voice.

Things are working now. My problem was that the Radio Reference site info confused me by listing a "System ID" (348) and a "Site NAC" (25A) but not the 343 NAC.

1. Attached copy-paste from Radio Reference.

2. Attached current trunk.tsv.

3. Attached screenshot of the traffic tab.

4. I also changed hardware from RTL-SDR.com dongle to HackRF; this site has channels spread over 9+ MHz so the dongle missed most channels. HackRF doesn't get them all, but there are only a couple that are outside its sample rate. At some point I'll hook up my USRP2 and cover 10 MHz.

Thanks again for the help! I will separately post a couple of more minor questions now that the big rock has been moved.

John ----

On 06/09/2017 01:57 PM, ikj1234i@yahoo.com [op25-dev] wrote:

let's have you post a copy of the "Traffic" tab (fully populated) and your revised trunk TSV file

On 06/09/2017 04:31 PM, ikj1234i@yahoo.com [op25-dev] wrote:

your rtl-sdr should work fine on any system as long as you don't specify a "center frequency" in the trunk TSV. If you omit the center frequency OP25 retunes the SDR as needed to follow calls. The only real exception is when using the log all TGs to disk mode, in which case you need to span the entire range of the system.

So do I then just use the control channel as the frequency on the command line? And in that case, is there any point in running the dongle at full sample rate to maximize bandwidth, or can I back down and reduce the CPU load?

As far as white lists you need not list the TGs in the trunk TSV, you can specify a file name in that position of the trunk TSV. Having both a white list and a black list at the same time is nonsensical since the white list enables only TGs in the list.

Excellent! Yes, I understand that white and black list are mutually exclusive.

Instead of putting scope.py in /usr/local/bin which hasn't been provided for in the install procedure it might be better to write a small sh script that cd's to the proper directory and invokes scope.py from there.

OK.

Finally as far as the choppy audio there are a couple of possibilities - poor reception due to DX reception of certain towers/sites/ TGs is one, also is it possible that these TGs are phase 2/TDMA?

I don't think there are any phase 2 TGs in the system (yet) but I'll dig further. I seem to have a pretty much line-of-site path to the main site, but I don't know if there are satellite sites that might be interfering as you say.

There was one other question I may have asked in the other thread: what's the best way to capture frequency and talkgroup data to a file? I want to build a list of the site frequencies, and all the talkgroups seen. Basically, to capture the output of the "traffic" window.

Max

Thanks again for all your help. I really wasn't expecting to get everything working so well in one day!

John ----

As you suggested, I deleted the "-T trunk.tsv" and set the frequency to the control channel. Now I'm seeing lots of decodes on the "traffic" tab. Woot woot!

Next step is to get the trunk.tsv file sussed...

Thanks much for the suggestions.

On 06/09/2017 11:37 AM, ikj1234i@yahoo.com [op25-dev] wrote:

ok the console window indicates you're receiving on a NAC of 0x343 whereas the traffic tab shows a NAC of 0x25A. (with respect to these two NACs, your trunk.tsv is totally daft). This is certainly one problem. At the stage you're at you should forego the trunk TSV and use manual mode until the trunk CC is properly acquired.

Separately the datascope indicates a very strong LSM signal (i.e., not C4FM), so you'll need to use the constellation tab for normal ops. If you stay on the datascope tab it will (incorrectly) use the C4FM demod, this is a legacy of scope.py. Based on that constellation any attempt to use C4FM will fail miserably, it's pretty nasty and a really good example of why C4FM demods won't work well on LSM.

One other thing is that your datacscope tab isn't centered vertically, it suggests the tuning is slightly below where it should be tuned. This can be adjusted using the -q pa rameter and fine tuned using the slider...

Max