OP25 Tuning Offset - help needed

[w8jfj]

I have an RTL-SDR monitoring the Michigan MPSCS system, specifically Shiawassee county. My location is about 10 miles from the primary tower. Reception is very good once I get the tuning error tweaked down.

When OP25 starts I have an Tunning Error of about -3800. Clicking on ">>" twice and ">" once I can get the tuning error down to about 100hz.

With all the great options and tuning parms to play with (thanks BOATBOD), what setting can I use to bring the tuning error down at startup?


Thanks, John.

My OP25.sh is

./multi_rx.py -c p25_shiawassee.json 2> stderr.2 -v 1

My p25_shiawassee.json is:

{
"channels": [
{
"name": "Voice Channel",
"device": "sdr0",
"trunking_sysname": "Shiawassee County",
"demod_type": "cqpsk",
"destination": "udp://127.0.0.1:23456, ws://127.0.0.1:9000",
"meta_stream_name": "",
"excess_bw": 0.2,
"filter_type": "rc",
"if_rate": 24000,
"plot": "",
"symbol_rate": 4800,
"enable_analog": "off",
"whitelist": "",
"blacklist": "Blacklst.txt",
"crypt_keys": ""
}
],
"devices": [
{
"args": "rtl",
"gains": "LNA:47",
"name": "sdr0",
"offset": 0,
"ppm": 2.1,
"usable_bw_pct": 0.65,
"rate": 2400000,
"tunable": true
}
],
"trunking": {
"module": "tk_p25.py",
"chans": [
{
"#nac": "0x797",
"#wacn": "0x92493",
"#sysid": "0x796",
"sysname": "Shiawassee County",
"control_channel_list": "853.9375,853.4375",
"whitelist": "",
"blacklist": "Blacklst.txt",
"tgid_tags_file": "MPSCS Merged.tsv",
"rid_tags_file": "",
"tdma_cc": false,
"crypt_behavior": 2
}
]
},
"metadata": {
"module": "icemeta.py",
"streams": [
{
"stream_name": "stream0",
"meta_format_idle": "[idle]",
"meta_format_tgid": "[%TGID%]",
"meta_format_tag": "[%TGID%] %TAG%",
"meta_format_rid": "@ [%RID%]",
"meta_format_rtag": "@ [%RID%] %RTAG%",
"icecastServerAddress": "192.168.3.24:8000",
"icecastMountpoint": "op25",
"icecastMountExt": ".xspf",
"icecastPass": "hackme",
"delay": 0.0
}
]
},
"audio": {
"module": "sockaudio.py",
"instances": [
{
"#instance_name": "audio0",
"instance_name": "",
"device_name": "alsa",
"udp_port": 23456,
"audio_gain": 1.0,
"number_channels": 1
}
]
},
"terminal": {
"module": "terminal.py",
"#terminal_type": "curses",
"terminal_type": "http:0.0.0.0:7000",
"curses_plot_interval": 0.1,
"http_plot_interval": 1.0,
"http_plot_directory": "../www/images",
"tuning_step_large": 1200,
"tuning_step_small": 100
}
}

 

[boatbod]

Edit the "ppm" parameter in the devices section of you cfg.json. Right now it's 2.1, which is a pretty big adjustment for most modern TXCO dongles. Try resetting it to 0.0 and see where that starts you out.

 

[w8jfj]

Edit the "ppm" parameter in the devices section of you cfg.json. Right now it's 2.1, which is a pretty big adjustment for most modern TXCO dongles. Try resetting it to 0.0 and see where that starts you out.

Opps, the PPM 2.1 was one of my earlier tests (it did not help-forgot to reset it). I had been running with a default of 0.0 Forever. I will reset to 0.0 and probably get back to my original error that was in the -3400 area.

 

[w8jfj]

Edit the "ppm" parameter in the devices section of you cfg.json. Right now it's 2.1, which is a pretty big adjustment for most modern TXCO dongles. Try resetting it to 0.0 and see where that starts you out.

I have reset ppm to 0.0. I am sitting at a tuning error of -3125 hz. And as I mentioned earlier 2 clicks ">>" and one click ">" and I am down to +- 110 hz.

Thanks, John.

 

[boatbod]

I have reset ppm to 0.0. I am sitting at a tuning error of -3125 hz. And as I mentioned earlier 2 clicks ">>" and one click ">" and I am down to +- 110 hz.

