Menu:



Version:

Nov 12, 2020:
Revised: v1.1

Developing a Flexible CTCSS Decoder

A CTCSS decoder can be useful when restoring an older two-way radio. It can also be used for some specialized two-way radio applications.  Since reliable compliant CTCSS decoders are difficult to design, it's worth explaining more about them before describing several possible approaches.

Introduction

The Continuous Tone Controlled Squelch System ("CTCSS") is used in many analog two-way VHF and UHF FM radio systems all around the world. In North American markets, this system is sometimes called “Private Line” or “Channel Guard”.

A CTCSS tone encoder generates low level CTCSS audio tone in the range of 67 – 254Hz which is transmitted with the voice signal (300 – 3000 Hz). This CTCSS tone is then detected by a CTCSS decoder in the matching receiver. This “unsquelches” or “unmutes” the receiver and allows other users to hear that voice.

CTCSS allows a number of user groups to share a radio channel or repeater (a transmitter/receiver used to extend coverage) and improves spectrum efficiency. If each group uses a different CTCSS tone, each user will only hear calls from the other users in their group. Other groups of users on the shared repeater remain unheard. A ‘busy’ light on the radio usually indicates when other users are using the repeater. This also ensures one group cannot transmit at the same time as another group.

A high-pass filter in the receiver’s CTCSS decoder and/or the radio makes certain that the CTCSS tone cannot be heard in the receiver audio.

Almost every modern transceiver and repeater includes these CTCSS encode and decode functions.

CTCSS Encoders

In amateur radio, CTCSS is increasingly being used to reduce repeater interference. If you want to restore older VHF or UHF equipment which lacks CTCSS for use on these repeaters, all you probably need to add is a CTCSS tone encoder.

If so, you click here to read how this can be done quickly, effectively and inexpensively using my very compact CTCSS encoder. All the details are there.

                  Figure 1 : My small digital CTCSS encoder


CTCSS Decoders

A CTCSS decoder is used with a VHF or UHF receiver to detect a specific CTCSS tone. When detected, the receiver audio is unmuted and the incoming signal can be heard. Of course, a CTCSS decoder is required on repeater receivers and most professional repeaters include this functionality. This feature is usually added to older repeaters by installing a separate ‘tone panel’ into the repeater rack. A typical example made by Zetron, is shown in Figure 2.
 
Figure 2 : Typical CTCSS tone panel used in repeater sites
(Image and product copyright: Zetron. Image used with permission.)
These panels incorporate a very flexible programmable CTCSS decoder (for use with the repeater receiver) as well as an encoder (for the repeater transmitter). They allow multiple tones to be detected and regenerated.

CTCSS decoders used in mobiles and handhelds are almost always implemented along with a matching CTCSS encoder. If you need one, you probably need the other. That’s the reason that such modules or devices are called ‘dencoders’ in the industry. They DEcode and ENcode CTCSS tones, often simultaneously.


Figure 3 : Here is a typical example of a (previously) widely used commercial CTCSS dencoder with microprocessor (lower right) and op-amp for buffering and filtering (centre) which had a wide range of programmable settings and connectivity options

Unlike professional or commercial users, most amateur radio transceivers (handhelds or mobiles) rarely use the CTCSS decoder functions. These are usually just left disabled when programming these handhelds and mobiles. Private group calling is rare. Amateur radio operators usually want to hear everybody else on the repeater all the time. So, aside from inside amateur radio repeaters,

CTCSS dencoders are seldom required by most amateur radio users. Although, occasionally, they can be useful.

Why is Decoding a CTCSS Tone so Difficult?

Detecting a CTCSS tone is not a trivial task. The decoder has to detect a specific tone in a radio environment often filled with noise, interference and signal fading. Tones are very tclosely spaced, the radio equipment can introduce distortion and harmonics, and timing is critical too.

Some websites suggest CTCSS detectors can just measure the frequency of CTCSS tone as you might with a frequency counter. While simple, ‘zero-crossing’ frequency measurements do not turn out to be very reliable. It can be fast, but it’s easily upset by noise bursts, signal fading and adjacent CTCSS tones. Tone harmonics, improperly filtered speech, and distortion can also easily upset it.

Tone correlation methods have also been proposed. This approach compares the incoming signal against a delayed version of itself. While also quite fast and potentially effective, it can suffer from false detection particularly from tone harmonics. Noise and distortion can be a problem, too.

Another tone detection method mentioned uses Goertzel filters. This is a Fast Fourier Transform method focused on a specific frequency and bandwidth. It works, but it’s very slow if you want reliable tone decoding, and adjacent CTCSS tone rejection is a significant problem. Approaches exist to improve detection speed, but these are relatively complex.

CTCSS tone detection speed and resistance to the detection of other tones ("false" detection) are critical features in decoders. CTCSS tones are typically just 2 – 5 Hz apart. For example, detecting a 146.2 Hz CTCSS tone reliably requires the decoder drejeccts the nearby tones of 141.3 Hz or 151.4 Hz.  Other sets of CTCSS tones are even closer! Have a look at the CTCSS tone table.


