psr 500 missing first half second

[SquierStrat]

hello, im thinking i need to adjust a certain setting for this problem but im not sure which, if any.

i have both my cobra sr900 and my psr 500 paused on an analog conventional frequency, i have the ctcss tone set and enabled on my psr 500. EVERY time a transmission comes through the psr500 misses the first 1/4-1/2 second of that transmission while the cobra sr900 picks it up instantly.

is there any way to fix/work on this?

 

[1alpha]

I get the same sometimes on my 500 & 600. Not sure whats going on.

 

[WayneH]

Since the circuitry has to decide whether the sig is analog or digital (basically process the signal) there is some loss to the beginning of the transmission. I hate it too. I can reduce it slightly by messing around in the Advanced GLOBal menu (Func-GLOB) by changing the DG Int Prime. If you set it too low you may get some motorboating and/or no decoding of P25.

ETA: corrected the Func-GLOB value.

 

[1alpha]

Thanks for the info Wayne.

 

[SquierStrat]

would it still have to decide weather its p25 or not if i have a ctcss tone enabled?

also i cant find the "dg int delay" i have "zm delay" and "dg int prime".......

 

[mtindor]

would it still have to decide weather its p25 or not if i have a ctcss tone enabled?

also i cant find the "dg int delay" i have "zm delay" and "dg int prime".......

DG INT PRIME is it. I run mine at 20. I don't monitor any Project 25 systems, but i monitor an analog and a digital Motorola Type II system as well as an EDACS system and do not encounter any problems decreasing DG INT PRIME to 20 - I think the default is 50 or 60. Lowering it to 20 makes a big difference - improves the symptoms you describe. However, like Wayne said, if you start getting a lot of motorboating on your digital systems that you monitor or on P25 cconventional, you may have to play around with figures between 20 and 60 for DG INT PRIME.

Mike

 

[1alpha]

cool thanks for the info. I just set it to 20.

 

[Mike_G_D]

Missed 1/2 second

SquierStrat and 1alpha,

Although I agree that the settings Wayne_h and mtindor have outlined are important for trunking usage and (I think) Auto Modulation mode conventional, as I understand it, when scanning conventional and using a setting of CTCSS or DCS it forces the radio to not look for a digital signal (since digital signals do not use CTCSS or DCS). Now, I am not absolutely sure of this since you can have the Modulation set to Auto and the Squelch mode set to CTCSS or DCS. So the first thing I would try is setting the Modulation to FM or NFM rather than Auto if it isn't already (it's under the Expert settings for the channel/frequency/conventional object in question). Then try it out and see if you notice a difference.

If that STILL doesn't work (or it wasn't set at Auto modulation in the first place) then I would direct you to an earlier thread wherein I responded to a related question: http://www.radioreference.com/forums/showthread.php?t=113753.

Basically, if Modulation set at FM or NFM doesn't work, try setting the the ACSQ Polint to a higher value (I'd try 500 first) and HD5 Fade to the maximum of 2500. These are located in the special Expert extended settings (Func. + Glob) menu.

What Wayne_h and mtindor suggested probably will still work since I think the DGInt Prime setting applies across the board to all scanning operation including trunking and conventional (??...I think?!) but I am thinking that, if you are just having a problem in scanning a known conventional mode frequency then trying other more specific settings (specific to that mode) without affecting the more global settings which may affect, in a way you might not want, other operations such as trunk scanning a mixed analog/digital system, then that may be a more disireable option.

Hope this helps!

-Another Mike

 

[WayneH]

As far as I know there is no way to avoid the signal processing. Can't say I've ever checked with an analog tone protected channel but I want to say it is not different

 

[DonS]

If a CONV object is set to "Sq Mode: CTCSS" or "Sq Mode: DCS", the scanner will not do the "auto check for digital" at the beginning of a transmission (since it must be analog), and "DG Int Prime" will have no effect. Setting it to CTCSS or DCS should give you audio almost instantly, unless the scanner is, for some reason, having a hard time detecting the CTCSS tone or DCS code.

 