Thanks, John.

1ppm in Hz is equivalent to the integer of your tuning freq in MHz, so in your case about 854Hz.
Each ">>" or "<<" is 1000Hz, and each ">" or "<" is 100Hz, so you are making a 2100Hz manual correction, or 2.46ppm. You'll have to experiment to see if you need the ppm correction to be + or -

 

[w8jfj]

1ppm in Hz is equivalent to the integer of your tuning freq in MHz, so in your case about 854Hz.
Each ">>" or "<<" is 1000Hz, and each ">" or "<" is 100Hz, so you are making a 2100Hz manual correction, or 2.46ppm. You'll have to experiment to see if you need the ppm correction to be + or -

Thanks, that was kind of my understanding also. When I tried the setting in the json file ppm=2.1 there was no real change. And I assumed since my manual correction was greater-than arrows '>>' it should be a positive correction. Since I am -3125 error. I'll keep tweaking.

 

[boatbod]

Thanks, that was kind of my understanding also. When I tried the setting in the json file ppm=2.1 there was no real change. And I assumed since my manual correction was greater-than arrows '>>' it should be a positive correction. Since I am -3125 error. I'll keep tweaking.

Hard to know what to say without sitting in front of it. You can compare the mixer & tuner plots to see which way the "hump" is shifting.
My dongle is pretty accurate so the two plots look the same, but basically in your situation one would be offset either left or right, while the tuner output is centered.

 

[w8jfj]

Hard to know what to say without sitting in front of it. You can compare the mixer & tuner plots to see which way the "hump" is shifting.
My dongle is pretty accurate so the two plots look the same, but basically in your situation one would be offset either left or right, while the tuner output is centered.

View attachment 206831

So, playing around: At startup I had a -3125 error. My thinking was with a minus error I should do a plus correction. That did not work. So, I did a -3.0 PPM. That shifted too much. I backed off and did a -2.4 ppm and now at startup I have about a -400hz error. Signals lock on much sooner. Progress....

 

[saioke]

Do you have access to a Windows machine? Might be easier to figure out what ppm you need by using DSD+. Adjust it on the fly until you can get it as low as possible. In my experience with my RTLSDR V4's, one of devices has a ppm at -0.1 with about 150-200-ish offset on a control channel. The other has about -1.2 correction for around the same offset. Every dongle is different.

 

[RobDLG]

"control_channel_list": "853.9375,853.4375"

I've had difficulties using RTL-SDR Blog V4 devices to monitor a Harris P25 system with similar frequencies.

It's almost as if these SDRs don't even support this frequency range. I'm also monitoring 400MHz and 700MHz P25 systems, and though the SDRs do fine there, I suspect that PPM measurements across a range would yield non-linear results, which is wrong by definition.

Every dongle is different.

Indeed! In my case, I swapped dongles around (I have ten RTL-SDR Blog V4) until I found units suitable for 800MHz. By "suitable" I mean they seemed stable with regard to the corrections indicated by trunk-recorder's P25 "autoTune" setting.

 

[wgbecks]

I have an RTL-SDR monitoring the Michigan MPSCS system, specifically Shiawassee county. My location is about 10 miles from the primary tower. Reception is very good once I get the tuning error tweaked down.

When OP25 starts I have an Tunning Error of about -3800. Clicking on ">>" twice and ">" once I can get the tuning error down to about 100hz.

With all the great options and tuning parms to play with (thanks BOATBOD), what setting can I use to bring the tuning error down at startup?


Thanks, John.

My OP25.sh is

.
}
],
"devices": [
{
"args": "rtl",
"gains": "LNA:47",
"name": "sdr0",
"offset": 5000,
"ppm": 0.0,
"usable_bw_pct": 0.65,
"rate": 1000000,
"tunable": true
}
],

John,

I don't know if what I am about to suggest pertains to your specific SDR, but I recently assisted another fellow ham to get OP25 up and
running on an 800 MHz simulcast system. I pulled my hair out trying to obtain a suitable PPM adjustment but was unsuccessful until I
applied a minimum offset of 5000.

Normally, the offset is use to shift around a large spike that appears at the center of some SDR devices but is not specifically always a problem or is necessary. What I would suggest is setting an initial offset of 5000 then begin with an initial PPM of 0 that you'll test
values of from 1 to 3 and then from -1 to -3 to determine if you are able to decode trunk signaling blocks and to get a readout on the
frequency error.

