Unitrunker voice receiver drops a lot of transmissions?

Status
Not open for further replies.

johnfeher

Member
Joined
Aug 31, 2016
Messages
7
I have recently discovered the possible benefits and exciting potential of inexpensive SDR hardware. I installed the latest version of Unitrunker and I am experiencing the same issue as aspicer posted on a different thread, back in 2014. Since I can't tell whether the issue has been resolved I opened a new thread.

I am using two dongles, one as a signal and the other as the voice receiver. Some transmissions complete fine, usually with a brief, low tone hum, followed by an also brief white noise bit before the receiver is "parked" .
The problem is that many of the transmissions stop abruptly, while the speaker is still talking. It ends without the low tone hum and white noise segment, just like as if there were a power failure. It doesn't switch to another transmission right away and it is clear that this is not happening because a higher priority call gets preference. After a brief pause, usually the responding person keys up and the conversation continues and the listener just missed a chunk of the first person talking.

I am wondering whether anyone else is experiencing the same and if the issue can be resolved? It would help to know where exactly the problem originates; the signal receiver, voice receiver or perhaps just a software or configuration problem.

Since already on the soapbox; is there a way to eliminate the annoying white noise that blasts for about a second at the end of most transmissions, just before the voice receiver is parked. It makes the scanning experience into a very annoying affair, even more to nearby family members. Part of the problem is that the audio level needs to be relatively high to be able to understand the transmission but at the end the noise blasts significantly louder.

Any help is much appreciated.
 

Attachments

  • Capture.jpg
    Capture.jpg
    76.5 KB · Views: 551
  • CaptureSmall.jpg
    CaptureSmall.jpg
    84.8 KB · Views: 334

dave3825

* * * * * * * * * * * *
Premium Subscriber
Joined
Feb 17, 2003
Messages
7,647
Location
Suffolk County NY
Looking at your voice receiver, it looks like your squelch is set to zero. Setting that should eliminate the white noise you get. I believe you set that slightly higher than the rssi value when there is an active voice call.

Is there digital on the system? Not sure of your location so I can not look up the system..

I too get a hum but when I check Deemphasis and it goes away.

Here is the info and explanations on voice following UniTrunker | Voice Following
 

johnfeher

Member
Joined
Aug 31, 2016
Messages
7
Thank you dave3825 for your response. I set the squelch to zero just to see if it eliminates the bigger problem. One theory I had was that the voice cutting off could be a squelch issue even though I considered it unlikely. I just wanted to take squelch out of the equation. Since yesterday, I set it back to a higher number and the white noise is gone.

The original issue, a large number of interrupted/aborted/dropped transmissions is still there and you haven't addressed that ... I understand, you may not have the same problem.

I watch the RSSI field during transmission and let's say dispatch is giving out an address as the RSSI hovers around 64. In the middle of the transmission/address the audio stops with a clean cut, no humming or white noise. The RSSI hasn't dropped, in fact it freezes at the point the transmission was cut and receiver parked, in my example still showing 64. Just in case anyone wonders, I have tested this both on an old laptop and a brand new desktop with plenty of resources and got the same problem. You can tell that the person was still talking because of the context, that they were in the middle of their message and that there is a silent gap while they presumably finish. Then the responding person keys up with their transmission. I want to find out the source of this problem, as I mentioned in the original post.

The "deemphasis" has always been turned on as shown on the picture. To be clear I am using two of these dongles: IEIK SDRMCX RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Looks like you're monitoring site 6 of this system:

RadioReference.com - Scanner Frequencies and Radio Frequency Reference Database

There's a note about rebanding. I don't know if that impacts site 6. An incorrect band plan will cause you to miss chunks of conversation.

If the missing parts seem to be at the start of a transmission eg. you hear something mid-sentence, this usually means the program did not see the control channel message for the call start. If your decode rate is less than 100%, this can happen.

If you are missing speech randomly - this can be (a) squelch value too high or (b) missed call-in-progress messages. The latter occurs when the decode rate is less than 100%. There is no end-of-call message so the program infers the end of a call by the absence of control channel activity.
 

johnfeher

Member
Joined
Aug 31, 2016
Messages
7
Unitrunker, you are correct, I am monitoring King County SouthEast (Seattle area) traffic. All groups and users are locked out in the XML except a handful in the Auburn area - police & fire. Almost all communication here is ANALOG, everything I monitor is ANALOG so I assume decoding (decode rate) is no issue at all. I doubt rebanding is a problem, doesn't Unitrunker jump to a specified frequency? But regardless, the receiver is ALREADY playing the transmission fine when it abruptly goes to park in the middle of the sentence. I can't imagine that the system switched frequencies/channels mid sentence. The symptom I am observing is that the transmission (always) starts fine, but a large percentage quits while they are talking. Yes, there are also a few that cut out for a split second but return, those could be squelch related but if you read the original post, I started out by setting the squelch to 0 just to rule out that it was the source of the problem. Even with the squelch at 0, the exact same cutting out happens, the only difference is that the COMPLETED transmissions ALSO have a small segment of hum and trailing white noise at the end, before the receiver goes silent. Another piece of evidence against a squelch theory is that the RSSI number doesn't drop when it goes silent, it remains the same higher number and "freezes" on it, well above the squelch value. So I am wondering - in my case - is the SIGNAL, VOICE receiver dropping the call or Unitrunker doing something funny in-between? Hope I am making sense with the above description :)

Thanks for responding so quick, by the way.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Almost all communication here is ANALOG, everything I monitor is ANALOG so I assume decoding (decode rate) is no issue at all. I doubt rebanding is a problem, doesn't Unitrunker jump to a specified frequency?
By decode rate, I am referring to the control channel. To emphasize from my earlier post:

unitrunker said:
There is no end-of-call message so the program infers the end of a call by the absence of control channel activity.
Does the control channel stay at 100%?

johnfeher said:
the RSSI number doesn't drop when it goes silent, it remains the same higher number and "freezes" on it, well above the squelch value.
That does not sound good. What version of the program are you running? To get more information, turn on *Tuner* logging. This will show the commands sent to the radio as the program follows calls.

UniTrunker | Log Files
 

johnfeher

Member
Joined
Aug 31, 2016
Messages
7
The Universal Trunker version I am using is : 1.0.32.7

I have captured some logs since, they are attached. One small sample is also attached as an image.
Due to the website's limitations I had to cut it down to just a small section. Please let me know if you need anything else.
 

Attachments

  • TunerLog.jpg
    TunerLog.jpg
    88.2 KB · Views: 196
  • Tuner-20160922.LOG.PARTIAL.TXT
    152.5 KB · Views: 44
  • DecodeA-20160922.LOG.PARTIAL.TXT
    192.2 KB · Views: 33
Status
Not open for further replies.
Top