Menu:

• Main
  

ZL2PD Multi-Map CTCSS Encoder - Emulating CML or MX-Com or Panasonic or Seiko CTCSS Encoders

My DIL switched CTCSS encoder was published in UK's Practical Wireless in June 2022. It permits any of the 50 standard tones to be selected using either the 6-way PCB DIL switch or an external 6-line input. 

I've now developed a new version of the software for this board to  allow it to be used in older FM transceivers from Icom, Yaesu, Kenwood, and Trio. It can replace the tone encode functions in some of those obsolete or hard to find CTCSS chips made by CML, MX-Com, Panasonic, or Seiko.

Introduction

Commercial two-way mobile radio users and many amateur radio operators frequently use CTCSS on VHF and UHF FM transceivers. You can read about CTCSS tones and how they are used here.

Twenty or thirty years ago, if a mobile radio manufacturer wanted an off-the-shelf CTCSS encoder, there were relatively few options. Most used a small range of chips made by CML (UK) or their subsidiary, MX-Com (US), or Panasonic, Seiko, and Asahi Kasei (Japan). Several other companies produced one or two CTCSS chips, but these seem to have met with limited success.

Initially, many of the parts from these suppliers used a 6-line parallel input for tone selection. Later devices used more specialised multi-pin inputs to support an increasing range of features. Along with CTCSS, this interface allowed the configuration of companders, voice inverters, scramblers, and filters that were integrated into these chips.

Many amateur radio FM transceivers from that era (Yaesu, Kenwood, Trio, Icom, etc) used the parallel input chips. If you are looking for one of these parallel-input CTCSS encoder chips for your legacy radio now, or if your CTCSS encoder goes faulty, they can be hard to find and very expensive.

Replacing other CTCSS Encoders

The design described here allows my parallel-input CTCSS encoder to replace the CTCSS encoder functionality in many of these older chips. Usually, the CTCSS tone generation (encode) feature is the only function used by hams. (If you want to learn about CTCSS dencoders - CTCSS tone detection and encoding in one device- then you can find some information over on this page on my website)

These devices are quite difficult to replace with my other designs unless you only require one or two CTCSS tones. The relationship between the 6-bit tone selection lines on these older chips and the CTCSS tones they supported was anything but logical or sequential, and far from comprehensive. Each manufacturer used something different which required me to undertake a extensive study into how the addressing (i.e. the chip input selection-to-tone output map) was arranged in each of these chips, the tone set supported in each case, and to identify any limitations which may have existed.

I've managed to focus on what I think are the four most commonly used legacy CTCSS encoders. It's also possible that one of these four chip-emulating schemes supported by my new software may help those trying to replace an unusual chip not specifically mentioned here so I've tried to provide as much detail on each of the four MAPs supported..

First, let's review the hardware used in my CTCSS multi-MAP encoder.

Design Overview

The ATtiny24 (or ATtiny44 or ATtiny84 - Your choice) reads the tone number required from six input pins. The input selection can be provided by a 6-way DIP switch or, if the DIP switch is not fitted, from the inputs set by an external processor or switch. That tone number is used by the chip to identify which CTCSS tone is required.

The schematic is shown in Figure 1.

The actual CTCSS tone generated depends on the device being emulated. This' tone number to CTCSS tone' relationship, or map, is set by a pair of MAP jumpers. These jumpers allow four tone selection 'maps' to be supported by this design. These will be described in more detail below.

The CTCSS tone is generated internally by the firmware. This uses a 24-bit DDS algorithm to deliver the required tone resolution. The 8MHz crystal ensures precision and stability. The software allows the CTCSS tone selection may be changed at any time via input pin interrupts. The chip emulation map bit, however, are only read once each time power is applied.

The ATtiny24/44/84 can also read the PTT status. It assumes an ‘active ground’ PTT, with a series diode to prevent damage from a PTT input which swings between (say) +13.8V and ground. Connecting your transceiver's PTT to the encoder is entirely optional. The PTT input is used to generate the Reverse Tone Burst (RTB), a phase shift on the output tone of 180^o. This phase shift is detected by most repeater CTCSS tone panels and some dencoders. It can significantly reduce the length of any repeater ‘noise tail’, the brief burst of noise at the end of each transmission. 

Capacitor C3 reduces the effect of particularly erratic or worn PTT switch contacts.

The pulsewidth modulated (PWM) sinewave tone generated by the chip is filtered by a simple RC filter. Tone distortion is typically less than 1%. The tone output level can be set using a preset resistor (RV1) on the PCB.

As noted, the tone selection map used (and thus the CTCSS encoder chip to be emulated) is set by the Map jumpers. These are set AFTER the chip has been programmed since these settings share some of the pins used for programming.

