OP25 OP25 up and running, but it seems to be deaf to traffic on the system.

[plutonium233]

Hi all,

I spent this afternoon setting up OP25 on my Raspberry Pi, and i have it up and running. I have configured trunk.tsv and the associated *.tsv which contains the TGIDs and alpha tags. The RTL is functional, and I can see the message that shows the NAC, SysID, etc. However, it may only show one or two calls, if any, after running for hours even though I have other scanners nearby that are picking up tens of calls with no issue. I have performed the PPM adjustment and confirmed I am "dead-on" frequency using the scope function. In fact, I can see the other calls appear on the FFT display, but OP25 doesn't react to them at all. The control channel is approximately 25dB above the noise floor.

I am using the configuration described on "John's Tech Blog" if that helps to understand my setup. The only adjustments that I made were to reduce the gain slightly and adjust the PPM correction for my RTL dongle.

I should also mention that I am running the RPi in a headless configuration so I haven't really tested the audio decode yet. I did confirm that I can receive the local WX audio using GQRX just to make sure the RTL configuration was correct.

Best Regards.

 

[dave3825]

What system are you trying? And in the trunk.tsv, what modulation are you setting it for?

 

[maus92]

Hi all,

I spent this afternoon setting up OP25 on my Raspberry Pi, and i have it up and running. I have configured trunk.tsv and the associated *.tsv which contains the TGIDs and alpha tags. The RTL is functional, and I can see the message that shows the NAC, SysID, etc. However, it may only show one or two calls, if any, after running for hours even though I have other scanners nearby that are picking up tens of calls with no issue. I have performed the PPM adjustment and confirmed I am "dead-on" frequency using the scope function. In fact, I can see the other calls appear on the FFT display, but OP25 doesn't react to them at all. The control channel is approximately 25dB above the noise floor.

I am using the configuration described on "John's Tech Blog" if that helps to understand my setup. The only adjustments that I made were to reduce the gain slightly and adjust the PPM correction for my RTL dongle.

I should also mention that I am running the RPi in a headless configuration so I haven't really tested the audio decode yet. I did confirm that I can receive the local WX audio using GQRX just to make sure the RTL configuration was correct.

Best Regards.

Please paste the line you use to start the program as well. John uses a ridiculously high S value btw.

 

[boatbod]

If op25 is picking up occasional audio,I wonder if you have inadvertently configured choice channel frequencies into trunk.tsv? Only put control channel frequencies in there.

Secondly, make sure your command line has -2 -U

Graham

 

[boatbod]

If op25 is picking up occasional audio,I wonder if you have inadvertently configured choice channel frequencies into trunk.tsv? Only put control channel frequencies in there.

Secondly, make sure your command line has -2 -U

Graham

That should say "voice" not "choice" channels.

 

[plutonium233]

The system is MSWIN which is a P25 Ph II, Motorola ASTRO-25 700 MHz TRS. I have it set as C4FM as per the results I get when I run Unitrunker.

I also confirmed that the frequency in trunk.tsv is the control channel (not a voice freq). Which makes me wonder why I even need a frequency as a command line argument anyway?

Here is the line I am using to start the program:
./rx.py --args 'rtl' -N 'LNA:40' -S 2400000 -f 773.7937e6 -o 25000 -q 56 -T trunk.tsv -V -2 -U 2> stderr.2

