Two Simple CTCSS Encoders

Main

Version:

Oct 28, 2021:
Revised: v1.3

Two Miniature Crystal-locked CTCSS Tone Encoders

Do you have an elderly FM transceiver that needs CTCSS? Here is a very low cost versatile, accurate and super-stable CTCSS tone encoder module which should be ideal for your requirements. Two versions are described here, both using the same tiny single-sided PCB - The first is a BASIC encoder allowing link selection of one of four programmed tones, and the second is a MULTITONE encoder with Reverse Tone Burst allowing pushbutton selection of one of fifty CTCSS tones.

NEW: Files for FIVE commonly used sets of four amateur radio CTCSS tones are now available in the DOWNLOAD section below for programming your ATtiny85 chip (Standard Intel HEX format for use with most programmers)

I have also corrected an error with the 85.4Hz tone in the pushbutton version (Thanks Ludvik!

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.

A continuous low level audio tone in the range of 67 – 254Hz is mixed with audible 300 – 3000 Hz speech when transmitting. The transmitted CTCSS tone is detected by a CTCSS decoder in the matching receiver. This “unsquelches” or unmutes the receiver to allow people listening to the receiver to hear the speech. A high-pass filter in the decoder ensures the CTCSS tone is inaudible to users. In North American markets, this system is sometimes called “Private Line” or “Channel Guard”.

Figure 1 : This basic version of my new compact CTCSS encoder module (Type A) allows selection of one of four programmed CTCSS tones at power-up

CTCSS is often used in shared repeater systems to allow channel sharing and privacy between groups of repeater users with improved repeater and frequency utilization. A “repeater” is a full-duplex transmitter and receiver often located on a high hill or prominent building in order to provide expanded two-way radio system coverage.

Each group of users sharing the repeater is assigned a specific CTCSS tone by the repeater operator or owner. Each user’s CTCSS decoder is configured to detect only that user group’s tone. This tone decode signal is used to enable the receiver audio in user radios. In this way, each user only hears calls for their group. The calls between other users on the shared repeater remained inaudible. A ‘busy’ light on the radio indicates when other users are using the repeater. This also prevents one user group transmitting over top of another.

This approach significantly increases channel occupancy and leads to improved spectrum efficiency.
In a typical repeater, a CTCSS detector detects the CTCSS tone to generate the push to talk (PTT) signal to ‘repeat’ the incoming received audio.

Figure 2 : The CTCSS encoder generates a sub-audible tone. This is added to the microphone audio signal to modulate the amateur radio FM transmitter

Some repeaters also generate the PTT once the incoming signal has reached a suitably high signal strength level regardless of the presence of a CTCSS tone. This arrangement shown in the block diagram of a repeater illustrated in Figure 3.

Figure 3 : A typical repeater system expands two-way radio coverage. CTCSS is used to reduce interference, and to improve spectrum efficiency through channel sharing in commercial networks. Repeaters may use a common antenna with special ‘duplexer’ filters or separate antennas as shown in this diagram.

CTCSS can also improve VHF repeater receiver immunity to interference. This is a common reason for using CTCSS on amateur radio repeaters where, normally, everyone hears everyone else using the repeater. In amateur radio repeaters, therefore, it is more typical to find only a CTCSS tone encoder fitted to every user’s FM transceiver. A matching decoder in the transceiver is not required because everyone wants to hear everyone else using the local ‘ham’ community. Usefully, however, potential interference from, say, remote repeaters reusing the same frequency assignment, but using a different CTCSS tone, will be significantly reduced.

CTCSS Specifications

CTCSS tones generally still comply with the earliest EIA standard RS-220 first released back in April 1959. This specification originally defined 37 CTCSS tones ranging from 67.0 to 254.1 Hz. These tones were later augmented by up to 13 (or more) non-standard tones by some vendors. A few amateur radio users even added a few special tones of their own for use on privately owned repeaters.

Back in those distant times, CTCSS demanded a remarkably high level of performance from encoders and decoders. Tones must be within +/-0.5%, with harmonics less than 10%, for example, across a temperature range of -30 to +60C and across the expected typical supply voltage range of, say, 11.5 to 14.5V for a mobile transceiver. When enabled, tones must be generated within 50mS.

To achieve this very narrow bandwidth and high stability, encapsulated mechanical vibrating reeds were originally used. These were similar to miniature musical tuning forks. Despite their simplicity, they were effective in delivering the required accuracy and stability. However, their operation gave rise to some other interesting (and useful!) CTCSS features such as Reverse Tone Burst ("RTB").

The main problem encountered with the ‘tuning fork’ mechanical decoders was their tendency to keep vibrating long after the incoming tone had disappeared. You can hear this with musical tuning forks. They keep vibrating long after they have been hit. This property made reed-type CTCSS decoders turn off very slowly.

To resolve this problem, the encoder’s tone was inverted when the PTT was released by any user. This changed the phase of the output tone signal by 180^o producing a significantly faster shutdown of ‘tuning fork’ oscillation (and thus CTCSS tone detection) through the use of a signal specifically designed to damp the ongoing mechanical oscillation quickly.

Here’s how RTB affects the CTCSS tone. This example shows RTB injecting the 180^o phase change when the PTT button is released. The phase shift is injected and transmitted immediately, with the tail of the CTCSS tone being sent until the modulated transmitter output ceases some time later. This tail time may be anywhere from a few tens of milliseconds to up to 500mS depending on the transmitter/transceiver design and configuration.

By the way, the CTCSS encoder can continue to operate during receive and therefore it can be powered from a continuous 3 - 5V rail or be powered from a 3 - 5V rail which is only available during transmit.

Figure 2 : Reverse Tone Burst implements a phase shift in the outgoing CTCSS when the user’s PTT is released.

While most RTB signals shift the output phase by 180^o, some vendors used 120^o which they claimed more accurately damped their tuning fork oscillators, thereby improving overall system performance. There is little evidence to support this claim, few (if any) decoders appear to support it specifically, and the majority of digital CTCSS decoders may not operate correctly with such vendor-specific features.

Typical digital detector software in modern (say, post-1990) digital-based CTCSS decoders can continually monitor for any 180^o phase change and promptly shut off the repeater transmitter when it is detected. This is very effective at removing the otherwise irritating noise ‘tail’ which otherwise occurs at the end of every call using the repeater.

These days, crystals are almost always used as the reference for tone generation and detection, almost always providing superb accuracy and stability. Low cost IC regulators provide the necessary supply rail performance. Similarly, RTB is implemented in many good transceiver encoders.

CTCSS remains in extensive use, even today. Commercial repeaters commonly use 5 to 15 CTCSS tones on each shared repeater channel to serve up to 120 users/channel. Every mobile or handheld FM transceiver I came across in a recent wide-ranging market study of two-way radio products included CTCSS as a standard equipment feature, regardless of equipment price.

Incidentally, there is/was a digital variation of CTCSS developed much later called Digital Controlled Squelch (DCS). Relatively rare, the 83 or 104 ‘tones’ or ‘codes’ that system used were digitally generated using 23-bit group addresses or ‘codewords’ using FSK FM carrier modulation. Opinion varied in the industry on the exact number of DCS codes available from the potential set of 512 given the potential for bit inversion and bit alignment errors in DCS decoders. However, it was possible to use up to 100 DCS codes in some locations.

CTCSS and Amateur Radio

Many current amateur radio VHF FM repeaters require CTCSS, as mentioned earlier, primarily to improve resistance to interference. Where I live in New Zealand, a CTCSS tone of 123.0Hz is required on my transceiver's transmit signal to access my local 2m amateur radio repeater. I needed to implement a CTCSS encoder for several of my VHF transmitters, a couple for old FM transceivers being restored, and one for a new homebrew project.

A decade or more ago, CTCSS encoders, or more often, “dencoders” (a board combining both the CTCSS encoder and decoder in one module) were commonly available at very modest cost from many sources. However, with CTCSS now a standard feature on all new products, the need for separate encoders or dencoders has long disappeared. Consequently, I had no CTCSS encoder modules in my parts bin, and those available for purchase featured surprisingly high price tags typically ranging from US$25 to US$50, or more.

I searched around for a suitable design to build. Some elderly analog designs can still be found using legacy chips like the ancient NE567 or (even!!) the NE555. Suffice it to say, these designs would never provide the required performance. There were several potentially very good analog opamp-based designs available where careful component selection can give excellent results. However, these required a lot of parts and careful alignment. Other designs featured excellent performance but went overboard on complexity. One relatively recent commercial design I came across featured almost 250 components with nearly a dozen ICs!

Looking still further, I found a few interesting microcontroller-based designs. Several of these relied on the chip’s internal RC oscillator. That’s unlikely to be successful if you are looking for long term reliability since the microcontroller’s clock frequency can vary significantly with temperature and supply voltage. Yet another design used an external crystal oscillator as the microcontroller’s clock, but that single part consumed over forty times the current drain of the associated microprocessor! Not a great encoder to fit to a low current heldheld radio.

So, yes, I decided to design and build my own CTCSS encoder. Less than a day later, a multi-tone capable CTCSS encoder compliant with EIA Standard RS-220 was alive and well on my bench.

Encoder Hardware Description

In my enthusiasm, I ended up developed three different encoders. They all used the same basic hardware. The Basic design (Version A) is the one shown pictured at the top of this web page. It supports four selectable CTCSS tones. These are selected using PCB jumpers. These jumpers are read by the microcontroller when the power is turned on.

As soon as I finished this first encoder, a few ideas came to mind about other possible variations. The next encoder to be developed was an enhanced multitone version (Version B). It provides simple pushbutton tone selection of any of 50 CTCSS tones. It also supports Reverse Tone Burst (RTB) and user programmability.

Having done that one, I then designed a third version, this time featuring a rotary encoder for tone selection and an OLED display to show the selected tone. It also uses the same PCB. However, unless there is particular interest in that design, I won’t it further here. It's more useful for test bench use, I suspect.

A low cost ATtiny85 microcontroller was used for all of these designs. It’s certainly possible to implement the first two versions using an ATtiny13, but as I happened to have some of the Tiny85 chips on my bench, so that was what I used.

Here is the schematic of the Basic CTCSS encoder, Version A.

Figure 4: Schematic of Version A - the Basic CTCSS encoder

This module features fewer than a dozen components. It can be operated from a regulated voltage of 2.7 to 5V. Tests on the prototype module were carried out using both 3V3 and 5V supplies.

The poor accuracy of the internal RC clock of all microcontrollers when exposed to manufacturing, supply rail and temperature variations, coupled with the Atmel-designed-in clock jitter in most of the Atmel processor family, required the use of a crystal.

Selecting the appropriate crystal frequency requires a balance between considerations of cost, current consumption and tone resolution. An 8MHz crystal was used here. These are inexpensive and widely available, and the desired tone resolution of 0.05Hz was readily achieved by the software. Temperature performance is consequently well within RS-220 limits.

The use of an 8MHz clock does increase current consumption over that for, say, a 1MHz crystal. It draws about 5mA versus 1mA at 1MHz. However, this difference is not particularly critical in this application, the related transmitter always consuming orders of magnitude more current, and 1MHz crystals, for example, are generally harder to find.

The tones are generated using direct digital synthesis (DDS) methods similar to those used in my audio test generator described elsewhere on my website. In contrast to that design, however, this design generated a pulse-width modulated (PWM) output tone via a single output pin on the microcontroller. The 64 kHz PWM ‘carrier’ containing the modulating CTCSS tone can be easily filtered using a single resistor-capacitor low pass filter (R1, C2).

The resulting sinewave is very clean, with less than 1% distortion, and the 64kHz carrier is more than 40dB below the wanted CTCSS signal. No evidence of the PWM carrier could be detected on the transmitted FM signal with a spectrum analyzer.

This filtered signal is attenuated further using a 10:1 resistor divider, if desired, and the PCB preset allows further fine adjustment across each range. If R2 (100k) is replaced by a wire link, then the full output may be used. Typical levels are detailed in Table 1.

Table 1: The output of the CTCSS tone encoder module can be varied over a
wide range but the maximum output level depends on the supply voltage

If DC isolation is required, it is possible to substitute a 4.7uF electrolytic capacitor for R2 (100k). This modification holds true for the other version(s) of the CTCSS encoder described here for situations where DC isolation is required in the associated transceiver or equipment.

Figure 5: Simply replace resistor R2 on the PCB with a 4.7uF capacitor if DC isolation is required

The maximum time for the tone to start is also defined in RS-220 (<50mS) and this design easily achieves the specified value. In fact, the measured time for the prototype to start sending the CTCSS tone after turning the power on is 8mS.

Tone selection on the Basic Version A encoder is done using two jumpers (JMP A and JMP B). The CTCSS tones chosen included my local CTCSS tone of 123.0Hz, and three other tones across the 67 to 254 Hz range. The tones are shown in Table 2.

Table 2: Version A Tone Selection

Note: This, and a number of other tone sets for this encoder, are now available in the Download section below.

Version B: Enhanced Multitone CTCSS Encoder

The second version I designed, Version B, uses the same basic hardware design but changes the jumper inputs into inputs for, firstly, the tone selection pushbutton and, secondly, an optional PTT input. The PTT connection is only required if you wish to implement RTB.

Tone selection is done using a small momentary pushbutton. This allows any of the 50 ‘standard’ CTCSS tones to be selected. One tone is stored in EEPROM, and this is tone used when the CTCSS encoder powers up. If the pushbutton is held down following selection of a different tone, that selected tone will be saved into EEPROM for use at any successive power-on.

The current version of software stores 123.0 Hz as this default EEPROM-stored tone. Actually, DDS data for all 50 tones are saved as a table in the program flash memory of the ATtiny85. A table pointer which indicates the address of the data in the table for 123.0Hz, tone #18 of 50 tones, is actually stored in location 001 of the EEPROM.

Pressing the pushbutton briefly selects the next tone. At the top of the range, 254.1 Hz, a further brief press will select 67.0 Hz, the lowest tone.

As noted above, if the pushbutton is now held down for more than one second, this currently selected tone will be permanently saved into EEPROM. This tone will then become the 'default' tone generated whenever power is reapplied. Internally, the CTCSS table pointer value stored in EEPROM is actually changed rather than the tone itself, but the result is the same.

Figure 6: Changes for Version B - the Basic CTCSS encoder

The 50 tones available are:

Table 3: Version B Tone Selection

While this set of tones is widely accepted as the "standard" CTCSS tone set in the industry, the EIA/TIA industry standard only specifies 38 of these tones. The European ETSI standard TS 103 236 similarly only specifies 39 tones. The other tones were added by vendors to form this wider set of tones, giving a set of tones which are all reasonably equally separated across the 67 – 250Hz range. The 254.1 Hz tone was a relatively late addition to this set when most commerical transceivers and repeaters were found to adequately filter it out from speech.

For this reason, it is possible that you will encounter a digital decoder which will not decode all or some of these 50 tones. Curiously, most adjustable legacy analog op-amp based designs, such as those made by (or copied from) Selectone, for example, can be set to any of these tones.

Some UK analog FM PMR446 transceivers add a further tone just above this set, and some military systems use 150.0Hz. Be aware that using 100.0 Hz or 150.0 Hz in markets with 50 Hz AC mains systems will result in poor performance due to the presence of low level 50 Hz and related harmonics on transmitted signals.

Finally, some Chinese transceivers also use 55Hz for a tone-based squelch-tail elimination scheme. Noe of these more unusual CTCSS tones have not been included in this version.

Reverse Tone Burst (RTB) is also supported in this version.

Software

The software for the Basic and the enhanced Multitone versions was written in assembly code for speed and efficiency. It’s feasible to revise this software slightly to permit the software to run in an ATtiny25 or 45, and possibly even in an ATtiny13. I’ve not done these other versions because the cost difference between these devices and the ATtiny85 is minimal. It also made it easier to migrate both designs to the display/rotary encoder version described elsewhere on my website, and to a later DIP-switched 50-tone CTCSS encoder.

Decoding CTCSS Tones

These versions of this design only support tone encoding. Specialised hardware and/or software is used in most modern CTCSS decoders to accurately and reliably detect CTCSS tones. These feature tone detection bandwidths ranging from 2 to 8Hz, with detection times typically ranging from 200mS to 130mS respectively.

While CTCSS inter-tone spacing is typically 3 to 5Hz, most repeater systems which use multiple tones to support multiple fleets or user groups select a set of tones for each shared channel to provide much greater spacing between each tone. Typically, each CTCSS tone for each of the groups sharing the repeater will be separated from the next group’s tone by 10 to 20Hz, and often more.

Construction

I’ve designed a small single-sided 25 x 25mm (1” x 1”) PCB to make construction and installation easier. Gerber and PDF files can be obtained from the Download section below. It could be made smaller using SMD parts, but the design described here makes it much easier to make the PCB at home, if you prefer, as well as easing the sourcing of suitable parts. It also makes it easier to build.

Figure 8 : The CTCSS encoder may be constructed on a small 1”x1” PCB

I had a set of PCBs made by JLCPCB and, as usual, the service was swift and the result of a very high quality. (Note: I have no relationship with JLCPCB – I am just a very satisfied customer) I also made several variations of the PCB design at home to validate the layout.

The PCB is small enough to be fitted in a handheld transceiver while also providing for each of the versions described above.

As an aside, I used to obtain all of my PCBs from such South Asian suppliers via air mail before COVID-19. Now, with variable shipping delays and substantially higher delivery costs, I am increasingly relying on making my own PCBs, reserving the South Asian manufacturers for PCBs that are too complex for me to make with my laser-based PCB fabrication system.

Oddly, the longest delay in the delivery chain has not been with PCB manufacturing or the internal Chinese mail system or, these days, with the ships or aircraft that bring freight from China to New Zealand. Consistently, the longest time in the entire delivery process comes from New Zealand Post, the postal service provider here in New Zealand. This delay is unpredictable and often lengthy, with a recently added variable of 'no delivery' where the local postal delivery person periodically delivers the mail to the wrong address. There's apparently no way for them to recover these misdelivered packages, they provide no explanation nore, more importantly, any compensation. That's become a costly problem.

NZ Post used to be a world leader in mail delivery. I guess they still are. Now, they can be included as one of the world's slowest and least reliable mail services. Having lived in many third-world countries over the past few decades, I can base this opinion on extensive experience with other appalling mail service providers. So, I am no longer sure when (or if) anything will arrive from China now. Fortunately, this small single-sided PCB can be made in almost any home workshop.

With that rant out of the way, let's get back to the construction:

Begin construction for all versions by mounting the resistors and capacitors. I would suggest installing an IC socket for IC1. 0.1” headers and connectors may be used for J1 and J2 (J1 is for the DC supply, while J2 is for the CTCSS tone output) or the external wiring may be soldered directly to J1 and J2 PCB pads.

Install the crystal. It can be fitted either way around.

The next stage of the construction depends on the version being built.

Version A: Basic CTCSS Encoder

Add 0.1” 2x1 header pins in the locations for jumpers A and B on the PCB. Alternately, if you are only using a single tone, you can replace the jumpers with simple wire links.

Version B: Enhanced CTCSS Encoder

Connect a pushbutton via short connecting wires to the PCB pads for Jumper A or connect the pushbutton via a 0.1” header and matching connector. If reverse tone burst is to be used, connect the radio’s PTT via a diode (D1). This diode is mounted externally to the PCB.

(For those interested, the other version I designed, the one using a rotary encoder and OLED display, uses the same PCB)

Completing Either Version:

Once you’ve programmed your ATtiny85 (See the next section) and inserted jumpers or pushbutton or display, as required for the version you are building, then insert the IC into its socket carefully and apply power. You should find your CTCSS tone present on J2. The level can be adjusted with RV1.

The PCB is usually best mounted using double-sided adhesive foam. It's a common method used in the two-way radio industry, and it makes for a remarkably robust and swift installation.

Programming the ATtiny85

See the other pages on my website describing ATtiny85 programming. One example is found here. The HEX file for programming the chip can be downloaded from the Downloads section below.

After programming the flash memory with the HEX file, program the ATtiny fuses as follows:

Version A: Basic 4-tone Encoder (Jumper Tone Selection)
Extended:    0xFF
High:             0xD7    (save EEPROM)
Low:          0xEF     (for external 8MHz crystal)

Version B: Enhanced Multitone Encoder with User Programming and RTB
Extended:    0xFF
High:             0xD7    (save EEPROM)
Low:          0xEF     (for external 8MHz crystal)
AND
EEPROM Location 01: Save a single byte HEX value containing the table pointer value for the tone you wish to use on power-up into the ATtiny EEPROM .

To determine this value, look up the tone you wish to have as the initial default tone (You can change it later at any time using the pushbutton). Since the internal pointers start from zero, subtract 1 from the Tone# shown in Table 3 (above) and store this number in its equivalent HEX value in location 01 of the EEPROM e.g. Store the value &H12 (i.e. 18 in decimal) for 123.0 Hz

Parts List

All Versions:

For Version B, add the following parts to the parts list above:

The estimated cost of the parts for the basic or enhanced multitone CTCSS encoder, including the PCB, is under US$5 at time of writing (Early 2020).

Installation and Alignment in FM Transceivers

The installation of the CTCSS encoder will depend on your transmitter or transceiver. Some equipment have inputs identified for injecting CTCSS tones. Where this does not exist, identify the path taken by the microphone audio to the modulated crystal oscillator or synthesizer. That’s where the CTCSS tone will also be injected.

Here is a photo of one of my encoders fitted to a 35 year old Tait T530 FM transceiver which has been returned to service on the 2m VHF amateur radio band. The added CTCSS board is the pale coloured PCB at centre left.

In this case, installing the basic CTCSS board was very easy. The radio was designed for commercial two-way radio service with CTCSS connection points clearly identified in the service manual. All it required was to wire the CTCSS board tone output to the "CTCSS Tone In" pin and adjust the level on the CTCSS board for the correct deviation. The only additional hardware required was a small Zener diode supply for the encoder. This is shown in Figure 10.

I fitted the Version B software on this module although, at this stage, I have not wired in the PTT connection to give RTB nor the front panel CALL momentary switch (available as standard on the front panel of the basic Tait T500 series radios for just this sort of use) to the Tone switch input on my CTCSS board. Both connections are very easy to add into this radio at any time.

When wiring the board into other radios, where such interface connections are not clearly defined on the radio schematic, it’s often possible to simply inject the CTCSS tone, for example, at a point just after the microphone gain preset potentiometer, as close as possible to the modulating varicap diode or phase modulator.

Take care to connect the appropriate +5V or +3V3 supply to the encoder board. Here is a diagram showing the connections for this Tait T530 transceiver and the power supply modification I needed. I added a 270 ohm 1/4W resistor and a standard 4.7V 600mW zener diode to provide the regulated supply of around 5V. Using a zener diode regulator adds a further 5mA or so to the CTCSS encoder load of 8mA.

Figure 10 : Interface example for the Basic CTCSS module. This is the approach I used for my elderly Tait T530 transceiver which covers the 2m VHF amateur radio band. The DC isolating capacitor noted earlier was substituted for R2 on the module when I installed it into this transceiver.

On 25kHz channel repeaters, microphone audio is usually set to give about 3kHz average deviation and about 4.5kHz peak modulation. The CTCSS tone should also be adjusted using the preset on the CTCSS board to give 500Hz deviation. On 12.5kHz channel bandwidth systems, modulation settings should be 50% of these values.

After alignment, a voice call to another licensed user can verify that the CTCSS encoder is working correctly.

I also fitted another of these encoders to an old synthesised FM amateur radio transceiver that was built from a kit. In that transceiver, I had to apply the tone output of the CTCSS board in parallel with the microphone audio via a 47k resistor directly at the location on the circuit where the transceiver’s microphone audio modulation is fed into the VCO. This sounds difficult, but it was really very easy to do. It took me only a few minutes longer to add compared with the Tait T530 modification above. Once again, I had to use the zener diode regulator scheme to provide the required 5V supply for the CTCSS encoder from that radio’s regulated 10V supply rail.

Final Comments

CTCSS is a useful and, at times, essential component for both amateur and professional mobile radio. But it has other uses too. One example is in remote control.

Many years ago, I was involved in the design and implementation of a radio-controlled airline freight handling system at one of their large warehouses. Manual 'push and shove' methods had resulted in a growing number of back injuries to their staff.

Changing to motorised control reduced the need for physical freight handling. The new system used a number of small VHF handheld radios each fitted with a CTCSS multitone encoder. A pair of rotary switches selected a CTCSS tone specific to each freight-shifting motor used to handle these standard aircraft containers.

The CTCSS signals received from a VHF receiver and various CTCSS tone decoders were used as inputs to a compact, but very powerful, industrial PLC which directly controlled the motors. There were various safety measures added into the PLC software. It all worked very well, and represented an interesting use of an unusual mix of technologies.

CTCSS tones have also been extensively used to control large high capacity commercial trunking mobile radio systems. Other trunked mobile systems such as TETRA, MPT-1327 and LTR tend to have more extensive features and performance but these are far more costly and complex. These low-end CTCSS trunking systems were ideal for applications on a very tight budget.

This new CTCSS encoder design of mine is similarly quite basic. Despite the small size of the encoders, this low cost module has allowed me to restore several classic (Others might call them ancient!) VHF FM transceivers back into service, quickly and effectively.

I hope you get as much fun and enjoyment out of these encoders as I did in designing and building them.