SDS200 Intermittent Delay Issue

[brian86]

Hey everyone I have an SDS200 programmed for a P25 Phase II System and have the Delay Time Set for 4 Seconds on "Alpha 1 Dispatch". The Problem is that for whatever reason randomly but mostly during dispatches the radio resumes scanning once the carrier drops, completely ignoring the fact that I have a delay set for 4 seconds on Dispatch. I have delay set on other channels ranging from 1-3 seconds and those channels tend to always hold after transmission. I can't seem to figure it out, but it is problematic because if a call is being dispatched and the delay feature fails to hold the channel Its a good possibility the dispatch is completely missed as I scan several different systems.

Video Here of Issue watch the very beginning of video to see dispatch delay fail and then the rest of the video to see it work.

Let me know if anyone has any suggestions. It seems it may be a Multicast issue as it is most prominent on Dispatches. It is a Harris p25 PII System.

 

[doctordialtone]

If you have a "Negative Delay" value set, it will force the scanner to move on after "-X" seconds.

I'd double check that 1st

 

[Ed6698]

I have also run across this issue with Fire dispatch TG 301 on Vanderburgh Co Indiana Harris P25 PI system with a 5 sec delay, soon as dispatch is finished announcing call scanner ignores delay and just moves on to scanning. What I have done in the past is set that particular TG to a 10 sec delay, it seems to not ignore the delay then. However, having delay set that long is not a fix and far too long to have delay set. It only happens after initial dispatch it seems and the only TG it happens on.

@brian86 set your TG delay to 10 sec temporarily to see if that stops the ignore of delay.

 

[tvengr]

Turn off all priorities and see what happens. Joe Bearcat once said that if P25 trunked priority is on, it will go to a priority talkgroup once the present talkgroup drops.

 

[Ed6698]

I know on my SDS 200 it is not happening due to priority being on, I don't have anything set with priority.

 

[werinshades]

I have seen this happen on a Phase 2 P25 system and a Cap+ system. It's not a consistent issue, just once in a while. I chalk it up as the scanner is briefly loosing the control channel data.

 

[brian86]

Thanks for all the responses. First off there are no trunked priorities set, actually no priority cannels at all set. When monitoring the SDS200 side by side with a Harris M7300 on the Dispatch Channel I can see a pattern starting to form. It has to do with the 2-tone input method from the dispatcher, it appears anyhow. So when the dispatcher unkeys there Transmit during a dispatch the call drops on the M7300 and abruptly clicks and pops and so forth in rapid secession can be heard on the M7300 but this radio always picks right back up and nothing is missed. When this happens on the M7300 the scanner does not delay for 4 seconds and even if the channel is on hold I still seem to miss a good portion of the dispatch. its a clear correlation I have witnessed but the question is why is this happening? Its only when a dispatcher is transmitting and almost only during a tone out dispatch or the voice transmission directly following a tone out dispatch.

Thanks for all your advice it is greatly appreciated!

 

[werinshades]

Thanks for all the responses. First off there are no trunked priorities set, actually no priority cannels at all set. When monitoring the SDS200 side by side with a Harris M7300 on the Dispatch Channel I can see a pattern starting to form. It has to do with the 2-tone input method from the dispatcher, it appears anyhow. So when the dispatcher unkeys there Transmit during a dispatch the call drops on the M7300 and abruptly clicks and pops and so forth in rapid secession can be heard on the M7300 but this radio always picks right back up and nothing is missed. When this happens on the M7300 the scanner does not delay for 4 seconds and even if the channel is on hold I still seem to miss a good portion of the dispatch. its a clear correlation I have witnessed but the question is why is this happening? Its only when a dispatcher is transmitting and almost only during a tone out dispatch or the voice transmission directly following a tone out dispatch.

Thanks for all your advice it is greatly appreciated!

Since it's a Harris system, are all frequencies programmed in..voice,control, alternate? I know others have done this with success, and don't know if it has anything to do with your issue.

 

[nessnet]

Please correct me here if I am wrong.....
I may learn something here...(?)

Isn't the delay just a (dumb) timer on the 100/200/X36?
It 'wait's for however long you set it on the TG/freq assigned?
Regardless of squelch, so to speak...
Resumes scanning in X seconds...