I reduced the LNA from what John used since the scope showed excellent SNR, and I was getting errors from the program (can't recall exactly what it said). Basically, it couldn't lock onto the signal.

I did make some progress since last night, however. I played with the tuning after reading something about using scope 4 to tune and look for convergence at certain coordinates. I couldn't make them match what was reccommended, but I got it close enough that it seems to be working. I am using a -300 (hz?) right now. This also makes the tsbks value count upwards more consistently. I don't know what this value is, but it seems like it is good for it to always be counting upwards. So, maybe I wasn't as "dead-on" as I thought?

 

[boatbod]

P25 phase 2 systems should use the default cqpsk modulation. You will not need any -D parameter on the command line and the modulation entry in trunk.tsv is ignored except for a very special case that nobody uses.

Try reducing your sample size; I like -S 960000 for a desktop/laptop. Having it set to large can impact performance.

Have you looked at your stderr.2 logs, the mixer plot and the constellation plot?

You are correct, the D parameter is not needed on the command line in the noatbod version.

 

[plutonium233]

Ok, I have made a little more progress. Adjusting the sample rate seemed to help a lot. My stderr.2 logs show this:

p25_framer::rx_sym() tuning error -1200

I believe these are coming in just after executing the program until I am able to get the fine tuning where it should be. Before adjusting the sample rate, I could not get the fine tuning adjustments to work every time. In other words, I could use -300 one time and needed -800 another time. At this point, I can make it work with -300 every time.

So, what is the recommended method to do this? I assume I can use "-f -300" to accomplish this? If I did my math correctly, any additional PPM adjustment will overshoot my target so I that's why I think -f would be better.

I have looked at the plots, and the mixer ranges from ~4 to ~13 after dialing in the fine tuning manually. The constellation show four distinct "poles" or clusters most of the time, but it sometimes changes to a large circle, briefly.

Best Regards.

 

[boatbod]

Ok, I have made a little more progress. Adjusting the sample rate seemed to help a lot. My stderr.2 logs show this:

p25_framer::rx_sym() tuning error -1200

I believe these are coming in just after executing the program until I am able to get the fine tuning where it should be. Before adjusting the sample rate, I could not get the fine tuning adjustments to work every time. In other words, I could use -300 one time and needed -800 another time. At this point, I can make it work with -300 every time.

So, what is the recommended method to do this? I assume I can use "-f -300" to accomplish this? If I did my math correctly, any additional PPM adjustment will overshoot my target so I that's why I think -f would be better.

I have looked at the plots, and the mixer ranges from ~4 to ~13 after dialing in the fine tuning manually. The constellation show four distinct "poles" or clusters most of the time, but it sometimes changes to a large circle, briefly.

Best Regards.

Fine tune is the -d parameter followed by either a positive or negative integer. I'm actually surprised you only need -300 adjustment but are seeing -1200 tuning errors. Usually they need small ppm adjustments.

Presumably your dongle is not temp compensated? If so, you'll find it helps to run it with op25 for a good while, then dial in the ppm and fine tune. Usually it'll settle down and return to previous settings quite reliably once it heats up.

Is the audio working reliably now?

 

[plutonium233]

I made a double typo there. Yes, -d is what I meant. I added that to my script a few minutes ago to do a test run. For the first time, I was able to execute the script and have it start up and work correctly without doing anything else.

I adjusted the sample value as I mentioned earlier but, just for information purposes, I wanted to let everyone know I was able to get it to work reliably at 1200000. This is on a Raspberry Pi 2, running Raspbian.

The dongle is not temp compensated as you suspected. So far it is running well at a 56 ppm adjustment and the -300 fine tuning after several hours so I think it should be good to go. As you suggested, it may take a few moments for it to heat up and work correctly if I start from a cold unit.

Audio is working very well. Reliable and with good sound. I am going to start experimenting with some of the other capabilities and maybe add other sites to see how it handles more than one control channel in the trunk.tsv file.

Thanks for all the help so far. If I run into any other issues in the next day or so, I'll just keep this thread going.

 

[boatbod]

Glad to hear it's working.

Unless you're watching the fft plot, there really is no advantage if running larger sample sizes. It just eats up more cpu. On a pi3 I've found smaller to be better.

By the way, most of the op25 discussion takes place in the SDR forum just down the street. I don't normally monitor this one as it's mainly focused on Windows software.

 

[plutonium233]

I added two more sites to the trunk.tsv file, and I started having issues again. After adding the control channels for two other nearby sites, it is giving me -1200 errors. I can immediately go back to my previous configuration with one site, and it has no problem at all. Perhaps the sample size is still too high? Maybe it's low enough for one site, but multiples sites add enough resource loading that it can't reliably handle it? I'll try to drop it down some more.

 

[plutonium233]

Ah ok. My apologies. Please disregard my last message. I will migrate that direction for any future issues.

Best Regards.

 

[boatbod]

I added two more sites to the trunk.tsv file, and I started having issues again. After adding the control channels for two other nearby sites, it is giving me -1200 errors. I can immediately go back to my previous configuration with one site, and it has no problem at all. Perhaps the sample size is still too high? Maybe it's low enough for one site, but multiples sites add enough resource loading that it can't reliably handle it? I'll try to drop it down some more.

Adding sites to the trunk.tsv file won't cause tuning errors, nor will the max sample size be affected by the number of sites. Usually if you see intermittent tuning errors on an uncompensated dongle it's because it cooled down enough while you had the app stopped (e.g. for file editing). I have 6 tcxo dongles that start up correctly every time and one really old device that is non-compensated. The latter can be a pain to get working because a cold startup can be more that +/-2400 off from the warm steady state. Even stopping for a minute or two is enough to change the frequency significantly. What can also happen is that your gardner-costas loop can lock on and start tracking even though the underlying dongle frequency can shift appreciably. (You can visually see this happen in the "mixer" plot with the signal hump sliding to one side or the other.) When this happens you can stop/restart op25 and it won't lock back on until you adjust the fine-tune in real time.

Ah ok. My apologies. Please disregard my last message. I will migrate that direction for any future issues.

Best Regards.

No big deal - it's just easier for people to search if all the discussion is in one place.