Forcing RTL Center Frequency In UniTrunker

Status
Not open for further replies.

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Howdy,

I was wondering if anyone has had any success -- or if Rick has any tips -- for forcing the receiver center frequency to a predetermined value in Universal Trunker when using RTL R820T receivers.

I'm trying to eliminate the brief audio cutout I currently get in my recordings when the receiver changes center frequency to accommodate new calls on other VCOs on the same receiver. I have more than enough receivers and VCOs to cover the bandwidth and number of voice channels of the system I'm monitoring; however, the software has a strong priority to use the first receiver and the VCOs in order as well.

For example, say I am looking to monitor 852-857MHz. I'd like receiver one to cover 852-854, receiver two to cover 854-856, and receiver three to cover 856-857. Instead, currently, the program will utilize receiver one as much as possible. Say it is set to signal VCO at 853 with multiple voice VCOs. If a call comes on at 855 and receiver one isn't listening below 853, it would readjust center to catch the call on 855, disrupting a currently active call on 854. Instead of causing the shift in RTL tuning, it would be ideal if, instead, receiver two picked up the new call on 855.

In a voice VCO, setting the park frequency is just an idle parking spot when there are no other demands on the receiver (i.e., it will abandon that park if there is a call on another channel, even if it needs to jump out of bandwidth to take the other call).

So far, I can think of the following solutions, but each are less than ideal:

1) Buy more RTLs so each RTL has only 1 voice VCO. This would be expensive and would substantially increase computing workload.

2) Set two additional signal VCOs, with each parked on opposite sides of the bandwidth I would like to monitor with a specific receiver. I assume this would also increase computer workload, but it seems ideal compared to the above solution.

Ideally, I would be able to tell the receiver exactly where I wanted it to be.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Adding support for "anchor" tuning is on my TODO list.

Beware that #1 would actually decrease workload. Each Realtek could run at a lower sample rate (like 0.96 instead of 2.4 msps) and use a more compute efficient form of frequency translation.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Thanks for the response. I think that'll be a great feature to have.

Right now I have 2 receivers covering 8 channels on this system, so I'd be adding an additional 5 (signal + voice on 1). 2X2.5 vs 7X1 The other consideration is that, since switching to Windows 10, every time I restart my computer, it rearranges the USB ports, so I have to plug in the RTLs one at a time to make sure the correct device is on the correct port/receiver.

Would my idea about parking signal frequencies on either side work?
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Usually, Windows is consistent on the order it adds USB devices at start up. You'll only see weird looking device names when two or more Realteks have the same serial number. There are instructions out there to give each device a unique serial number. Note that the so-called serial number is actually alpha-numeric. Name your devices after cartoon characters.

You have the option of using "0.000" as the park frequency. It effectively turns off the VCO while parked.

There is a way to force an SDR to a specific center frequency. For a Realtek, set two signal role VCOs exactly 2 Mhz apart (for 2.4 msps). For an AirSpy - 8 Mhz apart. One can be a legitimate control channel. The other is just there to prevent the center-tuing logic from changing frequency. The placeholder VCO is a bit of a waste on resources. Signal role VCOs always have priority over voice role VCOs.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
I setup two RTLs with fake (well one was real) placeholder signal VCO on either side. 2.4msps wasn't an option for me, so I went with 2.56msps, which was useful since SDR# also has the same option. I reviewed the bandwidth in SRD#, found the margins, and then further refined the margins in UniTrunker down to the ten hertz place until any wider of a margin put one of the placeholders "out of reach." For my first receiver, it was 851.31680 and 853.36479, with a center of 852.34079.

Even with this setup, I still have the same issue. The audio cuts out on active voice VCOs for a little over a 3/10 of a second when another VCO on the receiver takes a new call. I've tried to keep an eye on the center frequency, but I can't confirm either way whether it has been stable or if it has jumped slightly.

Is there anything else that could be causing this? I have auto gain enabled. I also have drift correct enabled. I don't think it's drift correct, though, because I just recently started using that feature.

What I don't understand is that the control channel decode doesn't seem to be hit much by this, unless there is simply no data to decode while it "silences" so the decode log just picks up where it left off. Here's an example from the decode log from one of the instances of this issue. Talkgroup 0CC, on LCN 1, was in progress and had a 3/10 second cutout when the call initiated on LCN 2 for talkgroup 115. There are two "dumped" lines that follow the command. Unfortunately, the receiver logging was deselected during this. I'll try to catch it again with both logs running.

The action is on both sides of the 2016-04-22 12:22:42 timestamp. From the decode log:

EE080CC[0] (1) Continuation analog Ch 1 G 0CC
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
F3E7119[0] (0) Patch P 7CE adds G 119
FC21210[0] (1) Neighbor Site 1 CCh 1 Slot 1 Status 0
EE080CC[0] (0) Continuation analog Ch 1 G 0CC
FC40000[0] (1) Extended Options 00 Color 0
0442915[0] (0) Grant Msg Analog
1482915[0] (1) Group Ch 2 I 08A4 G 115
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
00709F9[5] (0) dumped