So, it is the control channel that is changing here?
Thus, not picking up the reply(s), because the radio is still tuned to the orig channel grant for 4 seconds?

 

[brian86]

Please correct me here if I am wrong.....
I may learn something here...(?)

Isn't the delay just a (dumb) timer on the 100/200/X36?
It 'wait's for however long you set it on the TG/freq assigned?
Regardless of squelch, so to speak...
Resumes scanning in X seconds...

So, it is the control channel that is changing here?
Thus, not picking up the reply(s), because the radio is still tuned to the orig channel grant for 4 seconds?

My understanding is that it holds on the TGID and if that TGID becomes active on any of the TRS Frequencies it would automatically switch to that frequency to hear the voice traffic. The problem is that the scanner hold feature is not doing that all the time. It resumes scanning right away during dispatches. So seems to be something fishy with the way the system admin has the dispatch / VHF simulcast interlinked cause It seems to only cause a problem with the hold not working during dispatches and always with a Dispatcher console transmitting, never a user radio. I just can't quite figure out how to fix the problem. I miss complete dispatches sometimes even if I am manually holding on the channel its very frustrating.

 

[werinshades]

Please correct me here if I am wrong.....
I may learn something here...(?)

Isn't the delay just a (dumb) timer on the 100/200/X36?
It 'wait's for however long you set it on the TG/freq assigned?
Regardless of squelch, so to speak...
Resumes scanning in X seconds...

So, it is the control channel that is changing here?
Thus, not picking up the reply(s), because the radio is still tuned to the orig channel grant for 4 seconds?

It will hold on a system for a set time, then while it's in the system and a programmed talkgroup finishes transmitting, then it will hold on that talkgroup for the set amount of time. 2 levels of holding/delay.

 

[Ubbe]

The only time it should disregard the TG delay time are if it thinks that it is an encrypted transmission. And that seems to happen from time to time with unencrypted signals that are weak and have bit errors. If I listen to some HAM's on a DMR repeater and one of them have a bad uplink that gives some bit errors the scanner immediately starts to scan. The firmware code that controls this are not working as it should and I have tried different firmwares and the flaw seems to have been introduced when DMR RAS capability where included, a long time ago.

Those system control tones seems to also trigger the encryption detection.

/Ubbe

 

[JoeBearcat]

The only time it should disregard the TG delay time are if it thinks that it is an encrypted transmission. And that seems to happen from time to time with unencrypted signals that are weak and have bit errors. If I listen to some HAM's on a DMR repeater and one of them have a bad uplink that gives some bit errors the scanner immediately starts to scan. The firmware code that controls this are not working as it should and I have tried different firmwares and the flaw seems to have been introduced when DMR RAS capability where included, a long time ago.

Those system control tones seems to also trigger the encryption detection.

/Ubbe

It *might* also 'move on' if that frequency is assigned to a different TG since the original TG will not be using it while another is.

I've never tested that theory (not enough systems that busy) but it would be logical. No sense waiting for activity that will never come.

 

[Ubbe]

No sense waiting for activity that will never come.

Isn't going to a monitor mode during the delay period, and can catch the same TG on another timeslot or even frequency if that information are available in the data stream, as well as the priority function searches for other TG's that are set to prio in that system during the TG delay time?

/Ubbe

 

[JoeBearcat]

It was a little hard to follow that, but it may return to the control channel if that is what you are asking. I will have to check on that, as I never used that long of a delay. But it may stay on the voice channel, too (which would result in the behavior I indicated).

 

[Ubbe]

I didn't understand my own writing either. I probably skipped some words.

Looking at the video it seems to be interference on that 852.475 frequency that creates the issue.

You have -60dBm to -50dBm signal levels from that site, so engage the attenuator to help the receiver fight those interferencies.

Make a display field indicate D-Error, you can use the Noise field, to see the errors in the datastream and set the scanner manually to the channel, Channel+freq+Channel.

Try IFX at first, Fn+7, and you can go back to normal scanning to check if that issue with the 852.475 frequency have cleared. Otherwise try the different filter settings while in manual mode and look at the bit errors if it stays low with 2-3 as a maximum.

/Ubbe