Squelch broken at end of TX (BCD536HP)

[jeffrogerson]

Hello,
Anyone else noticing issues with conventional freqs having a squelch fail at the end of some transmissions? I'm getting it once every 10 or so transmissions on a local fire frequency. Have my squelch set to 9 and it's still coming through.

 

[jeffrogerson]

Here's a video. The occurrence happens at :24 mark. It's clearly different than the usual end of tx static heard prior to that mark in the video. ALSO... at the :16 mark of the video, you can hear in the background that the 996XT is picking up the full transmission of the FD, whereas the 536HP cuts off the first half second of the tx. Not good
Squelch tail. - YouTube

 

[jeffrogerson]

Also, this happens on Bellfleetnet Zone II on a regular basis as well, regardless of where the squelch is sitting. Note: My 996XT does not pick up this same annoying squelch tail.

 

[RF23]

Does the long squelch tail and the apparent late unmuting of the squelch (loss of the very first parts of words) also occur if you are holding on a single frequency compared to your 996XT?

 

[jeffrogerson]

Does the long squelch tail and the apparent late unmuting of the squelch (loss of the very first parts of words) also occur if you are holding on a single frequency compared to your 996XT?

Yes. I'm beginning to wonder if this issue is related to the CTCSS search feature (which it appears is the default.) I saved the tone manually, and so far I've yet to encounter the problem. Will update in an hour or so.

 

[kikito]

For what is worth, this happens to me also with other scanners and a variety of frequencies when there's interference on said frequency. Most of the time you can tell by fully opening the squelch and hearing higher than usual "white noise" and other noise artifacts on the frequency Maybe the 536HP is more sensitive in that particular band or frequency, hence the issue? Just a thought....

 

[jeffrogerson]

Update...

Okay, I've found the cause. With the scanner set to it's default setting of tone search, it's causing the first half second or more of the transmission to be clipped off. Conversely, it seems to be dragging the open squelch to the end of the transmission by a half second or more, causing the squelch tail heard in my video.

Entering a CTCSS tone manually, or saving the tone on said frequency eliminates this problem 100%!

 

[kikito]

That makes sense now, because that's how other scanners also behave. When you think about all the things the scanner needs to be sensing i.e. analog or digital, CTCSS/DCS/NAC, etc. and all within a second or two, sometimes with interference on top of it. It's amazing that it can do it at all with missing only a word or so of the transmission in the process.

 

[Boatanchor]

That makes sense now, because that's how other scanners also behave. When you think about all the things the scanner needs to be sensing i.e. analog or digital, CTCSS/DCS/NAC, etc. and all within a second or two, sometimes with interference on top of it. It's amazing that it can do it at all with missing only a word or so of the transmission in the process.

Well, if that's the way Uniden deals with CTCSS decode & search, it's pretty piss poor!

If you set the tone decode to 'Search', the noise/RSSI squelch should open immediately on receiving a carrier above the preset squelch level. Then and only then, should the tone decoder do it's job and display the decoded tone/CTCSS, which may well take an additional 0.5-1 second, depending on the tone frequency.

If the scanner is delaying squelch open until after it has completed a tone scan/search, then this could explain the slow squelch opening and the first part of transmissions being missed. I find it hard to believe that Uniden would set it up like this though, it just doesn't make sense.

Having said all that, if it is true that setting the CTCSS tone to the correct value actually speeds up the squelch opening, then this seems to confirm my hypothesis.

If this is the way Uniden are doing things, it should be able to be changed in a future firmware update as it is a software, not a hardware related fault.

 

[RF23]

Well, if that's the way Uniden deals with CTCSS decode & search, it's pretty piss poor!

If you set the tone decode to 'Search', the noise/RSSI squelch should open immediately on receiving a carrier above the preset squelch level. Then and only then, should the tone decoder do it's job and display the decoded tone/CTCSS, which may well take an additional 0.5-1 second, depending on the tone frequency.

If the scanner is delaying squelch open until after it has completed a tone scan/search, then this could explain the slow squelch opening and the first part of transmissions being missed. I find it hard to believe that Uniden would set it up like this though, it just doesn't make sense.

Having said all that, if it is true that setting the CTCSS tone to the correct value actually speeds up the squelch opening, then this seems to confirm my hypothesis.

If this is the way Uniden are doing things, it should be able to be changed in a future firmware update as it is a software, not a hardware related fault.

In the past GRE owner have claimed that the GRE radios searched for CTCSS tones much faster than Uniden radios and that Uniden was so slow at this that it impacted scanning speed.

Do any of you guys remember such statements?

 

[kikito]

In the past GRE owner have claimed that the GRE radios searched for CTCSS tones much faster than Uniden radios and that Uniden was so slow at this that it impacted scanning speed.



Do any of you guys remember such statements?

Yeah, I remember. I also remember that previous generations of both main brands that I owned did in fact find tones
faster when set to only look for one kind or another.

 

[kikito]

Well, if that's the way Uniden deals with CTCSS decode & search, it's pretty piss poor!

Don't take my observations and explanations in layman's terms to be technical facts about how this scanner does it because honestly I don't know exactly how it does it. Maybe UPMan can better technically explain how these particular radios do it.

 

[UPMan]

There is a P25 wait time setting that defaults to 400 mS (.4 seconds). For channels set to CTCSS/DCS/NAC search, audio will be muted for 400 mS on all analog tranmissions, as the scanner uses that time to determine whether the signal is analog or digital. Without this wait time, you would be frequently bombarded with digital bursts at the beginning of transmissions on digital channels. You can avoid this on known analog channels by setting the type to Analog.

 

[LIScanner101]

There is a P25 wait time setting that defaults to 400 mS (.4 seconds). For channels set to CTCSS/DCS/NAC search, audio will be muted for 400 mS on all analog transmissions, as the scanner uses that time to determine whether the signal is analog or digital. Without this wait time, you would be frequently bombarded with digital bursts at the beginning of transmissions on digital channels. You can avoid this on known analog channels by setting the type to Analog.

Paul,

Your comment I bolded above is very intriguing to me. Although I “only” have a BCT15X, I am now curious if I have ever set it up properly. I use FreeSCAN to program my scanner and all of my conventional systems have the “P25 Wait Time” set to the default of 400mSec, and I have never changed it because I always thought it wouldn’t matter on an analog scanner. I should also note that 99% of my conventional frequencies have CTCSS/DCS tones but there are a very few that I have in "SEARCH" since the agencies don't transmit tones.

Now, DOES it make any difference what the "P25 Wait Time" is is set to on a BCT15X? From what you said above, it does seem to have an impact but I could just be misinterpreting your comment.

 

[UPMan]

P25 Wait Time is not an option on the BCT15X.

 

[Markscan]

I have the same issue, but on an EDACS narrow system. It only happens intermittently . Very annoying when it happens though.