[Mike_G_D]

So DonS, according to what you are saying, if the Sq. Mode is set to CTCSS or DCS then the Modulation setting has no effect, at least insofar as the "Auto" setting is concerned in the sense that the digital modulation (APCO25) detection is not activated (it is automatically set at FM, I assume)?

Can you still at least set it for NFM?

If this is true, then, whether or not you can engage NFM, you would be correct - the cause of the reported delay in unmuting a signal with CTCSS or DCS present would not be due to the digital modulation detection and other causes would have to be considered. Then perhaps my other suggestions would be relevant.

I have always set my Modulation to FM or NFM rather than Auto when dealing with known analog only frequencies in conventional mode whether or not I have CTCSS or DCS engaged. To date, I have yet to notice a significant delay in unmuting when CTCSS or DCS is set on such a signal. Just for giggles I will have to try the Auto setting with a CTCSS or DCS set and see if there is any effect. According to what you say, there should be no difference. Interesting!

-Mike

 

[DonS]

So DonS, according to what you are saying, if the Sq. Mode is set to CTCSS or DCS then the Modulation setting has no effect, at least insofar as the "Auto" setting is concerned in the sense that the digital modulation (APCO25) detection is not activated (it is automatically set at FM, I assume)?

If "Sq Mode" is set to CTCSS or DCS, then the scanner presumes it's analog. It never waits for digital to "be decoded".

For CONV objects, the scanner's P25 digital detection is based on a few things:
1. If Sq Mode == CTCSS or Sq Mode == DCS, no digital attempted
2. If Sq Mode == P25, *require* digital
3. If Sq Mode == None or Sq Mode == Search, *try for* digital
4. If Modulation == AM (either explicitly or based on default mode for the frequency if "Auto"), inhibit both Sq Mode and "trying for digital"

Can you still at least set it for NFM?

Yes.

If this is true, then, whether or not you can engage NFM, you would be correct - the cause of the reported delay in unmuting a signal with CTCSS or DCS present would not be due to the digital modulation detection and other causes would have to be considered.

If the scanner is unable to "instantly" decode CTCSS or DCS, there will be a delay. If you've programmed a specific CTCSS tone or DCS code, the scanner will not unmute audio until that tone/code is detected.

 

[Mike_G_D]

Don,

Arggh! I should have wrote (and did mean) "...the cause of the reported excessive (noticeable) delay..."; of course there will be some delay (albeit, ideally, nearly unnoticeable) in any case (hence your "instantly" in quotes;-)!

Anyway, I understand, thank you!

-Mike

 

[JT-112]

GRE really should have stuck in an option for analog only by channel.

There are a few things about how GRE decides to handle the unsquelching/DSP behavior of the radio that frost my cake, this is one of them.

 

[rdale]

They did - read DonS's message above, it tells you how to force a channel to analog only.

 

[NB0B]

They did - read DonS's message above, it tells you how to force a channel to analog only.

That's not necessarily the right answer. I not saying that's not how it actually works. But "None" really should be none; or create another entry called CSQ for carrier squelch. If I set it for CTCSS or DPL, it may force it to analog, but the scanner is now listening for those respective modes to open the squelch.

Bob/NBØB

 

[DonS]

If I set it for CTCSS or DPL, it may force it to analog, but the scanner is now listening for those respective modes to open the squelch.

No, it's not - as long as you don't enter a specific CTCSS tone or DCS code value.

 

[NB0B]

No, it's not - as long as you don't enter a specific CTCSS tone or DCS code value.

Thanks for the clarification. I found more info at http://www.greamerica.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=10 where they state ...

If the CONV transmitter you are monitoring does not use CTCSS or DCS, you can eliminate the 600 millisecond delay by using Sq Mode: CTCSS or DCS and "Search" as the CTCSS or DCS code.

Bob/NBØB