search

robotastic / trunk-recorder

Records calls from a Trunked Radio System (P25 & SmartNet)
GNU General Public License v3.0
857 stars 192 forks source link

P25 Recording: How to interpret the "Error" value in logging for TDMA recordings #840

Closed theficus closed 1 year ago

theficus commented 1 year ago

The SmartNet II system that I've been using trunk-recorder to capture for the past year or so has been shut down and replaced with a digital P25 system creating a very different experience for me.

One thing in particular that I'm curious about is the "Error" value that gets logged on a call conclusion that looks something like this:

593C    - Stopping P25 Recorder Num [0] TG:                NC Pol 2 (      1217)        Freq: 851.637500 MHz    TDMA: true      Slot: 0 Hz Error: 222

At first I thought it was some kind of count of invalid packets that were processed, but looking at the source code here: https://github.com/robotastic/trunk-recorder/blob/ca64f7a7f5aa48ac82196b43b3d04700f5825051/trunk-recorder/recorders/p25_recorder_impl.cc#L320 it seems to be a value in Hz? (If it is, does this mean that the Slot: 0 Hz Error: 222 line has "Hz" in the wrong place?)

Is this something where I should try to fiddle with my PPM values to get it as close to 0 as I can?

I've been pretty unhappy with the quality of the recordings from the new digital system. The analog system was crystal clear but the digital system sounds pretty garbled so I'm looking at anything I can to make sound quality better on recordings and this seems like something that may be worth optimizing once I understand what I need to optimize for (and if this is a good thing to look at).

theficus commented 1 year ago

Just for reference, here's recordings from the new system: https://openmhz.com/system/psern025

I find the quality of these recordings to be pretty poor. Pretty garbled and at times very hard to understand.

These are recordings from the old analog system: https://openmhz.com/system/kcers040

The recordings from this were extremely clear.

Maybe the answer is just "digital sucks". :)

taclane commented 1 year ago

it seems to be a value in Hz? (If it is, does this mean that the Slot: 0 Hz Error: 222 line has "Hz" in the wrong place?)

The console info can be a little mashed together, but it's reporting two things: TDMA Slot: Slot: 0 Apparent Tuning Error in Hz (as approximated by the gnuradio band edge filter): Hz Error: 222

As far as P25 goes, being off by 222 Hz is well within "close enough". If you divide that number by the frequency, it gives you PPM, and ~0.26 PPM is perfectly reasonable. Depending on the SDR device you are using, it's possible you won't get much better than that, I typically see SDR sticks jumping anywhere inside +/-350 Hz.

It might take some additional observations if you want to set a error correction in the tuner config, but as long as you're consistently under 1 PPM (Hz Error: +/-850), it won't make a ton of difference to trunk-recorder.

theficus commented 1 year ago

Thanks, that makes perfect sense now! One of my tuners was consistently reading in the 1000 range but I was able to tweak it to be around -90 and the other is running at about 100 which seems good enough. (These are RTL2832U based dongles so some slop is expected even with a good TCXO.)

Still unhappy with the overall RX quality but I’m guessing it may not get much better than it is. Looking at the waterfalls I have a strong signal.

I guess P25 TDMA just kinda sucks and there’s not really much I can do to make it any better at this point? As I mentioned before, this type of system is new to me since I’m very accustomed to the clarity of the old analog system, so maybe my ears just need some adjustment. :)

tadscottsmith commented 1 year ago

You could try setting softVocoder to true in your config.json. It's the newer vocoder that OP25 uses and is supposed to have better support for P25 P2. It's kind of a personal preference on which you like better.

theficus commented 1 year ago

Closing this issue since this isn't a trunk-recorder problem :)

tadscottsmith commented 1 year ago

Just curious how you determined that? Same audio issues with another software?

theficus commented 1 year ago

Well my primary issue was with interpreting the logs. Audio issues are kind of a tangent. I had some discussions with others who say it sounds ok even though it still sounds bad to me. I plan to do some A/B testing with SDRTrunk when I have some time soon. I didn't really notice any difference with softVocoder.