The encoder may be powered from a supply rail between 3V and 5V. Do NOT exceed 5V! The encoder consumes about 3.5mA at 3.3V or 6mA at 5V.

'Normal' CTCSS Encoder Tone Selection Map

The complete set of 50 'industry-standard' CTCSS tones arranged in strict numeric order is available in the first of four maps contained in the chip. These match the set used on several of my other CTCSS encoders here on my website. These tones and the input required to select them are shown in Table 1.

I refer to this as the "normal" tone selection map (MAP=00).

Since six input pins supports the selection of 64 tones, a 50 tone map results in some 14 redundant tone input values. A tone of 123.0Hz will be generated for any tone selection outside the defined range in Table 1. Non-standard tones could be supported here should the need arise in future. 

Emulating CML and MX-Com CTCSS Encoders

One of the more popular CTCSS chips was the family produced by UK's CML and their US subsidiary, MX-Com. CML's CTCSS-capable parallel-driven devices do not appear to follow an orderly tone selection mapping arrangement. (That's a polite way of saying the selection arrangement used in these chips appears to have been done by a drunken one-eyed parrot with a dart board in the middle of a tornado at midnight!)

OK, that's a bit harsh. Actually, I suspect this tone selection map was likely the result of difficult chip-level layout contraints encountered by the original designers during the tape-out of CML's first CTCSS encoder chips. Subsequent CML designers must have cursed as they were forced to retain some degree of compatibity in later upgraded devices. (Maybe there is some underlying order to the map that I have not seen. Feel free to email me with the information.)

In any event, to compound this problem for me, it turned out that this company appears to have used at least five(!) different parallel 6-line CTCSS tone selection maps. These are neither entirely consistent nor totally compatible across the CML CTCSS family.

As far as I can determine, the situation can be summarised like this:

As I studied the tone selection mapping required, I tried to determine the CML chip(s) that I should try to support. Also, I tried to determine what I could do to support the missing three tones (or more, depending on the device) of the 50 industry-standard CTCSS tones in CML's chips.

I decided the best solution was to use a CML-compatible encoder input map based on Tone Map E (See Figure 2) which was used by the MX165/465 chips. (This is selected by MAP=01)

There are some issues that result from this choice:

• Selecting a tone selection input value of 0x30 (i.e. &30h or 110000b) on the tone input pins will produce no output. This matches what actually occurs with the MX165/465 chips, too. I mention this here because it otherwise be an unexpected result for some users. Note also that this tone input selection value (&30h) is not supported by the other parallel input devices in the CML family.
  
  
• If my encoder (with MAP = 01 for CML emulation) is used to replace the widely used FX/MX315, then the CTCSS tone of 189.9Hz (the tone generated by my encoder in this CML mode when the input value is &33h) probably won't be accessible because of limitations in the host radio. The original radio, when fitted originally with the CML/MX-Com FX/MX315, would probably not have supported selection of this tone  since this input value (&33h) does not select a valid CTCSS tone in the original chip. (Actually, this selection would have resulted in the output of a 4032 Hz test tone(!) which is a further tone unsupported by any other parallel input CML device!
  
  
• I have made other industry-standard CTCSS tones available in the "CML-compatible" encoder's selection map (See the highlighted tones in Table 2). However, these tones are also outside the defined CTCSS tone selection map for the original CML devices noted in Figure 4. Therefore, it's unlikely these tones can be selected by the original transceiver firmware.
  

The tone selection for this CML-compatible version is detailed in Table 2.


Note: A tone of 123.0Hz will be generated for any tone selection outside the defined range in Table 2.

Emulating the Panasonic MN6520 CTCSS Encoder

Panasonic appears to have only made one CTCSS device, the MN6520. Usefully, the tone selection map for this device is reasonably well-ordered, although it's split into two separate numerically ordered series. Also, a number of the industry standard tones are not supported by the chip.

The MN6520-compatible mode of my encoder (MAP=10) makes it possible to replace the encode functionality of the MN6520 chip. Please note: This design does not support any of the chip's CTCSS decode functions. Fortunately, these are rarely required in amateur radio applications.

This MN6520 mode (MAP=10) also also provides access to the industry-standard tones missing from the Panasonic chip although these may not be able to be selected by the original radio's firmware.

The tone selection for this MN6520-compatible mode (MAP=10) is detailed in Table 3.

Note: A tone of 123.0Hz will be generated for any tone selection outside the defined range in Table 3.

Seiko S-7116A CTCSS Encoder

In marked contrast to the other manufacturers, Seiko's S-7116A encoder has the CTCSS tones selection arranged in numerical order. Uniquely, it also includes some audio tones ranging from 500 to 2975Hz for use in other applications.

The S-7116A-compatible mode (MAP=11) makes it possible to for my encoder to replace the CTCSS features of the S-7116A device. This mode does not support any of the additional audio test tones. Instead, and in order to provide access to the full set of industry-standard codes (potentially, anyway - It depends on the original radio's firmware), the missing CTCSS tones in the original Seiko device are supported by selection addresses which were originally used by these unusual audio tones. These other CTCSS tones may not be able to be selected when using the original radio's firmware.

The tone selection for this S-7116A mode (MAP=11) is detailed in Table 4.

Note: A tone of 123.0Hz will be generated for any tone selection outside the defined range in Table 4.

Building the Encoder

The single-sided PCB is designed for through-hole components and measures less than 40mm (1.5") square. That allows the PCB to fit into most legacy equipment with ease. While a 6-way DIP switch is preferable and was used with the prototype, 8-way switches are more commonly available and can be less expensive. The PCB allows for both types.









Figure 4 : The PCB's solder-side layout can be seen here. Right-click on this image to see it at full resolution or to download the JPG image to make the PCB at home. The PCB measures 37.1 x 38.6mm (1.46" x 1.52").









If the encoder is to be used with an external tone selection switch or an external processor's tone selection output pins, the ATtiny24 / 44 / 84 pins must NOT be subjected to voltages beyond the ATtiny's supply rail voltage. Usually, that's either 3V or 5V depending on your supply rail. An external switch needs only ground any pin requiring Logical 0. The other pins are internally tied to Logic 1, and pins requiring a Logical 1 input may simply be left open-circuited. If they are pulled high (i.e. Logic 1), this voltage must not exceed the ATtiny's supply rail.

Don't forget to install the jumper under IC1 before installing the socket for IC1.

Programming

The 6-way connector (J4) is used to program the ATtiny24/44/84. Once the firmware HEX file is programmed into the chip, the fuses should then be programmed.

The ATtiny fuses must be programmed as follows:


Note: This configures the ATtiny to reconfigure the Reset pin (PB3 / pin 4) as an I/O pin. If you wish to program the chip again in future, a HV programmer will be required to reset the fuses first.

After programming, pins on J4 are used to select the required MAP setting. This is shown in Figure 5. One jumper can be seen fitted in the photo of the prototype at the top of the page.



 

Installing and Using the CTCSS Encoder

Assuming the programming has been successful, you can now power up the board, select the required tone and tone selection input map, and verify it is working correctly before installing it in your transceiver.

Installation will depend on the specific hardware of your transceiver. The transceiver's service manual should prove a useful guide.

Figure 3 shows the PCB location for a DIL switch. In the photo of the prototype at the top of this page, you'll see I fitted an 8-way pin strip instead. This allows for a neater installation in the transceiver using a single ribbon cable.

There are two free pins on this 8-way pin-strip. We can connect 5V and a ground to the CTCSS encoder using this connector. Figure 6 shows the two jumpers which are added under the PCB  for this purpose.



Figure 6 : Two short jumpers can be added to allow a single cable to be used when installing the encoder in a transceiver. Jumpers connect the supply rail and a ground to the encoder.


As can be seen, one of the unused eight DIL switch pins is strapped to the PCB's ground. The other unused pin at the opposite end, the pin adjacent to pin 14 of the ATtiny, can be tied to the DC supply under the PCB. This allows the 8-way pin strip to carry all the necessary connections on one cable to the radio.


The optional PTT connection can be wired into the transceiver separately if required.

Downloads:

Software: Email me for the ZIP file which includes three HEX files for programming an ATtiny24 or ATtiny44 or ATtiny84 chip. In the email, ask for the software for the multi-MAP CTCSS encoder that emulates legacy encoders. Also, please note in your email that the software is for your personal use. My email address is on the main page of this website.

(A number of my designs have been copied and sold by others as their own product without credit or reference to me or my website and this has forced me to adopt this tedious procedure)

PCB-Gerbers: This ZIP file contains the Gerber industry-standard file for the single-sided PCB.

PCB-Images: This ZIP file contains the PDF/GIF/JPG copper-side image file and layout diagram for the single-sided PCB.

Third party products and brands and the intellectual property contained therein or associated with these are retained by their respective copyright holders. No claim over these hould be inferred or implied by the material published herein. 

This material is provided in good faith and without warrantee or guarantee of any kind including over any use made of this material and any outcome of that use based on this or any associated detail which should be understood to be undertaken entirely at your own risk. 

Ownership and copyright of the intellectual property provided here and contained in the referenced software and hardware design is claimed by Andrew Woodfield ZL2PD. 

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

© 2022 Andrew Woodfield ZL2PD
Template design by Andreas Viklund