Table 1 : These 50 CTCSS tones are commonly supported by most CTCSS encoders and dencoders

Similarly, a CTCSS detector cannot take several seconds to carefully measure the tone before unmuting the receiver. The guy that just called “Hey, Billy, are you there?” on the repeater has gone before the receiver even unmutes. The CTCSS specifications say it’s got to take no more than 250mS.

It’s equally important the decoder quickly turns off when the tone disappears. Some decoders can act a bit like flywheels. Once they get started, they can be surprisingly hard to stop.

A further issue is the level of the CTCSS tone appearing at the CTCSS detector. 25kHz channel spaced systems use 5kHz FM peak deviation while 12.5kHz narrowband FM uses 2.5kHz peak deviation. Radio equipment is usually aligned to give average speech FM deviation levels of about 60% of these values i.e. 3kHz and 1.5kHz respectively. 

CTCSS tone deviation should be set to about 500Hz (25kHz channels) and 250Hz (12.5 kHz channels). Setting CTCSS levels above this risks tones becoming audible, particularly in systems using CTCSS tones above 200 Hz. (Higher frequency CTCSS tones are usually decoded more rapidly)

CTCSS levels into the decoder will vary with different radio receivers, system settings, and with signal fading. Levels from 50mV to 3Vpp can be encountered. Some decoders that work well at high modulation levels can fail at low levels, and vice-versa. Good decoder designs should allow for wide variations in such levels although with the vast number of receivers in use, there will be occasional issues that occur with even the most reliable of decoders.

Audio Filtering in CTCSS Systems

Audio filters are important in a CTCSS decoder. Commercial two-way radios generally have good audio filtering to improve CTCSS decoder performance. Other radios, including a number of legacy amateur FM radio transceivers (and even some modern radios!), can have transmit and receive audio filters with “limited” performance.

CTCSS decoding require two filters. The CTCSS details are highlighted in the block diagram of a  typical FM two-way radio's receiver  in Figure 4. Usually fed from the receiver discriminator (FM demodulator/detector), a 260 Hz Low Pass (LP) filter is required to filter CTCSS audio tones (67 – 254 Hz) going into the CTCSS decoder. This reduces the potential for incoming speech to generate false decodes or to ‘talk over’ and block CTCSS decoding.

A second filter is also required, a 300 Hz High Pass (HP) filter. This filter passes the receiver low level audio from the discriminator to the radio’s audio amplifier and speaker. It prevents any CTCSS tone modulation from being heard by the user in the receiver's audio. If a HP filter is not used, or if the radio filters are inadequate, a low level tone will be continually and annoyingly audible in the background.


Figure 4 : CTCSS decoders benefit from audio filtering to extract CTCSS tones from the receiver IF detector (discriminator) while other filtering ensures CTCSS tones cannot be heard in speech

Some lower cost commercial 'add-on' CTCSS dencoders assume the presence of adequate HP filtering in the transceiver. Fitting such decoders to equipment lacking filters can lead to some unpleasant surprises. This has led to some amateur radio users believing that CTCSS tones above 200Hz are 'bad' and unusable. In commercial applications, such tones are routinely used without any problems.

Finally, there’s audio muting. Some CTCSS decoders assume the radio has audio muting circuits to control the receiver audio depending on the presence or absence of the correct CTCSS tone. These are commonly present in commercial radios but not always present and as easily accessible to the decoder in legacy amateur radio transceivers. Ideally, then, the CTCSS decoder should also include provision for optional control of receive audio muting. Some surprisingly expensive CTCSS decoders do not include this feature.

In conclusion, it’s a difficult technical challenge to design an effective, reliable CTCSS dencoder with all of the required features at a suitable cost and in a satisfactory size. In particular, it’s also very tough to get CTCSS decoders working reliably across the range of conditions encountered in the field.

But it can be very satisfying to achieve that objective.

CTCSS Decoder Applications

There are some interesting applications for CTCSS dencoders in amateur radio. One example can be seen near where I live. A nearby ‘multi-mode’ VHF amateur radio repeater handles voice and data calls. As usual, these calls must use a valid CTCSS tone for access. However, only voice calls through the repeater are retransmitted along with the CTCSS tone. Data calls are re-transmitted without any CTCSS tone.

This turns out to be very useful. If you do not wish to hear the occasional shrill sound of data bursts while you are listening for your friends to call you on the repeater, you can enable your mobile or handheld receiver’s CTCSS decoder for that CTCSS tone (e.g. 123.0 Hz). The you’ll only hear the voice calls. Data decoding and display will continue to occur in the background, as usual, of course.

Similarly, if your legacy transceiver’s receiver suffers from nearby interference, with the squelch opening the receiver audio intermittently, adding a CTCSS decoder will often restore the transceiver to useful operation. Presence of the CTCSS tone is required on the repeater transmitter, but that’s rarely a problem. Many amateur radio repeaters transmit the CTCSS tone precisely for this reason.

So, if you are wanting to restore that ancient Sumerian era VHF handheld or an elderly Jurassic period UHF mobile transceiver for such situations, you may want to fit a CTCSS dencoder.

