P25 sumulcast decode errors

Hello all. I'm currently monitoring a motorola P25 CQPSK trunking system with two RTL-SDR dongles, unitrunker, and virtual audio cable piping output to DSD+ on windows 7.

I was only getting around 30% decode rate with the whip antenna that came with the dongles, so I built a 10 element 850Mhz yagi in the hopes of improving that. I've read that decode errors can be caused by interference between slightly out of sync signals from multiple simulcast towers, so I thought that a directional antenna would help reduce the interference. The yagi is surprisingly good for an hour of work and a few bits of copper tubing, and has increased my decode rate to around 75%. Unfortunately, it turns out that one tower is about northwest of me, and the next one is directly northwest of that, so I can't really lock onto a single tower.

I've heard that OP25 has better error correction algorithms than DSD+, and I'm pretty experienced with linux, so eventually I'll head that direction. OP25/GNUradio is a bigger project than I have time for at the moment though, and I think unitrunker is great, so I'm hoping someone can provide some suggestions for unitrunker or DSD+ fine tuning to help reduce the errors.

If it would help to look at the geography, this is the system I'm monitoring: https://www.radioreference.com/apps/db/?action=siteMap&sid=2361&type=rr
My location is about directly east of "Boys Town" on the map.

With the Yagi, try aiming for a tower further away (whose bearing isn't close to another tower).

With simulcast, it isn't so much getting the same signal from two sources; it's getting the same signal reflected from multiple obstructions.

Unitrunker said:

With the Yagi, try aiming for a tower further away (whose bearing isn't close to another tower).

With simulcast, it isn't so much getting the same signal from two sources; it's getting the same signal reflected from multiple obstructions.

Click to expand...

I don't know why I didn't think of that. Thanks for the suggestion. The antenna is indoors right now, could that be increasing the reflection problems?

P.S. Unitrunker! I feel like I'm meeting a celebrity. I don't have much scanning experience, but I love your program. Thanks for the hours of entertainment it's provided.

Edit: Hmm. It looks like my location is just not ideal. The only other choice is the Pottawattamie county, about 35 miles east, which seems to be out of my range. I moved the yagi onto the porch, pointed it east, and my signal receiver's health dropped from 100% to ~15%. There's almost no obstructions between me and that tower, but it's well over the horizon... I suppose the earth counts as an obstruction.

There are currently only two options to monitor/listen to P25 simulcast systems. Those are OP25 and SDRTrunk. SDRTrunk is cross platform as it's written in Java. You can simply download the app and run it. However, the jmbe library will need to be compiled yourself in order to listen to voice traffic. It's a bit of a learning curve using it, but it is coming together very well. The decoder works as good, or better than OP25.

OP25 is the only solution that has Phase 2 support.

Neither of these two require any special antenna setup as long as the signal strength is sufficient to pull in the system.

nickajeglin said:

I've heard that OP25 has better error correction algorithms than DSD+

Click to expand...

I'm pretty sure you have DSD and DSD+ confused with one another. DSD+ has the necessary error correction, DSD just ignores it completely.

Picco, thanks for the info. I don't actually need phase 2, so I'll look into SDRTrunk. I'm very confused about DSD+ though. I was running under the assumption that my decode problems were because DSD+ didn't have good enough error correction. Now I'm pretty much back to square one as to why I'm not getting good voice quality.

In any case, I'm glad to hear that OP25 isn't the only option. Now I'm trying to compile gnuradio on a raspberry pi 2, which is a nightmare since it's ARM based... even if I could get it to compile, it would probably take a week.

nickajeglin said:

I'm very confused about DSD+ though. I was running under the assumption that my decode problems were because DSD+ didn't have good enough error correction. Now I'm pretty much back to square one as to why I'm not getting good voice quality.

Click to expand...

I'm pretty sure DSD+ doesn't have an ECC issue. What you're having trouble with is the demodulation. I don't know how well DSD+ handles CQPSK/DQPSK/LSM, etc natively via FMP... I'll wait until I don't have to run any virtual audio crap.

If you have to pipe the audio in, from sdr#, that isn't going to work.

nickajeglin said:

Now I'm trying to compile gnuradio on a raspberry pi 2, which is a nightmare since it's ARM based... even if I could get it to compile, it would probably take a week.

Click to expand...

Yeah, good luck with that.. I think a lack of memory/swap space is going to be your biggest hurdle trying to compile on the pi2. Have you looks for binaries? I seem to recall someone doing this, but I can't remember when/where I read that. I don't think the Pi platform has enough grunt to do any complex DSP stuff though.

The dream here is to have a portable sdr scanner on rtl-sdr + pi based hardware, but I'd be happy just to get 100% decode on a windows desktop. Right now unitrunker is directly tuning two rtl-sdr sticks, and piping the output of the voice tuner to DSD+ via VAC.

Now I'm beginning to think that my VAC settings may be the issue. I'll fiddle with those for a while, since I've tried every combination of unitrunker settings I can imagine.

edit: the processor on the new pi 2 is actually pretty solid, but I think you're right about memory/swap being the bottleneck.

nickajeglin said:

but I'd be happy just to get 100% decode on a windows desktop. Right now unitrunker is directly tuning two rtl-sdr sticks, and piping the output of the voice tuner to DSD+ via VAC.

Click to expand...

This is a bit of a sore subject to me, and I'm not going into it here on the forums. However, you shouldn't expect 100% from anything. It's much less aggravating and can take the fun out if it trying to get such high decode rates. There isn't any harm in trying different things such as antennas, or different platforms. Just don't to too hung up on getting 100% decode rate.

nickajeglin said:

Now I'm beginning to think that my VAC settings may be the issue. I'll fiddle with those for a while, since I've tried every combination of unitrunker settings I can imagine.

Click to expand...

I kind of doubt that.

nickajeglin said:

edit: the processor on the new pi 2 is actually pretty solid, but I think you're right about memory/swap being the bottleneck.

Click to expand...

Can you install Java on that thing and try SDRTrunk?

So here's another point of confusion for me. Am I only picking up dispatch from the simulcast site, or both dispatch and the car/mobile radios? It seems like dispatch has a better decode rate than the mobiles, so it occurred to me that maybe a high gain directional antenna is counterproductive. Would I be better served by something omni with an in-line amplifier of some kind?

Also, There are so many variables to tweak here, it's really hard to tell what will make the most difference. I have the antenna, then I have unitrunker settings like gain, AGC, sample rate, and the interaction between drift correct, squelch, and deemphasis. Then there's VAC settings: sample rate, bps, volume control, channel mixing, buffers. etc.

Can anyone tell me what the most important variables are, and in what order to approach optimizing the setup?

Well, ok. I understand that 100% is asking a lot, especially from some cheap European TV receivers, but what I have right now isn't entirely usable. I wouldn't really mind if I was missing around 20% of what's happening, but my set up is much closer to 30% errors. The "auto-tune" voice is really annoying too.

Maybe I'm asking more than the hardware is capable of doing, which I can accept. If it's a configuration or fine-tuning error on my part though, I'd really like to get it solved.

Have you tried decoding one or 2 of the trunked frequencies by themselves using FMP and DSDPlus and taking Unitrunker temporarily out of the loop? If you are still getting a poor decode, then you can rule out Unitrunker and VAC (although it is doubtful that those are where the problem is).
Have you looked into running DSDTUNE to see if optimizing your decoding settings makes a difference?

Mark

Sent from my SM-G920V using Tapatalk

Using the crappy little antennas that come with the SDR units is asking for a poor signal unless you are in the neighborhood of the tower. But the fact that you got something indicates that a site is not too far away.
It would appear that you have improved your reception. Perhaps you improved it too much? Both UniTrunker and DSDPlus have the ability to drop the gain in those SDR units. I would suggest making adjustments in those.

chris

I don't see any mention of whether the OP is using DSD+'s PSK decoding option.

Thanks for the testing suggestion Markb. I took unitrunker out of the loop, and got pretty much identical performance. It looks like my issues are in my DSD+ setup. I failed to read DSD+'s documentation, so I didn't realize that there were so many options.

How does the gain level in unitrunker compare to the one in DSD or SDR#? My typical gain in those programs is 30.0-35.0. Unitrunker's gain is definitely 3 digits though. Is it just 10x?

I'll looking into DSDTUNE, and report back once I've spent some time on that.

Thanks everyone! After turning on the -mp PSK decode option, and using dsdtune to optimize my settings, my decode rate is much better. I still have periodic errors of course, but now it's definitely possible to listen to the setup without pulling my hair out.