2016-04-22 15:22:42 66 of 68 (97%)

00709F9[5] (1) dumped
EE080CC[0] (0) Continuation analog Ch 1 G 0CC
EE10115[0] (1) Continuation analog Ch 2 G 115
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC9FFFF[0] (0) Dynamic Regroup 8 thru F:AAAAAAAA 00
FC9FFFF[0] (1)
EE080CC[0] (0) Continuation analog Ch 1 G 0CC
EE10115[0] (1) Continuation analog Ch 2 G 115
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC20200[0] (0) 1 Neighbors
EE080CC[0] (1) Continuation analog Ch 1 G 0CC
F3E712A[0] (0) Patch P 7CE adds G 12A
EE10115[0] (1) Continuation analog Ch 2 G 115
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Here's another example of what I described in my previous post. I had the tuner log on this time, but it doesn't give time stamps.

This is what the tuner log file looks like (it repeats the same thing over and over):

PLL LO 855910795 prescale 1 Quotient 59 SDM 28525 error 5.
gain BF FB FF E9
PLL LO 855910795 prescale 1 Quotient 59 SDM 28525 error 5.
PLL LO 855910795 prescale 1 Quotient 59 SDM 28525 error 5.
gain 9A FB FF E9

And here's the decode log. The relevant stuff is ~4/5 of the way down.

2016-04-23 00:00:26 68 of 68 (100%)

EE0806E[0] (0) Continuation analog Ch 1 G 06E
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC9FFFF[0] (0) Dynamic Regroup 8 thru F:AAAAAAAA 00
FC9FFFF[0] (1)
EE0806E[0] (0) Continuation analog Ch 1 G 06E
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC20200[0] (0) 1 Neighbors
EE0806E[0] (1) Continuation analog Ch 1 G 06E
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC21210[0] (0) Neighbor Site 1 CCh 1 Slot 1 Status 0
EE0806E[0] (1) Continuation analog Ch 1 G 06E
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC8FFFF[0] (0) Dynamic Regroup 0 thru 7:AAAAAAAA 00
FC8FFFF[0] (1)
EE0806E[0] (0) Continuation analog Ch 1 G 06E
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC9FFFF[0] (0) Dynamic Regroup 8 thru F:AAAAAAAA 00
FC9FFFF[0] (1)
EE0806E[0] (0) Continuation analog Ch 1 G 06E
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC20200[0] (0) 1 Neighbors
EE0806E[0] (1) Continuation analog Ch 1 G 06E
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC21210[0] (0) Neighbor Site 1 CCh 1 Slot 1 Status 0
EE0806E[0] (1) Continuation analog Ch 1 G 06E
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC8FFFF[0] (0) Dynamic Regroup 0 thru 7:AAAAAAAA 00
FC8FFFF[0] (1)
EE0806E[0] (0) Continuation analog Ch 1 G 06E
FC40000[0] (1) Extended Options 00 Color 0
1BA28CB[0] (0) Grant Msg Analog
0F628CB[0] (1) Group Ch 2 I 377B G 0CB
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC9FFFF[0] (0) Dynamic Regroup 8 thru F:AAAAAAAA 00
FC9FFFF[0] (1)
FD4104D[4] (0) dumped
223EFF2[5] (1) dumped
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC20200[0] (0) 1 Neighbors
EE0806E[0] (1) Continuation analog Ch 1 G 06E
EE100CB[0] (0) Continuation analog Ch 2 G 0CB
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC21210[0] (0) Neighbor Site 1 CCh 1 Slot 1 Status 0
EE0806E[0] (1) Continuation analog Ch 1 G 06E
EE100CB[0] (0) Continuation analog Ch 2 G 0CB
FC40000[0] (1) Extended Options 00 Color 0
FD43101[0] (0) Station Site 01 Control Ch 3 (852.8500) Delay 5 Priority 0
FC40000[0] (1) Extended Options 00 Color 0
FC8FFFF[0] (0) Dynamic Regroup 0 thru 7:AAAAAAAA 00
FC8FFFF[0] (1)

2016-04-23 00:00:27 64 of 66 (97%)
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
PLL LO 855910795 prescale 1 Quotient 59 SDM 28525 error 5.
PLL LO 855910795 prescale 1 Quotient 59 SDM 28525 error 5.

Wow. It's re-tuning to the same center frequency - even though it didn't actually change.

Thanks AggieCon!
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Interesting. On these decode logs, are they continuous, or can they stop writing all together while it re-tunes and pick up like nothing happened (other than dumping a few frames)?
 
Status
Not open for further replies.
Top