And here’s a further example: In professional two-way radio systems, it’s occasionally useful to access remote radio links or specialised services and functions by sending a specific CTCSS tone. The control equipment in the radio system must then detect each CTCSS tone to carry out the required function. Most ‘tone panels’ do not provide that level of functionality so CTCSS dencoders can be used for this purpose.

Where can I Buy a CTCSS Dencoder?

These days, with CTCSS functionality built into most equipment, CTCSS dencoders for use with legacy mobiles and handhelds (or commercial VHF/UHF links!) are more difficult to find. They are still available but often only at very considerable cost.

On further investigation, some rely on the transceiver having certain features, like good filtering. Others only support some tones. Interestingly, some CTCSS decoder specifications for transceivers with dencoding built-in openly state they can't always reliably detect all tones or that some tones will experience 'falsing' from adjacent tones. Say, what?!

At time of writing, in late 2020, I did manage to locate a few compact CTCSS dencoders that are still available. These ranged in price from US$40 to US$200 each, plus shipping.

At these prices, if you need a CTCSS dencoder for that elderly transceiver you want to restore, my guess is you may decide to buy a new radio instead. It’s possible that could be a cheaper and faster solution!

Can I Build my Own CTCSS Dencoder?

Well, yes. Ah, maybe. Actually, it depends....

It is possible to build an analog CTCSS dencoder with a number of quad op-amps and a good handful of passive components. There are several solid designs which work well. However, it is essential to use high quality metal film resistors and a few temperature stable (NP0) capacitors in the right places to achieve reliable results.

An analog dencoder built using these designs is a relatively large device, even if you are building it in SMD. The resulting decoder is somewhat inflexible and can be difficult to align. If you need to change your CTCSS tone for use with different repeaters, this approach quickly becomes impractical.

You could build a digital CMOS-based CTCSS dencoder. Again, several designs are available. One uses about ten standard CMOS chips and a few op-amps, another uses nearly twice that number of parts while supporting some extra features, each accompanied by a substantial handful of passive parts. Performance is very good, but it’s neither a cheap nor compact approach. It's unlikely to fit in a handheld.

It’s possible to use one of a number of proprietary CMOS CTCSS dencoder chips. These can be expensive and they can disappear without trace after a few years. Most require a supporting microcontroller for tone selection as well as some external interface components.  Performance is usually acceptable although some do not achieve the performance of multi-chip CMOS designs or the better microcontroller or DSP-based designs. Some require audio buffering, switching and filtering. The result is quite compact, especially in SMD.

What about a software-based microcontroller or a DSP-based dencoder? Many commercial products have been designed over the past decades. See Figure 3, for example. Considerable effort has been expended on protecting much of this with patents over the years. Most of these products have disappeared as the functionality has been integrated into handhelds, mobiles and base station equipment.

Interestingly, and aside from software written for integration into Software Dependent Receivers (SDR) or related PC applications, and the small number of CTCSS dencoders currently available on the market, as far as I am aware, no full-feature 50-tone capable software-based CTCSS decoder (or dencoder) has ever been published as a DIY project. (Well, OK, there are one or two feature-limited kits, and maybe I have missed a DIY design published in Russian or some other language in which I may not yet be fluent, but....)

Perhaps this reflects the difficulty in designing a good flexible CTCSS tone decoder with the necessary performance.

Features of a Software-based CTCSS Dencoder

What features would be useful in a CTCSS dencoder? Here’s my brief list:

A few things appear unnecessary:

Conceptually, a CTCSS decoder with these features might look something like conceptual thru-hole and SMD designs illustrated in Figure 5.

           
Figure 5 : Draft concept through-hole and SMD designs for a CTCSS dencoder

How Much Would a Dencoder like this Cost?

The kit of parts to build such a software-based microcontroller CTCSS dencoder including a PCB might sell for about US$20. That looks suitably below the cost for the few remaining commercial dencoders.

But is there any demand for such a dencoder at this price? A simple decoder-only design would be cheaper, but such a basic CTCSS decoder, with or without a small display to show the selected tone, is unlikely to be of much interest. Or is it?

And then there are those extra postal costs. The postal service here charges very high prices for their highly COVID-variable airmail deliveries. (Curiously, their mail delivery performance seems to fall in rough inverse proportion to their rising prices) I think it could cost as much as $US8, and probably more, to send a kit of parts to the US, Australia, France, Germany or the UK. It’s probably a similar situation in other countries.

Ensuring a design is not immediately copied and sold by third parties is also a problem I've encountered a number of times, This limits the way the software for the design can be made available to builders. Also, at these prices,with the associated problems of stocking up parts for a kit run along with the process and costs of selling and supporting the kits, and in the face of uncertain mail deliveries, I wonder if there is any viable way to make a CTCSS dencoder like this these days.

I'm really uncertain about this. Perhaps there’s a sensible approach to all this that makes sense…


Thoughts and Comments

Let me know via email if there is any interest in this design or if you have any suggestions relating to the various questions raised in this discussion piece.






Want to go back to the main page? Click here to return directly.