(relatively new to motorola gear)- when using some old GM300s and GM350s with CTCSS, there seems to be a very slight delay in the squelch opening on reception. I presume that this delay arises from the ctcss decoder's "thinking time". Is this normal? The setting is a rural low-budget taxi service, with a hilltop repeater. the fleet of mobiles is somewhat disparate and is a complete mixture of radio equipment, some of which does probably does not have ctcss. I presume that the radios without ctcss open squelch more instantly.
It seems dissapointing that the motorola GM300s have this delay in opening their sq, and I was wondering if there was anything I could do to make it more instantaneous. The repeater is controlled by an external control panel and this is also the source of the ctcss tone. I wonder if increasing the level (?) of the ctcss might speed the ctcss decode?
are the GM300/350s "known" to have this issue?
or is the decode delay just something Ive got to live with?
(the situation is not helped by the dispatchers who are not very radio savvy and often start talking as they key ptt. interestingly, the drivers all seem to be able to key before speaking)
ctcss squelch delay
Moderator: Queue Moderator
-
kb4mdz
- Posts: 282
- Joined: Tue Oct 02, 2001 4:00 pm
- What radios do you own?: Too many for the time I have.
Re: ctcss squelch delay
Couple things:
I've read some jabber around the internet that lower frequency CTCSS tones decode 'slower' than higher tones, ie 70 Hz will decode slower than say 200 Hz; argument is that some radios decode by counting the frequency. PL audio gets low-pass filtered (to filter out the voice traffic), sent to the decoder, where it's (in this scenario) counted for either audio peaks, or zero-crossings. Obviously you'll have more 'countable events' within say 1/4 second if you're using 210 Hz,, vs. 70 Hz; It's an argument that makes sense on the face, but I don't know how true it really is.
This will probably be compounded by whatever decode delay of the repeater controller, and then the field radios;
No, I don't see that increasing the level of the CTCSS would help any, unless it is very very low already.
BTW, I checked some other posts; looks like you're in Scotland? What are your technical rules for deviation levels, etc? Here in the US, our current 'wide-band' systems, 5 KHz total deviation, the CTCSS level is supposed to be between 500 Hz & 1000 Hz deviation. I like to set radios to 750 Hz or below, maybe even 600 Hz. Our upcoming narrowband (2.5 KHz system deviation) stuff - ctcss between 250 Hz & 500 Hz.; I like to set at about 300 Hz.
Where do you guys there stand in 'narrowbanding'?
And FWIW, the GM300 is not a current production radio; it's going to be harder & harder to get parts for; spend your efforts moving the customer to a) new radios and b) education of the dispatcher on proper radio usage. and c) education of the dispatcher on proper radio usage. Not necessarily in that order.
I've read some jabber around the internet that lower frequency CTCSS tones decode 'slower' than higher tones, ie 70 Hz will decode slower than say 200 Hz; argument is that some radios decode by counting the frequency. PL audio gets low-pass filtered (to filter out the voice traffic), sent to the decoder, where it's (in this scenario) counted for either audio peaks, or zero-crossings. Obviously you'll have more 'countable events' within say 1/4 second if you're using 210 Hz,, vs. 70 Hz; It's an argument that makes sense on the face, but I don't know how true it really is.
This will probably be compounded by whatever decode delay of the repeater controller, and then the field radios;
No, I don't see that increasing the level of the CTCSS would help any, unless it is very very low already.
BTW, I checked some other posts; looks like you're in Scotland? What are your technical rules for deviation levels, etc? Here in the US, our current 'wide-band' systems, 5 KHz total deviation, the CTCSS level is supposed to be between 500 Hz & 1000 Hz deviation. I like to set radios to 750 Hz or below, maybe even 600 Hz. Our upcoming narrowband (2.5 KHz system deviation) stuff - ctcss between 250 Hz & 500 Hz.; I like to set at about 300 Hz.
Where do you guys there stand in 'narrowbanding'?
And FWIW, the GM300 is not a current production radio; it's going to be harder & harder to get parts for; spend your efforts moving the customer to a) new radios and b) education of the dispatcher on proper radio usage. and c) education of the dispatcher on proper radio usage. Not necessarily in that order.
Re: ctcss squelch delay
I think you would have to quantify how slow is slow. PL tends to be faster decode than DPL, but decode still runs in the order of a few tens of milliseconds - enough to chop the first syllable.
Re: ctcss squelch delay
I forgot to mention that it isn't necessarily a decode problem. It is just as likely that it is a transmit problem - that the transmit vco doesn't achieve a lock and bring up power for over 100ms. Most lower tier product by all manufacturers use dual vco's. After ptt, it has to turn off the rx vco, then turn on the xmit vco, then get a lock, then enable the pa. Takes time. Lots of opportunity for the first parts of words to disappear.
Re: ctcss squelch delay
The GM300 has two VCO coils that are switched in as needed, but there's only one oscillator/synthesizer. The radio can't receive and transmit at the same time. This switching is usually fairly fast, in the 5-20 msec range. If your frequency is right on the edge of the band the radio was manufactured for, it could be just a bit slower, or if the two frequencies are at band extremes it could take a bit longer to lock.
On average, PL signal detection is in the 150-200 msec range. The GM300 RSS manual says "<0.250 sec at 8dB SINAD".
If the console operator is keying his radio via a tone remote control system, that will also add some delay. Best thing to do is instruct the users to key up, count to 2, then talk.
Bob M.
On average, PL signal detection is in the 150-200 msec range. The GM300 RSS manual says "<0.250 sec at 8dB SINAD".
If the console operator is keying his radio via a tone remote control system, that will also add some delay. Best thing to do is instruct the users to key up, count to 2, then talk.
Bob M.
Re: ctcss squelch delay
Check to see if MDC signalling is enabled on receive. If so there is a parameter called DOS (Data Operated Squelch), its there to keep the squelch closed on systems with the PTT ID at the beginning of the transmission. The default was 1/2 second I believe. If MDC is enabled then turn it off or set DOS to zero.
On the other hand, you could enable MDC with PTT ID at the beginning with a pre-tone. That way they will have to wait for a "go-ahead" tone before speaking, just like in a trunking system.
On the other hand, you could enable MDC with PTT ID at the beginning with a pre-tone. That way they will have to wait for a "go-ahead" tone before speaking, just like in a trunking system.
Re: ctcss squelch delay
Years ago I had to measure a bunch of different models of UHF radios NIB to see if they could meet a 40ms attack time and a 20ms decay time spec for an TDMA automated data system. At the time, only Spectras, MCS2K, old SRA Syntors, and GE Orions could do it. Every other model failed to transpond quickly enough. The Maxtrac / GM300 series all came in in excess of 100ms to key up. Icoms came in slightly better breaking the 100ms barrier but not by much. Kenwoods almost made it with +50ms attack times and comm fails approaching 50% if we added time pads to the system.kcbooboo wrote:The GM300 has two VCO coils that are switched in as needed, but there's only one oscillator/synthesizer. The radio can't receive and transmit at the same time. This switching is usually fairly fast, in the 5-20 msec range. If your frequency is right on the edge of the band the radio was manufactured for, it could be just a bit slower, or if the two frequencies are at band extremes it could take a bit longer to lock.
On average, PL signal detection is in the 150-200 msec range. The GM300 RSS manual says "<0.250 sec at 8dB SINAD".
If the console operator is keying his radio via a tone remote control system, that will also add some delay. Best thing to do is instruct the users to key up, count to 2, then talk.
Bob M.
Then 9/11 happened, and funding dried up. Project never left the ground. But, I got a lesson in just how slow some radios are. Okay for people, and okay for asynchronous but not fast enough for a synchronous system.
Re: ctcss squelch delay
I just tested a 42-50 MHz MaxTrac. I triggered the scope on the negative-going PTT line and measured the time until RF appeared at the output. I got 55.2 msec. Your mileage may vary and it might depend on the firmware in the radio. This radio had a 5-pin logic board and probably not the latest and greatest firmware, but it was the first one I grabbed that my scope would deal with.
Note that in my earlier post I did not state how long it took for the RADIO to actually transmit; just how long it took for the VCO to switch. There are other delays built into the radio, such as PTT input debounce, that will be added to this.
Bob M.
Note that in my earlier post I did not state how long it took for the RADIO to actually transmit; just how long it took for the VCO to switch. There are other delays built into the radio, such as PTT input debounce, that will be added to this.
Bob M.
Re: ctcss squelch delay
This IS an age old problem from the 60's when radios started coming with CTCSS.
Operator education is still a requirement. Operators still talk before they push "the button". Two separate parts of the brain?
Some Ham systems delay the repeater's transmit audio by a few tenths of a second and there are simple audio delay boards available.
Operator education is still a requirement. Operators still talk before they push "the button". Two separate parts of the brain?
Some Ham systems delay the repeater's transmit audio by a few tenths of a second and there are simple audio delay boards available.
Re: ctcss squelch delay
I used a dual trace scope as well. PTT triggered start and a power monitor set for 10w triggered stop.kcbooboo wrote:I just tested a 42-50 MHz MaxTrac. I triggered the scope on the negative-going PTT line and measured the time until RF appeared at the output. I got 55.2 msec. Your mileage may vary and it might depend on the firmware in the radio. This radio had a 5-pin logic board and probably not the latest and greatest firmware, but it was the first one I grabbed that my scope would deal with.
Note that in my earlier post I did not state how long it took for the RADIO to actually transmit; just how long it took for the VCO to switch. There are other delays built into the radio, such as PTT input debounce, that will be added to this.
Bob M.
-
N4KVE
- Posts: 1652
- Joined: Wed Apr 02, 2003 10:35 am
- What radios do you own?: APX XTS XTL TRBO 900MHZ
Re: ctcss squelch delay
I still remember my friend telling me 20 years ago "Key the mike, then talk". GARY N4KVE
Re: ctcss squelch delay
PTT stands for Push Then Talk. (big grin)
Re: ctcss squelch delay
thanks for the intersting replies particularly re the delay time for txs to actually tx.
I am pretty sure that in this case, the delay is mostly due to ctcss decode though. the weird thing is, that some drivers seem to be able to respond reliably... this may be because they are able to second-guess the dispatcher I guess....
the main problem is the usual one though, that the dispatcher is talking at the same time as keying up. strange, that the dispatcher does this yet the drivers seem to all key, then talk, and they are all at the same level brain-wise (ie, theyve barely got one)
I shall attempt to quantify the delay that the gm300s give on decoding ctcss. I feel that it is of the order of 250-300ms though. ie, a third of a second. quite a lot with a gobby glaswegian dispatcher.
re deviation legal limits, Im not too sure of this. (its a very rural service with no competition for spectrum really so we can get away with quite a lot of bad practice) I shall find out. But its fairly academic as I have no means of measuring it at the moment.
I am pretty sure that in this case, the delay is mostly due to ctcss decode though. the weird thing is, that some drivers seem to be able to respond reliably... this may be because they are able to second-guess the dispatcher I guess....
the main problem is the usual one though, that the dispatcher is talking at the same time as keying up. strange, that the dispatcher does this yet the drivers seem to all key, then talk, and they are all at the same level brain-wise (ie, theyve barely got one)
I shall attempt to quantify the delay that the gm300s give on decoding ctcss. I feel that it is of the order of 250-300ms though. ie, a third of a second. quite a lot with a gobby glaswegian dispatcher.
re deviation legal limits, Im not too sure of this. (its a very rural service with no competition for spectrum really so we can get away with quite a lot of bad practice) I shall find out. But its fairly academic as I have no means of measuring it at the moment.
Re: ctcss squelch delay
Speaking of CTCSS decode delay, I ran some experiments on several radios, including one that used mechanical reeds for decoding. I found that one radio (GE MLS-II) did have considerably longer decode times as the frequency decreased, from around 250-300 msec at 67.0 Hz to 100-150 msec for 192.8 Hz. The Motorola MaxTrac and Spectra radios had widely varying times but they didn't seem to be frequency-dependent. The times for these radios was in the 200-300 msec range with some tests running as short at 150 msec. The mechanical reed decoder also was not frequency-dependent but it was very precise and repetitive in its action. Every test I ran (at a given frequency) came out exactly the same, to the millisecond. They ranged from 180 to 210 msec and I think this is more due to reed manufacturing tolerances. Surprisingly the lower frequency reeds had the shorter decode time.
In the old days (1960s and 1970s) when all they had were mechanical reeds, I'm surmising that the lower frequency ones took longer to decode, but that doesn't seem to be the case today, and certainly not on modern synthesized two-way radios.
Bob M.
In the old days (1960s and 1970s) when all they had were mechanical reeds, I'm surmising that the lower frequency ones took longer to decode, but that doesn't seem to be the case today, and certainly not on modern synthesized two-way radios.
Bob M.