OP25 Error Tracking Values

[krutzy]

Below is table of the frequency error table from the RX screen. What I don't know is if these values are normal. If you look at the 12:24 minute, things go a bit wild. I have noticed this happens when there is talk traffic. Because it is a TDMA the frequency switches to the talk frequency assigned. I assume this is to be expected. I am just not sure and want to know if my -q value (1.53 now) is indeed correct for my rtl-sdr.

Time​	Device​	Name​	Error Band​	Freq Corr​	Freq Error​	Tune Error​
12:25:30	rtl	rx.py	0	-140	0	-140
12:25:27	rtl	rx.py	0	-140	-1	-140
12:25:24	rtl	rx.py	0	-140	-2	-140
12:25:21	rtl	rx.py	0	-140	-3	-140
12:25:18	rtl	rx.py	0	-140	-1	-140
12:25:15	rtl	rx.py	0	-140	-3	-140
12:25:12	rtl	rx.py	0	-140	-1	-140
12:25:09	rtl	rx.py	0	-140	-4	-140
12:25:05	rtl	rx.py	0	-140	-2	-140
12:25:02	rtl	rx.py	0	-140	-3	-140
12:24:59	rtl	rx.py	0	-140	-4	-140
12:24:56	rtl	rx.py	0	-140	-5	-140
12:24:53	rtl	rx.py	0	-140	-6	-140
12:24:50	rtl	rx.py	0	-140	-9	-140
12:24:47	rtl	rx.py	0	-139	-9	-139
12:24:44	rtl	rx.py	0	-138	-10	-138
12:24:41	rtl	rx.py	0	-137	-9	-137
12:24:38	rtl	rx.py	0	-136	-14	-136
12:24:35	rtl	rx.py	0	-134	-13	-134
12:24:32	rtl	rx.py	0	-133	-17	-133
12:24:28	rtl	rx.py	0	-131	96	-131
12:24:22	rtl	rx.py	0	-146	-302	-146
12:24:19	rtl	rx.py	0	-101	-301	-101
12:24:12	rtl	rx.py	0	-56	306	-56
12:24:09	rtl	rx.py	0	-102	307	-102
12:23:59	rtl	rx.py	0	-149	0	-149
12:23:56	rtl	rx.py	0	-149	-1	-149
12:23:53	rtl	rx.py	0	-149	0	-149
12:23:50	rtl	rx.py	0	-149	-1	-149
12:23:47	rtl	rx.py	0	-149	0	-149
12:23:44	rtl	rx.py	0	-149	0	-149
12:23:40	rtl	rx.py	0	-149	0	-149
12:23:37	rtl	rx.py	0	-149	0	-149

 

[wgbecks]

The tuning errors posted are not significant. I would suggest using the -X option if you don't already employ it on your rx.py command line. It's completely normal for RTL SDR devices to wander about while tracking voice channels due to the limited ADC employed in these cheap receivers.
They are anything but linear!

You can spend a lot of time tweaking your SDR such that there is little or no error while it's sitting idle on the control channel only to observe a jump in frequency error as the SDR is retuned to another system frequency in response to tracking voice channel traffic. Attempt to find the best value for the -q (PPM) setting, then add -X to your command line and let op25 due it's best to maintain a minimal tuning error rate.

 

[krutzy]

That is exactly the information I wanted to know. Thank you.

 

[KA1RBI]

These numbers are very interesting - there is a definite hit in the 14:24 area. There are several possibilities, for example the relative error determination that OP25 does could be running into bugs in p25p2, say, using p25p1 time constants when it should be using p25p2 values. It is very curious that there's a +300 Hz error in close proximity to the -300 Hz error. I guess it could be down to SDR tuning inaccuracy, but not sure. Is this by any chance a mixed 700/800 system?

Another thing is I don't know if the -q(PPM) setting allows fractional numbers. It's possible it's rounding to the nearest int (not sure). One way to test this is (while resting on a CC) try to get the "Freq Corr" to sit closer to zero than the current -150.

Another observation is the error updates are not being scheduled at the proper 3 second rate - there are extra delays. This is all stuff that will need to be addressed in a future OP25 update...

Max

 

[krutzy]

Max,

This is a 800 MHz system only. However there is still some P1 communications mixed in due to that all equipment is not replaced in that particular county, but it isn't very many.

Here is a snip from the RX screen.


Also I don't know if this is taken into account but the control channel can and does change (how that works I am not sure) but I knew this was the case. So trying to zero a control channel can be a bit of a challenge. Everytime I tried it would get out of whack right off until it settles down. I just tried to get it after starting running to get the Freq Error column to 0 ± 3.

OP25 sure seems to use a decimal value as I honed into 1.53 through lots of trials and letting it run. I just know I got -1200 or +1200 errors at 1 and at 2.

Hope this helps some.

 

[Outerdog]

Another observation is the error updates are not being scheduled at the proper 3 second rate - there are extra delays.

fwiw, I just checked this here and noted the very occasional instance where the interval displayed in the browser was > 3 sec. I believe the issue is that a decimal remainder is present in the epoch time value before displaying in the ui, resulting in an occasional rounding error sufficient to bump the displayed value by 1. But that doesn't (shouldn't) account for a 6 sec interval in the example above.

The fix in main.js is easy as pie -- I'll post up in our other thread.