I would also recommend lowering the sample rate to a value of 1000000 in that op25 tunes the SDR between the control channel frequency and the service channel when following trunked traffic. Therefore, a high sample rate is not required for op25 in this configuration.

Bill, WA8WG

 

[saioke]

I've had difficulties using RTL-SDR Blog V4 devices to monitor a Harris P25 system with similar frequencies.

Come to think about it, I'm also in the same boat with a weaker than normal Voice Channel in that range (852.200). But, the highest VC is 858.6375 and that signal is okay.

I wonder if the V3 would be better for 700-800mhz because it doesn't have as much filtering as V4. My next SDR will probably be the V3. I initially bought the V4 because I wanted to listen to ham and shortwave but, my Tecsun pl-330 does a better job with hf.

 

[alwayslistening]

WRT fine tuning: Should I be trying to center the eye diagram around the zero level or the displayed numeric frequency offset in the main web status page? I have tried to tweak the offset for the lowest value on the main screen but find that the eye diagram is significantly offset on the eye diagram page.

Thank you!

 

[boatbod]

It's generally older SDR hardware that requires an "offset" of 15000 to move outside of the DC spike region at the center tuning frequency. Most newer hardware are much better behaved and simply do not have that spike. An easy way to see if your hardware does have it is to tune to some random freq with no nearby signals and look at the FFT to see if there is a large signal spike present at the tuned freq. No spike = no problem. If you see a spike, add a tuning "offset" to work around it.

 

[w8jfj]

Thanks for all the great comments and suggestions. I really appreciate it.

John,

I don't know if what I am about to suggest pertains to your specific SDR, but I recently assisted another fellow ham to get OP25 up and
running on an 800 MHz simulcast system. I pulled my hair out trying to obtain a suitable PPM adjustment but was unsuccessful until I
applied a minimum offset of 5000.

Normally, the offset is use to shift around a large spike that appears at the center of some SDR devices but is not specifically always a problem or is necessary. What I would suggest is setting an initial offset of 5000 then begin with an initial PPM of 0 that you'll test
values of from 1 to 3 and then from -1 to -3 to determine if you are able to decode trunk signaling blocks and to get a readout on the
frequency error.

I would also recommend lowering the sample rate to a value of 1000000 in that op25 tunes the SDR between the control channel frequency and the service channel when following trunked traffic. Therefore, a high sample rate is not required for op25 in this configuration.

Bill, WA8WG

Thanks Bill, I'll also try the OFFSET test also as I have noticed a pretty decent spike on the Shiawassee system that is not there on other SDR's or receivers (SDRPlay) I have and I know it is not a CC or VC for any system near me.

Do you have access to a Windows machine? Might be easier to figure out what ppm you need by using DSD+. Adjust it on the fly until you can get it as low as possible. In my experience with my RTLSDR V4's, one of devices has a ppm at -0.1 with about 150-200-ish offset on a control channel. The other has about -1.2 correction for around the same offset. Every dongle is different.

I do have a WIN 11 machine with DSDPlus on it. I will try playing around. I am always tinkering.

John - W8JFJ

I've had difficulties using RTL-SDR Blog V4 devices to monitor a Harris P25 system with similar frequencies.

It's almost as if these SDRs don't even support this frequency range. I'm also monitoring 400MHz and 700MHz P25 systems, and though the SDRs do fine there, I suspect that PPM measurements across a range would yield non-linear results, which is wrong by definition.



Indeed! In my case, I swapped dongles around (I have ten RTL-SDR Blog V4) until I found units suitable for 800MHz. By "suitable" I mean they seemed stable with regard to the corrections indicated by trunk-recorder's P25 "autoTune" setting.

The system in question for Shiawassee County is indeed a V3 RTL-SDR dongle. I had not thought about the differences in the engineering of the various dongle versions.

As a side note I have another Debian system monitoring the Saginaw County system running on a Air-Spy MINI. After I tweaked the Shiawassee system to a 400hz level with a PPM setting of -2.4 I started play with Saginaw county system which was running about -2300 hz. trying a similar PPM of -2.1 the error went to almost -4000hz. I then set a PPM of +1.3 and that settled down to an error of -125hz. Strange animals these various dongles.

Just for grins I do have some NOELEC'S and Ver 4 RTL-SDR dongles to try on the Shiawassee Setup.